Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 79365 invoked from network); 24 Feb 2010 16:41:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Feb 2010 16:41:05 -0000 Received: (qmail 54605 invoked by uid 500); 24 Feb 2010 16:41:05 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 54481 invoked by uid 500); 24 Feb 2010 16:41:05 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 54470 invoked by uid 99); 24 Feb 2010 16:41:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Feb 2010 16:41:05 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates 209.85.220.210 as permitted sender) Received: from [209.85.220.210] (HELO mail-fx0-f210.google.com) (209.85.220.210) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Feb 2010 16:40:56 +0000 Received: by fxm2 with SMTP id 2so805864fxm.36 for ; Wed, 24 Feb 2010 08:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=nv+Ksg+x1jTp1TlWc+cLgaadFnCuWVdEco2qEzZZlKY=; b=SooPFRTKJsUpOkHIMLiMv59rP/b1nBjb3jZR4KJWZ7E4AOEZv4cBM8pD3RwmhjCMJE DsbKiNUf7lUiWh7emTlV3UEHeV3C3J8cd6puUQlDxCeSdLtbJ2jxeuorfEwEqlDt4Rkz NL1EtGNsR4FhbgTHZ1UfK0UpIzRJO//hS0DEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XS9O7LqAMSanDGg7mi8SOBbSD0ZbjgxA6Dw7Xb1qcKAqwVLeZkOf2AZmxDMGoAxMHz zvGNaRRHT0ZT4v12prkvdiY/k8sp5sTmv37IUw/fQSBoz84wV7jkYK/DSW+t+p18QNk7 Nf/8PVbCjr+QZfgSCp1ae9rzUXRVAYxouMWuw= MIME-Version: 1.0 Received: by 10.239.180.19 with SMTP id f19mr8629hbg.35.1267029635519; Wed, 24 Feb 2010 08:40:35 -0800 (PST) In-Reply-To: <55afdc851002231838g957592axde0271423901d016@mail.gmail.com> References: <55afdc851002231629ra623eefk376b997f57ee120e@mail.gmail.com> <25aac9fc1002231707x22909ff4h6171229f276f03d@mail.gmail.com> <55afdc851002231838g957592axde0271423901d016@mail.gmail.com> Date: Wed, 24 Feb 2010 16:40:35 +0000 Message-ID: <25aac9fc1002240840h1910a352qe382ce164ede897e@mail.gmail.com> Subject: Re: [all] Preparing for commons-parent pom release From: sebb To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 On 24/02/2010, Niall Pemberton wrote: > On Wed, Feb 24, 2010 at 1:07 AM, sebb wrote: > > On 24/02/2010, Niall Pemberton 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. 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. It's also tedious trying to find the JVM requirements if one has to look in both the project pom and the parent pom. > 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. > Niall > > > >> Niall > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org