On Tue, 2018-02-27 at 17:38 +0100, Oliver Lietz wrote: > On Tuesday 27 February 2018 18:28:05 Robert Munteanu wrote: > > On Tue, 2018-02-27 at 17:09 +0100, Oliver Lietz wrote: > > > > Well, let's try and avoid that :-) > > > > > > > > Could we either: > > > > > > > > 1) Create a profile in the parent pom, activated for bundle > > > > projects, > > > > which adds the OSGi dependencies? > > > > > > > > 2) Create a 'non-OSGi' parent POM (A) and an 'OSGi' parent POM > > > > (B), > > > > where A is the parent of B. This way we could use the parent > > > > POM in > > > > different projects without getting any clashes. > > > > > > We could use the bundle profile but that "requires" switching to > > > bnd > > > Maven > > > Plugin (or at least placing a file bnd.bnd in the module). > > > > Well, I assume that using the bnd.bnd file is another manual > > transition > > that we must do, right? If that is the case we should discuss it on > > the > > dev list before committing to another migration. > > Putting bnd instructions into a file is the preferred way (instead of > POM, see > discussion in SLING-7417). Once Maven JAR Plugin is fixed those > profile from > parent can be removed. You don't have to switch to bnd Maven Plugin, > Maven > Bundle Plugin is still supported.
Right, but AFAICT a marker file is the only way to detect a bundle, and I'd like to not tie up the migration to the bnd-maven-plugin and the migration to a newer parent pom. > > > Maybe we can have a compromise and require a property in the pom, > > e.g. > > > > <properties> > > <sling.bundle>true</sling.bundle> > > </properties> > > > > That property will activate the OSGi-related profile from the > > parent > > pom. > > > > Not ideal but still better than copy/pasting considerably more > > dependency versions. > > Ugly... no other way to activate profile? Not even this is an option, see Konrad's response. So maybe we should consider multiple parent poms. Robert
