4 Replies Latest reply on Aug 5, 2011 10:08 AM by kcbabo

    Versioning of modules in AS7

    beve

      Hi,

       

      I've been working on a task that involved upgrading Camel to 2.8.0 and in the process I've added a version slot to the Camel modules.

      I was thinking that it would be nice to do the same for our own modules too. For example, for our components we could add a version slot that would be the current version of SwitchYard.

       

      Thoughts on this?

       

      Regards,

       

      /Daniel

        • 1. Re: Versioning of modules in AS7
          rcernich

          Hey Daniel,

           

          I think this is a good idea.  It shouldn't be hard to add a version selector into the AS7 SwitchYard subsystem modules configuration.

           

          Rob

          • 2. Re: Versioning of modules in AS7
            kcbabo

            I looked through the existing module definitions for AS and they all appear to use main unless two incompatible versions of a module are required. I like the idea of being able to use a version slot for these exceptional cases, but I'm not sure what it buys us to start out this way.  I definitely could be missing something though. :-)  BTW, not sure if you've seen the module identifier documentation which covers slots here:

             

            https://docs.jboss.org/author/display/MODULES/Module+names

             

            So it seems like the approach should be to go with the default slot as a primary option and use version-specific slots as they become necessary.

            • 3. Re: Versioning of modules in AS7
              beve

              I looked through the existing module definitions for AS and they all appear to use main unless two incompatible versions of a module are required.

              Yeah, I have noticed this too and I'm sure there is a good reason for this but I would rather have an explicit version instead of the default 'main' version slot. If I see a dependency to 'org.apache.commons.collection' I know this implies 'org.apache.commons.collection:main'. To find out which version that is in use for this dependency, I have to look into the module.xml file for this module. Having 'org.apache.commons.collection:3.2.1' would save me from doing this.

               

              I like the idea of being able to use a version slot for these exceptional cases, but I'm not sure what it buys us to start out this way.

              I just think it makes it easier to determine what version of module you are using. And when a new version of SwitchYard is installed, existing SwitchYard deployments should be unaffected since they depend on the previous version. This is still possible with defaulting to the default 'main' version but if we get into the habit of doing this ourselves we might be able to pick up on any issues that could pop up.

               

              So it seems like the approach should be to go with the default slot as a primary option and use version-specific slots as they become necessary.

              I'm getting the feeling that I'm missing some easy way of gathering dependency info about the dependencies that a deployment has   Can anyone enlighten me?

               

              Thanks,

               

              /Daniel

              • 4. Re: Versioning of modules in AS7
                kcbabo

                I will ask the AS folks, but the main (no pun intended) issue I see here is that I'm not sure how flexible the versioning support is for slots.  In OSGi, for example, you can provide version ranges for dependencies (e.g. anything within 5.x is good).  I don't see a way where you can do that with modules in AS7.  You have the option of providing a specific slot name and that's it.  The upshot of this is that a patch to a given module with a specific slot name would require updates to all the other modules which specifically depend on that slot.  I'm assuming that's why they went with the strategy of using 'main' as the default module slot and additional slots are used when incompatible changes are introduced.  That's a lot of assuming on my part though, so I'll ask some folks that really know what they're talking about (unlike me). :-)