Re: [JBoss-dev] WTF happened to XDoclet tool config?!
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
Re: [JBoss-dev] WTF happened to XDoclet tool config?!
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. 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
Re: [JBoss-dev] WTF happened to XDoclet tool config?!
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
Re: [JBoss-dev] WTF happened to XDoclet tool config?!
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
