Build, run and package from CLI an OSGi Felix project

[Vincenzo Mighali]

Hi all,

I'm developing an OSGi project based on the Felix implementation.

The developing environment I’m using is Eclipse equipped with Bndtools plugin. In the project, there are several packages. Each of them represents a bundle (for each package, there is a bundle descriptor, i.e. a .bnd file, and the "Enable sub-bundles" option is checked).

When I have to run the project, I simply open the bnd.bnd file and press the “Run OSGi” button. Instead, if I need to package the whole project in a single jar file in order to execute it on the “production server", I press (again in the bnd.bnd file panel) the “Export” button.

These procedures work well, but now I want to automate them in the context of a Continuos Integration flow, which is made up of a Bitbucket repo, a Jenkins server and Docker. So, how can I run my OSGi project or, even better, package it in a jar file through Command Line? In this way, the Jenkins server could package the project starting from its source code and deploy the resulting jar file on the proper docker container (currently I manually export the jar and run it on the docker container). I installed bnd from the command line and I tried the "build", “run” and “package” commands. 

The "build" command (bnd build) actually generates a jar file for each bundle in the "generated" folder, but it returns several warnings for each bundle. More specifically, for each "exported" bundle (package) it returns "The JAR is empty: The instructions for the JAR named BUNDLE_NAME did not cause any content to be included, this is likely wrong". For each private bundle it returns two additional warnings: 

1. Unused Private-Package instructions, no such package(s) on the class path: [PACKAGE_NAME]

2. Bundle-Activator PACKAGE_NAME.ACTIVATOR_CLASS_NAME is being imported into the bundle rather than being contained inside it. This is usually a bundle packaging error

The “run" command (bnd run) returns "missing dependency" errors for all bundles I have developed. Finally, the “package” command (bnd package bnd.bnd) returns the error: 

“Errors

000: For project PROJECT_NAME,  file bnd.jar,  failed to create executable exception java.lang.NullPointerException, 

001: Project has multiple bnd files, please select one of the bnd files"

P.S. I also evaluated the use of Apache Ace for CI purposes, but I was no able to successfully use it.

Thanks in advance.

Best regards,

Vincenzo

[Raymond Auge]

Going on the assumption that you have a bnd workspace which uses gradle to build.

if you run `./gradlew tasks` you should see:

Export tasks
------------
export - Export all the bndrun files to runnable jars.
export.agent.subsystem - Export the agent.subsystem.bndrun file to an executable jar.
export.demo - Export the demo.bndrun file to an executable jar.
export.launch - Export the launch.bndrun file to an executable jar.
export.x - Export the x.bndrun file to an executable jar.
resolve - Resolve the runbundles required for each of the bndrun files.
resolve.agent.subsystem - Resolve the runbundles required for agent.subsystem.bndrun file.
resolve.demo - Resolve the runbundles required for demo.bndrun file.
resolve.launch - Resolve the runbundles required for launch.bndrun file.
resolve.x - Resolve the runbundles required for x.bndrun file.
runbundles - Create a distribution of the runbundles in each of the bndrun files.
runbundles.agent.subsystem - Create a distribution of the runbundles in the agent.subsystem.bndrun file.
runbundles.demo - Create a distribution of the runbundles in the demo.bndrun file.
runbundles.launch - Create a distribution of the runbundles in the launch.bndrun file.
runbundles.x - Create a distribution of the runbundles in the x.bndrun file.

- Ray

--
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-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Vincenzo Mighali]

Dear Raymond,

thanks for your quick response.

Sorry for the dumb question, but...how can I check if my workspace uses gradle?

I ran into this doubt other times in the recent past (when I dealt dependency issues while trying to integrate wrapped external libraries...with no success), but I never found nothing in the project concerning gradle (e.g., gradle config files).

The only thing I noticed is the checked "gradle" option in Eclipse-->Preferences-->Bndtools-->"Generated Resources"-->"Create headless build template files for" section.

