Use Apache Felix osgi-core 1.0.1 instead of osgi_core R4
--------------------------------------------------------
Key: PAXCONSTRUCT-88
URL: http://issues.ops4j.org/jira/browse/PAXCONSTRUCT-88
Project: Pax Construct
Issue Type: Improvement
Components: archetypes
Affects Versions: 1.3
Reporter: Hendy Irawan
Assignee: Stuart McCulloch
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 <[EMAIL PROTECTED]>
Date: Fri, Jun 27, 2008 at 3:26 AM
To: General OPS4J <general@lists.ops4j.org>
this is strange:
[EMAIL PROTECTED]:~/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
[EMAIL PROTECTED]:~/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 <[EMAIL PROTECTED]>
Date: Fri, Jun 27, 2008 at 3:48 AM
To: General OPS4J <general@lists.ops4j.org>
2008/6/26 Hendy Irawan <[EMAIL PROTECTED]>:
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 :)
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 :)
_______________________________________________
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 <[EMAIL PROTECTED]>
Date: Fri, Jun 27, 2008 at 3:52 AM
To: General OPS4J <general@lists.ops4j.org>
2008/6/26 Stuart McCulloch <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Date: Fri, Jun 27, 2008 at 12:59 PM
To: General OPS4J <general@lists.ops4j.org>
2008/6/27 Hendy Irawan <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Date: Fri, Jun 27, 2008 at 1:12 PM
To: General OPS4J <general@lists.ops4j.org>
Cc: Peter Kriens <[EMAIL PROTECTED]>
1. 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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Date: Fri, Jun 27, 2008 at 1:27 PM
To: General OPS4J <general@lists.ops4j.org>
Cc: Peter Kriens <[EMAIL PROTECTED]>
2008/6/27 Hendy Irawan <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>
Date: Fri, Jun 27, 2008 at 2:47 PM
To: General OPS4J <general@lists.ops4j.org>
Cc: Peter Kriens <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
