Re: [Clirr-devel] maven plugin

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

Simon Kitching wrote:

>On Mon, 2004-07-05 at 17:47, Lars Kühne wrote:
>  
>
>>Simon Kitching wrote:
>>    
>>
>>OK, so the plan is to have two top level modules, core and maven.
>>
>>The top level package structure is not affected by that move, I don't 
>>think Maven requires the module name to occur as a package name. This 
>>means we can have:
>>
>>clirr-core.jar
>>+ n.s.c.core (includes only Checker)
>>+ n.s.c.core.event
>>+ n.s.c.core.internal.framework (not to be used by integration frontends)
>>+ n.s.c.core.internal.checks (dito)
>>+ n.s.c.cli
>>+ n.s.c.ant
>>
>>    
>>
>
>Sorry, what do you mean by "module"?
>
>  
>

I mean toplevel modules in a Maven multiproject setup. This is basically 
the toplevel directory structure when you CVS-checkout clirr. Each 
module (core and maven) have a toplevel project.xml.

Basically the multiproject plugin will search for subdirectories with 
project.xml files, cd into each of those, and build it (plus I think it 
will also build a couple of other things, like a wrapper website).

Most of the current content of the root directory will be moved into the 
'core' module/subdir, Vincent will fill the maven module.

If I understand things correctly, the multiproject plugin is _the_ way 
to make Maven build multiple artifacts (jars) in one combined build.

>I see *four* basic packages:
>  n.s.c.core
>  n.s.c.ant
>  n.s.c.cli
>  
>

Yes, that is the basic java package structure. The core multiproject 
module (Vincent, please correct my terminology if necessary) will 
contain the above three Java top-level packages. Because each module 
corresponds to one jar, this will lead to a combined jar that is easy to 
use, just like what we have now.

>  n.s.c.maven
>  
>

If the Maven plugin requires that (maybe it only use Jelly script?) that 
package will be hosted by the maven module.

>If the above package structure is what is proposed, I like it.
>Have I misunderstood?
>
>  
>

I hope I have clarified the difference between the multiproject 
directory structure and the java package structure, and how the latter 
is more fine-grained in our case.

>[...]
>I think the ant/maven enhancement I suggested in recent emails is
>*really important* for users. 
>
>Given the decision to issue ERROR level messages for lots of things that
>may not be a problem for users depending upon context (eg adding method
>to interface only breaks systems where users are expected to implement
>those interfaces), I think it is really important to give users the
>ability to selectively ignore certain errors being reported by clirr
>when using the ant or maven tasks.
>
>Personally, I would really like to see this (pretty simple) feature
>added before the 0.4 release....
>  
>

If you can do it quickly, that's fine by me. We can also push out 
another release quickly ("release often" style), so I don't think it's 
*that* important.

Maybe it would be better to specify those ignored errors in a separate 
file instead of using the ant file directly? The Maven plugin could then 
use it to build a web page that documents the incompatibilities that 
were ignored, and why (define an XML format that allows to specify the 
reason).

Lars