Hi,
Can I please get some feedback on some of the opened JIRA issues, such as:
https://issues.apache.org/jira/browse/DROIDS-89
https://issues.apache.org/jira/browse/DROIDS-90
https://issues.apache.org/jira/browse/DROIDS-91
https://issues.apache.org/jira/browse/DROIDS-92
I have gained some experience with droids in the past month, so I can start
sending the patches for these and perhaps add others.
Thanks.

On Tue, 2010-08-10 at 01:06 +0300, Eugen Paraschiv wrote:
> Hi,
> Can I please get some feedback on some of the opened JIRA issues, such as:
> https://issues.apache.org/jira/browse/DROIDS-89
> https://issues.apache.org/jira/browse/DROIDS-90
> https://issues.apache.org/jira/browse/DROIDS-91
> https://issues.apache.org/jira/browse/DROIDS-92
> I have gained some experience with droids in the past month, so I can start
> sending the patches for these and perhaps add others.
> Thanks.

Eugen

I am only peripherally involved in Droids development, but if no one
else steps in, I can commit those patches. The proposed changes seem
reasonable / simple / non-disruptive enough to be committed without a
lengthy review process.

Oleg

Cool, well I have worked on Droids for over a month now on and off, so I
will probably have some other patches in the pipeline when I have time to
formulate them and extract them from my own code. In the meantime, I hope
the patch I have provided is OK (if not, please let me know). About the
other issues, I have not attached patches because I didn't have any feedback
on them. I will start doing that soon. Thanks for the help.
Eugen.

On Wed, Aug 11, 2010 at 4:08 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:

> On Tue, 2010-08-10 at 01:06 +0300, Eugen Paraschiv wrote:
> > Hi,
> > Can I please get some feedback on some of the opened JIRA issues, such
> as:
> > https://issues.apache.org/jira/browse/DROIDS-89
> > https://issues.apache.org/jira/browse/DROIDS-90
> > https://issues.apache.org/jira/browse/DROIDS-91
> > https://issues.apache.org/jira/browse/DROIDS-92
> > I have gained some experience with droids in the past month, so I can
> start
> > sending the patches for these and perhaps add others.
> > Thanks.
>
> Eugen
>
> I am only peripherally involved in Droids development, but if no one
> else steps in, I can commit those patches. The proposed changes seem
> reasonable / simple / non-disruptive enough to be committed without a
> lengthy review process.
>
> Oleg
>
>

Hi Eugen,

I saw some interesting things in the issues created. I will have time this
weekend to review it, maybe you could start to attach some patches for
simple changes so we can review and commit them asap.

Salu2.

2010/8/11 Eugen Paraschiv <[EMAIL PROTECTED]>

> Cool, well I have worked on Droids for over a month now on and off, so I
> will probably have some other patches in the pipeline when I have time to
> formulate them and extract them from my own code. In the meantime, I hope
> the patch I have provided is OK (if not, please let me know). About the
> other issues, I have not attached patches because I didn't have any
> feedback
> on them. I will start doing that soon. Thanks for the help.
> Eugen.
>
> On Wed, Aug 11, 2010 at 4:08 PM, Oleg Kalnichevski <[EMAIL PROTECTED]>
> wrote:
>
> > On Tue, 2010-08-10 at 01:06 +0300, Eugen Paraschiv wrote:
> > > Hi,
> > > Can I please get some feedback on some of the opened JIRA issues, such
> > as:
> > > https://issues.apache.org/jira/browse/DROIDS-89
> > > https://issues.apache.org/jira/browse/DROIDS-90
> > > https://issues.apache.org/jira/browse/DROIDS-91
> > > https://issues.apache.org/jira/browse/DROIDS-92
> > > I have gained some experience with droids in the past month, so I can
> > start
> > > sending the patches for these and perhaps add others.
> > > Thanks.
> >
> > Eugen
> >
> > I am only peripherally involved in Droids development, but if no one
> > else steps in, I can commit those patches. The proposed changes seem
> > reasonable / simple / non-disruptive enough to be committed without a
> > lengthy review process.
> >
> > Oleg
> >
> >
>

Hi,
I have attached patches to most of the issues in JIRA. I will probably
create some more once these are resolved. I am waiting for your feedback on
*DROIDS-89 <https://issues.apache.org/jira/browse/DROIDS-89> *before
attaching any patch, as I am unsure of how much flexibility there is on this
one. Two questions - should I move all of the droids in the test directory
in src? And can I create a package for them or should I follow some specific
standard or convention when I move them?

Moving on from simple renames I will try to focus on a proposal from an
earlier discussion thread: the *Save *handler has an *outputDirectory
*property;
that only allows the files to be stored in a single place, with no
additional rules applied to this process; the process of choosing the path
of the file can be more flexible, based on client logic; this can be done
via a simple object that would decide the path based on that logic - *
PathDecider*; also this would get rid of the path related logic from this
handler for a clear separation of responsibilities between deciding the path
where data is saved and actually saving the data.

Also, I understand that there is no specific coding standard or best
practice document for committing into the repository. One possibility is an
Eclipse formatter to make things easier. I am aware that this is IDE
specific, but it doesn't have to be - the coding standards document would be
IDE agnostic, and the Eclipse formatter would simply be there if you want to
use it. Is JIRA the place to start something in this direction?

