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
