On 2003.03.02 08:44 Jason Dillon wrote: > I would like to eliminate the buildmagic tasks too. Right now I am > looking into using Maven to replace it all. If I get something running > with Maven I will try to add an XDoclet module as a depend to allow > other projects to use the built tasks... not sure how well that will > work just yet though. > > Unfortunately the changes made broke other projects (like buildmagic, > though I believe that project is hosed in other ways too). > > Lastly I am not sure that we really want to pull xdoclet from its cvs > each build. Can you provide me with more details as to what we want to > achieve please.
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 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? Many many thanks for looking into this david > > Thanks, > > --jason > > > On Sunday, March 2, 2003, at 08:09 PM, David Jencks wrote: > > > Well, I hope you can fix this Jason because I couldn't, and I'm about > > 98% > > sure the problems lie in the buildmagic extensions being incompatible > > with > > current versions of ant. > > > > We have a long term goal of moving the jboss related xdoclet support > > to > > jboss cvs. > > > > I attempted to start this and to make constructing an appropriate > > xdoclet > > version for use in the jboss build an automated process by building > > xdoclet > > in the jboss build process. Thus, the xdoclet module attempts to check > > xdoclet out of xdoclet cvs and build it. > > > > So far so good, but it is impossible to build the rest of jboss using > > the > > just built xdoclet. For a while I was able to build by trying twice, > > the > > second attempt succeeded, but this did not seem to work reliably. The > > really odd thing was that the parts that could not be found had just > > been > > used for one or two module builds! After struggling for a week or so I > > gave > > up and made a simple mechanism to check the results of the xdoclet > > build > > into cvs thirdparty. > > > > BTW having xdoclet in tools/lib will obviously not work if xdoclet is > > built > > as part of the jboss build. In general I believe ant recommends not > > putting jars in tools/lib but defining your tasks using an explicit > > classpath. > > > > The build failures seemed to occur mostly because some part that had > > been > > compiled earlier in the build process were not available later in the > > build > > process. > > > > I just found another possibly similar example of this behavior that is > > possibly more serious. On a clean checkout, executing the main build > > module tests target will not build very many modules before stopping, > > being > > unable to find a module it just built. Running ./build.sh, then > > ./build.sh > > tests seems to work. (The build tests target builds each module, runs > > module-level unit tests, and finally starts jboss and runs the > > testsuite. > > The output from module level unit tests is included in the test > > reports.) > > > > My feeling after struggling with these problems is that the buildmagic > > build organization is the best part of the jboss build system, but > > that we > > should try to eliminate the buildmagic tasks if at all possible in > > favor of > > standard ant. I don't think anyone here wants to spend their time > > working > > on ant tasks. Ant demonstrated a long time ago that they do not > > preserve > > backward compatibility with external tasks, and we demonstrated that we > > don't keep up. (originally build/build.sh clean main worked, but it > > stopped > > working a really long time ago: the order of the modules is confused > > in the > > "main" target). > > > > Thanks > > david jencks > > > > On 2003.03.02 03:43 Jason Dillon wrote: > >> What happened to the XDoclet tool configuration? I don't get it... we > >> went from simply including the required jars in tools/lib (IMO the way > >> it should be) to including it from thirdparty (which has just been a > >> pain) and now there is some jboss-xdoclet pseudo module which does who > >> knows what. > >> > >> So what is the deal? This has complicated the already over > >> complicated > >> build system. > >> > >> Can someone please explain the reasoning behind this. I am sure there > >> was a good reason, but I am even more sure that there is a less > >> intrusive and simpler way to go about getting the same effect. > >> > >> --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 > >> > >> > > > > > > ------------------------------------------------------- > > 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 > > > > > > ------------------------------------------------------- > 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 > > ------------------------------------------------------- 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
