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 17:30:58 GMT
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


Mime
View raw message