commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] JAVA environment settings appear in MANIFEST.MF
Date Sat, 13 Mar 2010 16:52:56 GMT
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.

I'll update the pom accordingly.

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.

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.

>
>  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


Mime
View raw message