2 Replies Latest reply on Mar 12, 2014 12:19 PM by Gary Brown

    Common Karaf features

    Gary Brown Master

      Currently SRAMP has a features.xml for its project, which includes a feature for third party dependencies. The features.xml is automatically generated - which is a good thing here, as there are a lot of dependencies.


      RTGov also has some thirdparty dependencies that are included as part of its set of features, although currently far less than sramp, so have been manageable.


      However now that rtgov is changing from using cxf to RESTeasy for the REST services, it will also increase the number of thirdparty dependencies.


      Therefore, rather than each sub-project having a 'third-party dependencies' feature which just includes a large number of bundles and imports jars, was wondering whether we should attempt to create some smaller features in overlord-commons for some of the key dependencies, e.g. resteasy, infinispan, modeshape, etc.? Then in the future, when these projects provide their own features, we can just switch over?



        • 1. Re: Common Karaf features
          Eric Wittmann Apprentice

          I am 500% in favor of this approach.  The main reason I haven't done this already was that it was pretty daunting.  For example, s-ramp depends on resteasy and modeshape (to name only two).  Each of those dependencies might also depend on apache commons or http client or whatever.  It has the potential to snowball a bit, so I cut my losses as soon as I got everything actually working.


          The current plugin that s-ramp is using to generate the features.xml file may need some improvements if you are interested in using it for this purpose.  I'd say give it a try and I'm happy to work with you to enhance it if necessary.

          • 2. Re: Common Karaf features
            Gary Brown Master

            Ok, sounds like a good target to aim for, but possibly (if as daunting as you say) may not be possible before the next release.


            So initial step I'll take the same approach as you have done for sramp, and then we can look to refine over time.