Home | About | Sematext search-lucene.com search-hadoop.com
 Search Lucene and all its subprojects:

Switch to Threaded View
Droids >> mail # dev >> feedback needed on JIRA issues


Copy link to this message
-
Re: feedback needed on JIRA issues
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
> > >
> > >
> >
>