> > I think it would be very cool if the GUI part were entirely > > separate from the engine of Middlegen. I have taken Middlegen apart so > > that I can have my own XML created by other programs, which I > > then convert to a middlegen.Schema and I am now generating beans from > > it, or at least just starting to do so. GUIs are great, but only > > if you can get at the back end by other means as well. > > > > I totally agree with yo that guis should be separate from the core stuff. > > If you're keen on sharing your work with the XDoclet people, it would be > great! Konstantin and I are working together (aren't we, Konstantin? ;-) > on > a system that can describe tags in an xml format. (Purpose: > validation/documentation/gui) You've apparently done some work on > describing > EJBs with xml. Although not very much related at the first glance, it migh > very well be soon, if we can establish a gui project that unites all this > stuff. There is xjavadoc too. > > In short, there is a lot of new XDoclet related tools popping up here and > there. It's time now to have a serious discussion about what we want these > tools to do and how they should be related, designed and so on.
Oh yeah "serious discussion". XDoclet is becoming a software stack. It includes some core stuff, some add-ons and so on. There should a clear understanding of what belongs to what, where the pieces relate and so on. We've gone all this way in a hackery manner, but you know XDoclet is now a big project, the sources+resources is now more than 1MB of code and template. It's getting harder and harder to refactor so it's time to boost communication and to design more officially. The "bare minimum"/"the simplest thing that possibly wroks" now consists of some serious layering/design. Cheers, Ara. _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
