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. 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
