commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [ALL] JAVA environment settings appear in MANIFEST.MF
Date Sat, 13 Mar 2010 17:01:44 GMT
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

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

> 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

Niall

>>
>>  Niall
>>
>>
>>  > Agreed?
>>  >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message