5 Replies Latest reply on Dec 4, 2006 7:56 PM by starksm64

    ejb3x mavenized

    wolfc

      As a precursor to the separation of ejb3 from AS. I've copied ejb3x to projects/ejb3/trunk and mavenized it.
      Please take a look and comment here.

        • 1. Re: ejb3x mavenized
          bill.burke

          You merged from TCK branch before doing this? Otherwise, might merging become a lot harder?

          • 2. Re: ejb3x mavenized
            bill.burke

            Also, if you are maveninzing EJB3, how will you get a testsuite running? Will you have a jboss installation in the project? Also, don't you think that fixing up the testsuite in HEAD and the TCK are more important than this move?

            Just asking...

            • 3. Re: ejb3x mavenized
              wolfc

              We're not going to mavenize EJB3 now. Mainly this move is to get a head start at separating out EJB3 and so I don't have to merge EJBTHREE-758 to all the branches.

              The testsuite will become a separate module in the EJB3 project. That should keep dependencies clear. I don't know yet how to get a proper instance of AS running. We need to be able to use different versions.

              I agree that fixing HEAD and CTS testsuites are the priorities of which EJBTHREE-758 was a resultant.

              • 4. Re: ejb3x mavenized
                bill.burke

                I've run into problems with the "mavenization" of the jbossas project. Over the past few months, EJB3 code just breaks without any changes to our codebase. You go to debug these problems and you find the module in question is party of repository.jboss.com and usually no access to the source that built that binary. This leads me to checking out that module and hoping and praying the HEAD of that submodule is in synch with the binary (many times it isn't). IIRC, JBoss 2.0 used to be broken out in much the same way that we're moving to now. We had many of the same problems and, in JBoss 3.0 decided to move to a build system that built every subproject together into one checkout.

                A project like EJB3 sees these problems more often than other projects because EJB, at its core, is an integration project of many different technologies within JBoss. BTW, this is one of the reasons why I want to leave the EJB project. I'm sick of other projects breaking my code and me having to clean up after them.

                IMO, if we're going to mavenize every JBoss project and break it up into its own build and its binary stuffed into repository.jboss.com, we need to start getting much stricter on what we allow to be checked into head. If you're going to rev jbossas/build-thirdparty for your project, you should be required to test any modules that are dependent on your project. The problem with this, is that nobody does a good job of keeping their junit tests passing. Since there is no good baseline to measure against, any rule of this type would make it very difficult to determine if your thirdparty checkin to repository.jboss.com causes any new instability.

                What we really need to get to is a HEAD where all unit tests pass. If somebody checks in anything anywhere that causes a testsuite regression then HEAD should be frozen from *ALL* commits unti:

                a) The eroneous commit is rolled back
                b) the culprit fixes any problems.

                IMO, we're just too big right now to allow the current development process to proceed as it is going.

                • 5. Re: ejb3x mavenized
                  starksm64

                  Every project should have a source component in repository.jboss.com to simplify validating it.

                  The head testsuite does need to be restored, but its been in neglect for a while and the restructuring going on complicates this. ejb3 is no different than jbossas in terms of integration issues. Existing duplication needs to be cleaned up along with integration boundaries with tests validating the integration contract. Help in getting to this point.