>>> 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.
As a side note: there are tools that easily do that on the jar without the need to build from source. http://maven.apache.org/plugins/maven-shade-plugin/ Don't have links to the ant tasks at hand. >> 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. In my book consistency is of value, but people have different opinions on that. My point is not whether we should do it or not. My point is that we already have a lot of restrictions of what we can change at commons without breaking compatibility and so on. Adding also our directory structures to this mix feels a bit over the top to me. There needs to be a balance between backwards compatibility and handcuffs. The official way to build the source distribution would not even change! If someone relies on the directory structure ...well ...honestly? ...then that's their problem if we change it. That said: I doubt it would be a big deal for the Tomcat guys or whoever uses the non-standard way of building the commons projects like that. They would have probably fixed this faster than the time we are spending on discussing the pros/cons of it. cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
