1 2 3 Previous Next 73 Replies Latest reply on Aug 14, 2006 6:02 PM by ruel.loehr

    Breaking up common in jboss-head

    Scott Stark Master

      We need to break out jbossxb from common, and this in turn requires refactoring common into at least 3 pieces:

      - logging with a split into an api and logger plugins
      - jbossxb
      - util which is everything else?

      All these nested exceptions, coercible garbage, and unused classes should just be dumped.

        • 1. Re: Breaking up common in jboss-head
          Adrian Brock Master

          Also, at least:

          - collections
          - net (url handlers)
          - property editors
          - thread pool

          I'd also suggest a project where we can put retro stuff.
          There are already a number of helpers in common like
          JBossStringBuilder, NestedXXXException
          along with the ones we have added in JBossRetro.

          The main issue for me is sorting out the interplay between the main
          helpers Classes, Strings, etc. and the way they leak dependencies from the rest
          of common (including system property retrieval and that horrible System.setProperties()).

          • 2. Re: Breaking up common in jboss-head

            Where would org.jboss.util.xml live? It is required by classes in xb (org.jboss.xb.binding.sunday.unmarshalling). It is also required by logging (e.g. org.jboss.logging.jdk.xml).

            • 3. Re: Breaking up common in jboss-head

              We should get a dependency graph of the packages in common and post it to some wiki page. There are probably 1000's of tools out there to do this, and probably an eclipse plugin or two. Ruel, can you look in to this?

              • 4. Re: Breaking up common in jboss-head
                Scott Stark Master

                I would say org.jboss.util.xml belongs in the core util jar.

                • 5. Re: Breaking up common in jboss-head

                  I tried out a few of the dependency graph offerings. The visual ones were pretty ugly and not very helpful. JDepend, however, has one which can create a text based representation of package dependencies, which I found more useful.

                  I placed the report into a wiki:

                  The important point of this report is that for each package you can see the packages that depend on it, and vice-versa. A quick perusal shows that classes in org.jboss.logging.* reference classes in org.jboss.util.*. The opposite is also true.
                  To start working on a solution for this, as Scott suggested, logging should be split up into two components. I'll put together a class listing for each these and make a post.

                  • 6. Re: Breaking up common in jboss-head
                    Scott Stark Master

                    Some obvious issues:

                    javax.xml.namespace package can really be dropped since its bundled with jdk5 and the xml parser jars we bundled with jboss4.x.

                    org.jboss.util.CollectionsFactory should really be in the org.jboss.util.collection packagae to avoid a cycle between org.jboss.util.collection and org.jboss.util. This will require a number of other modules to be changed.

                    All of the org.jboss.util.coerce should be removed. I'll work on this now.

                    I think the org.jboss.util.platform has little use and should be dropped.

                    • 7. Re: Breaking up common in jboss-head
                      Scott Stark Master

                      I removed the coerce stuff and looked at removing the javax.xml.namespace.* package. This can be done as well just by adding the xerces classpath to a couple of modules, so I'm going to remove these as well.

                      • 8. Re: Breaking up common in jboss-head
                        Scott Stark Master

                        I moved the CollectionsFactory and WeakClassCache from the org.jboss.util package to the org.jboss.util.collection package and updated the current uses of these classes.

                        Next I'm going to work on the logging package refactoring. into a new common-logging module. How we would structure a module with an api/impl seperation of classes into two artifacts using maven I would like to know.

                        • 9. Re: Breaking up common in jboss-head

                          There are two options for the structure:

                          1) 2 top level projects - one for api, one for impl. Because eclipse doesn't allow the true nesting of projects, this is the preferred method. In this fashion, each project can have it's own dependency list (.classpath) in eclipse.

                          2) A nested structure:


                          This method groups them together nicely, but again, doesn't work well with ide's. This would be similiar to how jmx-remoting and remoting are nested with jbossas.

                          • 10. Re: Breaking up common in jboss-head
                            Adrian Brock Master

                            I prefer option 1, not because of the ide issue but because

                            1) It gives Clebert what he wants - a small (null) api for standalone use
                            to which extra functionality can be added in the appserver.

                            2) There is less chance of dependency creep if the impl and api
                            are clearly separated in different builds.

                            • 11. Re: Breaking up common in jboss-head
                              Scott Stark Master

                              Going further, at what point is there aggregation of similar codebases into a top level module 1):


                              vs 2):

                              It would seem neither really promotes feature creep because under each directory are seperate source trees that map to a single artifact, and dependencies have to be expressed independent of the structure.

                              • 12. Re: Breaking up common in jboss-head
                                Adrian Brock Master

                                I thought the problem was that Maven doesn't support (2) and
                                at least Eclipse doesn't support (1)?

                                • 13. Re: Breaking up common in jboss-head

                                  Adrian, Unless I am misunderstanding what you are referring to, Maven supports both 1 & 2.

                                  You are correct that the limiting factor is eclipse when used with nested projects (1).

                                  I get Scott's point though. If you exclude the eclipse problem, the net of either of these approaches is the same. You get distinct trees building against a distinct dependency list outputting distinct artifacts.

                                  When would you aggregate?

                                  1) When ide support is present
                                  2) When you have a series of related projects (of which I would say logging is a good example).

                                  The only drawback that i see from of the non-aggregation approach is that you have the potential for a great number of top level projects.

                                  • 14. Re: Breaking up common in jboss-head
                                    Scott Stark Master

                                    We need to be clear about what "supports" means. tobrien said eclipse supports the nested structure in this thread:

                                    The notion of supports to me is does the maven plugin have the ability to generate the correct ide project. Supports is also a question of what do the maven plugins/ide tools for svn/cvs work best with. I'm inclined to believe that the entire logging project will be versioned/relased together rather than having implementations roll out independently. Maybe not though.

                                    This is why I'm looking for a lifecycle overview of how we are going to use all of the tools as it needs to flow from initial development through to end of life service pack maintence.

                                    1 2 3 Previous Next