Re: What is the recommended way to deploy a module with dependencies?

[Jean-Baptiste Onofré]

My point was that most of Karaf examples use features (as described in 
the README.md), so you can see there how to play with import packages 
and the way to write a Karaf feature.


Regards
JB

On 25/08/2021 11:36, Xad Kile wrote:
@Jean-Baptiste Onofre: I have been studying the official examples, but 
haven't figured out a way to make the whole building process painless. I 
must have missed something as I often do. But Steinar Bang's examples 
really show me the way.
@Steinar Bang: OMG, your project gives me so much enlightenment, thanks 
a million times.


Thank you all so much for helping me overcome this block :D
Kile

On Tue, Aug 24, 2021 at 11:15 PM Steinar Bang > wrote:


 > Jean-Baptiste Onofre mailto:j...@nanthrax.net>>:

 > Hi,
 > You can take a look on the karaf examples.

 > Basically, you have two options:

 > 1. You create a feature containing your module/bundle and the
dependency bundles, playing with import package
 > 2. You create a uber bundle embedding the dependencies (private
package or embed dependency)

 > The preferred approach is probably 1.

FWIW, alternative 1 is my preferred approach.

My applications consist of a cloud of bundles and a feature pulling them
in (this let me "mix and match", ie. switch between production database
and test database, and either pull in a dependency or have it be
provided).

Here's an example uber-feature:

https://github.com/steinarb/ukelonn/blob/master/karaf/src/main/filtered-resources/feature.xml#L16



At the top it pulls in all of the feature reposiories that are built
together with my OSGi bundles, and attached to the OSGi bundles
(creating features and attaching them, is done by the
karaf-maven-plugin).

Then I create some high level features that I use to load the
application in different configuration:
  1. ukelonn-with-derby loads the application with an in-memory test
     database with dummy data
  2. ukelonn-with-postgresql loads the application with a PostgreSQL
     database
  3. ukelonn-with-postgresql-and-provided-authservice expects an
     authservice application to already be loaded (authservice provides
     authentication and authorization using apache shiro)

Re: What is the recommended way to deploy a module with dependencies?

[Xad Kile]

@Jean-Baptiste Onofre: I have been studying the official examples, but
haven't figured out a way to make the whole building process painless. I
must have missed something as I often do. But Steinar Bang's examples
really show me the way.
@Steinar Bang: OMG, your project gives me so much enlightenment, thanks a
million times.

Thank you all so much for helping me overcome this block :D
Kile

On Tue, Aug 24, 2021 at 11:15 PM Steinar Bang  wrote:

> > Jean-Baptiste Onofre :
>
> > Hi,
> > You can take a look on the karaf examples.
>
> > Basically, you have two options:
>
> > 1. You create a feature containing your module/bundle and the dependency
> bundles, playing with import package
> > 2. You create a uber bundle embedding the dependencies (private package
> or embed dependency)
>
> > The preferred approach is probably 1.
>
> FWIW, alternative 1 is my preferred approach.
>
> My applications consist of a cloud of bundles and a feature pulling them
> in (this let me "mix and match", ie. switch between production database
> and test database, and either pull in a dependency or have it be
> provided).
>
> Here's an example uber-feature:
>
> https://github.com/steinarb/ukelonn/blob/master/karaf/src/main/filtered-resources/feature.xml#L16
>
> At the top it pulls in all of the feature reposiories that are built
> together with my OSGi bundles, and attached to the OSGi bundles
> (creating features and attaching them, is done by the
> karaf-maven-plugin).
>
> Then I create some high level features that I use to load the
> application in different configuration:
>  1. ukelonn-with-derby loads the application with an in-memory test
> database with dummy data
>  2. ukelonn-with-postgresql loads the application with a PostgreSQL
> database
>  3. ukelonn-with-postgresql-and-provided-authservice expects an
> authservice application to already be loaded (authservice provides
> authentication and authorization using apache shiro)
>
>

Re: What is the recommended way to deploy a module with dependencies?

[Steinar Bang]

> Jean-Baptiste Onofre :

> Hi,
> You can take a look on the karaf examples.

> Basically, you have two options:

> 1. You create a feature containing your module/bundle and the dependency 
> bundles, playing with import package
> 2. You create a uber bundle embedding the dependencies (private package or 
> embed dependency)

> The preferred approach is probably 1.

FWIW, alternative 1 is my preferred approach.

My applications consist of a cloud of bundles and a feature pulling them
in (this let me "mix and match", ie. switch between production database
and test database, and either pull in a dependency or have it be
provided).

Here's an example uber-feature:
 
https://github.com/steinarb/ukelonn/blob/master/karaf/src/main/filtered-resources/feature.xml#L16

At the top it pulls in all of the feature reposiories that are built
together with my OSGi bundles, and attached to the OSGi bundles
(creating features and attaching them, is done by the
karaf-maven-plugin).

Then I create some high level features that I use to load the
application in different configuration:
 1. ukelonn-with-derby loads the application with an in-memory test
database with dummy data
 2. ukelonn-with-postgresql loads the application with a PostgreSQL
database
 3. ukelonn-with-postgresql-and-provided-authservice expects an
authservice application to already be loaded (authservice provides
authentication and authorization using apache shiro)

Re: What is the recommended way to deploy a module with dependencies?

[Jean-Baptiste Onofre]

Hi,

You can take a look on the karaf examples.

Basically, you have two options:

1. You create a feature containing your module/bundle and the dependency 
bundles, playing with import package
2. You create a uber bundle embedding the dependencies (private package or 
embed dependency)

The preferred approach is probably 1.

Regards
JB

> Le 22 août 2021 à 14:28, Xad Kile  a écrit :
> 
> Hello,
> TLDR: What is the recommended way to deploy a module with dependencies?
> 
> I am new to Karaf, and haven't figured out the right way to deploy an 
> application on Karaf.
> 
> Generally an application consists of the application code and dependencies.
> 
> For application code, I think there's only one and reasonable way to deploy, 
> and that is: build the code into bundles and install the bundles (manually or 
> using karaf-maven-plugin)
> 
> For dependencies, there are more than one way to delivery dependencies into 
> Karaf:
> 
> Way 1: pack the dependencies into the application bundle by manually enter 
> the dependencies' packages into  /  of 
> maven-bundle-plugin
> Pros: only one file to install
> Cons: I have to manually manage  /  
> which is very error-prone. Also there is a huge risk of missing transitive 
> dependencies.
> 
> 
> Way 2: use ,  to included the 
> dependencies into the bundle jar.
> Pros: less risky with transitive dependencies. I can control exposure of 
> the dependencies to other modules.
> Cons: Still have to manually manage which dependencies to included, 
> decide which one is public, which one is private.
> 
> Way 3: create a kar file from the project, then install the kar
> Pros: The process is mostly automatic
> Cons: 
> - All the dependencies are public and accessible to all modules
> - I have two files two install for each module: a bundle file and a 
> kar file. 
> - This still cannot handle transitive dependencies of very big 
> libraries such as Google Firebase SDK, but this is not a problem for the time 
> being.
> 
> Way 4: manually create a feature project to install bundles and features I 
> need.
> 
> Currently, I use:
> - "Way 4" to install globally-used dependencies (Apache common libraries, 
> jdbc, etc).
> - "Way 3" to install dependencies of a module that I might want to share with 
> other modules
> - "Way 2" to install private dependencies that I don't want to share with 
> other modules
> 
> I don't know if I am missing anything but this is a lot of work and 
> error-prone, anyone know a better way to do this? Something more automatic, 
> less manual, less typing.
> 
> Thank you,
> 
> Kile