This looks to me as if it is too fine grained. If I want to use jboss, do I really need to include 57 modules? Why not just one? Same for WL. For mvcsoft, why not mvcsoft + (perhaps) my app server?
When would you combine these little modules other than to simulate a big module? jboss-ejb + wl-web seems unlikely;-) BTW jboss-jmx has: xmbean xml descriptor generation service template for jboss-service.xml jmx-api xml docbook /html generation david jencks On 2002.04.24 09:37:44 -0400 Vincent Harcq wrote: > I agree. > > BTW the jboss-service stuff is really a different module than jboss. > jboss is to develop EJBs on jboss > jboss-service is to run jboss (only JMX for example) > By cutting modules into pieces, it will be more easy to combine them. > (even if I don't think we need a module dependancy mechanism) > > So > modules > jboss-ejb > jboss-web > jboss-jmx (??? what is the diff with standard jmx ???) > jboss-service > wl-ejb > wl-web > castor > mvcsoft-core > mvcsoft-jboss > mbcsoft-wl > etc... > > A page simply explain each module and eventual dependancy that exists > > Now what is core and what is optional, I am not sure but all J2EE 1.3+ > should be core : servlet, ejb, jmx, web services (upcoming release but > xdoclet must be on the edge), ... > > If we put ejb as a module, the dependancy check for a user will become > too > difficult > ejb in core should do what the ejb spec says : home/remote IF, impl, ejb- > jar.xml, value object. If we add jboss, the jboss DDs are added, etc... > > Comments? > Vincent > > > > Modules is fine with me, but I thought part of the previous proposal > > was to have vendors at a higher level, so for instance jboss stuff > > would fit into one module rather than >= 2 (ejb + jmx). > > > > Is there really an point to separating the core tasks for ejb, jmx, > > web, etc out from core? > > > > xdoclet > > template > > util > > ejb > > xml-rpc > > jmx > > web > > > > modules > > jboss > > ejb > > jmx > > WL > > ejb > > web (?) > > Castor > > > > I don't know about the size issues, but I think the important > > pluggability is for what app server you are using more than which layer > > you are working on. > > > > david jencks > > > > On 2002.04.24 04:27:41 -0400 Ara Abrahamian wrote: > >> Btw, I think we shouldn't have the word "optional" in file/package > >> structure, "modules" is better. I'm generalizing some XML-RPC > >> templates right now and I don't know whether to put it under optional > >> or in core. If I put it under core then I don't have the nice > >> directory structure of optional modules (as described below), and if I > >> put it under optional then well it's really not optional, after all > >> Sun's JWSDP package is going to be the standard for web services > >> stuff! > >> > >> So agree on "modules" instead of optional/core? Something like this: > >> Core > >> Xdoclet > >> Template > >> Util > >> Modules > >> Ejb > >> Core (entitypk/etc) > >> Jboss > >> Xml-rpc > >> Web > >> core > >> Jrun > >> > >> Now in build.xml of root we decide which ones are part of the standard > >> distribution and which ones are going to end up in optional.jar, maybe > >> defined in a modules.properties file. This makes it easy to move a > >> subtask from optional<->standard. > >> > >> Thoughts? > >> > >> Ara. > >> > >> > -----Original Message----- > >> > From: [EMAIL PROTECTED] > >> > [mailto:xdoclet-devel- [EMAIL PROTECTED]] On Behalf Of Ara > >> > Abrahamian > >> > Sent: Wednesday, April 24, 2002 8:33 AM > >> > To: [EMAIL PROTECTED] > >> > Subject: RE: [Xdoclet-devel] CVS update: xdoclet/core/samples/jboss > >> > - > >> New > >> > directory > >> > > >> > > > I think we should put samples and test > >> > > > in each module's folders: > >> > > > Optional > >> > > > Jboss > >> > > > Src > >> > > > Script > >> > > > Tests > >> > > > Samples <- > >> > > > > >> > > > This way if a guy comes up with JDO templates for Kodo vendor he > >> can > >> > > > simply provide the whole stuff including samples in a single > >> > > > ready > >> > to > >> > > > commit zip file. > >> > > > > >> > > > Agree? > >> > > > >> > > Tests, sure, but I'm not convinced about the samples - it makes it > >> > harder > >> > > to demonstrate how we can have one set of source files producing a > >> jar > >> > > that's deployable on a variety of app servers. Plus, either > >> > > they've > >> > got > >> > > to come up with more samples or (more likely) they'll re-use the > >> ones > >> > we > >> > > have with their tags instead, in which case is it really that much > >> > work to > >> > > merge them into a common set? > >> > > > >> > > Also, I though the samples were moving up to the same level as > >> > > core > >> & > >> > > optional, since they contain examples of both lots of tags? > >> > > >> > Keep the giant samples in root. These samples are more focused on > >> > that module. Jboss samples in jboss module demonstrate all jboss > >> > tags and options. Samples in root demonstrate a complete > >> > multi-faceted project, including some jboss/multi-vendor stuff. > >> > > >> > Ara. > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 > >> > >> > > > > _______________________________________________ > > 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 > > _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
