On 11/04/2010, Luc Maisonobe <luc.maison...@free.fr> wrote: > Phil Steitz a écrit : > > > Torsten Curdt wrote: > >>> I think tomcat may still build repackaged versions of dbcp and pool > >>> classes from source and this change might break their builds. So -1 > >>> for now for changing those. > >> As much as I am for cross-project collaboration this reason for a "-1" > >> takes it a step too far IMO. If they really want to keep using the > >> repackaged versions (why?) > > > > Mark or someone else can confirm, but I think the repackaging is to > > avoid conflicts between the bundled versions and user-supplied > > replacements. > > > > they can probably adjust their build within > >> minutes to work with a new project layout. > > > > But why force that? I see know value to this change from a [pool] > > or [dbcp] perspective. What exactly do we gain from it? I know > > that tomcat is not the only user who builds classes from these > > sources from source. Why force this change on everyone who does > > that? If I am missing some benefit other than adhering to a > > (changed) maven standard, I would like to know what that is. > > > I think it is the first time I disagree with you, Phil, I'm sorry for > that. I think going back to accepted standards instead of having our own > way is good. People and quality assurance teams often build lots of > scripts to check source trees, so having a directories tree that is > similar to trees from other project adds value and remove some burden to > users.
+1, well put. > We already did the move for [math], due to some maven plugin (I don't > remember which one). It was an easy move and nobody complained. I agree > the users base is smaller than for other commons components, though. Also, the change does not affect the binary artifacts. AFAICT it does not affect any of the Maven artifacts. It does affect the source archives, but the build process is still the same. So the source tree re-arrangements are likely to affect very few users, if any. > > Luc > > > > > > Phil > >> cheers > >> -- > >> Torsten > >> > >> --------------------------------------------------------------------- > >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
