Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.220.218 as permitted sender)
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=KQdVjf+y2Q9M0VlwpT2xJbR/xT00YI0xgaE2qKiTNj2A66dbBHsEGn0hcjkzoAOEeF
         ojC8u05ZiDEFDE2s8bUq6ZBiCx6xLXR6Tyd1G+MUiHW2l2BWQi4h6cerD2x0HPHqMAxL
         NT+AmYMTA+S9mG59VSSjSPCLCRMBti32jVIfI=
MIME-Version: 1.0
In-Reply-To: <55afdc851003130901w6303fb65n10f785a7e34955ce@mail.gmail.com>
References: <25aac9fc1003130453l4407f3b6n384a7acbedbc99ae@mail.gmail.com>
	 <55afdc851003130506y2ae6ec77hcfd190d34db1bb29@mail.gmail.com>
	 <25aac9fc1003130812k11b66e1bt17cc1123a5526464@mail.gmail.com>
	 <55afdc851003130838v46c32168qa92a9be60109979@mail.gmail.com>
	 <25aac9fc1003130852o6190ca19w75e3fa9f78f01a59@mail.gmail.com>
	 <55afdc851003130901w6303fb65n10f785a7e34955ce@mail.gmail.com>
Date: Sat, 13 Mar 2010 17:30:58 +0000
Message-ID: <25aac9fc1003130930y16b69eci2758e1f59d9e5672@mail.gmail.com>
Subject: Re: [ALL] JAVA environment settings appear in MANIFEST.MF
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 13/03/2010, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> On Sat, Mar 13, 2010 at 4:52 PM, sebb <sebbaz@gmail.com> wrote:
>  > On 13/03/2010, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>  >> On Sat, Mar 13, 2010 at 4:12 PM, sebb <sebbaz@gmail.com> wrote:
>  >>  > On 13/03/2010, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>  >>  >> On Sat, Mar 13, 2010 at 12:53 PM, sebb <sebbaz@gmail.com> wrote:
>  >>  >>
>  >>  >> > If the JAVA_1_n_HOME variables are defined in settings.xml, they
>  >>  >>  > appear in the OSGI manifest created by the maven-bundle-plugin.
>  >>  >>  >
>  >>  >>  > This appears to be because the property names start with a capital letter.
>  >>  >>  > I'm not sure if it is possible to exclude these from the manifest.
>  >>  >>  > [I'll ask on the Felix list]
>  >>  >>
>  >>  >>
>  >>  >> http://markmail.org/message/viatovhpjlx355on
>  >>  >
>  >>  > Answer is to use the -removeheaders directive.
>  >>  > Unfortunately this requires a LIST of all the property names (no wild-cards).
>  >>  >
>  >>  >>
>  >>  >>  > If not, then one simple solution would be to use lower-case for the
>  >>  >>  > property names.
>  >>  >
>  >>  > I think we should just use lower-case for the property names, as the
>  >>  > other options are a lot messier, and easier to get wrong.
>  >>
>  >>
>  >> The advantage of using those values is thats what the maven
>  >>  documentation uses as an example - its not a standard but it wouldn't
>  >>  surprise me if other projects/people didn't just copy that - also
>  >>  naming them like JAVA_1_4_HOME is close to the JAVA_HOME standard.
>  >>  Also if other projects do use those and people set them up in their
>  >>  settings.xml for those projects and then build commons - the same
>  >>  pollution of the MANIFEST will happen. So I think we should exclude
>  >>  them
>  >
>  > OK, I see. However the exclusions will only work if they use exactly
>  > the same property names.
>
>
> yes
>
>
>  > I'll update the pom accordingly.
>
>
> thanks
>

Done.

>  > By the way, your solution of putting the definitions in individual
>  > profiles in settings.xml only excludes the properties that belong to
>  > the inactive java profiles.
>
>
> True, but I think generally people won't be activating those profiles
>  when building a release.
>

Perhaps they should...

>  > On the other hand, it does mean that the properties are automatically
>  > activated as needed.
>  > A bit more work, but I think it's better than creating a new profile
>  > that is always active.
>
>
> Yes because these properties for our project could pollute other
>  projects that use the bundle plugin and don't exclude them

Good point.

>
>  Niall
>
>
>  >>
>  >>  Niall
>  >>
>  >>
>  >>  > Agreed?
>  >>  >
>
>  ---------------------------------------------------------------------
>  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