However, my issue is not in Eclipse. Now, I cloned the project from the Bitbucket repo and I have to build and package it in a single jar file by command line.

Vincenzo

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.

[Raymond Auge]

On Wed, Sep 13, 2017 at 3:27 PM, Vincenzo Mighali <pha...@gmail.com> wrote:

Dear Raymond,

thanks for your quick response.

Sorry for the dumb question, but...how can I check if my workspace uses gradle?

Check inside the directory which contains the projects (the directory which also contains the cnf directory).

If you see the files gradlew and/or gradlew.bat execute the appropriate one.

HTH,

- Ray

 

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.

[Vincenzo Mighali]

Il giorno mercoledì 13 settembre 2017 22:18:31 UTC+2, Raymond Auge ha scritto:

On Wed, Sep 13, 2017 at 3:27 PM, Vincenzo Mighali <pha...@gmail.com> wrote:

Dear Raymond,

thanks for your quick response.

Sorry for the dumb question, but...how can I check if my workspace uses gradle?

Check inside the directory which contains the projects (the directory which also contains the cnf directory).

If you see the files gradlew and/or gradlew.bat execute the appropriate one.

HTH,

- Ray

Inside that directory I have only the cnf directory and the project directory. The only reference to gradle that I found is a "gradle" directory (containing the biz.aQute.bnd.gradle.jar file) inside the cnf directory.

Could my project have no build automation systems? Is it possible to integrate gradle without a substantial project refactoring? If so, I would really appreciate some tips on how using gradle to automate the building process.

Thanks again

Vincenzo

[Vincenzo Mighali]

Il giorno mercoledì 13 settembre 2017 22:50:37 UTC+2, Vincenzo Mighali ha scritto:

Il giorno mercoledì 13 settembre 2017 22:18:31 UTC+2, Raymond Auge ha scritto:

On Wed, Sep 13, 2017 at 3:27 PM, Vincenzo Mighali <pha...@gmail.com> wrote:

Dear Raymond,

thanks for your quick response.

Sorry for the dumb question, but...how can I check if my workspace uses gradle?

Check inside the directory which contains the projects (the directory which also contains the cnf directory).

If you see the files gradlew and/or gradlew.bat execute the appropriate one.

HTH,

- Ray

Inside that directory I have only the cnf directory and the project directory. The only reference to gradle that I found is a "gradle" directory (containing the biz.aQute.bnd.gradle.jar file) inside the cnf directory.

Could my project have no build automation systems? Is it possible to integrate gradle without a substantial project refactoring? If so, I would really appreciate some tips on how using gradle to automate the building process.