One last question about dependencies - how flexible are these at this point?
For instance, there may be a benefit from using things like Guava (the
former google collections). I haven't checked what the licence on that is,
but I know it's a core dependency for some other Apache projects (Mahout for
instance), so I guess the licence is OK. Another dependency that may be
easier to work with is SLF, which has some advantages over commons-logging.

These are some specific questions for when you or someone from the community
has time to address them. Thanks for the help. Eugen.
On Wed, Aug 11, 2010 at 11:11 PM, Javier Puerto <[EMAIL PROTECTED]> wrote:

> Hi Eugen,
>
> I saw some interesting things in the issues created. I will have time this
> weekend to review it, maybe you could start to attach some patches for
> simple changes so we can review and commit them asap.
>
> Salu2.
>
> 2010/8/11 Eugen Paraschiv <[EMAIL PROTECTED]>
>
> > Cool, well I have worked on Droids for over a month now on and off, so I
> > will probably have some other patches in the pipeline when I have time to
> > formulate them and extract them from my own code. In the meantime, I hope
> > the patch I have provided is OK (if not, please let me know). About the
> > other issues, I have not attached patches because I didn't have any
> > feedback
> > on them. I will start doing that soon. Thanks for the help.
> > Eugen.
> >
> > On Wed, Aug 11, 2010 at 4:08 PM, Oleg Kalnichevski <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Tue, 2010-08-10 at 01:06 +0300, Eugen Paraschiv wrote:
> > > > Hi,
> > > > Can I please get some feedback on some of the opened JIRA issues,
> such
> > > as:
> > > > https://issues.apache.org/jira/browse/DROIDS-89
> > > > https://issues.apache.org/jira/browse/DROIDS-90
> > > > https://issues.apache.org/jira/browse/DROIDS-91
> > > > https://issues.apache.org/jira/browse/DROIDS-92
> > > > I have gained some experience with droids in the past month, so I can
> > > start
> > > > sending the patches for these and perhaps add others.
> > > > Thanks.
> > >
> > > Eugen
> > >
> > > I am only peripherally involved in Droids development, but if no one
> > > else steps in, I can commit those patches. The proposed changes seem
> > > reasonable / simple / non-disruptive enough to be committed without a
> > > lengthy review process.
> > >
> > > Oleg
> > >
> > >
> >
>

Hi Eugen.

I hope to get some time tomorrow to review the JIRA comments and patches.

2010/8/12 Eugen Paraschiv <[EMAIL PROTECTED]>

> Hi,
> I have attached patches to most of the issues in JIRA. I will probably
> create some more once these are resolved. I am waiting for your feedback on
> *DROIDS-89 <https://issues.apache.org/jira/browse/DROIDS-89> *before
> attaching any patch, as I am unsure of how much flexibility there is on
> this
> one. Two questions - should I move all of the droids in the test directory
> in src? And can I create a package for them or should I follow some
> specific
> standard or convention when I move them?
>

IMO Droid is a general purpose framework to allow you to create droids to
solve your needs. The idea is that you add the droids-core library to your
project and create your own implementation. The files that you mentioned in
the issue are concrete and simple implementations to provide examples to
other developers for a starting point.

I think that this files should be moved too but not in the core project. We
could create another maven project as basic implementations. Maybe the
community have some ideas about this.
>
> Moving on from simple renames I will try to focus on a proposal from an
> earlier discussion thread: the *Save *handler has an *outputDirectory
> *property;
> that only allows the files to be stored in a single place, with no
> additional rules applied to this process; the process of choosing the path
> of the file can be more flexible, based on client logic; this can be done
> via a simple object that would decide the path based on that logic - *
> PathDecider*; also this would get rid of the path related logic from this
> handler for a clear separation of responsibilities between deciding the
> path
> where data is saved and actually saving the data.
>

+1

The PathDecider basic implementation could be the actual behaviour but it
can be a good improvement.

Also, I understand that there is no specific coding standard or best
> practice document for committing into the repository. One possibility is an
> Eclipse formatter to make things easier. I am aware that this is IDE
> specific, but it doesn't have to be - the coding standards document would
> be
> IDE agnostic, and the Eclipse formatter would simply be there if you want
> to
> use it. Is JIRA the place to start something in this direction?
>
>
You can follow the guidelines in
http://incubator.apache.org/droids/contrib.html#Coding+Guidelines

Basically, you must follow the Java conventions and use always 2 spaces for
indentations, no tabs. The patches provided must contain the full files
path.
> One last question about dependencies - how flexible are these at this
> point?
>

If the license is compatible and it help to the development there's no
problem.
> For instance, there may be a benefit from using things like Guava (the
> former google collections). I haven't checked what the licence on that is,
> but I know it's a core dependency for some other Apache projects (Mahout
> for
> instance), so I guess the licence is OK. Another dependency that may be
> easier to work with is SLF, which has some advantages over commons-logging.
>
>
I don't know too much about licenses but if Mahout uses as core dependency
it should be compatible with the ASFL. But why do you want to add an
external dependency like Guava?
> These are some specific questions for when you or someone from the
> community
> has time to address them. Thanks for the help. Eugen.
>
>
Thanks to you for use Droids and contribute.

Salu2.