Hey Harald,
On Thu, Aug 4, 2011 at 22:41, Harald Wellmann <[email protected]>wrote:
> I've started digging into this feature, and I now have some intermediate
> results and suggestions:
>
First of all: I really like this feature. We're discussing for a while now
at the Apache Karaf project how we could provide support for something like
jetty:run for Karaf itself. Some feature which also allows to work against
exploded bundles, similar to jetty. With this upgrade making it into pax-url
we would be one step closer to this goal. So your work in this area is very
appreciated. Thanks!
> 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?)
3) reference: URLs also work for bundle JARs, e.g. reference:file:/home/**
> hwellmann/targetPlatform/**plugins/mybundle.jar. The difference between a
> reference: and a file: URL is that reference: bundles are provisioned
> in-place, without copying them to the Equinox install area.
>
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. Another point jumping into my mind. I haven't
looked this up by now but is the reference: url part of the osgi-spec?
> 5) Thus, I think it would be a useful extension for Pax Runner to support
> the reference: protocol, not only for my original use case of provisioning
> exploded bundles directly from the Eclipse workspace.
>
Definitely and not only for eclipse. Also from IDEA and Netbeans. Although
the majority of people I know use Eclipse many guys I know from OpenSource
projects (also here at OPS4J) use intellij (free license for OS/Apache
developement). So it would be a great loss if we do not look at those IDEs
too.
@PaxRunner: once you've added the new feature to pax-url you'll get the
support PaxRunner for free :-)
> 6) I locally created a new module pax-url-reference (based on pax-url-link)
> to support the reference: protocol.
>
> 7) I added the new reference: handler to default.handlers in
> runner.properties.
>
> 8) I changed the aggregator POMs of Pax Exam 2 and Pax Runner to use my
> local SNAPSHOT version of Pax URL.
>
> 9) I changed PlatformImpl.downloadBundles() to pass through all bundles
> with reference: URLs as local bundles without downloading them.
>
> 10) With all these changes, I can now deploy exploded bundles to Equinox
> from Pax Exam like this.
>
> @Configuration()
> public Option[] config()
> {
> return options(
> url("reference:file:/home/**hwellmann/workspace/mybundle")**,
> junitBundles(),
> equinox()
> );
> }
>
> This is just a first shot, and I would love to hear some opinions if this
> approach makes sense at all.
>
>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.
> The interesting thing is that I didn't have to touch Pax Exam so far
> (except for the POM dependencies).
>
Same as PaxRunner here. They are working mostly via the URL registration.
Would have been very surprised if you were forced to touch anything/much in
runner or exam.
> However, a new option for Pax Exam would better support the typical use
> case of deploying multiple bundles from your workspace. I'm thinking of
> something like
>
> 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?
Kind regards,
Andreas
> What do you think?
>
>
> Best regards,
> Harald
>
>
>
> Am 26.07.2011 23:57, schrieb Toni Menzel:
>
>> Its currently not directly supported (if normal "urls" do not work).
>>
>> What you can try is using the "url()" option and passing a equinox string
>> into it,
>> so like you say:
>> url("bundle:/path/to/**workspace/project/bin")
>> but i'm pretty sure something in Exam will check this and probably not
>> "understand".
>>
>> If equinox has this feature, it should be pretty simple to implement as
>> its just about leaving the url identifier untouched as much as possible and
>> pass it over to the osgi framework.
>>
>> I hope to have a look at it and either directly do it or at least give
>> pointers.
>>
>> What would help definitely is a specific example that is known to work
>> with equinox.
>>
>> Thanks for suggesting this one!
>> Toni
>>
>> On Jul 26, 2011, at 9:22 PM, Harald Wellmann wrote:
>>
>> Does Pax Exam support exploded bundles, i.e. unpacked JARs?
>>>
>>> Use case: I would like to run Pax Exam tests directly from my Eclipse
>>> workspace, working on workspace bundles/projects.
>>>
>>> AFAIK, Equinox supports URLs like bundle:/path/to/workspace/**project/bin
>>> (I'm not sure about the exact syntax) for provisioning exploded bundles, so
>>> I think it should be sufficient for Pax Exam and/or Pax Runner to wrap these
>>> URLs in suitable options and forward them to Equinox.
>>>
>>> If this is not currently supported, I wouldn't mind trying to implement
>>> this feature, if someone could give me some pointers where to start...
>>>
>>> Best regards,
>>> Harald
>>>
>>
> ______________________________**_________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/**mailman/listinfo/general<http://lists.ops4j.org/mailman/listinfo/general>
>
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
