Stop embedding libs in OSGi bundles?

[Antonio García Domínguez]

Hi all,

We've been running again and again into problems when combining BPELUnit and our Eclipse plugins, especially because BPELUnit embeds a lot of its libraries inside its own plugins instead of using separate bundles (the current best practice).

I think we should make the build infrastructure a bit more clear on the Eclipse side. Perhaps we should try and make all our modules have manually specified Eclipse projects with plugin- and package-based dependencies instead of the current mix of project, plugin, package and embedded dependencies.

What do you guys think?

Best regards,

Antonio

[Tammo van Lessen]

Hi Antonio,

sounds reasonable to me, perhaps that would also provide a solution for that nasty InputStream exception, that shows up periodically yet undeterministic... My impression is that this is a classloading/dependency issue.

Best,

  Tammo

--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "BPELUnit" sind.
Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an bpelunit+u...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out

--
Tammo van Lessen - http://www.taval.de

[Antonio García Domínguez]

Hi Tammo,

Yes, it very well might be. Sorry, I saw your Github report but I'm currently busy preparing the defense for my dissertation, so I haven't been able to do much about it :-/.

I tried several solutions for two days, but in the end I had to patch up my existing issue quickly and move on. I concluded that doing this properly would probably need repackaging all our deps as OSGi bundles a P2 site and defining an explicit target platform for our Eclipse plugins. I found that quite a few of our dependencies are already available as OSGi bundles through the kind folks at Eclipse Orbit, but we'd still need to do a few ourselves and then test them out.

The problem is where we could host the P2 site and how to maintain it. Daniel, do you think we could use a subfolder in bpelunit.github.com for that?

Best regards,

Antonio

[Daniel Lübke]

Hi,

sorry for replying so late.

I don't know OSGI very much but isn't there a way to make it encapsulate a JAR in the plug-in? As Tammo already said we struggle with different Velocity-Tools versions of BPELUnit and the Eclipse Maven Plugin. I would have asumed that OSGI takes care of this.

If repackaging all JARs is the only solution then we should do this quickly. I don't know GitHub's policies on this, i.e. whether we can host this on a GitHub page or not.

Daniel

[Antonio García Domínguez]

Hi Daniel,

I believe that as long as we don't bundle too many binaries we should be fine. Most of our binaries would already come from the Eclipse Orbit update site, so we'd only have to redistribute some of the .jar files.

Eclipse provides some facilities for making OSGi bundles out of .jar files, but the generated OSGi metadata still needs some manual tweaking and testing and that'll take at least a week of work between repackaging, testing and deployment. I could do that after my PhD defense in December, if that's OK with you.

Best regards,

Antonio

--

[Daniel Lübke]

Hi, perhaps we can take this opportunity and tidy up dependencies a bit. E.g. I would prefer to kill the alternative File API that is being used. Every dependency that is not already packaged by somebody else would be a good candidate IMO.

Regards,
Daniel

[Antonio García Domínguez]

Hi Daniel,

Yeah, that would be nice. So far, the only problem is that the alternative ZipFile has a bit more logic than the default functionality in the JDK, but making a wrapper for this and/or touching up the existing code shouldn't be too hard.

Regards,

Antonio

2013/11/20 Daniel Lübke <daniel...@gmail.com>

Hi, perhaps we can take this opportunity and tidy up dependencies a bit. E.g. I would prefer to kill the alternative File API that is being used. Every dependency that is not already packaged by somebody else would be a good candidate IMO.

Regards,
Daniel

--

[Daniel Lübke]

Hi,

I posted a new branch to Github (Main Repo) for a version in which TrueZip is eliminated. Can anyone test the ODE Deployer by giving a directory to package? I currently have no ODE installed.

Regards,
Daniel

[Daniel Lübke]

Hi,

did we agree on something? I wanted to try packaging the current snapshot and Eclipse obviously fails because it cannot find the new plugins.

Daniel

[Antonio García Domínguez]

Hi Daniel,

Yes, we agreed on doing this after I finished with my PhD. I'm doing it bit by bit now, but I'm not done yet :-).

Best regards,

Antonio

On 17 December 2013 14:20, Daniel Lübke <daniel...@gmail.com> wrote:

Hi,

did we agree on something? I wanted to try packaging the current snapshot and Eclipse obviously fails because it cannot find the new plugins.

Daniel

Am Freitag, 15. November 2013 21:30:44 UTC+1 schrieb Antonio García Domínguez:

Hi Daniel,

I believe that as long as we don't bundle too many binaries we should be fine. Most of our binaries would already come from the Eclipse Orbit update site, so we'd only have to redistribute some of the .jar files.

Eclipse provides some facilities for making OSGi bundles out of .jar files, but the generated OSGi metadata still needs some manual tweaking and testing and that'll take at least a week of work between repackaging, testing and deployment. I could do that after my PhD defense in December, if that's OK with you.

Best regards,

Antonio

On 15 November 2013 14:39, Daniel Lübke <daniel...@gmail.com> wrote:

Hi,

sorry for replying so late.

I don't know OSGI very much but isn't there a way to make it encapsulate a JAR in the plug-in? As Tammo already said we struggle with different Velocity-Tools versions of BPELUnit and the Eclipse Maven Plugin. I would have asumed that OSGI takes care of this.

If repackaging all JARs is the only solution then we should do this quickly. I don't know GitHub's policies on this, i.e. whether we can host this on a GitHub page or not.

Daniel

--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "BPELUnit" sind.

Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an bpelunit+u...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out

--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "BPELUnit" sind.

Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine E-Mail an bpelunit+u...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out