Support for specifying start level for modules [PAXCONSTRUCT-127]

[ops4j-issues]

Kristoffer Peterhänsel created PAXCONSTRUCT-127

I am in a position where I need one of my bundles to start early to set up some things in Config Admin. Unfortunately it seems impossible to get Pax Construct to run a bundle - that is part of the build - at a specific start level.

I have a Pac Construct-created Maven project with a number of sub-modules. And one of those I am trying to get to run at start level 2, while everything else runs at 5. I can add it in the provision section of my POM as mvn: url and get it written into the config.ini (I am using Equinox as OSGi framework). But the module dependency will also be written into the file. And it appears that the last one will take priority under Equinox.

So it might be an idea to remove duplicated from the list of bundles to provision, to allow this type of overwriting. Alternatively there should be some support for having a bundles start level in its POM file. But then I guess the issue is Pax Runner related.

---

Affects: 1.4
Votes: 0, Watches: 0

[ops4j-issues]

Stuart McCulloch commented

Just FYI, this topic has come up several times over the years and the problem always comes down to representing the start-level in the Maven POM.
We just haven't found a way to record the start level inside the <dependency> stanza without affecting the resolution (ie. you can't use classifier, etc.).

Regarding config priority: we always put any explicit URLs and argument files before the generated deployment POM when passing it to pax-runner,
so perhaps it's just a matter of changing the Equinox platform module so it organizes the bundles differently, or removes duplicates from the config.
(it's non-trivial to do this in pax-construct because we don't parse the URLs at the moment - this means we can't tell if they duplicate a dependency)

[ops4j-issues]

Alin Dreghiciu commented

@Stuart
I think the first thing that Pax Construct should do is to use a different way then the pom scanner when starting Pax Runner.
In my view simpler, easier way, is that Pax Construct will generate a simple test file that can be read with scan-file:. This one allows specification of start level per provisioning url where the scan-pom will not because the reasons you mentioned.

Now regarding how one could specify the start level and / or a bundle to be started or not cant we use the approach they have in dependency plugin?
For example:

          <configuration>
	<artifactItems>
		<artifactItem>
			<groupId>foo</groupId>
			<artifactId>bar1</artifactId>
			<startLevel>10</startLevel>
			<start>false</start>
		</artifactItem>
		<artifactItem>
			<groupId>foo</groupId>
			<artifactId>bar2</artifactId>
			<startLevel>2</startLevel>
		</artifactItem>
	</artifactItems>
<configuration>  

[ops4j-issues]

Stuart McCulloch commented

Sure that is an option, but I do wonder if repeating a long list of artifactItems (with duplicate groupIds / artifactIds) is better than a short pax-url...

[ops4j-issues]

Alin Dreghiciu commented

Sure, is not the ideal situation to duplicate stuff, only that is within the way maven works. Maybe an alternative to shorten the specification is to use something like foo:bar1 instead. Maybe even allow some kind of wildcards.
I'm just thinking now loud 😉

[ops4j-issues]

Kristoffer Peterhänsel commented

As I understand it, currently Pax Construct builds one pom with each of the various provisioned artifacts as a dependency. Correct? And I also found a reference to specifying a start level in the pom, as a property, for Pax Runner.

Couldn't each artifact just be referenced as a pom to be scanned? Or would that be too slow to be a workable solution? That would at least solve my issue as it is one of my own bundles I need to start early. And the 3rd-party bundles I need to modify start level on I am simply referring in the provision block instead of having them in my provision/pom file.

I guess what ends up in the config.ini isn't really the responsibility of Pax Construct. But could there be any reason why duplicates are not sorted out? Or has it just not come up as an issue before? Can't seem to find any issues reported on it anyway.

[ops4j-issues]

CliffordC commented

I just ran into this shortcoming today. I don't think it's "Un Maven-like" to have a separate file for additional meta-data. For example, look at the "assembly.xml" that the maven-assembly plugin uses. We don't even have to have an XML file. Something like this:

foo/bar/artifact1@1
foo/bar/artifact2@nostart

in a text file would work. Although the lack of XML probably is un Maven-like 😉

I actually don't see why these can't be duplicates since it's a seperation of concerns: pom.xml is for deps and bundle-config.xml (or whatever you want to call it) is for specifying bundle configurations that override the default (all bundles started at start leve 5).