I'm really happy you're bringing this up Andrew. The whole structure is quite messy right now.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew > Stevens > Sent: 10. april 2002 19:30 > To: [EMAIL PROTECTED] > Subject: [Xdoclet-devel] directory hierarchy > > > As an alternative to the current xdoclet/core/optional/... > hierarchy, I've > the following suggestions for discussion: > > xdoclet > \core > \src > \resources > \... > \optional > \weblogic > \src > \resources > \... > \struts > \src > \resources > \... > \contrib > \whatever... > > i.e. separate the optional stuff from core, since they're being built to > separate jars (and could, in principle, be updated > independently). Plus, it > uses the same structure (src, resource, test etc.) in both core and the > optional directories, rather than a resources subdir below the > java source > files in optional. IMO, it's more consistent that way. > > Secondly, so far as the java package hierarchy is concerned, > which do people > think is better (I can't decide which I prefer) - > xdoclet.optional.weblogic.ejb (as it now is), or > xdoclet.ejb.vendor/optional.weblogic (as it was)? On the one hand, I can A third option would be xdoclet.vendor.weblogic.ejb, but I think optional is better, since all optional things is not necessarily from a *vendor* if you see what I mean. Intuitively it makes more sense to me to group at vendor level first, and then on domain level. I'm maintaining the weblogic stuff, so all the stuff I care about is under weblogic. Further, I don't see any benefits from using xdoclet.ejb.vendor/optional.weblogic. I think it's quite unlikely that there will be interdependencies between packages in the optional code, so having all ejb stuff under ejb doesn't make much sense to me. Further, I think we should have related tag handlers and sub tasks in the same package. The principle I'm advocating is grouping files and packages by cohesion. In CVS now I have put all weblogic ejb related resources in a resources folder (templates, Messages.properties and dtds) beneath the code that uses it. Basically because I'm a more efficient developer when I don't have to search around a whole file system in order to get to thew files I care about. > see the sense in having everything below the optional package and, say, > having x.o.weblogic.ejb and x.o.weblogic.web together under a single > weblogic package. On the other hand, it also makes sense to have all the > ejb stuff below a single package, plus the various vendor modules > will still > be using strings from xdoclet.ejb.Messages so it feels right to have them > under there (likewise for web, jmx, etc.) Also, if we continue > using vendor > rather than optional, we can separate things out into optional > and contrib > but have the same package hierarchy for them (which makes it > easier to move > things from one to the other). > > Third, I think we should move the samples up out of core too i.e. to > xdoclet/samples/src,script,etc. rather than xdoclet/core/samples. > They're > not just examples of the core stuff, they have various vendor > tags in them; > if we're moving the vendor stuff out of core into optional, the samples > don't really belong there either. Let's keep xdoclet/core for > only the core > classes, the samples don't need to be there to be included in the > dist zip > (heck, we build them separately already...) > Completely agree with you. > Fourth, docs... We should have each module's docs in its own directory, Then I'd like to put them under xdoclet/optional/weblogic/docs > rather than everything under xdoclet/core/docs. It's still > useful to have > them combined into a single set for distribution and online, though. I > guess using xml & stylesheets would make this easier to do (with > less work > to maintain links etc?) docbook and stylebook have been mentioned > previously, but I don't know too much about them. I though > stylebook was a > jakarta thing, but I don't see a subproject for it on there. And isn't > docbook geared more towards producing books and papers etc.? > I mentioned this before, I'll mention it again: XDoclet GUI (which Konstantin is doing great progress with) reads in xml which describes the tags. This is used to set up the gui and provide tooltips. If you take a peek in xdocletgui and do a build docs, you'll see that the same xml is used to generate html docs. The ideal would be to have this xml generated by xdoclet from the sources, but it's kind of hard, and not high pri imo. > Of course, none of this is of earth-shattering importance, it just seems > neater. Plus I was planning to do the EAServer support as a module (and > probably refactor Bluestone into one too) so I figure it's better > discussed > before I start adding anything else in CVS. I'm happy to do the > reorganising myself if we can agree on the best way to have it. > Regards, Aslak > > Andrew. > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
