The deployment packaging does not have to be tied to the release cycle /
code management.
Think about the simple use case where you implement a public interface: you
don't release the API (it may never change), but you're still free to embed
the API in your bundle or not.
Also, the use case for
Hi,
I think it's better to separate bundle interface and bundle
implementation, you can have many implementations of the same interface
(like OSGi specifications) and you can release a new implementation
version without release the api version. Generally, implementations
bundles are releases more
Why do you advise that fat bundles should be avoided? My current idea of good
osgi design is to only export service interfaces, and generally package the
interfaces with the implementations; since jarA and libA aren’t even bundles
they are good candidates for hiding inside bundleA since they
Did you check your import/export ?
Creating a uber bundle is also an option, but fat bundles should be avoided.
Regards
JB
On 01/04/2018 06:18 PM, GFO wrote:
Hi,
Thanks for your answer.
I have tried to create a kar file: my bundle does not find some dependencies
although dependencies are
Hi,
Thanks for your answer.
I have tried to create a kar file: my bundle does not find some dependencies
although dependencies are started as bundles.
I have the following dependencies:
BundleA (mine) depends on jarA (mine) which depends on libA (third party).
jarA and libA are wrapped as
Hi,
1/ If you really want a zip file, then take a kar.
If you want to work with a repo, feature is better.
2/ It's possible using fileinstall and specifying your folder
3/ Cave can be an option too (with Bundle Repository).
Regards
JB
On 01/04/2018 12:05 PM, GFO wrote:
Hello,
I have a
Hello,
I have a question about dependencies in Karaf.
I have a bundle which contains a lot of dependencies:
- jars created by me
- third party jars
Those dependencies may have transitive dependencies.
To deploy my application in a production environment I would like a zip file
post and to create feature for
packagingbundle/packaging
so it will include in the final feature.xml and in the
target/assembly folder
both its own bundle jar and also this' bundle dependencies;
so in my case project pom is a self-descriptor document : self
bundle
its own bundle jar and also this' bundle dependencies;
so in my case project pom is a self-descriptor document : self
bundle + dependencies;
I get both self bundle entry and dependency entires OK in the final
feature.xml
I also get all the dependencies jar OK in the target
Hey Fulco,
Short answer: The clean way to go here is to define all bundles
required in your features.xml. Everything else could generate a GREAT
mess, because (for example) not all deps have to be osginized, not all
deps import versions correctly (which leads to some problems since
transitive
: Bundle dependencies
Hey Fulco,
Short answer: The clean way to go here is to define all bundles required in
your features.xml. Everything else could generate a GREAT mess, because (for
example) not all deps have to be osginized, not all deps import versions
correctly (which leads to some problems
[mailto:anpie...@gmail.com]
Sent: vendredi, 10. juin 2011 12:40
To: user@karaf.apache.org
Subject: Re: Bundle dependencies
Hey Fulco,
Short answer: The clean way to go here is to define all bundles required in
your features.xml. Everything else could generate a GREAT mess, because (for
example
]
Sent: vendredi, 10. juin 2011 12:40
To: user@karaf.apache.org
Subject: Re: Bundle dependencies
Hey Fulco,
Short answer: The clean way to go here is to define all bundles required in
your features.xml. Everything else could generate a GREAT mess, because (for
example) not all deps have
13 matches
Mail list logo
