1. Ara, the issue of losing xdoclet core developer support for the jboss module was my main reason for initially opposing moving jboss xdoclet to jboss. After the hassle of updating xdoclet (jboss jmx fixes mostly) and then updating all the jboss xdoclet .jars, I started thinking having the jboss stuff at jboss is a better idea.
I really like the idea of xdoclet pulling vendor modules from the vendors. However, I think there is still an unaddressed issue.... namely, one of the main reasons for moving jboss stuff to jboss is so jboss can include with each jboss release and branch a version of xdoclet that works with it. In other words, jboss is planning to maintain a branch of at least the jboss module for each jboss branch (currently there are 3 that would include 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). I often come up with solutions that are more complicated than necessary, so I hope someone has a simpler idea: >From the jboss side, how about if we tag xdoclet source (core and the other modules needed by jboss, such as ejb and jmx) for each jboss branch. I imagine on the jboss side we will have something that pulls xdoclet source by tag and builds all of xdoclet. Jboss will have to decide if the resulting jars should be checked into jboss cvs or built by each jboss developer (when the tag moves, not with each jboss build). With luck, many of these tags will be on the same version as an xdoclet release. This will let jboss get known versions of xdoclet core/other modules for each jboss branch. Perhaps JBoss can keep the xdoclet tag for the HEAD JBoss branch also at HEAD. >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. 2. (Dmitri) I don't think anyone wants a copy of xdoclet source in JBoss. (I don't, anyway). The ideas I think have supporters are: 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. Any ideas would be appreciated. Thanks david jencks On 2002.09.21 09:48:54 -0400 Dmitri Colebatch wrote: > I'd like to hear input from some of the JBoss committers on the list as > to > whether they think this approach would be sufficient from the JBoss dev > community pov. From my understanding JBoss would have been thinking of > including the entire xdoclet src (not just the jboss module) in their > cvs... > cheers > dim > > ----- Original Message ----- > From: "Ara Abrahamian" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Sunday, September 22, 2002 12:41 AM > Subject: RE: [Xdoclet-devel] DISCUSSION: removing JBoss tags > > > > Michael, 100% agree that it's better to host the jboss module in > jboss's > > cvs. > > > > But as you've seen there are some concerns that such a radical move has > > some drawbacks such as the points made about ejb:persistence tags or > the > > consolidation of res-ref/etc jndi-name tags. > > > > So we have a problem: > > > > We need to find a way which lets jboss (and other vendors) maintain > > their own modules in their cvs tree and yet not completely cut off from > > xdoclet's cvs and become hard to synch with the latest xdoclet changes > > and incompatible. > > > > I propose this solution: > > > > Jboss and other vendors will keep their modules in their own cvs. The > > modules will be removed from xdoclet's cvs. But, we'll modify the build > > process of xdoclet to checkout those external modules whenever we do a > > build-all. The external modules are defined in an external-modules.xml > > file, where we define the cvs address/etc of external modules there > > (similar to Maven). So you checkout xdoclet-all, jboss is not there. > You > > do a build-all, jboss is now downloaded with anonymous account from > > jboss's cvs. Now let's say Marcus updates the jndi stuff of some app > > server modules including jboss (which he now has in his local copy by > > doing a build-all). He can't commit it back to jboss's cvs, so he makes > > a patch (which is easy, I use tortoiseCVS in windows and it rocks) and > > sends it to jboss. It's committed there and the next time another > > developer builds it an updated and synched jboss module is downloaded. > > If a jboss committer changes adds a new tag then we also get and > updated > > copy automatically and we know what's going on there. Obviously we > > communicate more too. > > > > What are the benefits? > > > > - jboss controls its module, but we keep an eye on it too. We even > > bundle it with xdoclet (though it can be configured via a flag in > > extnernal-modules.xml file). JBoss committers can veto our change. > > - it prevents jboss module from becoming outdated. It's synched because > > we also build it. If we change some tags at xdoclet, and jboss should > be > > updated too, we just don't leave it to the guys at jboss to update > them. > > We can also update them and send them the patch. > > - This way we don't need to handle things formally. I mean if we're not > > going to do it this way probably then we need to publish an "ejb > modules > > specification and vendor implementation guide" (!) and let vendors do > us > > a favor and keep their stuff compatible with our stuff. So we make sure > > everything is uptdate and compatible and the vendor makes sure it's > > using the latest and greatest stuff and it's not outdated and they also > > use our manpower (that I think is very important, jboss developers may > > not have the best ideas, but we might have it because we're more > > user-oriented than the core developers of jboss). > > > > We could just let jboss go, but xdoclet is not Ant and xdoclet modules > > are not like ant modules. We need to keep things compatible. A tag like > > ejb:persistence is used in more than 10 modules. A vendor specific Ant > > task like AS400Task is not. There's really a standardization process > > going on under the umbrella of xdoclet. So by the above described > > process we have a balance. > > > > Thoughts? Any detail you've noticed? Any tricky issue we should tackle? > > > > PS: I came up with this solution in the bathroom :-) Yeah, I often > > design there rather than sing loudly ;-) > > > > Ara. > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > [mailto:xdoclet-devel- > > > [EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] > > > Sent: Thursday, September 19, 2002 11:19 PM > > > To: [EMAIL PROTECTED] > > > Subject: [Xdoclet-devel] DISCUSSION: removing JBoss tags > > > > > > XDocleteers, > > > > > > There is a push to get the JBoss XDoclet tags under JBoss-CVS. This > > would > > > represent a shift in ownership/responsibility/location of all the > > > JBoss-specific tags/tasks/templates to the JBoss project. > > > > > > It may sound a little distressing at first, but in reality, it is a > > major > > > win for XDoclet. > > > > > > The basic argument *for* moving JBoss module to JBoss-CVS comes down > > to > > > one > > > question, 'Why does XDoclet have any custom, vendor-specific > modules?' > > > Answer: because the vendors didn't care/know anything about XDoclet > > and > > > wouldn't/couldn't/didn't-know-how-to supply their own tags! > > > > > > Well, JBoss is all over XDoclet. It is used in generating JMX > > components > > > and in the test-suite. With the move to JBoss, the tags will be > > versioned > > > with the appropriate releases of JBoss (extremely important as JBoss > > goes > > > to > > > 24x7x365 support). When users download JBoss, they will get a JBoss > > > module > > > that supports their version of JBoss. It also allows the JBoss > > developers > > > to keep the JBoss module up-to-date with the latest changes to JBoss. > > > JBoss > > > developers will now be *required* to develop/maintain JBoss tags as > > they > > > add/remove/change features of JBoss. > > > > > > Another not-so-obvious point is exposure. JBoss gets an average of > > > 150,000+ > > > downloads a month (~208,000 in 04/02). They have users with CD > > > subscriptions, Marc Fleury regularly gives briefings to Java User > > Groups, > > > advanced training occurs almost twice a month all over the world, ... > > > JBoss > > > is the hottest thing since sliced bread! Now, everywhere JBoss goes, > > > XDoclet will be taught as the way to develop EJBs! > > > > > > Thoughts? > > > > > > Michael > > > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > ------------------------------------------------------- > 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 > > ------------------------------------------------------- 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
