On Sat, Mar 13, 2010 at 4:52 PM, sebb <seb...@gmail.com> wrote: > On 13/03/2010, Niall Pemberton <niall.pember...@gmail.com> wrote: >> On Sat, Mar 13, 2010 at 4:12 PM, sebb <seb...@gmail.com> wrote: >> > On 13/03/2010, Niall Pemberton <niall.pember...@gmail.com> wrote: >> >> On Sat, Mar 13, 2010 at 12:53 PM, sebb <seb...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
