On Wed, Feb 24, 2010 at 11:42 PM, sebb <seb...@gmail.com> wrote: > On 24/02/2010, Niall Pemberton <niall.pember...@gmail.com> wrote: >> On Wed, Feb 24, 2010 at 4:40 PM, sebb <seb...@gmail.com> wrote: >> > On 24/02/2010, Niall Pemberton <niall.pember...@gmail.com> wrote: >> >> On Wed, Feb 24, 2010 at 1:07 AM, sebb <seb...@gmail.com> wrote: >> >> > On 24/02/2010, Niall Pemberton <niall.pember...@gmail.com> wrote: >> >> >> I'd like to do a release of the commons-parent pom - primarily to >> >> >> upgrade to the latest commons-build-plugin 1.2 release. >> >> >> >> >> >> I have also upgraded the plugin versions and changed the "rc" & >> >> >> "release" profiles to now only produce the javadocs and not the >> whole >> >> >> site (this resolves a problem for multi-module components). >> >> >> >> >> >> Are there any other changes or feedback before calling a vote on >> this? >> >> > >> >> > I think the default maven.compile.source|target entries should be >> >> > removed from the POM. >> >> > >> >> > Seems to me that projects should have to define these, and not rely on >> >> > the default. >> >> >> >> >> >> I disagree with this because the whole point of the commons-parent >> >> pom.xml is to reduce the amount of dulicate configuration in component >> >> projects and I see no benefit in forcing components to define >> >> unnecessary properties when the default suits them. >> > >> > But the compilation source and target are specific to each project, >> > just like inceptionYear. >> >> >> As I said it reduces duplication of configuration - no difference from >> inherintance in java. >> > > It does not reduce duplication in the long run, as each project that > upgrades from the minimum of 1.3 will need to define the properties. > It can only reduce duplication for the very few projects that will > never change their minimum version from 1.3. > >> > Unlike other properties, such as plugin versions, the source and >> > target versions can never be updated in the parent pom. If it is >> > updated, that all projects that are currently relying on the default >> > will have to be updated to override the parent pom. At which point the >> > parent pom properties become useless anyway. >> >> >> The parent-pom is versioned and released - we can update those values >> at any time. Obviously if we did change the values we would have to >> make each component had the correct value configured either through >> the parent or overriden in its pom before it was moved to the new >> version parent. > > Exactly. > > So every project that does not currently want to use 1.3 must override > the properties.
Yes, and those that are still on 1.3 don't have to. > If the parent pom properties were ever to change from 1.3, then those > projects that currently rely on the default must define the > properties, at which point the parent pom properties are not being > used by any projects. So worst case secario they're redundant which is not a big deal OR we decide to change the default. >> > It's also tedious trying to find the JVM requirements if one has to >> > look in both the project pom and the parent pom. >> >> >> Tedious is something people do repetitively - I'm sure once people see >> whats in the parent they don't have to continually go back and keep >> checking. >> > > But if the value in the parent POM can change, and multiple parent > poms are in use, then rechecking *is* needed. Agreed, if and when they ever change. I imagine that *might* only happen once we no longer have a component with a minimum of 1.3. If it ever does I'm sure it will be discussed first and someone will ensure that everything is correctly setup. But thats some theoretical red-herring IMO. These default have IMO worked well and I haven't seen any good argument yet for removing them and so I'm against it. Niall >> >> I also think this is a non-issue. We have a good history over the past >> >> few years of making sure components are compatible with the JDK >> >> version they target and I don't believe theres a single example of a >> >> release that had these properties incorrectly set. >> >> Also we did have this discussion before: >> >> >> >> http://markmail.org/message/sc2d7efxscz6n3sz >> >> >> > >> > I know, and I still disagree. >> >> >> Me too :) >> >> >> Niall >> >> >> >> Niall >> >> >> >> >> >> >> Niall --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
