Hi fellows, We had a rather lengthy conference on Yahoo Messenger discussing the new module structure. Unfortunately, only Ara and I were able to attend, but here is the transcript. I'm too bored to make a summary, but we came to a consensus on both package naming, directory structure and build procedure. We're working on it now. It's a big job, so I hope someone can help us. We'll post task descriptions on the dev list, and those who are able to are encouraged to pick them up.
Cheers, Aslak Yahoo! Messenger: Conference pazustep-0 started. aslak_hellesoy: cool, invite ara pazustep: ah, nice! pazustep: strange. I can start conferences but can't join them. Well... linux isn't treated as a serious OS by some people. Yahoo! Messenger: ara_e_w has joined the conference. ara_e_w: so pazustep: Hello, Ara ara_e_w: hi pazu aslak_hellesoy: pazu, the others are dbudworth, jerome_bernard and vincent_harq aslak_hellesoy: sorry, vincent_harcq aslak_hellesoy: ok, here's the status: aslak_hellesoy: i have moved all subtasks and taghandlers (except the classtaghandler... handlers that are generic) to the new structure aslak_hellesoy: these classes should be tagged (look in the wls stuff aslak_hellesoy: then we generate xdoclet.xml with the xdoclet/modules/xdoclet-xml.xdt template. ara_e_w: ok, anyway you added the new stuff, old stuff is still there. right? aslak_hellesoy: the resources aren't moved yet. let's focus on compilation and building first.. ara_e_w: ok aslak_hellesoy: no, i have removed everything i moved pazustep: I've just invited everyone aslak_hellesoy: -to make sure the core compiles without it. it does. aslak_hellesoy: so far, what do you think? ara_e_w: still checking out... ara_e_w: i hope it's not too flat ara_e_w: everything in modules root i mean aslak_hellesoy: the package scheme i suggest is xdoclet.vendorname.productname.[subproductname] ara_e_w: i've done it this way: xdoclet.modules.xmlrpc aslak_hellesoy: if vendorname and productname is the same (like xdoclet and mvcsoft) we skip one level ara_e_w: what do you think about grouping? say group all JDO vendors under JDO aslak_hellesoy: sure, why not? ara_e_w: should we have root level Kodo/OpenFusion/J1? aslak_hellesoy: -but the recommended package name from sun puts vendor before product... ara_e_w: what about ejb? jboss under ejb? root level jboss having ejb/web/etc? aslak_hellesoy: ejb.jboss or jboss.ejb, it doesn't really matter. ara_e_w: ok, so you mean xdoclet.modules.sun.xmlrpc? aslak_hellesoy: -but from a developer perspective i think it does. i will support everything weblogic (because i know the platform) wouldn't it be nice if all my work (both web and ejb) could have one parent folder? ara_e_w: it'll be too flat to not have modules in package name, after all although they are in different source paths but they get compiled and confused with same package names ara_e_w: yes, it's intuitive, you mostly need both web and ejb stuff for a vendor ara_e_w: so: aslak_hellesoy: you mean if some vendor shows up which is called util, loader, doc or template??? ara_e_w: for application server vendor->top level (jboss->ejb/web) ara_e_w: no!! but isn't it better to group modules under a package name? ara_e_w: but it's not a big deal really ara_e_w: so forget it aslak_hellesoy: that makes xdoclet.modules.bea.wls.ejb|web. Ok with me aslak_hellesoy: can we settle on that? ara_e_w: anyway, for non-vendor stuff->group it (ejb->dataobject/etc) ara_e_w: ok with me too, but we should then move files again and again lots of commits aslak_hellesoy: i agree. the std ejb package has a lot of classes, and it's the only one i split in subtasks and taghandlers. bad approach, yours is better. aslak_hellesoy: so we get xdoclet.modules.sun.ejb.pk|dataobject|session etc? sounds nice ara_e_w: so my xmlrpc stuff will end up in: xdoclet.modules.sun.xmlrpc? aslak_hellesoy: YUP aslak_hellesoy: if you think it's ok.... ara_e_w: sun.ejb? jcp.ejb what about javax.ejb? aslak_hellesoy: even better! ara_e_w: or simply modules.ejb aslak_hellesoy: i prefer to be consistent in the naming standard -> xdoclet.modules.sun.javax.ejb.entity ara_e_w: so we will restrict ourselves to putting javax.* stuff under modules.*, anything else in modules.vendor.* ara_e_w: it's too deep/long, remove "sun" plz! aslak_hellesoy: xdoclet.modules.javax.ejb.xxx? ara_e_w: doesn't it look ugly? i mean javax has always been top level!! ara_e_w: +1 to xdoclet.modules.ejb, xdoclet.modules.web, xdoclet.modules.jmx, xdoclet.modules.webservice and so on ara_e_w: pazu, r u still there? aslak_hellesoy: -and state that the vendor.product applies to everybody except sun? aslak_hellesoy: pazu's fighting with linux aslak_hellesoy: linus ara_e_w: sun? everything which is marked by jcp with javax we'll consider an standard (javax.ejb.*->modules.ejb) ara_e_w: isn't there a yahoomessenger for linux? aslak_hellesoy: ok, so if the classes the generated classes derive from are java.xxx or javax.xxx, we put xxx straight under xdoclet.modules? sounds ok. ara_e_w: and if the module produces something which only needs java/javax.blabal then it's std ara_e_w: yup aslak_hellesoy: agreed. means we've decided a structure then! ara_e_w: so dataobject/entitypk under modules.ejb because it generates sth whihc only uses javax.blabal ara_e_w: decided, yes ara_e_w: btw i'm still checking out with my fucking dial up connection!!! aslak_hellesoy: wait a minute! will we have xdoclet.modules.ejb.entity for EntityHandler? ara_e_w: EntityHandler? what's that? aslak_hellesoy: I also have a fucking dialup. i thought you had something faster! aslak_hellesoy: sorry, EntityTagsHandler whatever the name is ara_e_w: this is the fastest thing u can get in iran at home ara_e_w: ejb.entity, yes sounds good aslak_hellesoy: we should get together and by you a roll of fiber! ara_e_w: i'll accept it happily aslak_hellesoy: fantastic! -now let's discuss file structure and build process ara_e_w: btw, still using .tags, right? ara_e_w: modules.ejb.entity.tags.* aslak_hellesoy: an option to use xml &superduperscript is to have one build script under modules and apply that to all modules aslak_hellesoy: ok, back to packages... ara_e_w: .tags ok? aslak_hellesoy: well, usually taghandlers and subtasks don't depend on each other, but i think it's more spottable if they live together. each package will only have a few classes anyway. ara_e_w: hmm, maybe ara_e_w: ok aslak_hellesoy: i mean, just because they have a different superclass doesn't necessarily mean they belong in a different package ara_e_w: ok aslak_hellesoy: ok? vincent_harcq's status is now "Idle" (25.04.2002 at 20:34) ara_e_w: okok ara_e_w: now about file structure ara_e_w: yes, build.xml in modules/script for building/testing/packing all modules aslak_hellesoy: yes. either one script applied to all modules, or one script in each module which includes a bigger one from the top. aslak_hellesoy: -but since we are enforcing a strict structure on modules, we can get away with only one script. no need to have scripts inside the modules! ara_e_w: ok, but each module will have it's own build, even a separate samples/script aslak_hellesoy: why? ara_e_w: no we still need them, my xmlrpc for example produces two jar: xmlrpcutil.jar and xmlrpc-module.jar, user has to use xmlrpcutil.jar in his app, templates use some utility classes defined there aslak_hellesoy: ok, but let's move all the generic stuff to some top script. for excample generation of xdoclet.xml and jarring it up... aslak_hellesoy: Download the latest version of Yahoo! Messenger at http://messenger.yahoo.com/ aslak_hellesoy: what the hell is that? ara_e_w: sorry i got disconnected! aslak_hellesoy: ok, but let's move all the generic stuff to some top script. for excample generation of xdoclet.xml and jarring it up... Everything will be driven by the top script... ara_e_w: ok aslak_hellesoy: how do you think the file structure looks? ara_e_w: the top level structure? aslak_hellesoy: xdoclet/modules aslak_hellesoy: sorry, i called it xdoclet/optional. should change that... ara_e_w: lots of vendor names, some ejb/web in it, and a script folder maybe ara_e_w: resources of a package in resources folder of that package ara_e_w: each module has a samples folder with src/build/etc aslak_hellesoy: wait, i DID call it xdoclet/modules. was looking at the old xdoclet/core/optional which goes away... aslak_hellesoy: what should go into ejb/web? ara_e_w: each module also has build/etc/src but the build.xml of the module and module's samples will merge a ../../merge.xml file containing common classpath/etc defs of ant ara_e_w: jsptaglib/webxml aslak_hellesoy: -but isn't that under sun module? aslak_hellesoy: oh i forgott, we dropped sun Yahoo! Messenger: ara_e_w has joined the conference. ara_e_w: hehe, there's two of me! aslak_hellesoy: hi ara aslak_hellesoy: hi ara aslak_hellesoy: two of us too aslak_hellesoy: two of us too ara_e_w: i'm getting two messages from you!!!! aslak_hellesoy: i was just kidding. hahaha ara_e_w: haha ara_e_w: ok, where were we? aslak_hellesoy: all the sun stuff goes to ejb and servlet package aslak_hellesoy: -module i mean ara_e_w: servlet? aslak_hellesoy: javax.servlet ara_e_w: javax.jsp ara_e_w: modules.web aslak_hellesoy: jbetter, yes. -so we're not 100% consistent, but nobody cares... ara_e_w: web.xml is not only about servlets of course ara_e_w: well, jsp/servlet are brothers ara_e_w: it's sun's fault! aslak_hellesoy: sure, but javax.web doesn't exist, but the deal is not big. hehe aslak_hellesoy: well, i guess this is enough to start working. anything else? ara_e_w: xdoclet.doc->xdoclet.modules.doc? ara_e_w: or xdoclet.modules.xdoclet.doc? ara_e_w: in core? modules? aslak_hellesoy: agree. xdoclet.doc.info -> xdoclet.info aslak_hellesoy: in modules, no? aslak_hellesoy: xdoclet.modules.xdoclet.doc! ara_e_w: in modules imho, yes like that! aslak_hellesoy: we're no better than anybody else! ara_e_w: absolutely no modules in core aslak_hellesoy: zip, nada ara_e_w: keep xdoclet.tags in core? aslak_hellesoy: yeah, let's not mess with it. ara_e_w: ok, it's ffine ara_e_w: so we have ant/loader/tags/template/util in core aslak_hellesoy: agree ara_e_w: and unit test for core stuff, but tests/retest/etc for each module in its own module aslak_hellesoy: yes ara_e_w: spliting core/test is a big headache! aslak_hellesoy: Let's wait until refactoring is ok. Using IDEA makes it easier. refactor in current structure, then copy out aslak_hellesoy: I want to make a new package in core: xdoclet.tasks put all ant tasks there. The goal ist to move towards aslak_hellesoy: ...ant independence ara_e_w: ok aslak_hellesoy: ok all three messages? ara_e_w: xdoclet.tasks? EjbdocletTask there? aslak_hellesoy: yes. aslak_hellesoy: unless we can move that to modules too, but i don't think we can/should ara_e_w: no, what if I want to create XmlRpcTask? messy. should be in its module aslak_hellesoy: do you think loader module/bcel will work still? aslak_hellesoy: ok, xdoclet.ejb.ant.EjbDocletTask? aslak_hellesoy: xdoclet.modules.ejb.ant.EjbDocletTask I mean ara_e_w: imho again put ejb/webDocletTask (std tasks) in core (xdoclet.tasks) ara_e_w: vendor Tasks in its module/group (jbossTask if ever under modules/jboss aslak_hellesoy: -but we moved the ejb/web taghandlers and subtask to modules ?! aslak_hellesoy: i mean, core is core and core only, no? ara_e_w: hmm, i'm getting confused! yup put it in modules/ejb ara_e_w: xdoclet.modules.ejb.ant.EjbDocletTask under modules/ejb aslak_hellesoy: agreed aslak_hellesoy: no what? aslak_hellesoy: now what? ara_e_w: what? have you moved them? can you commit so that I can play too? aslak_hellesoy: moved what? ara_e_w: moved to new structure aslak_hellesoy: Ejb/WebDocletTask.java are still under core, no? at least here in norway it is... ara_e_w: xdoclet.modules.ejb.ant.EjbDocletTask under modules/ejb aslak_hellesoy: my memory... well they are in both places it seems... aslak_hellesoy: took a closer look. I haven't moved EjbDocletTask from core... I don't understand what you mean. ara_e_w: here take a look at prev messages! we agreed!! ara_e_w: who said "xdoclet.modules.ejb.ant.EjbDocletTask I mean"? u. ara_e_w: don't get confused aslak_hellesoy: sure, i agree, but i haven't committed anything after we started chatting. you're confusing me! ara_e_w: lol aslak_hellesoy: hehe, -so how should we proceed? i think we have agreed on all important issues... ara_e_w: btw then how to do task/subtask loading? ara_e_w: we have xdoclet.jar, ejb-module.jar and some other jboss-module.jar/etc aslak_hellesoy: -or we put everything in one xdoclet-modules.jar aslak_hellesoy: don't you think we'll avoid people with 10-15 xdoclet-fubar.jar? ara_e_w: but no problem, for EjbDocletTask xdoclet.jar & ejb-module.jar are in tasks classpath aslak_hellesoy: exact ara_e_w: well, each module->its jar, but we'll also have a modules.jar aslak_hellesoy: jar in jars? ara_e_w: no, separately ara_e_w: even better: ejb-modules.jar, web-modules.jar, jmx-modules.jar ara_e_w: not a big modules.jar but a bit more categorized aslak_hellesoy: should put xdoclet somewhere in the name to avoid name clashes with other jars ara_e_w: ?? ara_e_w: xdoclet-ejb-modules.jar u mean? aslak_hellesoy: what if some other crazy guy makes a jmx-modules.jar. yes, something like that... ara_e_w: fuck that guy! xdoclet is king aslak_hellesoy: that's the attitude i love! ara_e_w: it's one of the things modules/ejb/script/build.xml will do->packaging xdoclet-ejb-modules.jar aslak_hellesoy: -but seriously, i still would like to be a jar file and say "aha, that must be an xdoclet plugin". many projects have a lot of jars... aslak_hellesoy: ok, so we _do_ put xdoclet in jarname then... ara_e_w: yes ara_e_w: have u committed sth? aslak_hellesoy: how about making one xdoclet-all-module.jar too? a simple ant stunt! I would prefer that. aslak_hellesoy: no, nothing. i have nothing to commit. ara_e_w: yes good idea aslak_hellesoy: let's split some work between us now... ara_e_w: ok aslak_hellesoy: suggestions? we can assign tasks to vincent and marcus too i think... ara_e_w: well,we should move lots of things aslak_hellesoy: personally, i'd like to writhe the new ant scripts. i've been doing that for a year at work, and i love it.i know the include feature... aslak_hellesoy: -so if you fire up your idea, refactor to new packages and move it...? ara_e_w: ok, plz put <pretty/> everywhere too ara_e_w: there's nothing left in your hard disk uncommitted? aslak_hellesoy: fucking pretty. it's she that puts newline everywhere! aslak_hellesoy: nuttin! ara_e_w: no it's Konstantin! I've asked it in IDEA's mailing list, it's a problem between linux/windows aslak_hellesoy: nothing red in tortoise/wincvs. ara_e_w: where the hell should i start from?! maybe from changing sun->ejb, putting modules in package names? aslak_hellesoy: sure? i think i've seen some files come out of my pretty with newlines. it has to be pretty, cus javadocs never has newlines. example: aslak_hellesoy: /** * Sets the Createtables attribute of the WebLogicSubTask object * * @param flag The new Createtables value */ public void setCreatetables(boolean flag) { _createTables = flag; } aslak_hellesoy: doesn't that smell of pretty? ara_e_w: easy to test, change a file, run pretty see if it fucks it ara_e_w: on a good looking file i mean aslak_hellesoy: yes, start moving the sun stuff, and the remaining parts that are in core that shouldn't be there aslak_hellesoy: -yeah, but the phenomenon is not reproducible. it's random. happens when you least expect it. ara_e_w: and how can u work in parallel? ara_e_w: fixcrlf fixes it aslak_hellesoy: I'll just work on the build.xml and assume the module structure is the same as now... aslak_hellesoy: we didn't decide to change that did we? -just add to it, and move resources under package... ara_e_w: ok, and we'll crosscheck with each other, it ara_e_w: it's 12:10 here and I'll sleep 2:30 (cause it's friday tomorrow and weekend) ara_e_w: haven't we decided? aslak_hellesoy: ok, i'll start on the scripts. i'll send this to dev. i think everything is agreed. ara_e_w: so i shouldn;t add modules to package name, right? keep as is? aslak_hellesoy: are you kidding me? ara_e_w: no but "we didn't decide to change that did we? -just add to it, and move resources under package..." ara_e_w: you meant no change in package names or not? aslak_hellesoy: wait, i'm scrolling up... ara_e_w: I see xdoclet.modules.ejb.ant.EjbDocletTask in prev messages/etc aslak_hellesoy: ara_e_w: +1 to xdoclet.modules.ejb, xdoclet.modules.web, xdoclet.modules.jmx, xdoclet.modules.webservice and so on ara_e_w: we have D:\Projects\xdoclet\modules\sun\src\xdoclet\sun\ejb, i should chnage it to: D:\Projects\xdoclet\modules\sun\src\xdoclet\modules\ejb\subtasks ara_e_w: ok, so i'll mov! aslak_hellesoy: D:\Projects\xdoclet\modules\ejb\src\xdoclet\modules\ejb\subtasks rather, no? ara_e_w: yup yup aslak_hellesoy: fine! i'm sending our discussion now then... ara_e_w: it's longer than middle east peace talks! aslak_hellesoy: wait! where did the subtasks package come from can't remember we agreed on that? ara_e_w: no it's there in current code ara_e_w: there's also taghandlers aslak_hellesoy: D:\Projects\xdoclet\modules\ejb\src\xdoclet\modules\ejb\entity|session|value ara_e_w: we'll have ejb.entity right? aslak_hellesoy: -and then subtask and taghandler in same package. wasn't that the consensus? ara_e_w: yes, so handler/subtasks all in modules.ejb aslak_hellesoy: yes, but one subpackage level to separate pk, session, value, data, entity etc... ara_e_w: ok/value/data under entity aslak_hellesoy: ok. ara_e_w: how bout EjbTagsHandler which is generral aslak_hellesoy: under xdoclet.modules.ejb We should push the general stuff up ara_e_w: ok ara_e_w: btw r u using TortoiseCVS v50 or 44? ara_e_w: stable or unstable version? aslak_hellesoy: v50 it has more options for merging, branching and so on. haven't had any problems aslak_hellesoy: it even has built-in menuitem for weblog! it's very smart ara_e_w: awesome ara_e_w: looks like you can commit/update right from win explorer aslak_hellesoy: yes. the only thing i'm missing is flat mode. aslak_hellesoy: even directories get red (if you enable that in prefs) aslak_hellesoy: -and the help is the best cvs tutorial i've ever seen. very short, very descriptive aslak_hellesoy: are we done? ara_e_w: I'm moving them ara_e_w: btw plz remove @todo-javadoc option from pretty settings, don't add useless comments aslak_hellesoy: ok, i'll disconnect unless you have sthn else on your mind... ara_e_w: nothing specific ara_e_w: cu aslak_hellesoy: it is removed. it was from the old pretty settings with BEKK in them. cu. great session! _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
