|
From: Koen S. <ko...@se...> - 2004-07-02 10:09:10
|
I guess this way we could eventually move to maven and use xdoclet to generate the (local)homes and local/remote interfaces as well as the dd. So the sources would be clean and easier to access by everybody. Koen Tomas Gustavsson writes: > > Good, lets give it a try :) > > /Tomas > > Stephane Bailliez wrote: > >> Tomas Gustavsson wrote: >> >>> Structuring is good and I agree about dependencies in general. The >>> cleaner the better. I guess you mean that path will move from >>> src/java/se/anatom/ejbca/keyrecovery to >>> src/keyrecovery/java/se/anatom/ejbca/keyrecovery? >> >> >> Yes. >> >>> It is not 100% clear to me that the extreme split up will only be >>> positive though. It will be more difficult to browse sources and get a >>> good overview. The modules have dependencies to one another, hopefully >>> only throught interfaces but still. How will the packaging and >>> compilation be done? Build jar for each module using other jars in >>> classpath? Or will one jar collect classes from several modules? And >>> what about the common parts? >> >> >> There is no problem browsing the sources, at least for a decent IDE. You >> are using Eclipse so you can have several modules inside a project and >> declare dependencies between modules. >> Same for me using Idea. >> >> Compilation is no problem yes we compile everything inside a single >> modules classes dir like or do exactly the same as it is right now. >> We need to know dependencies anyway, if we don't we have a problem. If we >> have circular dependencies this most likely indicate a problem. >> >> Common parts are common, and thus stay in the common tree like it is >> right now (that's the ejb-utils stuff, that is now stored in lib). >> >> What I did the last time while repackaging was stripping out the >> duplicated classes between jars, what was common is stored in the >> ejb-utils.jar and stored in lib. >> All ejb jars do have a Class-Path lib/ejb-utils.jar in the manifest and >> ejb-utils.jar load all other common libraries, thus dependency is >> resolved. >> >>>> In the very short term I plan to commit command line sources to 'cli', >>>> it is a bit refactor and use commons-cli to better manage command line >>>> options: >>>> Structure would then become: >>>> src/cli/src/main --> main source tree >>>> src/cli/src/test --> junit test case (hopefully) >>>> >>> The structure seems unessecary long to me, I assume the full path to a >>> class will be something like src/cli/src/main/se/...? The double 'src' >>> seems redundant. How about doing it like in ejbca/src today with >>> src/cli/java/... and src/cli/test/...? >> >> >> Yep looks fine I think. >> >>> In what shape is the XDoclet stuff now? That would be a good combination >>> with the above, since it should cut the number of classes to something >>> like half the current cumber? >> >> >> Some of it are ok, some are not. I will try switch the simple one asap so >> that at least we are set for some of them but I needed as well a somewhat >> clean structure, as we will probably have the need for merge points. >> >>> PS: After tomorrow I will be away three weeks on vacation. >> >> >> Ok, have a nice vacation then, I don't know yet for myself, but that most >> likely will be august (but preferably september) >> >> > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self > defense, top technical experts, no vendor pitches, unmatched networking > opportunities. Visit www.blackhat.com > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop |