BndTools Export problem : launch.bundles (Export feature/export button)

[flang...@gmail.com]

Hi,

some feedback on what I am doing wrong would be helpful. I have a run description of my project

1. I runt the run descriptor successfully 

2. Now, I want to deploy somewhere else 

3. I click the Export button on the run descriptor dialog and export to folder 

flangels-MacBook-Pro:bndtest flangel$ ls -la
total 1152
drwxr-xr-x 5 flangel staff 170 Apr 27 13:36 .
drwxr-xr-x+ 107 flangel staff 3638 Apr 27 14:06 ..
drwxr-xr-x 26 flangel staff 884 Apr 27 13:36 bundles
-rw-r--r-- 1 flangel staff 584278 Apr 27 13:36 launch.jar
-rw-r--r-- 1 flangel staff 1233 Apr 27 13:36 launch.properties 

4. Now I run the launch.jar 

flangels-MacBook-Pro:bndtest flangel$ sudo java -jar ./launch.jar ./launch.properties
Password:
java.lang.NullPointerException
at java.util.StringTokenizer.<init>(StringTokenizer.java:199)
at java.util.StringTokenizer.<init>(StringTokenizer.java:221)
at aQute.launcher.constants.LauncherConstants.split(LauncherConstants.java:129)
at aQute.launcher.constants.LauncherConstants.<init>(LauncherConstants.java:114)
at aQute.launcher.Launcher.<init>(Launcher.java:155)
at aQute.launcher.Launcher.main(Launcher.java:88)
at launch.main(launch.java:13)
flangels-MacBook-Pro:bndtest flangel$ 

5. Decompiling the launch.jar reveals this line to be the culprit. 

I assume launch.bundles is not set... Any idea why ? Do I have to set this ?

public LauncherConstants(Properties p)
{
this.services = Boolean.valueOf(p.getProperty("launch.services")).booleanValue();
if (p.getProperty("launch.storage.dir") != null)
this.storageDir = new File(p.getProperty("launch.storage.dir"));
this.noreferences = Boolean.valueOf(p.getProperty("launch.noreferences")).booleanValue();
this.keep = Boolean.valueOf(p.getProperty("launch.keep")).booleanValue();
this.runbundles.addAll(split(p.getProperty("launch.bundles"), ","));
this.systemPackages = p.getProperty("launch.system.packages");
this.systemCapabilities = p.getProperty("launch.system.capabilities");

thanks a bunch

Frank

[Janek Röhl]

I've had the same problem.
Here is what I did :

You could click on Export and create a single jar.
There should be a launcher.properties file, which has to be extracted.
Two line have to be modified :
launch.embedded=true -> launch.embedded=false
launch.bundles=jar/*bundle*.jar -> launch.bundles=bundles/'bundle*.jar

then you have to rename it to launch.properties.

Seems like this, i guess gradle script, does not convert the bnd-tools arguments runbundles to launch.bundles

I would guess, you've already discovered this 'failure'
Hopefully, others will see it - a shortcut instead of decompiling or whatsoever

Regards,
Janek

[BJ Hargrave]

This may be related to https://github.com/bndtools/bnd/issues/980. Can you add your information to the issue?

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

BJ

[Peter Kriens]

Why not run it as an exported jar???

java -jar whatever.jar

That is how it was designed (and actually tested), is there a particular reason to expand it to bundles?

Kind regards,

Peter Kriens

[Peter Kriens]

I wrote the export to JAR function and thought the export to folder was just a simple expansion of that JAR. It turns out that this is not the case. As far as I can see the export to folder makes assumptions about the internals of the launcher that it should not, see the new remote launcher that will support exports to KAR, Features, WAR, etc) that is completely broken with this code. I am actually surprised that it works with Equinox since it looks like the Equinox

So the best way to use executable jars is to export them as a jar:

$ bnd package demo.bndrun # or via the button to export button
$ java -jar demo.jar


If you feel the need to expand it to folders:

$ unzip ../demo.jar
$ ls
META-INF aQute jar launcher.properties
$ grep Main-Class META-INF/MANIFEST.MF
Main-Class: aQute.launcher.pre.EmbeddedLauncher
$ java -cp . aQute.launcher.pre.EmbeddedLauncher

—-

I suggest I change the export to folder to just unzip the jar so the launcher’s abstractions are not violated.

Or does anybody knows a reason why this would not work? (I actually don’t get why anybody needs the executable to be exported to a folder anyway, JARs are imho so much simpler?)

Kind regards,

Peter Kriens

[Janek Röhl]

Well, in my case our company already built a working snapshot with different folders in which
other companies could commit there progress to the osgi snapshot.
These things existed way before bndtools, without the ease of resolve etc. from bndtools
(Knopflerfish framework with the use of .xargs files)

That is why folder structure with the different bundles was needed, because
a fat jar could have probably inherit a bundle which was already in the snapshot folder and would have
lowered the clarity of the project arrangement.

Plus, i like it more to replace a specific updated bundle in the bundle folder than updating the fat jar.

Furthermore, partners implemented applications which need configuration files, which shouldnt be in the jar
but on the deployed folder path.
Eclipse has no problem to find these files, but i didnt find the right instruction for the bndrun to export/copy
these files to the created folder. (latest solution is to just copy the files by hand)
Maybe these specific needs should be accomplished by writing a plugin and adding it to the cnf.


Regards,
Janek

[Peter Kriens]

So it sounds you need more of a feature model? The idea of an executable JAR is that it is self contained. (The intention is that it actually should also contain the configuration.) However, I understand that you use the folder export as an intermediate stage where it is merged with the output of others?

How do you handle the resolving this? The other bundles that were not part of the original resolve could influence your runtime results?

Thanks for this kind of feedback. I always like to hear how people are using this stuff.

Kind regards,

Peter Kriens 

[Iwan]

Dear Peter & others,

In the EmbeddedLauncher, why are the BND launcher (aqute.launcher.Launcher etc.) and Felix Framework copied to a temporary file on disk (resource-<arbitrary number>.jar)?

In my situation I'm not using bundles from the "fat-jar" because, when expanded on disk, bundles can be installed by reference when using the launch.noreferences=false property. Saving me some space, since this doesn't create a copy of the bundle at the storage/cache location.

From the source code of EmbeddedLauncher, it seems that a seperate classpath is created with contents from the temporary created jars. Does it need the temporary jars on disk? Is there a way for me not needing this copy of the launcher and framework classes (since I already have them present in my jars-folder)?


Kind regards,
Iwan

Op woensdag 23 september 2015 11:40:04 UTC+2 schreef Peter Kriens:

[Peter Kriens]

You would have to provide a patch to the launcher for this. This is not included in the current version.

Kind regards,

Peter Kriens

[Iwan Flameling]

Dear Peter,

Thank you for your reply. Before I start working on this, could you please eloborate on why the BND launcher (aqute.launcher.Launcher etc.) and Felix Framework are copied to a temporary file on disk (resource-<arbitrary number>.jar) in the EmbeddedLauncher? I'm trying to understand this part of the code, would you please explain this to me?

Kind regards,

Iwan

Peter Kriens

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "bndtools-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bndtools-users/BH6q8sqXgyU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bndtools-users+unsubscribe@googlegroups.com.

[Peter Kriens]

The launcher was written to work from a fat JAR. This is an extremely easy to use model that does require the extraction. Initially this code used the JAR itself as the class path but it turned out that Equinox really required the Equinox JAR. I.e. you could not copy Equinox into the executable JAR. So we changed to also copy those files to a separate part of the file system.

Kind regards,

Peter Kriens