Getting XDoclet tags ownership into each of the projects seems like the way to go, really. Struts would own it's tags, etc. Once success with one project integration could be demonstrated, it seems that other projects would follow. As was already mentioned, having a forked core and issues with tags that cover different projects are major issues.
In the long term, a lot of the versioning issues could be solved by Subversion (http://subversion.tigris.org) and distributed repositories. I've only briefly scanned their lists to confirm this is still an active item for them, but ideally all the projects could be linked together to form a large distributed repository with numerous overlapping (at the module for each) administration domains. At that point, it would not matter what particular repository a set of sources resided in, since the permissions would allow members of either group to make changes in the overlapping section (the module) without requiring write permission to the entire other project. Taken to it's logical extreme, all open source software could be mapped into a giant single distributed repository (what a build *that* would be ;), and suddenly Maven starts to look a little long in the tooth. Anyway, the only way this all seems to work is to do inter-repository tags such that one project can have a release and put tags across all repositories that we are dependent on. Of course, tags are simply a collection of file references, and since the transport for Subversion is HTTP, the reference for a file in a Subversion repository is a URL. So a tag suddenly becomes just a list of URLs that create the version. This really isn't the place to yammer on about what "could be", I just wanted to plant the seeds with everyone, get people started thinking about using Subversion down the road. Hopefully Subversion support starts hitting some IDEs soon (it's been recently suggested on Idea EAP), and it's a very active group; it smells like it's going to be successful. Question: If Subversion is were decided to be inevitable in the long term, does it influence the decisions we make today? I suspect when it comes down to it, JBoss will fork XDoclet if the hassle factor gets high. I personally don't see a lot of other options under CVS though. If JBoss agreed that Subversion conversion was of high probability, it seems most expedient to simply be a module in their tree, then break back out when distributed repositories were for real. That way, they can get the tags they need, we can avoid forks, and both get the benefits. If two projects suddenly want to do this pre-Subversion, it's a problem, but less of a problem if JBoss already forked (making for a total of three copies of the source floating around, us, JBoss, and the "other" project). The increase in visibility would be outrageous. +1 from me if we can avoid a fork. -b > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 19, 2002 3:49 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
