Support for specifying start level for modules

Description

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.

Environment

None

Activity

Show:
Alin Dreghiciu
October 5, 2009, 5:19 PM
Edited

@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:

StuartS
October 5, 2009, 5:28 PM

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

Alin Dreghiciu
October 5, 2009, 7:41 PM

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

Kristoffer Peterhänsel
October 5, 2009, 10:04 PM

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.

CliffordC
January 25, 2010, 1:40 AM

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

Assignee

Unassigned

Reporter

Kristoffer Peterhänsel

Labels

None

Components

Affects versions

Priority

Major
Configure