On 2010-04-12 21:21, sebb wrote: > On 12/04/2010, Niall Pemberton <niall.pember...@gmail.com> wrote: >> On Sat, Apr 10, 2010 at 4:16 PM, sebb <seb...@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. > 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-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
