hi, > 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.
JBoss will be 4 : core/jboss-ejb/jboss-web/jboss-jmx OK jboss alone is maybe enough. It was not the better cases for the feature I want > 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;-) If in the future I add a session facade generator, a jdbc catalog generator, ... where do I put them ? Under core ? No because you don't need that to run ejbs Under module ? Right so a new one for all : these are two different things, so I need 2 IMHO The Value Object and Data Object stuff should not be in core Maybe a module "j2ee-pattern" that is a bunch of all above is what you propose ? It is also fine with me. But, What I do not understand is the need of submodules Why jboss/ejb and jboss/web and not jboss/src And like that for all modules : xyz/src xyz/conf, ... I hate complexity Regards Vincent > > 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 _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
