Luc Maisonobe 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 don't think so :) , I'm sorry for > that. Please never apologize for that. I am often wrong. I think going back to accepted standards instead of having our own > way is good. Its not so much "having our own way" as implementing change to adhere to "standards" that I don't see any value in beyond supporting brittle plugins. That is a side rant issue, so basically I am agreeing with you on this point. 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. I get that part. I have built and maintained these scripts. I was trying to be nice to those who have scripts in place that work with our sources. Doing work to make work for existing users so new users can have an easier time can be seen either way. (See point below on 2.x vs 1.x versions.) I do agree with Torsten that it is in general beyond reasonable for users to expect that the structure of our sources will not change. I did not mean to imply that we should in general try to maintain backward compatibility wrt source organization (or supported build tools). My point was just that I do not personally see enough value in this particular change to justify *any* work required by users who have to support it. Based on what everyone else is saying on this thread, I see I am in the minority on this, so probably wrong. > > 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. > And we did it as part of a move to 2.0, which had lots of other changes. Pool and dbcp are much older and trunk is still 1.x. I would be happier to postpone this change until 2.x; but I see I am odd man out on this, so if someone wants to do the work, fully test all of the builds, I am OK with it - i.e., now just -0. Please do it as part of a JIRA though so we don't forget to include mention of the change in release notes. Phil > 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
