Databases
StackOverflow2013
Postsdbo
POswitching to gradle from maven to manage a osgi big project (>200 bundles)
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POswitching to gradle from maven to manage a osgi big project (>200 bundles)
    primarykey
    data
    text
    <p>We have a big (~215 bundles and counting) osgi (felix+springdm) project, build with maven and maven-osgi plugin.</p> <p>We've several problems with maven way:</p> <p>1.　submodules pom have to inherit from parent pom to take advantage of common variables and dependencies (that's ok) but then parent pom has to include all bundles pom to be able to build everything in together. This kind of circular reference makes much hard to keep all in sync.</p> <p>2.　the individual versioning of subbundles was so complex that it was decided (before I joined the project) to use the same version for all bundles. This means we now update version of all bundles for every release also if just a bunch of them are actually changed. This makes the whole concept of osgi a bit meanless IMHO. Please note that I'm not saying we continue to touch just a minority of bundles, we work on all of them but every release usually contains 1 or 2 features, that affects just some bundles.</p> <p>3.　to do the package and the deploy of the final artifact we need still another submodule that imports all the bundles needed for the deploy (all but a few for tests and mocks). [edited] Note that this aggregation is different from the one in the main pom as it doesn't compile bundles but just pick them from the maven repository.</p> <p>4.　the maven dependency system and the osgi plugin imports are sometimes hard to keep aligned. It's just too easy to forget an import or putting a wrong dependency.</p> <p>[edited] In every bundle pom there is a section like this: `</p> <pre><code> &lt;plugin&gt; &lt;groupId&gt;org.apache.felix&lt;/groupId&gt; &lt;artifactId&gt;maven-bundle-plugin&lt;/artifactId&gt; &lt;extensions&gt;true&lt;/extensions&gt; &lt;configuration&gt; &lt;instructions&gt; &lt;Export-Package&gt; &lt;/Export-Package&gt; &lt;Import-Package&gt; com.google.gson, org.apache.log4j, org.apache.log4j.spi, org.dom4j, com.myinterfaces &lt;/Import-Package&gt; &lt;/instructions&gt; &lt;/configuration&gt; &lt;/plugin&gt;` </code></pre> <p>For all those reasons, we are ok but not perfectly happy with maven. Recently someone proposed Gradle not as a panacea but as a definite improvements over the current situation.</p> <p>Would you recommend moving to gradle? and in case which would be the best way?</p> <p>Has someone else experienced the same situation? I think it should be common for all big projects with Osgi.</p> <p>Disclaimer: I looked for similar questions like:</p> <p><a href="https://stackoverflow.com/questions/1306579/buildr-gradle-or-wait-for-maven-3">Buildr, Gradle or wait for Maven 3?</a></p> <p><a href="https://stackoverflow.com/questions/2635113/looking-for-a-good-dev-environment-for-osgi-bundles">Looking for a good dev environment for OSGi bundles</a></p> <p><a href="https://stackoverflow.com/questions/375172/maven-osgi-bundles-and-multi-modules-projects">Maven : OSGI, bundles and multi-modules projects</a></p> <p>but either where where not about osgi submodules or not about gradle.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USUberto
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POswitching to gradle from maven to manage a osgi big project (>200 bundles)
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POswitching to gradle from maven to manage a osgi big project (>200 bundles)
      1. USextraneon
      1. VTFavorite
    3. VO
      singulars
      1. POswitching to gradle from maven to manage a osgi big project (>200 bundles)
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'm watching this question like a hawk. We'll be porting a similarly large piece of software to OSGi soon and already have complicated dependencies. So I'm praying for a silver bullet here :)
      singulars
      1. POswitching to gradle from maven to manage a osgi big project (>200 bundles)
      1. USextraneon
    2. COI'm curious about your point number 4. You don't state it explicitly but it sounds like you are using the maven-bundle-plugin, which internally uses bnd to generate the MANIFEST.MF. In that case, why do you need to manually maintain imports? Since bnd generates the Import-Package statement by analysing your bytecode, it is essentially impossible to "forget an import". Bnd would also likely improve your version management too...
      singulars
      1. POswitching to gradle from maven to manage a osgi big project (>200 bundles)
      1. USNeil Bartlett
    3. COYes we're using maven-bundle-plugin, I edited the question with an example.
      singulars
      1. POswitching to gradle from maven to manage a osgi big project (>200 bundles)
      1. USUberto
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload