[Ejbca-develop] Re: Source layout structure

[Koen S. <ko...@se...>]

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