Good thing to bring this up. I really prefer b). Here are some remarks:
1. every plugin can be built seperately from the core (aka see Maven plugins) 2. the build process will be totally Maven, with maven.xml files containing jelly code that executes complicated things 3. I will set up a CruiseControl on my online server as soon as we have a build process and files (yep, everyone *will* know who broke the build or didn't execute JUnit ;-)) 4. Each component should provide their own documentation (xdoc). --> hmmm are you sure about this? this will be partly generated (xtags) so I don't know if it is applicable 5. I will put a proposal for a directory structure (core, per plugin etc) online asap 6. could you (Aslak) provide a starter with your ideas about the new Core API? we should discuss this stuff *before* implementing it.... 7. everybody agrees with my points made in http://users.pandora.be/ees/xdoclet/development/design.html ?? especially "NO more support for EJB 1.0 and 1.1, use XDoclet 1.2 for this"?? I will moan to people that break the build, don't follow general design guidelines or don't write unit tests for their code etc. 2.0 should be XDoclet done right! So beware :-) Mathias ----- Original Message ----- From: "Aslak Hellesøy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, October 05, 2002 7:01 AM Subject: [Xdoclet-devel] XDoclet 2 structure and process > Hi folks, > > Over the past six months there has been many discussions on email and > messenger between the developers regarding the new XDoclet Velocity > architecture. Some of us have already started to work on this. > > The build process is currently quite complicated, and we have to improve > that. The way I see it we have two options: > a) Make a new branch in the xdoclet module and start on XDoclet 2 there. > b) Make a new CVS module and code XDoclet 2 from scratch. > > With all the new initiatives (XGG, XRAI, more GUI plugins) + the various > points in Mathias' list > http://users.pandora.be/ees/xdoclet/development/design.html, I think we're > better off going for alternative b). Tag handlers will disappear, we'll > decouple XDoclet from Ant, use Maven for building etc... Trying to tweak the > current structure would cause too much headache IMO. -And we're talking > about a major version leap, so a complete rewrite is "normal". > > In fact, the XDoclet core will be very thin, since plugins and xjavadoc > contain most of the logic. XDoclet will only be glue. > > So my proposal is to create a new module called xdoclet2 where we can start > from scratch and do things "right". Ara and I have already discussed this, > and we have come up with a structure proposal: > > xdoclet2 > core (now) > plugins (now) > ejb (now) > jboss-ejb (later) > jboss-web (later) > jakarta-struts (later) > bea-wls-web (later) > bea-wls-ejb (later) > bea-wls-cmprdbms (later) > samples (soon) > xgg (now) > xdocletgui (later) > xjavadoc (later) > xrai (now) > > Some explanations: > -Let's use the term "plugin" in stead of "module". That's what they are, > isn't it? > -Each component should provide their own documentation (xdoc). > -There will be one plugin for each DTD/XML > -Everything will be built by Maven (compilation, jarring...) > -There will be JUnit tests everywhere > > So this is a proposal about a return to "one-module" CVS structure. What do > you think about this? > > I am working on a new ejb module using a structure similar to this, based on > Velocity/XGG. The intention is that it will serve as a proof-of-concept and > a template "best practice" structure for all the other plugins. > > Aslak > > > > ------------------------------------------------------- > 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
