Use Apache Felix osgi-core 1.0.1 instead of osgi_core R4 [PAXCONSTRUCT-88]

Hendy Irawan created PAXCONSTRUCT-88

Pax-Construct should default to using Apache Felix's osgi-core 1.0.1 (also in Maven central), which is OSGi R4.1 API, rather than (as of Pax Construct 1.3) OSGi R4 artifacts in Maven central.

Forwarded conversation
Subject: pax-runner and osgi_core
------------------------

From: Hendy Irawan <hendy@rainbowpurple.com>
Date: Fri, Jun 27, 2008 at 3:26 AM
To: General OPS4J <general@lists.ops4j.org>

this is strange:

ceefour@caliva:~/project/ops4j/pax-script$ pax-run.sh --platform=equinox --profile=log scan-pom:file:pom.xml
__ ____
/ / / / / / / /
/ / / / \ \ /
/ / / / / / / \ \
// // // // //

Pax Runner from OPS4J - http://www.ops4j.org
--------------------------------------------

-> Using config classpath:META-INF/runner.properties
-> Provision from scan-pom:file:pom.xml
-> Using property bundle.symbolicName=org.ops4j.pax.script
-> Using property bundle.namespace=org.ops4j.pax.script
-> Installing bundle [

{location=mvn:org.ops4j.pax.script/pax-script/1.0-SNAPSHOT,startlevel=null,shouldStart=true,shouldUpdate=false}

]
-> Installing bundle [

{location=mvn:org.osgi/osgi_R4_core/1.0,startlevel=null,shouldStart=true,shouldUpdate=false}

]
-> Installing bundle [

{location=mvn:org.osgi/osgi_R4_compendium/1.0,startlevel=null,shouldStart=true,shouldUpdate=false}

]
-> Installing bundle [

{location=mvn:org.ops4j.pax.swissbox/pax-swissbox-lifecycle/0.2.0,startlevel=null,shouldStart=true,shouldUpdate=false}

]
-> Installing bundle [

{location=mvn:org.ops4j.base/ops4j-base-lang/0.5.0,startlevel=null,shouldStart=true,shouldUpdate=false}

]
-> Installing bundle [

{location=mvn:org.ops4j.pax.swissbox/pax-swissbox-extender/0.2.0,startlevel=null,shouldStart=true,shouldUpdate=false}

]
-> Installing bundle [

{location=mvn:commons-logging/commons-logging-api/1.1,startlevel=null,shouldStart=true,shouldUpdate=false}

]
-> Downloading bundles...
-> mvn:org.osgi/osgi_R4_core/1.0 : 444838 bytes @ [ 2457kBps ]
_
/ /
/ / Oops, there has been a problem!
/ /
/_/

/__/

-> java.lang.RuntimeException: org.ops4j.pax.runner.platform.PlatformException: mvn:org.osgi/osgi_R4_core/1.0 is not a valid bundle
java.lang.RuntimeException: org.ops4j.pax.runner.platform.PlatformException: mvn:org.osgi/osgi_R4_core/1.0 is not a valid bundle
at org.ops4j.pax.runner.Run.startPlatform(Run.java:433)
at org.ops4j.pax.runner.Run.start(Run.java:156)
at org.ops4j.pax.runner.Run.main(Run.java:545)
at org.ops4j.pax.runner.Run.main(Run.java:518)
Caused by: org.ops4j.pax.runner.platform.PlatformException: mvn:org.osgi/osgi_R4_core/1.0 is not a valid bundle
at org.ops4j.pax.runner.platform.internal.PlatformImpl.validateBundleAndGetFilename(PlatformImpl.java:684)
at org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:565)
at org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:399)
at org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:197)
at org.ops4j.pax.runner.Run.startPlatform(Run.java:429)
... 3 more
ceefour@caliva:~/project/ops4j/pax-script$ svn info
Path: .
URL: https://scm.ops4j.org/repos/ops4j/laboratory/users/ceefour/pax-script
Repository Root: https://scm.ops4j.org/repos/ops4j
Repository UUID: 9b982a3c-3ae5-0310-a4bc-d9a3335569bd
Revision: 12127
Node Kind: directory
Schedule: normal
Last Changed Author: ceefour
Last Changed Rev: 12127
Last Changed Date: 2008-06-27 02:05:47 +0700 (Fri, 27 Jun 2008)

