commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] Non-standard maven source and test directories
Date Tue, 13 Apr 2010 15:29:38 GMT
On 12/04/2010, Dennis Lundberg <dennisl@apache.org> wrote:
> On 2010-04-12 21:21, sebb wrote:
>  > On 12/04/2010, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>  >> On Sat, Apr 10, 2010 at 4:16 PM, sebb <sebbaz@gmail.com> wrote:
>  >>  > 22 commons-proper projects are still using non-standard source and
>  >>  > test directories, i.e. they are using:
>  >>  >
>  >>  >    <sourceDirectory>src/java</sourceDirectory>
>  >>  >    <testSourceDirectory>src/test</testSourceDirectory>
>  >>  >
>  >>  > rather than the default:
>  >>  >
>  >>  >    <sourceDirectory>src/main/java</sourceDirectory>
>  >>  >    <testSourceDirectory>src/test/java</testSourceDirectory>
>  >>  >
>  >>  > Do we want to fix those?
>  >>
>  >>
>  >> I think its better to use the standard m2 layout but I don't think its
>  >>  a big deal. The one downside I see is that it can screw up existing
>  >>  patches - those can be fixed/manually edited but its an extra effort.
>  >
>  > Good point.
>  >
>  > So best to fix components when there aren't (m)any patches outstanding.
>  >
>  > I propose to create JIRA issues to track these "standardisation" efforts.
>  >
>  > Should the issues be filed per component, or would a catchall issue
>  > plus subtasks be better for this?
>
>
> I would prefer a separate issue per component. That way it will show up
>  in the generated changes report for the component. This is beneficial to
>  our users.
>

OK, agreed.

However, I'd like to avoid having to repeat the same information in
every JIRA issue.
So I propose creating a dummy parent issue in COMMONSSITE/CommonsAll.

Then I would add issues for each component, which link back to -
"relates to" - the common parent issue.

[Unfortunately one cannot create subtasks in another JIRA project]

Does that sound reasonable? Any pitfalls to watch out for?

>  > There may be other similar issues that crop up - e.g. where the parent
>  > pom now handles what originated in a few component poms - so it might
>  > be easier to track these as a catchall JIRA.
>  >
>  >>
>  >>  Niall
>  >>
>  >>
>  >>  > This would involve renaming the directories, removing the entries from
>  >>  > the pom files and updating any other build scripts e.g. Ant that may
>  >>  > be present.
>  >>  >
>  >>  > The projects are:
>  >>  >
>  >>  > betwixt
>  >>  > cli
>  >>  > codec
>  >>  > collections
>  >>  > configuration
>  >>  > daemon
>  >>  > dbcp
>  >>  > dbutils
>  >>  > digester
>  >>  > discovery
>  >>  > el
>  >>  > email
>  >>  > fileupload
>  >>  > io
>  >>  > jxpath
>  >>  > launcher
>  >>  > logging
>  >>  > modeler
>  >>  > net
>  >>  > pool
>  >>  > primitives
>  >>  > transaction
>  >>  >
>  >>
>  >>> ---------------------------------------------------------------------
>  >>  > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  >>  > For additional commands, e-mail: dev-help@commons.apache.org
>  >>  >
>  >>  >
>  >>
>  >>  ---------------------------------------------------------------------
>  >>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  >>  For additional commands, e-mail: dev-help@commons.apache.org
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  > For additional commands, e-mail: dev-help@commons.apache.org
>  >
>  >
>
>
>  --
>
> Dennis Lundberg
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message