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
