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