The primary overall goal is to move the xdoclet jboss module into jboss
cvs. A secondary goal is to be able to build a jboss specific version of
xdoclet core, since changes to the jboss-specific stuff have often required
bugfixes or implementation of missing functionality to xdoclet core. I
started with the secondary goal. The build system is set up so that
xdoclet will only be built once unless you manually delete some tag files
(last.xdoclet.update and last.xdoclet.build)
I see. I would rather not end up with another jboss/jetty module where we track XDoclet sources. Instead I would like to see us import a released source archive (or non-released I don't really care) then applying patches to that base and use it to compile. I think this will be easier to maintain and will also promote getting the changes back to the XDoclet folks in a manageable fashion for them. I do not know how well that would work, but it sounds reasonable at the moment.
I know Maven has some kind of repository idea. Is there some way we can
combine this with our need to use unreleased builds of e.g. xdoclet?
Hrm... not too sure what you are thinking. We could setup a JBoss-specific remote repo and place JBoss specific XDoclet builds there, but that is really no different than importing such a jar into the current CVS-based thirdparty mechanism. From what I grasp so far, the Maven repo is to allow projects to use external libs with out having to setup a repository of there own (like we do). That is one issue I have with Maven actually, but it can be gotten around by either continuing to use a CVS repository which conforms to their repository structure or by providing a JBoss remote Maven repo on our SF website.
The repository mechanism in general is a good one, but I think the Maven impl is a little lacking. One good thing that it does is force a structure, as well as provide simple access and organization for multiple library versions.
Either way I am starting to understand more for what you need. I expect we will eventually end up with more of these cases as JBoss expands to use more external software. As I mentioned before the Jetty stuff is already similar to this, but IMO unmanageable.
I am going to have to twist my brain into thinking about build systems in a completely new fashion to keep from going mad...
--jason
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development