1 2 Previous Next 29 Replies Latest reply on Apr 23, 2008 9:38 AM by pgier

    Move dependency management back into app server svn structur

    pgier

      After spending some time updating dependencies in the component-matrix pom while working on the build-thirdparty conversion, it seems that having the component-matrix as a separate project is somewhat error prone.

      The main issue is that whenever I make a change in the component matrix I have to make sure that the app server is immediately updated to match, otherwise there are build errors. When the dependency management is part of the app server codebase, this is not an issue because everything gets committed together, and built together.

      So consider the following scenario where I want to change a groupId or a dependency or add a new dependency.


      1. Using separate component-matrix

      I have to update the component-matrix and install it locally. Then I make the matching changes to the app server poms and install it locally. If it works, I commit and deploy the component-matrix. Then I commit the changes to the app server poms.

      Now someone checks out the updates to the app server poms. They try to build, but they are missing dependencies because their component-matrix pom in their local repository is out of date (by default maven checks for snapshot updates once per day).


      2. Having dependency management in the app server svn structure.

      In this case I can just make my changes locally, test them, and then commit the changes together. If someone does an svn update it will work fine for them because they are building and installing the component-matrix stuff along with the rest of the app server.


      So option 2 seems to be significantly simpler and less error prone. Other thoughts?






        • 1. Re: Move dependency management back into app server svn stru

           

          "pgier" wrote:
          After spending some time updating dependencies in the component-matrix pom while working on the build-thirdparty conversion, it seems that having the component-matrix as a separate project is somewhat error prone.

          The main issue is that whenever I make a change in the component matrix I have to make sure that the app server is immediately updated to match, otherwise there are build errors. When the dependency management is part of the app server codebase, this is not an issue because everything gets committed together, and built together.


          Why can't the component-matrix be included in the jbossas checkout
          using the same svn mechanism as shares docbook across many projects?


          • 2. Re: Move dependency management back into app server svn stru
            pgier

            You mean using svn:externals?

            It could be done that way. That would solve a lot of the issues. The only problem with svn:externals (if I remember correctly) is that you have to specify the entire svn url. Since we use different URLs for anonymous vs non-anonymous, the anonymous checkout might not work with this.

            • 3. Re: Move dependency management back into app server svn stru
              dimitris

              My view is that the dependencies must be part of the project.

              Now, if svn:externals can do the trick, that's maybe an implementation issue.

              Depending on an external project to get your dependencies is developer-unfriendly, as you've found out (and weird, too).

              • 4. Re: Move dependency management back into app server svn stru
                dimitris

                After the last call we had, I'm even more convinced that the component-matrix pom is a bad idea.

                So in a purely dictatorship fashion, Paul is going to bring back the dependencies in the AS project. :-)

                • 5. Re: Move dependency management back into app server svn stru
                  alrubinger

                   

                  "dimitris@jboss.org" wrote:
                  After the last call we had, I'm even more convinced that the component-matrix pom is a bad idea.


                  The POM itself? Or its external location?

                  S,
                  ALR

                  • 6. Re: Move dependency management back into app server svn stru
                    wolfc

                    EJB 3 requires an electronic overview of all components used in JBoss AS 5.0.0.CR1. This is to make sure we build against the correct versions. Since Maven is currently the build system defacto it must be directly consumable by Maven.

                    How you do this? I don't care.
                    Where you put this? I don't care.

                    As long as the above requirements are met before the actual release of JBoss AS 5.0.0.CR1. So I can actually deliver something usable in that AS version.

                    • 7. Re: Move dependency management back into app server svn stru
                      dimitris

                       

                      "ALRubinger" wrote:
                      "dimitris@jboss.org" wrote:
                      After the last call we had, I'm even more convinced that the component-matrix pom is a bad idea.


                      The POM itself? Or its external location?

                      Having the AS pom.xml essentially outside the project.

                      • 8. Re: Move dependency management back into app server svn stru
                        dimitris

                         

                        "wolfc" wrote:
                        EJB 3 requires an electronic overview of all components used in JBoss AS 5.0.0.CR1. This is to make sure we build against the correct versions. Since Maven is currently the build system defacto it must be directly consumable by Maven.

                        How you do this? I don't care.
                        Where you put this? I don't care.

                        As long as the above requirements are met before the actual release of JBoss AS 5.0.0.CR1. So I can actually deliver something usable in that AS version.


                        1) Your mission is to deliver a working EJB3 implementation, not screw up the AS build.

                        2) EJB3 is only pseudo-independent as long as cyclical dependencies exist. It was a mistake to move EJB3 outside AS until this is resolved.


                        • 9. Re: Move dependency management back into app server svn stru
                          alrubinger

                           

                          "dimitris@jboss.org" wrote:
                          Having the AS pom.xml essentially outside the project.


                          That's much different than "the component-matrix pom is a bad idea". :)

                          ----

                          Though I don't much care where component-matrix lives, we've got conflicting views on the topic of what constitutes a circular dependency.

                          "adrian@jboss.org" wrote:
                          If you depend upon a jbossas sub-project then you are doing it wrong. Circular dependency anyone? :-)


                          I don't agree with the above statement. The Thread at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132229 explains this more fully. In short, the dependency chain can be "AS Assembly > EJB3 > AS Component" just fine.

                          However, if Adrian's comment is true, then moving the component-matrix POM under jbossas/trunk means we cannot depend on it, which defeats its purpose in the first place.

                          ----

                          "dimitris@jboss.org" wrote:
                          1) Your mission is to deliver a working EJB3 implementation, not screw up the AS build.


                          We've outgrown the current layout of JBossAS. EJB3, webservices, (messaging?), and any future projects need to take advantage of the same libraries/projects that AS does. JBossAS cannot lay claim to exclusive control of these projects.

                          We need to discuss and come to agreement on the direction in which we're heading by identifying the requisite use cases for both AS and AS Component Consumers.

                          Let's try to give that some attention this week.

                          S,
                          ALR


                          • 10. Re: Move dependency management back into app server svn stru
                            wolfc

                            I've got a nice analogy now: go back to Paul's original post and substitute 'component-matrix' with 'Hibernate' or 'jboss-logging' or any other common component.

                            The arguments presented by Paul will still hold up, yet we do not want these things in the AS trunk.

                            • 11. Re: Move dependency management back into app server svn stru

                               

                              "wolfc" wrote:
                              I've got a nice analogy now: go back to Paul's original post and substitute 'component-matrix' with 'Hibernate' or 'jboss-logging' or any other common component.

                              The arguments presented by Paul will still hold up, yet we do not want these things in the AS trunk.


                              That's a logical fallacy, in fact probably a few of them. :-)

                              I only have to do the exercise proposed to see its not true.


                              After spending some time updating dependencies in the HIBERNATE pom while working on the build-thirdparty conversion, it seems that having ... HIBERNATE as a separate project is somewhat error prone.

                              The main issue is that whenever I make a change in ... HIBERNATE I have to make sure that the app server is immediately updated to match, otherwise there are build errors.


                              Which plainly isn't true.

                              There's a big difference between an external project that is included in JBossAS
                              as a component and an external project that actually defines what
                              those components should be.

                              • 12. Re: Move dependency management back into app server svn stru

                                I really don't see what the disconnect is here or why it is so hard to understand.

                                There's an integration project called JBossAS that is used to aggregate
                                other components. One of those components is EJB3 which isn't an integration project
                                and therefore shouldn't be making assumptions about what JBossAS will actually use.

                                You only have to go through a few simple use cases to see it doesn't work.

                                1) Suppose JBossAS wants to integrate the latest version of the TM but EJB3 doesn't
                                want to do that. Similarly EJB3 wants to use the latest snapshot of security, but
                                JBossAS doesn't because its not ready.
                                How do you define a component-matrix that would satisfy both?

                                2) Suppose JBossAS/Component Matrix is at 5.0.0.CR1 and wants to update
                                the security project. It can't change the 5.0.0.CR1 release so it has to do
                                a new release of Component Matrix (5.0.0.CR2). JBossAS trunk then
                                changes its parent to 5.0.0.CR2. But EJB3 is still on 5.0.0.CR1

                                Defeating the whole point.

                                Of course you could use snapshots, but then why have version control at all
                                if the only way to move things forward is ignore it?

                                3) Pauls point. You can't synchronously update a component and do the work
                                the integrate it in one commit. Of course you can play around with local builds
                                in your local maven repository, but
                                * that doesn't really test it works with the real build
                                * there's a gap between the two commits
                                * two people can't work on it at the same time - how do you create a branch?

                                4) Longer term EJB3 wants to go its own way anyway so shared dependencies
                                aren't even the correct solution.

                                5) The correct way to integrate things is via interfaces NOT implementations.

                                In my view EJB3 is just being lazy (can't be bothered creating a version
                                of EJB3 that isn't so brittle to thirdparty implementation details and versions)
                                and forcing JBossAS to jump through hoops because of that.

                                • 13. Re: Move dependency management back into app server svn stru
                                  alrubinger

                                   

                                  "adrian@jboss.org" wrote:
                                  4) Longer term EJB3 wants to go its own way anyway so shared dependencies aren't even the correct solution.


                                  Yes, but in the interim, EJB3 requires the AS runtime and component-matrix was built to ensure that our compile/runtime dependencies would match.

                                  "adrian@jboss.org" wrote:
                                  5) The correct way to integrate things is via interfaces NOT implementations.

                                  In my view EJB3 is just being lazy (can't be bothered creating a version
                                  of EJB3 that isn't so brittle to thirdparty implementation details and versions)
                                  and forcing JBossAS to jump through hoops because of that.


                                  You assume that we have access to the SPI/API/interfaces required for us to build.

                                  At the moment, the "integration" project (http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/)
                                  holds SPIs for a whopping 3 projects. Until all of our AS Component dependencies are properly extracted into SPI/Impl, we'll depend on implementations and hence have a cyclic dependency preventing release.

                                  The EJB3 team's efforts towards Mavenization has lead to the discovery of cyclic dependencies in AS. The problems were already there, and the new build tool is bringing them to the surface. For this laziness, you are welcome.

                                  S,
                                  ALR

                                  • 14. Re: Move dependency management back into app server svn stru
                                    wolfc

                                     

                                    "adrian@jboss.org" wrote:
                                    "wolfc" wrote:
                                    I've got a nice analogy now: go back to Paul's original post and substitute 'component-matrix' with 'Hibernate' or 'jboss-logging' or any other common component.

                                    The arguments presented by Paul will still hold up, yet we do not want these things in the AS trunk.


                                    That's a logical fallacy, in fact probably a few of them. :-)

                                    So was the theory of Galileo. We're still looking for *our* center of the universe. :-)
                                    "adrian@jboss.org" wrote:
                                    I only have to do the exercise proposed to see its not true.
                                    After spending some time updating dependencies in the HIBERNATE pom while working on the build-thirdparty conversion, it seems that having ... HIBERNATE as a separate project is somewhat error prone.

                                    The main issue is that whenever I make a change in ... HIBERNATE I have to make sure that the app server is immediately updated to match, otherwise there are build errors.


                                    Which plainly isn't true.

                                    There's a big difference between an external project that is included in JBossAS
                                    as a component and an external project that actually defines what
                                    those components should be.

                                    Yes it's true. If I do a non-backwards compatible change on a snapshot it all breaks apart.

                                    "adrian@jboss.org" wrote:
                                    You only have to go through a few simple use cases to see it doesn't work.

                                    1) Suppose JBossAS wants to integrate the latest version of the TM but EJB3 doesn't
                                    want to do that. Similarly EJB3 wants to use the latest snapshot of security, but
                                    JBossAS doesn't because its not ready.
                                    How do you define a component-matrix that would satisfy both?

                                    Won't happen because here we actually depend on the JTA API. :-D
                                    Security I agree with you, that is currently a mess because we have no *common* SPI. Still it will always be a common dominator which governs our releases.
                                    The goal of EJB 3 project is to provide both a plugin and a stand-alone which are 100% compatible (with an independent release-cycle!). So I don't want any other versions than those of the latest AS.

                                    "adrian@jboss.org" wrote:
                                    2) Suppose JBossAS/Component Matrix is at 5.0.0.CR1 and wants to update the security project. It can't change the 5.0.0.CR1 release so it has to do a new release of Component Matrix (5.0.0.CR2). JBossAS trunk then changes its parent to 5.0.0.CR2. But EJB3 is still on 5.0.0.CR1.


                                    That is 100% correct and how I want it to be, because EJB 3 is at that point incompatible with AS 5.0.0.CR2 and must do a refactoring upgrade.
                                    So the AS product, at that point, is not ready for assemblage and waiting for the next EJB 3 release.

                                    I think I've addressed 3.
                                    "ALRubinger" wrote:
                                    "adrian@jboss.org" wrote:
                                    4) Longer term EJB3 wants to go its own way anyway so shared dependencies aren't even the correct solution.


                                    Yes, but in the interim, EJB3 requires the AS runtime and component-matrix was built to ensure that our compile/runtime dependencies would match.

                                    No, we don't. :-)
                                    AS is our primary staging platform and the stand-alone is mostly a facilitator for unit testing.

                                    "adrian@jboss.org" wrote:
                                    5) The correct way to integrate things is via interfaces NOT implementations.

                                    If you mean public API/SPI then I completely agree with you.

                                    The main problem I see is that AS trunk defines facilitating components which are used by a lot of projects (not just EJB 3) (dare I mention jboss-as-aspects ;-) ). As Andrew says, we're just the messengers.

                                    1 2 Previous Next