Uploaded image for project: 'Karaf'
  1. Karaf
  2. KARAF-1512

enhancement: add self to generated feature in "features-generate-descriptor" goal

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Trivial
    • Resolution: Not A Problem
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: karaf-tooling
    • Labels:
      None

      Description

      When generating features in a pom that also creates a bundle artifact of it's own, it would be useful for that generated feature XML to include the project's bundle in the list of bundles for the purposes of publishing.

      1. KARAF-1512.patch
        1 kB
        Benjamin Reed

        Issue Links

          Activity

          Hide
          rangerrick Benjamin Reed added a comment -

          Attached is a patch which implements this functionality.

          Show
          rangerrick Benjamin Reed added a comment - Attached is a patch which implements this functionality.
          Hide
          chris@die-schneider.net Christian Schneider added a comment -

          I think we should not mix generating bundles and features in the same pom.

          Show
          chris@die-schneider.net Christian Schneider added a comment - I think we should not mix generating bundles and features in the same pom.
          Hide
          rangerrick Benjamin Reed added a comment - - edited

          Would it be useful, instead, to make the karaf-maven-plugin warn and/or exit if it's run from a project that is type:bundle then? Since it creates a new classifier and attaches it to the project, I assumed that it was expected/allowed to run alongside whatever other artifacts are built as part of the pom... If it's best-practices/policy to separate them, it would be nice if it warned at least.

          Show
          rangerrick Benjamin Reed added a comment - - edited Would it be useful, instead, to make the karaf-maven-plugin warn and/or exit if it's run from a project that is type:bundle then? Since it creates a new classifier and attaches it to the project, I assumed that it was expected/allowed to run alongside whatever other artifacts are built as part of the pom... If it's best-practices/policy to separate them, it would be nice if it warned at least.
          Hide
          chris@die-schneider.net Christian Schneider added a comment -

          +1 The warning is a good idea

          Show
          chris@die-schneider.net Christian Schneider added a comment - +1 The warning is a good idea
          Hide
          pieber Andreas Pieber added a comment -

          +1 from my side too

          Show
          pieber Andreas Pieber added a comment - +1 from my side too
          Hide
          richardsenior Richard Senior added a comment - - edited

          Please can someone implement this patch...
          The ability to have all bundles create their own features is incredibly useful.
          For example we use a parent POM to generate all bundles in our project, it would be great if a developer could simply drop the features XML for the bundle their working on into karaf and deploy (from Nexus say) their work, without having to create their own descriptor, or a KAR etc.

          Perhaps a switch could be added to the configuration of the maven task and defaulted to false, but could be made true, to allow addition of self to features... ?

          Show
          richardsenior Richard Senior added a comment - - edited Please can someone implement this patch... The ability to have all bundles create their own features is incredibly useful. For example we use a parent POM to generate all bundles in our project, it would be great if a developer could simply drop the features XML for the bundle their working on into karaf and deploy (from Nexus say) their work, without having to create their own descriptor, or a KAR etc. Perhaps a switch could be added to the configuration of the maven task and defaulted to false, but could be made true, to allow addition of self to features... ?
          Hide
          chris@die-schneider.net Christian Schneider added a comment -

          Why should you want to create a feature for an individual bundle? You can simply install the bundle without a feature.

          Show
          chris@die-schneider.net Christian Schneider added a comment - Why should you want to create a feature for an individual bundle? You can simply install the bundle without a feature.
          Hide
          richardsenior Richard Senior added a comment -

          The feature descriptor, and the process of deploying features is more powerful than that used to deploy individual bundles.

          So for example, in the OSGi manifest you might be specifying a version range for a dependency. If you deploy the bundle then you have no real control over exactly which version is pulled down from Nexus.
          If your POM build created a features xml for your bundle, you could fix the exact version of each dependency and it's start level. Which leads me on.. I notice that if you do specify a version range in your maven dependencies, then the generated features XML contains multiple bundle declarations for that dependency. There should be a way (in the goal config in the POM) of fixing the exact values for each dependency that is placed in the features XML.. etc.

          Show
          richardsenior Richard Senior added a comment - The feature descriptor, and the process of deploying features is more powerful than that used to deploy individual bundles. So for example, in the OSGi manifest you might be specifying a version range for a dependency. If you deploy the bundle then you have no real control over exactly which version is pulled down from Nexus. If your POM build created a features xml for your bundle, you could fix the exact version of each dependency and it's start level. Which leads me on.. I notice that if you do specify a version range in your maven dependencies, then the generated features XML contains multiple bundle declarations for that dependency. There should be a way (in the goal config in the POM) of fixing the exact values for each dependency that is placed in the features XML.. etc.
          Hide
          rangerrick Benjamin Reed added a comment -

          FYI, the karaf plugin ended up being different enough from what we're wanting to do I ended up just implementing a different plugin. You can see it here:

          https://github.com/OpenNMS/maven-plugins/tree/master/features-maven-plugin

          It's not well-documented, but there are plenty of example poms in src/integration-tests/ if you want an idea of how I ended up implementing things.

          Show
          rangerrick Benjamin Reed added a comment - FYI, the karaf plugin ended up being different enough from what we're wanting to do I ended up just implementing a different plugin. You can see it here: https://github.com/OpenNMS/maven-plugins/tree/master/features-maven-plugin It's not well-documented, but there are plenty of example poms in src/integration-tests/ if you want an idea of how I ended up implementing things.
          Hide
          richardsenior Richard Senior added a comment - - edited

          Benjamin,
          Because you've checked whether the project is a bundle, you cannot include your mojo in a parent pom. This is something that karaf-maven-plugin doesn't suffer from.
          I tried quickly hacking out "throw new .. (... is not a bundle!!) but the unit tests failed to build it.
          There should be a fail silently option, which would allow install of parent pom's featuring this plugin.

          Show
          richardsenior Richard Senior added a comment - - edited Benjamin, Because you've checked whether the project is a bundle, you cannot include your mojo in a parent pom. This is something that karaf-maven-plugin doesn't suffer from. I tried quickly hacking out "throw new .. (... is not a bundle!!) but the unit tests failed to build it. There should be a fail silently option, which would allow install of parent pom's featuring this plugin.
          Hide
          richardsenior Richard Senior added a comment -

          All, This is possible with the current 3.0.0-RC1 karaf-maven-plugin

          Simply create a template features.xml in /main/feature and add your bundle with wildcards :

          <bundle start-level="80">mvn:$

          {project.groupId}

          /$

          {project.artifactId}

          /$

          {project.version}

          </bundle>

          I've noticed that the XMLNS version number is being set to 1.2.0 which is incompatible with earlier versions of Karaf though. That needs a search and replace through your completed features.xml

          Show
          richardsenior Richard Senior added a comment - All, This is possible with the current 3.0.0-RC1 karaf-maven-plugin Simply create a template features.xml in /main/feature and add your bundle with wildcards : <bundle start-level="80">mvn:$ {project.groupId} /$ {project.artifactId} /$ {project.version} </bundle> I've noticed that the XMLNS version number is being set to 1.2.0 which is incompatible with earlier versions of Karaf though. That needs a search and replace through your completed features.xml
          Hide
          ozzyoli Oliver Wilkie added a comment -

          Richard Senior is this still the method I should pursue?

          Show
          ozzyoli Oliver Wilkie added a comment - Richard Senior is this still the method I should pursue?
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          Just use a template features XML file using the Maven data ($

          {project.groupId}

          , etc).

          Show
          jbonofre Jean-Baptiste Onofré added a comment - Just use a template features XML file using the Maven data ($ {project.groupId} , etc).

            People

            • Assignee:
              jbonofre Jean-Baptiste Onofré
              Reporter:
              rangerrick Benjamin Reed
            • Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development