Re: [equinox-dev] osgi.bundles property

[Raymond Auge <raymond.auge@xxxxxxxxxxx>]

Wondering if arquillian is using such an old version of equinox, since their module has the following dependency:

        <dependency>

        <groupId>org.eclipse.osgi</groupId>

        <artifactId>org.eclipse.osgi</artifactId>

        </dependency>

The newest equinox artifact with that coordinate is is 3.7.1

Perhaps here is another good reason why equinox should publish it's own artifacts to maven central, so that other projects don't get stuck using really really old dependencies like this.

So far tycho project is the only recent source of equinox in MC (and I would guess lots of people don't know this).

- Ray

On Thu, Jul 17, 2014 at 1:36 PM, Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:

So, Cristiano you have shed some light on the issue.

When using the felix framework we need these dependencies:

<dependency conf="test->default" name="org.apache.felix.framework" org="org.apache.felix" rev="4.4.0" />

<dependency conf="test->default" name="org.apache.felix.main" org="org.apache.felix" rev="4.4.0" />

However, the arquillian framework itself still only creates the osgi Framework using:

        Iterator<FrameworkFactory> factories = ServiceLoader.load(FrameworkFactory.class).iterator();

        if (factories.hasNext()) {

            frameworkFactory = factories.next();

        }

This operation is provided by a common parent module which the other osgi containers (both felix and equinox) inherit from.

So, it seems that Felix is doing the magic on it's own to decide to support these properties because arquillian is doing no such thing on it's own.

I guess the felix framework either finds an extension in the classpath and uses it.

- Ray

On Thu, Jul 17, 2014 at 1:26 PM, Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:

Ok, let me step back for a minute and make sure I'm not totally off base.

Will report back in a moment.

- Ray

On Thu, Jul 17, 2014 at 1:24 PM, Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:

Well, I'm going purely based on what I've debugged so far.

We were using arquillian container using felix, and the container code 

uses the Framework API only in both the felix impl and the equinox impl. 

I wanted to use equinox by default.

However, the tests work when running the felix container and setting felix.auto.start.

The tests fail when running the equinox container and setting osgi.bundles

- Ray

On Thu, Jul 17, 2014 at 12:23 PM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:

We certainly don't have anything like that, but I am surprised by this since the felix documentation seems to differentiate framework properties from launcher properties [1].  And the felix.auto.* properties all seem to be launcher properties which I would think do NOT apply when using the OSGi Framework API to create a framework.  But maybe I am confused about what they call a launcher vs the framework.

Tom

[1] http://felix.apache.org/site/apache-felix-framework-configuration-properties.html


Raymond Auge ---07/17/2014 02:01:25 PM---Actually, it's supported in Felix from the Framework API. felix.auto.start.<start_level>=<url>[\s<ur

From: Raymond Auge <raymond.auge@xxxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

Date: 07/17/2014 02:01 PM
Subject: Re: [equinox-dev] osgi.bundles property

Sent by: equinox-dev-bounces@xxxxxxxxxxx

---

Actually, it's supported in Felix from the Framework API.

felix.auto.start.<start_level>=<url>[\s<url>]+

I'm just confirming a bug in arquillian with their embedded equinox container module which assumes it can start bundles using the 'osgi.bundles' property in the same way felix does.

- Ray


On Thu, Jul 17, 2014 at 11:50 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:

Yes, this is correct.  If you are using the OSGi Framework API then it is up to your own launcher to populate the framework with the initial set of bundles.  We could think about doing something similar to felix which I think does something simple with loading bundles from a bundles/ folder by default.  But then again, I would not be surprised if that is only supported by the felix launcher and not directly by the felix implementation of the Framework API.

Tom



Raymond Auge ---07/17/2014 01:42:17 PM---So am I right that equinox doesn't support the 'osgi.bundles' property via the framework API?

From: Raymond Auge <raymond.auge@xxxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date: 07/17/2014 01:42 PM
Subject: [equinox-dev] osgi.bundles property
Sent by: equinox-dev-bounces@xxxxxxxxxxx


---





So am I right that equinox doesn't support the 'osgi.bundles' property via the framework API?

It looks like these are only supported via the EclipseStarter which isn't used when calling the Framework API.

Can I get a confirmation?

--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

--

Raymond Augé (@rotty3000)

Senior Software Architect

Liferay, Inc. (@Liferay)

--

Raymond Augé (@rotty3000)

Senior Software Architect

Liferay, Inc. (@Liferay)

--

Raymond Augé (@rotty3000)

Senior Software Architect

Liferay, Inc. (@Liferay)

--

Raymond Augé (@rotty3000)

Senior Software Architect

Liferay, Inc. (@Liferay)