1 2 Previous Next 22 Replies Latest reply on Mar 21, 2007 2:30 PM by alesj

    Breaking up the MC project and Mavenizing it

    alesj

      Scott, what exactly did you mean by breaking up the project?

      We once mentioned lifecycle, injection annotations separation - so that developers can use them.
      What other 'components' do we want?

      I've created a JIRA issue about this - assigned to me.

        • 1. Re: Breaking up the MC project and Mavenizing it
          starksm64

          My thougts are that we need to transform the existing jbossbuild projects under:
          https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/

          into a maven based build, and break up the container project in the process as its jboss-container.jar artifact is too coarse. At a minimum, it should probably be broken up into projects for the following packages:

          P1
          org.jboss.classloading

          P2:
          org.jboss.metadata
          org.jboss.repository - maybe should be dropped as metadata is replacing it

          P3:
          org.jboss.net
          org.jboss.virtual - VFS code

          P4:
          org.jboss.annotation
          org.jboss.beans
          org.jboss.classadaptor
          org.jboss.config
          org.jboss.joinpoint
          org.jboss.reflect


          Every project should be further broken up into an spi/api artifacts for the spi packages, and a plugin artifact for the plugin/implementation packages.

          The aspects in the aop-mc-int project should be in a separate common aspects project.

          • 2. Re: Breaking up the MC project and Mavenizing it
            anil.saldhana

            Good reference point is the "common" project that is broken as:
            http://anonsvn.jboss.org/repos/common/

            • 3. Re: Breaking up the MC project and Mavenizing it
              alesj

               

              "scott.stark@jboss.org" wrote:

              Every project should be further broken up into an spi/api artifacts for the spi packages, and a plugin artifact for the plugin/implementation packages.


              Divided into different projects - [project]-spi and [project]-impl?
              Probably not?

              Just a clean separation between spi and its impl when building artifacts?
              So that you could eventually take spi jar and build your own impl on top of it.


              • 4. Re: Breaking up the MC project and Mavenizing it

                 

                "alesj" wrote:
                "scott.stark@jboss.org" wrote:

                Every project should be further broken up into an spi/api artifacts for the spi packages, and a plugin artifact for the plugin/implementation packages.


                Divided into different projects - [project]-spi and [project]-impl?
                Probably not?


                Yes, that *is* what we want.
                We need a project that creates a kind of "j2ee.jar" for our shared integration
                such that people compile against the api/spi not the implementation details
                which are subject to change and will only lead to incompatibilies if people did it.

                There's also a case for creating seperate projects for
                [project]-tests
                since many of the tests do depend upon implemenation details (specific implementations)
                that the main projects should not depend upon.

                But, Maven does support classpaths for the main source and tests
                (unlike Eclipse), so this is less important.

                • 5. Re: Breaking up the MC project and Mavenizing it
                  alesj

                   

                  "adrian@jboss.org" wrote:

                  There's also a case for creating seperate projects for
                  [project]-tests since many of the tests do depend upon implemenation details (specific implementations)
                  that the main projects should not depend upon.

                  Definitely.
                  Just wanted to expose the same issue - with test projects also being separate.


                  But, Maven does support classpaths for the main source and tests
                  (unlike Eclipse), so this is less important.

                  How is with other IDEs?
                  Any man for himself?
                  I can add some IDEA project support if needed.

                  Also, just to connect the two issues:
                  - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990901
                  I don't really feel we should be doing this individually if there would be a common QA person reworking/remavenizing all of our projects.

                  • 6. Re: Breaking up the MC project and Mavenizing it
                    starksm64

                    If you not using eclipse, then your on your own.

                    We have to understand the build we are using, so having a dedicated qa person is not a requirement. Their role is more about the maven plugin/repository issues.

                    • 7. Re: Breaking up the MC project and Mavenizing it
                      starksm64

                      So, summarizing the mavenization and associated refactorings:

                      1. In general each project needs to be split up into [project]-spi [project]-impl and [project]-tests
                      2. The container project needs to be split up into multiple spi and impl projects. The vfs stuff has already been moved to a separate project.

                      We need to do this refactoring of the eclipse projects in trunk so that Paul can work on the mechanics of creating the maven poms.

                      • 8. Re: Breaking up the MC project and Mavenizing it
                        alesj

                        A quick overview of our current MC codebase:

                        Microcontainer's artifacts (via Maven):

                        * aop-int
                        ** no SPI
                        ** impl (+ resources/schema)
                        *** org.jboss.aop.microcontainer.aspect (separate artifact)
                        ** tests

                        * container
                        ** 4 diff projects
                        ** tests
                        *** P1 - org.jboss.classloading
                        **** SPI only
                        *** P2 - org.jboss.metadata
                        **** org.jboss.repository (this one can be dropped; a single interface exists)
                        **** SPI
                        **** impl: annotation, generic, plugins
                        *** P3
                        **** org.jboss.annotation
                        ***** no SPI
                        **** org.jboss.beans.info
                        ***** SPI
                        ***** plugins
                        **** org.jboss.classadaptor
                        ***** SPI
                        ***** plugins
                        **** org.jboss.config
                        ***** SPI
                        ***** plugins
                        **** org.jboss.joinpoint
                        ***** SPI
                        ***** plugins
                        **** org.jboss.reflect
                        ***** SPI
                        ***** plugins
                        *** P4
                        **** org.jboss.javabean
                        ***** no SPI
                        *** (P5) - org.jboss.net, org.jboss.virtual (already moved to VFS project) //

                        * dependency (org.jboss.dependency)
                        ** SPI
                        ** plugins
                        ** tests

                        * deployers (org.jboss.deployers)
                        ** SPI
                        ** plugins
                        ** tests

                        * kernel
                        ** org.jboss.beans.metadata
                        *** SPI
                        *** plugins
                        ** org.jboss.kernel
                        *** SPI + Kernel, KernelFactory, KernelPermission
                        *** plugins
                        ** org.jboss.test.kernel.junit
                        *** TODO - where to put this?
                        ** tests

                        * managed (org.jboss.managed)
                        ** API (why not SPI?)
                        ** plugins
                        ** tests

                        * metatype
                        ** API (why not SPI?)
                        *** we could separate API into SPI and plugins?
                        ** no plugins / impl
                        ** tests

                        * spring-int
                        ** no SPI
                        ** impl (+ resources/schema)
                        ** tests

                        Don't know what you need to do about Eclipse projects.

                        • 9. Re: Breaking up the MC project and Mavenizing it

                           

                          "alesj" wrote:

                          *** P1 - org.jboss.classloading
                          **** SPI only


                          This was only there for a test that no longer exists.
                          It should be replaced by whatever underlies the OSGi implementation
                          in terms of defining a bundle/module (I called it domain) classloader


                          **** org.jboss.repository (this one can be dropped; a single interface exists)


                          This needs to be left in place unless Kabir verifies that there was no real
                          AOP release that referenced this class.
                          IIRC this class is still referenced by AOP's Advisor for backwards
                          compatibility reasons.


                          ** org.jboss.test.kernel.junit
                          *** TODO - where to put this?


                          This is part of the yet to be defined MC api (see below for api vs spi).
                          In practice, I don't really want an api for the MC since a key idea
                          behind IOC is to not reference a container api.

                          But you obviously need some form of api for tests, e.g. the getBean()
                          supplied by this testcase implementation.


                          * managed (org.jboss.managed)
                          ** API (why not SPI?)


                          An API is meant to be used at runtime by an application/user.
                          It should be 100% stable across releases.

                          A SPI is for integration issues, which is meant for "super users".

                          Don't know what you need to do about Eclipse projects.


                          Maven can generate eclipse project files from the pom.

                          • 10. Re: Breaking up the MC project and Mavenizing it
                            kabirkhan

                             

                            "adrian@jboss.org" wrote:


                            **** org.jboss.repository (this one can be dropped; a single interface exists)


                            This needs to be left in place unless Kabir verifies that there was no real
                            AOP release that referenced this class.
                            IIRC this class is still referenced by AOP's Advisor for backwards
                            compatibility reasons.


                            If we are talking about the MetaDataContext, no real aop releases referenced this.

                            • 11. Re: Breaking up the MC project and Mavenizing it
                              pgier

                              Should the tests for each module actually be a separate project (ie. separate folder and pom.xml), or is the way that maven creates a [project-name]-tests.jar ok?

                              SPI should be a separate project for each component of microcontainer, right? For container, do we want 4 separate sub-directories (one for each sub-project listed) and within these a separate SPI and impl directories? Or should it be a more flat directory structure?

                              • 12. Re: Breaking up the MC project and Mavenizing it
                                alesj

                                I think the way things are now - with directories and packages, ... - it's ok.
                                What we want is artifacts (jars) to include certain 'type': SPI, plugins (impl), tests.
                                Maven should create these artifacts on the package (directory) name basis: e.g. org.jboss.[project].spi should be a part of [project]-spi.jar.

                                • 13. Re: Breaking up the MC project and Mavenizing it

                                   

                                  "pgier" wrote:
                                  Should the tests for each module actually be a separate project (ie. separate folder and pom.xml), or is the way that maven creates a [project-name]-tests.jar ok?


                                  The artifact is the main thing. e.g. the aop-mc-int tests rerun
                                  the kernel tests over the aop integration.

                                  Eventually, I would think we would want to pull all these test artifacts into
                                  one big integration testsuite.

                                  • 14. Re: Breaking up the MC project and Mavenizing it
                                    pgier

                                     

                                    "alesj" wrote:
                                    I think the way things are now - with directories and packages, ... - it's ok.
                                    What we want is artifacts (jars) to include certain 'type': SPI, plugins (impl), tests.
                                    Maven should create these artifacts on the package (directory) name basis: e.g. org.jboss.[project].spi should be a part of [project]-spi.jar.


                                    Maven is not really set up to do this automatically, we could generate the separate artifacts using the assembly plugin, but there might be an issue with dependencies.

                                    For example, if [project]-plugins.jar has a dependency on another project, I don't think there is a way to differentiate it's dependencies from [project]-spi.jar. In other words, all the artifacts generated by the project share a pom, and therefor have the same dependencies. So [project]-spi would always include the same dependencies as [project]-plugin.

                                    For now, I will set it up to generate the multiple artifacts this way, and then if there are problems with dependencies, we can always change it later.



                                    1 2 Previous Next