Agree 100% :)

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On Behalf 
> Of Andrew Stevens
> Sent: mercredi 10 avril 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 
> 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...)
> 
> Fourth, docs...  We should have each module's docs in its own 
> directory, 
> 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.?
> 
> 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.
> 
> 
> 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

Reply via email to