any suggestions? deleting/refreshing the m2 repo in respect to the suspecting file is not helping

pax-run.sh by itself runs just fine though...

–
Best regards,
Hendy Irawan ----------
From: Stuart McCulloch <stuart.mcculloch@jayway.net>
Date: Fri, Jun 27, 2008 at 3:48 AM
To: General OPS4J <general@lists.ops4j.org>

2008/6/26 Hendy Irawan <hendy@rainbowpurple.com>:

this is strange:

no actually, it's correct - if you crack open that jarfile
you will find it's not actually a bundle (no metadata)

the core artifact is only meant to be used for compiling
against, not deploying, because all OSGi frameworks
will provide the core classes by default - and including
another bundle with same/different versions of these
classes is not a good idea :smile:

note that the pax-plugin / pax-provision automatically
exclude non-bundle dependencies for you by checking
the manifest before passing them onto pax-runner

you can also mark dependencies as <optional> and
pax-plugin / pax-provision won't try to deploy them

I don't think pax-runner does anything like this itself,
if you want full maven support use pax-provision :smile:

___
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

–
Cheers, Stuart
___
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

----------
From: Stuart McCulloch <stuart.mcculloch@jayway.net>
Date: Fri, Jun 27, 2008 at 3:52 AM
To: General OPS4J <general@lists.ops4j.org>

2008/6/26 Stuart McCulloch <stuart.mcculloch@jayway.net>:

FYI, the core dependency is being pulled in by this option:which spots the org.osgi/osgi_R4_core/1.0 dependency
in your pom.xml - to stop this from happening you'll either
need to put that dependency somewhere else (ie. some
parent pom) or use the pax-provision script instead...

this is also why the default pax-run.sh command passes

–
Cheers, Stuart
___
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

----------
From: Hendy Irawan <hendy@rainbowpurple.com>
Date: Fri, Jun 27, 2008 at 12:04 PM
To: General OPS4J <general@lists.ops4j.org>

Thanks, but:

<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi_R4_core</artifactId>
<version>1.0</version>
<scope>provided</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi_R4_compendium</artifactId>
<version>1.0</version>
<scope>provided</scope>
<optional>true</optional>
</dependency>

they're both marked as optional, why pax-run.sh still use them?

Doesn't it use the same scan-pom that's also used by pax-provision?
Best regards,
Hendy Irawan ----------
From: Hendy Irawan <hendy@rainbowpurple.com>
Date: Fri, Jun 27, 2008 at 12:08 PM
To: General OPS4J <general@lists.ops4j.org>

Thanks, using pax-provision solves the problem...

I won't use Pax Runner with Maven projects then...
–
Best regards,
Hendy Irawan ----------
From: Alin Dreghiciu <adreghiciu@gmail.com>
Date: Fri, Jun 27, 2008 at 12:58 PM
To: General OPS4J <general@lists.ops4j.org>

