Also, at least:
- 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
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()).
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).
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?
I would say org.jboss.util.xml belongs in the core util jar.
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.
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.
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.
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.
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:
commons-logging/ /commons-logging-api /commong-logging-impl
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.
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.
Going further, at what point is there aggregation of similar codebases into a top level module 1):
common-logging-api/ common-logging-impl/ jdk-impl/ log4j-impl/ blah-impl/
common-logging-api/ common-logging-jdk/ common-logging-log4j/ common-logging-blah/
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.
I thought the problem was that Maven doesn't support (2) and
at least Eclipse doesn't support (1)?
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.
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.