Re: [Clirr-devel] New directory organization

[<lak...@t-...>]

Vincent,

to me the maven multiproject approach basically looks OK, although I 
still don't see how to express dependencies between subprojects (i.e. 
framework must be compiled before ant and cli). In an earlier mail you 
said that the individual projects would install their artifacts in the 
maven repository. But how does multiproject know that framework is 
outdated and should be rebuilt before trying to compile cli?

The name "framework" does not really fit, the current framework java 
package is not meant to be something that is externally visible. It's an 
internal package that should be used by checks only. Maybe "core" or 
"kernel" is a better module name? It should characterize "the stuff that 
every integration frontend uses" ...

I like the "internal" package name approach that Eclipse takes. 
Everything inside an "internal" package and it's subpackage is not part 
of the official API. For example it's easy to exclude the internal 
packages from the module's javadoc (with Ant, don't know about Maven)

If we did the same in clirr, that would result in:

clirr-core.jar
+ n.s.c.core (includes Checker and content of current event package)
+ n.s.c.core.internal.framework (not to be used by integration frontends)
+ n.s.c.core.internal.checks (dito)

clirr-ant.jar
+ n.s.c.ant

clirr-cli.jar
+ n.s.c.cli

The frontend modules should additionally create some "all" modules that 
increases usability. For example clirr-cli-all.jar would include 
clirr-cli, clirr-core, bcel, commons-cli and commons-lang, so the user 
just has to type "java -jar clirr-cli-all.jar -oldversion x.jar 
-newversion y.jar".

WDYT?

I think we should do the java package structure changes before we move 
to multiproject, so we have a clean start there.

Lars


Lars Kühne wrote:

> (resending as I may have sent it with a moderated email address)
>
> Sending on behalf of Vincent:
>
> Hi Lars,
>
> Please find attached the proposed new directory structure + build (it 
> requires some tuning but it should give an idea of how it works).
>
> To build the whole project, run "maven dist" in clirr/
> To build only the framework project, cd to clirr/framework/ and type 
> "maven jar" or "maven dist".
>
> To build the whole website, run "maven multiproject:site" in clirr/. 
> If we want to customize the home page we'll need to add a top level 
> xdoc/ directory.
>
> Notice also that I've named the clirr framework artifact: 
> clirr-framework (instead of just clirr).
>
> Let me know if I can commit this.
>
> Also, I think we would need to update or java package structure for 
> the framework project:
>
> net.sf.clirr.framework
> net.sf.clirr.integration.ant
> net.sf.clirr.integration.maven
> net.sf.clirr.integration.eclipse
> [...]
>
> If we keep net.sf.clirr for the framework it will be more difficult to 
> change in the future so we may want to get it right now (that's what I 
> had to do for Cactus...).
>
> What do you think?
>
> -Vincent
>