It does use scan pom but is not the scan the project pom but a runtime
generated pom.
If you think that will be useful, that scan pom, does the same for
optional dependencies (not take them in consideration, raise a jira
issue.
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
http://malaysia.jayway.net - New Energy for Projects - Great People
working on Great Projects at Great Places
----------
From: Stuart McCulloch <stuart.mcculloch@jayway.net>
Date: Fri, Jun 27, 2008 at 12:59 PM
To: General OPS4J <general@lists.ops4j.org>

2008/6/27 Hendy Irawan <hendy@rainbowpurple.com>:

the scan-pom handler is separate from the maven-pax-plugin and
doesn't use any Maven code - so there are cases like this where
it behaves differently (it doesn't merge poms with parents, etc.)

it should be straightforward to ignore optional dependencies in
pax-runner-scanner-pom, just need to edit PomScanner.java to
check for the optional element

–
Cheers, Stuart
___
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

----------
From: Alin Dreghiciu <adreghiciu@gmail.com>
Date: Fri, Jun 27, 2008 at 1:02 PM
To: General OPS4J <general@lists.ops4j.org>

Stuart is right that osgi core should be provided by the osgi
framework implementation but is also true that the dependencies from
maven central pom are also not "good" as they are not the same as the
one provided by OSGi Alliance. The problem with them is that are not
bundles are simple plain jars.
This is the reason why I uploaded th ecorrect artifacts from OSGi
Alliance to ops4j repository. In plus I created them on OPS4J repo
with the right version:

http://repository.ops4j.org/maven2/org/osgi/org.osgi.core/
http://repository.ops4j.org/maven2/org/osgi/org.osgi.compendium/

On Thu, Jun 26, 2008 at 11:48 PM, Stuart McCulloch
----------
From: Hendy Irawan <hendy@rainbowpurple.com>
Date: Fri, Jun 27, 2008 at 1:12 PM
To: General OPS4J <general@lists.ops4j.org>
Cc: Peter Kriens <peter.kriens@aqute.biz>

So why is pax construct still using the maven central one?
2. Why nobody uploads the correct OSGi framework bundles to maven central? Ironically, there are quite many OSGi bundles in maven central but not OSGi itself?

I also had difficulty with pax-construct defaulting to OSGi R4, that I got stumped because I cannot use Bundle.getBundleContext(), so I then had to resort to apache felix's osgi-core 1.0.1.

I'm CC-ing this to Peter Kriens too because I think this is critical issue. To put it shortly, OSGi R4.1 is not available from Maven central!
This is a major issue that needs to be fixed. I'd assume that Mr. Kriens is a pro-Maven too.

(A few weeks ago we were discussing why Equinox proper aren't available from Maven central... now OSGi itself)
–
Best regards,
Hendy Irawan ----------
From: Niclas Hedhman <niclas@hedhman.org>
Date: Fri, Jun 27, 2008 at 1:19 PM
To: General OPS4J <general@lists.ops4j.org>

He is also monitoring this list as much as time allows ;o)

Cheers
Niclas
----------
From: Stuart McCulloch <stuart.mcculloch@jayway.net>
Date: Fri, Jun 27, 2008 at 1:27 PM
To: General OPS4J <general@lists.ops4j.org>
Cc: Peter Kriens <peter.kriens@aqute.biz>

2008/6/27 Hendy Irawan <hendy@rainbowpurple.com>:

because 99% of the time that's all you need, and these days I have hardly any spare
time at all, so I typically only fix the things that people bug me about / raise on JIRA

it would also add a implicit dependency to the OPS4J repo, which I'd prefer to avoid
as the pax-construct archetypes are now available from the Maven central repository
(the golden rule there is not to depend on external repos)

yep, that's why Alin added the latest artifacts to the OPS4J repository - uploads
to the Maven central repo are typically only allowed by "owners" of the project

note that it's just a matter of changing the dependency in the pom.xml and adding
the OPS4J repository - a bit annoying certainly, but not a complete blocker imho.

–
Cheers, Stuart
___
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

----------
From: Hendy Irawan <hendy@rainbowpurple.com>
Date: Fri, Jun 27, 2008 at 2:47 PM
To: General OPS4J <general@lists.ops4j.org>
Cc: Peter Kriens <peter.kriens@aqute.biz>

I agree. One of these 1% is when coding extenders...

Is it preferable to use org.apache.felix osgi-core/compendium v1.0.1 instead? (in the mean time) It's in Maven central, and complies with R4.1...

I agree with what Peter Kriens said, it doesn't give much benefit staying with older version. Developing in R4.1 doesn't mean that the bundle can't run with R4, its up to the bundle developer to use whichever feature it wants...

I agree with your comment below, it's a minor annoyance to use R4 framework as default. In my case the difference between R4.1 and R4 was so subtle yet important...

Agree. I'm running just fine now, yet still hoping that future Pax Construct projects will default to OSGi R4.1...

–
Best regards,
Hendy Irawan ----------
From: Stuart McCulloch <stuart.mcculloch@jayway.net>
Date: Fri, Jun 27, 2008 at 3:00 PM
To: General OPS4J <general@lists.ops4j.org>

yes, that's certainly an option

true - when I first wrote those archetypes the Felix project didn't
fully support R4.1, because it had only recently been released,
but afaik the major frameworks now support the new method(s)

so I think we can now safely move over to use the Apache jars

they will, but I can't give a timeline at the moment
(but more likely to be weeks rather than months)

–
Cheers, Stuart
___
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

Affects: 1.3 Votes: 0, Watches: 1

ops4j / org.ops4j.pax.construct

Use Apache Felix osgi-core 1.0.1 instead of osgi_core R4 [PAXCONSTRUCT-88] #37