Re: [Clirr-devel] [Patch] minor improvements

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

Vincent Massol wrote:

> [...]
>
>BTW, I'm trying to find some time to write the Maven plugin for clirr
>(it's really simple to do - I probably need about 2-3 hours end to end).
>  
>

Great.

>Are you still happy if I commit it to the clirr CVS?
>
>  
>

Sure. From a user perspective it's much better to do find everything in 
one place, clirr.sf.net.

>If so, before being able to commit it, we need to restructure the CVS
>directory structure. Here's what I propose:
>
>clirr
>  |_ framework
>    |_ [move everything that is currently in clirr/]
>  |_ maven
>
>I'll also provide the top level maven.xml that builds the whole thing.
>
>What do you think?
>
>  
>

In principle I'm positive, but I've never worked with Maven reactor 
builds (in fact Clirr is the only project where I'm using Maven at all), 
so I have a few questions...

Would it also be possible to add the Maven plugin in a new CVS module, 
i.e. have mavenplugin alongside CVSROOT and clirr? What are the 
pros/cons here?

In the future I might want to add IDE plugins as well (e.g. an Eclipse 
plugin that tells you that you broke the API while you're typing). Would 
it be possible to add such plugins within the structure you're proposing?

Would it be possible / make sense to split up the current content into 
"framework" and "anttask"? After a split, is it possible to distribute 
framework and anttask in one combined jar (like it is now), so the 
classpath setup in Ant builds remains manageable?

How would the website be organized? We have some toplevel content, plus 
some content for the individual subprojects (framework, Ant task, Maven 
plugin, Eclipse plugin, ...) - where would the xdocs of each one appear, 
and what would be the structure of the resulting website?

Would the reactor builds enforce a combined build of everything to make 
a release? For example, if nothing changes in framework and you improve 
the Maven plugin, would it be necessary to create a new, unchanged, 
release of framework just to make the Maven plugin publically available?

>>BTW, I'm using Maven 1.0 RC1 and the "nonsense link" is still there -
>>guess it's time to upgrade... Will Maven 1.0 final be released shortly
>>or does it make sense to install RC3 now?
>>    
>>
>
>Hmmm.... I didn't see any link but maybe I was not looking at the right
>place. Could you explain where you see this link?
>
>  
>

On http://clirr.sourceforge.net/ the navigation menu on the left 
contains a link "Development Process" that now points to the Clirr 
homepage. I had expected it to be removed when I cleared the property.

The original link to the Maven site does not quite fit with Clirr: The 
Maven site documents the release process of Turbine ("for the 2.X 
development path..."), talks about writing SQL "alter table" scripts for 
compatibility, documents what to do when modifying Maven plugins, etc.).

>>Where can I see an example of an auto-generated download page? We need
>>to make sure that our releases are distributed via the sourceforge
>>mirrors (or ibiblio), and not via our web site... Is that possible?
>>    
>>
>
>[...]
>The problem I
>think is that SF URLs contain numbers and not artifact ids. That's
>unless we point directly to a mirror... 
>  
>

See my other mail.

Cheers,
Lars