incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Javier Puerto <>
Subject Re: feedback needed on JIRA issues
Date Fri, 13 Aug 2010 19:05:15 GMT
Hi Eugen.

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

2010/8/12 Eugen Paraschiv <>

> 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 <> *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.


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

Basically, you must follow the Java conventions and use always 2 spaces for
indentations, no tabs. The patches provided must contain the full files

> 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

> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message