Am 05.08.2011 06:24, schrieb Andreas Pieber:
1) Equinox handles exploded bundles from the Eclipse workspace via
URLs of the form reference:file:/home/__hwellmann/workspace/mybundle/
2) To build the correct bundle classpath, Equinox needs the usual
PDE build.properties file in the bundle root folder.
one thing which jumps into my mind here: if those properties are
available fine; but do we have to provide them? For example: I'm
developing my bundle with e.g. IDEA, or in VI using the
maven-bundle-plugin. Do I have to add the build property or can we
modify e.g. the maven-bundle-plugin to autogenerate this file in
target/build.properties. Can we use this file if it is located somewhere
else (as in the target folder?)
AFIAK, build.properties is optional. You only need it when your
directory structure does not exactly match the layout of an unzipped
bundle JAR.
Working with Eclipse PDE, you normally have a directory structure like
mybundle/
bin/
src/
META-INF/
so the class files are not in the bundle root, but in bin/. Both Eclipse
IDE and the Equinox runtime look in build.properties to find the
location of the class folder(s).
When you export the bundle/plugin or use the PDE batch tools, the class
files end up in the bundle root again, so you don't want to set the
Bundle-ClassPath to bin/ in the manifest.
Working with some other IDE or with Maven from the command line, you
don't need build.properties as long as you have a standard directory
structure. Equinox should be able to provision your bundle from an URL like
reference:file:/home/hwellmann/workspace/mybundle/target/classes/
I'll check this and write some JUnit tests to confirm my assumptions.
good to know :-) Makes perfect sense.
4) Felix also appears to support reference: URLs, at least for
regular bundles, but I haven't tried this.
Would be really cool if we could get the verification here that this
also works. There are many ppl out there basing their work on Apache
Felix and it would be a great loss if this pax-url extension could only
be used in combination with Equinox.
Sure... I'm planning to work bottom up and commit my changes first to
Pax URL and then to Pax Runner.
This will be the basis for some new integration or regression tests in
Pax Exam, and fortunately Pax Exam makes it easy to switch the
underlying framework.
Another point jumping into my mind.
I haven't looked this up by now but is the reference: url part of the
osgi-spec?
OSGi Core Spec 4.3 has no reference to "reference:" - pun intended :-)
From what you've described by now this makes great sense to me. Still I
would really like to see your changes (they don't have to be perfect
:-)). Since you've push rights to the OPS4J repos you can either push
your branch directly or in a fork.
I'll do some cleanup and hopefully commit everything over this weekend.
There is http://team.ops4j.org/browse/PAXURL-137 as a starting point, so
I hope it's ok to simply assign this issue to myself and start committing.
I'll create separate issues for the changes in Pax Runner and Pax Exam,
and I'll have to update some dependency versions in Runner and Exam from
a previous release to the current snapshot, hoping this won't break
anything for anyone else.
explodedBundles().root("/home/__hwellmann/workspace")
.bundle("mybundle1")
.bundle("mybundle2")
.bundle("mybundle3")
Basically yes. What I do not like is the absolute path here (since you
may also like to run the itests by maven on a build server). What might
be interesting is setting them via a system variable and also add
back-fall-bundles to make sure that the same tests would also run on
e.g. Hudson?
Yes, of course you don't want any absolute local paths in your Exam
test, this was just an example, you can always pull the value from a
system property.
And I like your idea of a fall-back configuration, e.g. "take this
bundle from the following "reference:" URL, and if the path does not
exist, try a Maven artifact instead".
Would this be the first case of a cascading bundle lookup in
Exam/Runner, or is there already a general fall-back or search path
mechanism?
Best regards,
Harald
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
