> xdoclet I think). In fact, some people at jboss want xdoclet not to
> distribute a jboss module independently to make it harder to get a
copy of
> xdoclet that doesn't work with your jboss version. (Then, the only
(easy)
> way to get jboss support in xdoclet would be by getting the jboss
module
> with your jboss download, then you get the correct version).
Ok, so if you don't want the jboss module to be included in xdoclet
distribution then we can set the flag I talked about before in
external-modules.xml file.
> From the xdoclet side, perhaps Ara's scheme could pull only the jboss
HEAD
> branch and leave the task of updating other jboss branches (and
possibly
> the xdoclet tag for that jboss branch) to the JBoss developers.
We just send you a patch. You decide whether you wanna update the tags
or not.
> a) JBoss build checks out xdoclet source by tag and builds xdoclet +
jboss
> module whenever tag moves or jboss module changes. Only jboss module
is
> in
> jboss cvs, no binary checked in. I support this idea.
>
> b) (a) except the resulting xdoclet core and "other" jars are checked
into
> jboss cvs. This saves jboss developers maybe 10 minutes (xdoclet
build
> time) whenever they do a fresh jboss checkout. I think Michael
Newcomb
> supports this idea.
>
> c) Some jboss developer builds xdoclet jars based on checkout on
day/time
> or (sometimes) xdoclet tag and checks the resulting jars into jboss
cvs.
> This is what JBoss is doing today. I've done most of the updates and
find
> this highly unsatisfactory.
So you want a specific and reliable version of xdoclet, you also want
our support and you also need to be uptodate, and you also want a fast
build.
I propose something like this:
- We'll tag our sources each week or so. I think we need this tagging.
Imho we need it for Maven's remote repository too. So 1-2 guys will be
assigned to test the latest code and tag it if it works fine.
- JBoss will have two targets in its build:
- one which checks out latest code always and builds using the
latest code. This is useful for checking whether it works with the
latest xdoclet or not. I think you'll be the main user of this target.
- another target checks out a specific tag from xdoclet cvs,
builds it, creates the jars and *stores them locally and after that uses
these pre-built jars*. It's how Maven works. Maven has a remote
repository (ok they store binaries there), when you run it for the first
time it gets the jars from the remote repository and stores them in the
local repository, thereafter it uses the local jars. It's just a simple
<available/> check, if it succeeds then the local jar is available, use
it. So every week or so the developers face a full checkout of a new
xdoclet tag but during the week they use the local copy.
So we tag the sources each week or so, you do a full build yourself, if
everything is ok, you update the tag attribute of your <cvs/> task to
the new tag. When you release a new version of jboss you ship this
latest working tag of xdoclet. Note that until v2.0 we won't have many
drastic changes in the HEAD, the refactoring is done in a separate
branch. So keeping the two in sync is not a big headache imho.
>From xdoclet's pov we always check out the latest jboss module from
jboss's cvs. If we find that jboss module is very unstable then we just
add a tag or a date to the cvs task and checkout that tag/date, mainly
when we want to do a release (but we're not going to include jboss
module in our distro so we don't need to do it for jboss, but may need
to for some other vendors).
Ara.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