Rereading my post I realized that my english is not so clear :( ... I would like to know if it is possible that currently my project has no build automation systems..this would explain the problems I had several times with dependencies. I would be very happy to integrate one of those tools if the procedure does not involve too changes in the project.

Vincenzo

 

[Vincenzo Mighali]

Il giorno mercoledì 13 settembre 2017 20:39:31 UTC+2, Raymond Auge ha scritto:

Going on the assumption that you have a bnd workspace which uses gradle to build.

if you run `./gradlew tasks` you should see:

Export tasks
------------
export - Export all the bndrun files to runnable jars.
export.agent.subsystem - Export the agent.subsystem.bndrun file to an executable jar.
export.demo - Export the demo.bndrun file to an executable jar.
export.launch - Export the launch.bndrun file to an executable jar.
export.x - Export the x.bndrun file to an executable jar.
resolve - Resolve the runbundles required for each of the bndrun files.
resolve.agent.subsystem - Resolve the runbundles required for agent.subsystem.bndrun file.
resolve.demo - Resolve the runbundles required for demo.bndrun file.
resolve.launch - Resolve the runbundles required for launch.bndrun file.
resolve.x - Resolve the runbundles required for x.bndrun file.
runbundles - Create a distribution of the runbundles in each of the bndrun files.
runbundles.agent.subsystem - Create a distribution of the runbundles in the agent.subsystem.bndrun file.
runbundles.demo - Create a distribution of the runbundles in the demo.bndrun file.
runbundles.launch - Create a distribution of the runbundles in the launch.bndrun file.
runbundles.x - Create a distribution of the runbundles in the x.bndrun file.

- Ray

I restarted from an empty project choosing a bndtools template. Doing so, I found several references to gradle in the project (build.gradle, gradle.properties, settings.gradle) never seen before.

So, I tried to import all packages, bundle descriptors and external bundles from the previous project to the new one. Now, from the Command Line, I am able to build the project (bnd build) and to run it (bnd run). Moreover, if I run "gradle tasks" both in the workspace directory (containing cnf and project directories) and in the project directory, I get this output:

------------------------------------------------------------

All tasks runnable from project :PROJECT_NAME

------------------------------------------------------------

Default tasks: build

Build tasks

-----------

assemble - Assembles the outputs of this project.

build - Assembles and tests this project.

buildDependents - Assembles and tests this project and all projects that depend on it.

buildNeeded - Assembles and tests this project and all projects it depends on.

classes - Assembles classes 'main'.

clean - Cleans the build and compiler output directories of the project.

cleanNeeded - Cleans the project and all projects it depends on.

jar - Assemble the project bundles.

testClasses - Assembles classes 'test'.

Documentation tasks

-------------------

javadoc - Generates Javadoc API documentation for the main source code.

Export tasks

------------

export - Export all the bndrun files to runnable jars.

runbundles - Create a distribution of the runbundles in each of the bndrun files.

Help tasks

----------

bndproperties - Displays the bnd properties.

components - Displays the components produced by project ':PROJECT_NAME'. [incubating]

dependencies - Displays all dependencies declared in project ':PROJECT_NAME'.

dependencyInsight - Displays the insight into a specific dependency in project ':PROJECT_NAME'.

echo - Displays the bnd project information.

help - Displays a help message.

projects - Displays the sub-projects of project ':PROJECT_NAME'.

properties - Displays the properties of project ':PROJECT_NAME'.

tasks - Displays the tasks runnable from project ':PROJECT_NAME'.

Release tasks

-------------

release - Release the project to the release repository.

releaseNeeded - Release the project and all projects it depends on.

Verification tasks

------------------

check - Runs all checks.

checkNeeded - Runs all checks on the project and all projects it depends on.

test - Runs the unit tests.

Rules

-----

Pattern: clean<TaskName>: Cleans the output files of a task.

Pattern: build<ConfigurationName>: Assembles the artifacts of a configuration.

Pattern: upload<ConfigurationName>: Assembles and uploads the artifacts belonging to a configuration.

Pattern: export.<name>: Export the <name>.bndrun file to an executable jar.

Pattern: runbundles.<name>: Create a distribution of the runbundles in <name>.bndrun file.

To see all tasks and more detail, run gradle tasks --all

To see more detail about a task, run gradle help --task <task>

BUILD SUCCESSFUL

Total time: 12.116 secs

This is the output when I run "gradle tasks" in the project directory. When I run it in the workspace directory, I see the WORKSPACE_NAME in place of the PROJECT_NAME.

Any ideas on how can I package the whole project in a single executable jar?

Thanks,

Vincenzo

[Vincenzo Mighali]

Il giorno mercoledì 13 settembre 2017 20:39:31 UTC+2, Raymond Auge ha scritto:

Going on the assumption that you have a bnd workspace which uses gradle to build.

if you run `./gradlew tasks` you should see:

Export tasks
------------
export - Export all the bndrun files to runnable jars.
export.agent.subsystem - Export the agent.subsystem.bndrun file to an executable jar.
export.demo - Export the demo.bndrun file to an executable jar.
export.launch - Export the launch.bndrun file to an executable jar.
export.x - Export the x.bndrun file to an executable jar.
resolve - Resolve the runbundles required for each of the bndrun files.
resolve.agent.subsystem - Resolve the runbundles required for agent.subsystem.bndrun file.
resolve.demo - Resolve the runbundles required for demo.bndrun file.
resolve.launch - Resolve the runbundles required for launch.bndrun file.
resolve.x - Resolve the runbundles required for x.bndrun file.
runbundles - Create a distribution of the runbundles in each of the bndrun files.
runbundles.agent.subsystem - Create a distribution of the runbundles in the agent.subsystem.bndrun file.
runbundles.demo - Create a distribution of the runbundles in the demo.bndrun file.
runbundles.launch - Create a distribution of the runbundles in the launch.bndrun file.
runbundles.x - Create a distribution of the runbundles in the x.bndrun file.

- Ray

ok...sorry, but I annoy you for the last time. If none can help me, I have to give up.

Again, I started a new project in Eclipse. This time I chose, unlike the other times, "Bnd OSGi Workspace", so a cnf directory was automatically created. In the cnf directory, I only created the "ext" directory in which I pasted the repositories.bnd file (copying it from the old project), where the Amdatu repositories are referenced. Then, I created a new "Bnd OSGi Project", where I pasted all the packages and bundle descriptors from the old workspace. As usual, I'm able to build and run the project from Eclipse, as well as to export an executable jar.

From the CLI, if I go the the project directory, I can build and run the project through "bnd build" and "bnd run" commands. If I go up in the parent directory (i.e. the directory that contains the cnf and project directories), I find the gradlew and gradlew.bat files. Running the ./gradlew tasks command, I see the following output:

Build tasks

-----------

assemble - Assembles the outputs of this project.

build - Assembles and tests this project.

buildDependents - Assembles and tests this project and all projects that depend on it.

buildNeeded - Assembles and tests this project and all projects it depends on.

classes - Assembles main classes.

clean - Cleans the build and compiler output directories of the project.

cleanCache - Clean the cache folder.

cleanNeeded - Cleans the project and all projects it depends on.

jar - Assemble the project bundles.

testClasses - Assembles test classes.

Build Setup tasks

-----------------

init - Initializes a new Gradle build.

Documentation tasks

-------------------

javadoc - Generates Javadoc API documentation for the main source code.

Export tasks

------------

export - Export all the bndrun files to runnable jars.

resolve - Resolve the runbundles required for each of the bndrun files.

runbundles - Create a distribution of the runbundles in each of the bndrun files.

There are also other tasks, but I think they are not useful. 

If I run "./gradlew clean", the jar files in the project_folder/generated directory are correctly deleted. However, nothing happens if I run "./gradlew build" or "./gredlew export". In the first case, only a "tmp" directory is created in the "project_folder/generated" directory, whereas in the secondo case nothing happens (even if I see the BUILD SUCCESSFUL result). 

Running those commands with the --info option, I noticed that many tasks give this output... Skipping task ':PROJECT_FOLDER_NAME:TASK_NAME' as it has no actions.

Thanks in advance 

Vincenzo

[BJ Hargrave]

Can you put your repo in github so I can look at it?

--

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

[Vincenzo Mighali]

Unfortunately, the ownership of the project is not mine, so I can't put it on a public repo. I'm developing part of the modules and I have the task to deploy the system by guaranteeing the CI...but OSGi is giving me a lot of problems and the available sources of information are very lacking..

Can I give you any further information to identify the problem?

Vincenzo

[BJ Hargrave]

Can you reduce it to an example you can share?  Without any details like your bnd files in the projects, I cannot really diagnose your problem.

Also have you looked at https://github.com/osgi/enroute.workspace/ which is the example Bnd workspace for enRoute?

[Vincenzo Mighali]

Il giorno lunedì 18 settembre 2017 17:06:39 UTC+2, BJ Hargrave ha scritto:

Can you reduce it to an example you can share?  Without any details like your bnd files in the projects, I cannot really diagnose your problem.

I'll try to do so as soon as possible

Also have you looked at https://github.com/osgi/enroute.workspace/ which is the example Bnd workspace for enRoute?

I tried this template, too. But I received an error concerning Equinox as soon as I clicked the "Run OSGi" button. Since I'm using the Felix implementation, I thought it was the wrong template. So, now I'm using this one https://github.com/bndtools/workspace

Vincenzo

[Vincenzo Mighali]

Il giorno lunedì 18 settembre 2017 17:06:39 UTC+2, BJ Hargrave ha scritto:

Can you reduce it to an example you can share?  Without any details like your bnd files in the projects, I cannot really diagnose your problem.

I wrote a simple example from scratch by following the same procedure I carry out for my project. 

Then, I pushed it on github (https://github.com/phate82/example) and cloned it from another computer to try CLI commands. 

I don't know why, but the behavior of the building process is now different: if I run "./gradlew build", the jar files are correctly generated in the "generated" directory and I can successfully run the project by launching "bnd run" from the project directory. If I run "bnd build" from the project directory, the process returns several warnings:

000: Example: Example.user.api: The JAR is empty: The instructions for the JAR named Example.user.api did not cause any content to be included, this is likely wrong

001: Example: Example.user.persistence.api: The JAR is empty: The instructions for the JAR named Example.user.persistence.api did not cause any content to be included, this is likely wrong

002: Example: Example.user.persistence.mongo: Unused Private-Package instructions, no such package(s) on the class path: [com.example.user.persistence.service]

003: Example: Example.user.persistence.mongo: Bundle-Activator com.example.user.persistence.service.Activator is being imported into the bundle rather than being contained inside it. This is usually a bundle packaging error

004: Example: Example.user.persistence.mongo: The JAR is empty: The instructions for the JAR named Example.user.persistence.mongo did not cause any content to be included, this is likely wrong

005: Example: Example.user.rest: Unused Private-Package instructions, no such package(s) on the class path: [com.example.user.rest]

006: Example: Example.user.rest: Bundle-Activator com.example.user.rest.Activator is being imported into the bundle rather than being contained inside it. This is usually a bundle packaging error

007: Example: Example.user.rest: The JAR is empty: The instructions for the JAR named Example.user.rest did not cause any content to be included, this is likely wrong

008: Example: Example.user.service: Unused Private-Package instructions, no such package(s) on the class path: [com.example.user.service]

009: Example: Example.user.service: Bundle-Activator com.example.user.service.Activator is being imported into the bundle rather than being contained inside it. This is usually a bundle packaging error

010: Example: Example.user.service: The JAR is empty: The instructions for the JAR named Example.user.service did not cause any content to be included, this is likely wrong

011: aQute.bnd.jpm.Repository is deprecated as of Bnd 3.4 and support will be removed in Bnd 4.0. Please change to another repository type.  

and the "bnd run" command fails to run bundles due to "missing requirement" errors.

Anyway, even when the project is successfully built, I can't export the executable jar by running "./gradlew export".

Vincenzo

[BJ Hargrave]

The export.* tasks operate on .bndrun files. Your Example project does not have any .bndrun files.

[Vincenzo Mighali]

Ok. I created a bndrun file for the example project. Now the "gradlew export" command works!

I thought that the bnd.bnd file would act as bndrun for the gradlew command (in Eclipse, it is no necessary to define a bndrun file). I noticed only one difference: in Eclipse, when using the bndrun file, I have to add to the "Run Requirements" all the bundles I define in the workspace, whereas by using bnd.bnd file those bundles are automatically added to the "Run Bundles".

Now, I have to understand which is the best strategy to deploy the built project on a docker container according to the CI approach...should jenkins export the executable jar from the source code and deploy it on the container? or should jenkins build a jar for each bundle and deploy all of them on the container by exploiting Apache Ace? how to treat the "conf" directory within the CI flow? etc., etc....But that is another story and shall be told another time (cit.) :D

Thanks for your support!!

Vincenzo