6 Replies Latest reply on Aug 12, 2015 12:10 PM by Randall Hauch

    Modeshape Roadmap 4.4 and beyond?

    Richard Lucas Apprentice

      Is there any information available regarding Modeshape's roadmap, specifically related to using it with Wildfly/JBoss EAP?

       

      - Now that WIldfly 9 is released what are the plans for supporting Modeshape as a sub-system on Wildfly 9?

      - Wildfly 10 is already in beta and I believe will be used as the baseline for JBoss EAP 7 (due later next near). Are their plans to provide Modeshape a a sub-system for these releases in the future?

      - Infinispan 8 in now in beta and has a number of improvements that would benefit Modeshape. Is moving to to 8 on the roadmap once it is released?

      - Are there any plans to support deploying Modeshape as a Fraction in Wildfly-Swarm?

       

      Any details you can provide would be a great help.

       

      I also wanted to add a belated congratulations on 4.3.0. Removing the sub-systems dependency on the Infinispan sub-system and bundling the latest version with Modeshape was a great move forward for Modeshape.

        • 1. Re: Modeshape Roadmap 4.4 and beyond?
          Horia Chiorean Master

          - Now that WIldfly 9 is released what are the plans for supporting Modeshape as a sub-system on Wildfly 9?

          we've already done the work for supporting Wildfly 9 (see [MODE-2488] Add support for Wildfly 9 - JBoss Issue Tracker). Not only that, but the change was done in such a way as to be binary compatible with 8. So starting with 4.4 the kit will run both on Wildfly 8 and Wildfly 9.

          - Wildfly 10 is already in beta and I believe will be used as the baseline for JBoss EAP 7 (due later next near). Are their plans to provide Modeshape a a sub-system for these releases in the future?

          it depends on what the differences between 10 and 9 are. If, for example, we can move to Wildfly 10 and still be binary compatible with 9 (like with the current 9/8 change) I see no reason why we couldn't support this version of Wildfly as soon as it goes final.

          - Infinispan 8 in now in beta and has a number of improvements that would benefit Modeshape. Is moving to to 8 on the roadmap once it is released?

          in general we've tried moving to newer releases of Infinispan as soon as they go Final, mainly because they keep fixing critical bugs for us. This is one of the reasons why we pulled out the subsystem from the WF kit and moved to embedded modules dependencies instead. There is only one caveat: if the new version if Infinispan *is not binary compatible* (at a cache-store level) with the current version we're using, we most likely won't move to it until the next major release of ModeShape. The other thing we normally consider is Infinispan XML schema configuration changes: moving from 5 to 6 and from 6 to 7, Infinispan has radically changed their XML schema and some of their API - which is not ideal - but we've moved to these versions none-the-less because of issues like https://issues.jboss.org/browse/MODE-2280

          So regarding ISPN 8: once it goes final, if the cache-stores are binary backwards-compatible and there are no significant XML schema changes, we can move to it right away. If the cache stores are not binary compatible, then most likely we won't move to it until the next major version of ModeShape.

          - Are there any plans to support deploying Modeshape as a Fraction in Wildfly-Swarm

          I have limited understanding of Wildfly Swarm, but from what I've read online it's a framework for delivering "microservices" inside Wildfly. As such, I don't see how ModeShape would integrate with it, since the JCR API (or entire spec really) is not client-server oriented. The current server "endpoints" that we do have, expose a limited subset of the JCR API/operations. However, if you have a particular use case in mind for Wildfly Swarm, please tell us and we can think about it some more.

          • 2. Re: Modeshape Roadmap 4.4 and beyond?
            Richard Lucas Apprentice

            hchiorean, thanks for the information. It is useful for my planning. Do you have an estimated release date for 4.4 yet?

             

            Wildfly-Swarm is indeed targeted at micro-services but it has many uses. It's main purpose is to allow you to create applications that leverage Wildfly and it's sub-systems (called Fractions in swarm) and package them together in a single 'Fat' jar, as opposed to the traditional approach of packing your application as a WAR and deploying it to a Wildfly Application server. Given this any application designed to run as a WAR in Wildfly could in theory be repackaged using Wildfly-Swarm as a single 'Fat' jar (assuming the Wildfly features you use are supported by Swarm). This greatly simplifies deploying your applications as all you need is a server (or container e.g Docker) with the a JRE that you can drop the JAR onto and run.

             

            In my opinion Modeshape would actually work well in a Micro-Service architecture. Given that one of tenants of Micro Services is each service should use the persistence best suited for it's use case I can see many scenarios were a service may want to use a hierarchical data store such as Modeshape as it's persistence tier while exposing a service specific API that maps data in and out of Modeshape via the JCR Java API (or modeshape extensions).

             

            Modeshape can be used in Swarm today by embedding it as standalone application but there may be some benefits to providing it as a Fraction (sub-system) to make it easier to configure and start out of the box.

            • 3. Re: Modeshape Roadmap 4.4 and beyond?
              Randall Hauch Master

              Richard Lucas wrote:

              ...

              Modeshape can be used in Swarm today by embedding it as standalone application but there may be some benefits to providing it as a Fraction (sub-system) to make it easier to configure and start out of the box.

              This is the key: providing a Wildfly Swarm Fraction for the ModeShape subsystem as a Maven-addressable artifact that you can include in your Wildfly Swarm project. Then, when you build your project, Swarm will add in the ModeShape subsystem into the Wildfly that is packaged and bundled as a "fat jar". And, when you run that fat jar, your application will internally run Wildfly with the ModeShape subsystem.

               

              Unfortunately I know very little about the guts of Wildfly Swarm, and after a few minutes of googling I found very little documentation on how to write a new custom Swarm Fraction. One thing I did find was this nice overview, although it doesn't really say how to make a custom Fraction -- or for that matter whether it even makes sense to have a Fraction for a non-standard Wildfly subsystem.

               

              I personally think Wildfly Swarm is pretty interesting but because its still pretty early a lot of things might still change, including Fractions. This is a great opportunity for one of our contributors to volunteer to work on. It might mean working with the Wildfly Swarm community to figure out how to do this and whether its even a good idea. Any takers?

              • 4. Re: Modeshape Roadmap 4.4 and beyond?
                Horia Chiorean Master

                Do you have an estimated release date for 4.4 yet?

                we'll probably be releasing 4.4 towards the end of this month.

                • 6. Re: Modeshape Roadmap 4.4 and beyond?
                  Randall Hauch Master

                  Richard Lucas wrote:

                  ...

                  Wildfly-Swarm is indeed targeted at micro-services but it has many uses. It's main purpose is to allow you to create applications that leverage Wildfly and it's sub-systems (called Fractions in swarm) and package them together in a single 'Fat' jar, as opposed to the traditional approach of packing your application as a WAR and deploying it to a Wildfly Application server. Given this any application designed to run as a WAR in Wildfly could in theory be repackaged using Wildfly-Swarm as a single 'Fat' jar (assuming the Wildfly features you use are supported by Swarm). This greatly simplifies deploying your applications as all you need is a server (or container e.g Docker) with the a JRE that you can drop the JAR onto and run.

                  ...

                   

                  If you're going to use Docker, then I'm not sure I see a huge benefit to using Wildfly-Swarm. It's already pretty easy to create your own Dockerfile for your app that uses ModeShape's Docker image as a base (or create your own) and copies your WAR file into the appropriate spot. Sure, using Wildly Swarm might it slightly easier to create a Docker image from a single executable, and the Docker image is slightly smaller (if you properly configure your Wildfly Swarm build to exclude stuff you don't need). But in reality, size of the Docker image will be dictated the most by the base OS image (don't flak out and use a crappy Linux flavor), and secondarily by the JDK (or JRE if you're super stingy). A full Wildfly and ModeShape are a relatively small portion of the Docker image, so using Wildfly Swarm won't decrease the Docker image size that substantially.

                   

                  Where I think Wildfly Swarm really benefits is by letting you create an app that has (the important parts of) Wildfly (and perhaps ModeShape) embedded in your app. Wildfly Swarm is still pretty new and very alpha, but we'd welcome any attempt to create a Fraction for ModeShape.