clirr-devel

[Clirr-devel] [Patch] minor improvements

[Vincent M. <vm...@pi...>]

Hi Lars,

As I have never committed yet on this project (AFAIC recall...), here's
a patch for minor things:

- added target to ignore list
- fixed my timezone
- removed TODO about some "nonsense link" as I don't see it anymore.
Must have been fixed.
- fixed maven version required in xdocs. BTW, I've just built it on
Maven rc3 and it works fine
- bumped version
- fixed shortDescription which must be under 49 chars as it is used in
the generated jar manifest as description.
- added <versions> tags in project.xml. BTW, they can be used to
automatically generate a download page if you're interested.

Thanks
-Vincent

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

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

Committed, thanks!

You can simply commit simple fixes like these - I'll scan the commit 
messages and we can revert the changes if there are problems. I think 
review/discussion is only required for major changes that are not so 
easy to revert with CVS, e.g.

    * Changing the build process (make it a multiproject reactor build,
      use Centipede or Ant instead of Maven, ...)
    * Adding new source packages or changing package names
    * Adding new distributables, i.e. stuff that is released
      independently (for example a Maven plugin, an Eclipse plugin, etc.)
    * ... you get the idea

That's how we work on the checkstyle team, and it seems to work well there.

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?

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?

Thanks,
Lars


Vincent Massol wrote:

>Hi Lars,
>
>As I have never committed yet on this project (AFAIC recall...), here's
>a patch for minor things:
>
>- added target to ignore list
>- fixed my timezone
>- removed TODO about some "nonsense link" as I don't see it anymore.
>Must have been fixed.
>- fixed maven version required in xdocs. BTW, I've just built it on
>Maven rc3 and it works fine
>- bumped version
>- fixed shortDescription which must be under 49 chars as it is used in
>the generated jar manifest as description.
>- added <versions> tags in project.xml. BTW, they can be used to
>automatically generate a download page if you're interested.
>
>Thanks
>-Vincent
>  
>

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

[Vincent M. <vm...@pi...>]

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: 25 May 2004 07:16
> To: cli...@li...
> Subject: Re: [Clirr-devel] [Patch] minor improvements
>=20
> Committed, thanks!
>=20
> You can simply commit simple fixes like these - I'll scan the commit
> messages and we can revert the changes if there are problems. I think
> review/discussion is only required for major changes that are not so
> easy to revert with CVS, e.g.
>=20
>     * Changing the build process (make it a multiproject reactor
build,
>       use Centipede or Ant instead of Maven, ...)
>     * Adding new source packages or changing package names
>     * Adding new distributables, i.e. stuff that is released
>       independently (for example a Maven plugin, an Eclipse plugin,
etc.)
>     * ... you get the idea
>=20
> That's how we work on the checkstyle team, and it seems to work well
> there.

Agreed. As I had not contributed in a long time, I preferred to send the
patch instead of committing right away in order to re-establish a
dialogue :-) Now that it's done and that you are ok for me to commit,
I'll commit simple things like this one.

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).
Are you still happy if I commit it to the clirr CVS?

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?

>=20
> 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?

>=20
> 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?

Here's an example:

To run it, you simply need to define the maven.xdoc.distributionUrl
property.

For example:
maven.xdoc.distributionUrl=3Dhttp://www.ibiblio.org/maven/maven/plugins

The xdoc plugin will generate the download page. However, it will
construct the full URL this way:

${maven.xdoc.distributionUrl}/${pom.artifactId}-${version}.jar

Thus we would need to find a SF URL that matches this. The problem I
think is that SF URLs contain numbers and not artifact ids. That's
unless we point directly to a mirror...=20

-Vincent

>=20
> Thanks,
> Lars
>=20
>=20
> Vincent Massol wrote:
>=20
> >Hi Lars,
> >
> >As I have never committed yet on this project (AFAIC recall...),
here's
> >a patch for minor things:
> >
> >- added target to ignore list
> >- fixed my timezone
> >- removed TODO about some "nonsense link" as I don't see it anymore.
> >Must have been fixed.
> >- fixed maven version required in xdocs. BTW, I've just built it on
> >Maven rc3 and it works fine
> >- bumped version
> >- fixed shortDescription which must be under 49 chars as it is used
in
> >the generated jar manifest as description.
> >- added <versions> tags in project.xml. BTW, they can be used to
> >automatically generate a download page if you're interested.
> >
> >Thanks
> >-Vincent
> >
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Clirr-devel mailing list
> Cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clirr-devel

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

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

[Vincent M. <vm...@pi...>]

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: 26 May 2004 06:21
> Cc: cli...@li...
> Subject: Re: [Clirr-devel] [Patch] minor improvements
>=20
> Vincent Massol wrote:
>=20
> > [...]
> >
> >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).
> >
> >
>=20
> Great.
>=20
> >Are you still happy if I commit it to the clirr CVS?
> >
> >
> >
>=20
> Sure. From a user perspective it's much better to do find everything
in
> one place, clirr.sf.net.
>=20
> >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?
> >
> >
> >
>=20
> 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...

In maven you no longer use the reactor. There's a plugin called
multiproject that handles multiprojects.

For example if you wish to call the "dist" target for all (sub)projects:

maven -Dgoal=3Ddist multiproject:goal

Of course, we could (and should) have a top level maven.xml file with:

<goal name=3D"dist">
  <j:set var=3D"goal" value=3D"dist"/>
  <attainGoal name=3D"multiproject:goal"/>
</goal>

so that users can simply type "maven dist" at the top level to build all
subprojects.

Note: each subproject needs of course to perform an installation to the
local repo (jar:install for example) so that their artifacts are
available to the other subprojects through a dependency (which btw
allows Maven to build all projects in the correct order).

>=20
> 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?

It's possible of course, but...

Pros:
- I don't see any pros... ;-)

Cons:
- We won't have a nice integrated build. People will be checkout only
one module and not the other, thus making it difficult to have an
integrated build.
- For example the maven plugin with its tests won't be able to serve as
functional testing of the clirr framework.

>=20
> 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?

Sure!

In that case I suggest:

clirr
  |_ framework
  |_ integration
    |_ maven
    |_ eclipse

>=20
> 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?

I was also thinking about this the other day. It's possible to have:

clirr
  |_ framework
  |_ integration
    |_ ant
    |_ maven
    |_ eclipse

I'm all for it.

We could combine the framework + integration/ant jars by using a custom
goal in our maven.xml:

<zip [...] clirr.jar>
  <zipfileset [...] clirr-framework.jar/>
  <zipfileset [...] clirr-ant.jar/>
</zip>

There's a plugin called uberjar that we could possibly use but I'm not
sure it's exactly for this.

>=20
> 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?

The multiproject:site goals can do some site aggregation. It means our
website would have the following kind of menu:

[rest is same as now]

Integrations
  Ant
  Maven
  Eclipse

[rest is same as now]

When clicking on Ant/Maven/Eclipse, it will go to the site for that
project.

>=20
> 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?

No. It's our choice.

>=20
> >>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?
> >
> >
> >
>=20
> 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.
>=20
> 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.).

ok. I can confirm that it's not there anymore with Maven rc3.

[snip]

Thanks
-Vincent

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

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

Vincent,

clirr
+ framework
+ integration
+ Ant
+ Maven
+ Eclipse

looks good. Could you create that project structure locally (with only 
Ant or Maven under the integration folder) and send me a zip file? I'd 
like to have a look at it "live", play with it a bit and get comfortable 
with multiproject builds before we take it to CVS...

Thanks,
Lars


Vincent Massol wrote:

>  
>
>>-----Original Message-----
>>From: cli...@li... [mailto:clirr-devel-
>>ad...@li...] On Behalf Of Lars Kühne
>>Sent: 26 May 2004 06:21
>>Cc: cli...@li...
>>Subject: Re: [Clirr-devel] [Patch] minor improvements
>>
>>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...
>>    
>>
>
>In maven you no longer use the reactor. There's a plugin called
>multiproject that handles multiprojects.
>
>For example if you wish to call the "dist" target for all (sub)projects:
>
>maven -Dgoal=dist multiproject:goal
>
>Of course, we could (and should) have a top level maven.xml file with:
>
><goal name="dist">
>  <j:set var="goal" value="dist"/>
>  <attainGoal name="multiproject:goal"/>
></goal>
>
>so that users can simply type "maven dist" at the top level to build all
>subprojects.
>
>Note: each subproject needs of course to perform an installation to the
>local repo (jar:install for example) so that their artifacts are
>available to the other subprojects through a dependency (which btw
>allows Maven to build all projects in the correct order).
>
>  
>
>>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?
>>    
>>
>
>It's possible of course, but...
>
>Pros:
>- I don't see any pros... ;-)
>
>Cons:
>- We won't have a nice integrated build. People will be checkout only
>one module and not the other, thus making it difficult to have an
>integrated build.
>- For example the maven plugin with its tests won't be able to serve as
>functional testing of the clirr framework.
>
>  
>
>>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?
>
>Sure!
>
>In that case I suggest:
>
>clirr
>  |_ framework
>  |_ integration
>    |_ maven
>    |_ eclipse
>
>  
>
>>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?
>>    
>>
>
>I was also thinking about this the other day. It's possible to have:
>
>clirr
>  |_ framework
>  |_ integration
>    |_ ant
>    |_ maven
>    |_ eclipse
>
>I'm all for it.
>
>We could combine the framework + integration/ant jars by using a custom
>goal in our maven.xml:
>
><zip [...] clirr.jar>
>  <zipfileset [...] clirr-framework.jar/>
>  <zipfileset [...] clirr-ant.jar/>
></zip>
>
>There's a plugin called uberjar that we could possibly use but I'm not
>sure it's exactly for this.
>
>  
>
>>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?
>>    
>>
>
>The multiproject:site goals can do some site aggregation. It means our
>website would have the following kind of menu:
>
>[rest is same as now]
>
>Integrations
>  Ant
>  Maven
>  Eclipse
>
>[rest is same as now]
>
>When clicking on Ant/Maven/Eclipse, it will go to the site for that
>project.
>
>  
>
>>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?
>
>No. It's our choice.
>
>  
>
>>>>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.).
>
>ok. I can confirm that it's not there anymore with Maven rc3.
>
>[snip]
>
>Thanks
>-Vincent
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>_______________________________________________
>Clirr-devel mailing list
>Cli...@li...
>https://lists.sourceforge.net/lists/listinfo/clirr-devel
>
>  
>

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

[Vincent M. <vm...@pi...>]

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: 27 May 2004 18:04
> To: cli...@li...
> Subject: Re: [Clirr-devel] [Patch] minor improvements
>=20
> Vincent,
>=20
> clirr
> + framework
> + integration
> + Ant
> + Maven
> + Eclipse

You mean:

clirr
+ framework
+ integration
  ++ Ant
  ++ Maven
  ++ Eclipse

right?

>=20
> looks good. Could you create that project structure locally (with only
> Ant or Maven under the integration folder) and send me a zip file? I'd
> like to have a look at it "live", play with it a bit and get
comfortable
> with multiproject builds before we take it to CVS...

I'll see if I find the time.

-Vincent

>=20
> Thanks,
> Lars
>=20
>=20
> Vincent Massol wrote:
>=20
> >
> >
> >>-----Original Message-----
> >>From: cli...@li... [mailto:clirr-devel-
> >>ad...@li...] On Behalf Of Lars K=FChne
> >>Sent: 26 May 2004 06:21
> >>Cc: cli...@li...
> >>Subject: Re: [Clirr-devel] [Patch] minor improvements
> >>
> >>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...
> >>
> >>
> >
> >In maven you no longer use the reactor. There's a plugin called
> >multiproject that handles multiprojects.
> >
> >For example if you wish to call the "dist" target for all
(sub)projects:
> >
> >maven -Dgoal=3Ddist multiproject:goal
> >
> >Of course, we could (and should) have a top level maven.xml file
with:
> >
> ><goal name=3D"dist">
> >  <j:set var=3D"goal" value=3D"dist"/>
> >  <attainGoal name=3D"multiproject:goal"/>
> ></goal>
> >
> >so that users can simply type "maven dist" at the top level to build
all
> >subprojects.
> >
> >Note: each subproject needs of course to perform an installation to
the
> >local repo (jar:install for example) so that their artifacts are
> >available to the other subprojects through a dependency (which btw
> >allows Maven to build all projects in the correct order).
> >
> >
> >
> >>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?
> >>
> >>
> >
> >It's possible of course, but...
> >
> >Pros:
> >- I don't see any pros... ;-)
> >
> >Cons:
> >- We won't have a nice integrated build. People will be checkout only
> >one module and not the other, thus making it difficult to have an
> >integrated build.
> >- For example the maven plugin with its tests won't be able to serve
as
> >functional testing of the clirr framework.
> >
> >
> >
> >>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?
> >
> >Sure!
> >
> >In that case I suggest:
> >
> >clirr
> >  |_ framework
> >  |_ integration
> >    |_ maven
> >    |_ eclipse
> >
> >
> >
> >>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?
> >>
> >>
> >
> >I was also thinking about this the other day. It's possible to have:
> >
> >clirr
> >  |_ framework
> >  |_ integration
> >    |_ ant
> >    |_ maven
> >    |_ eclipse
> >
> >I'm all for it.
> >
> >We could combine the framework + integration/ant jars by using a
custom
> >goal in our maven.xml:
> >
> ><zip [...] clirr.jar>
> >  <zipfileset [...] clirr-framework.jar/>
> >  <zipfileset [...] clirr-ant.jar/>
> ></zip>
> >
> >There's a plugin called uberjar that we could possibly use but I'm
not
> >sure it's exactly for this.
> >
> >
> >
> >>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?
> >>
> >>
> >
> >The multiproject:site goals can do some site aggregation. It means
our
> >website would have the following kind of menu:
> >
> >[rest is same as now]
> >
> >Integrations
> >  Ant
> >  Maven
> >  Eclipse
> >
> >[rest is same as now]
> >
> >When clicking on Ant/Maven/Eclipse, it will go to the site for that
> >project.
> >
> >
> >
> >>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?
> >
> >No. It's our choice.
> >
> >
> >
> >>>>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.).
> >
> >ok. I can confirm that it's not there anymore with Maven rc3.
> >
> >[snip]
> >
> >Thanks
> >-Vincent
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: Oracle 10g
> >Get certified on the hottest thing ever to hit the market... Oracle
10g.
> >Take an Oracle 10g class now, and we'll give you the exam FREE.
> >http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
> >_______________________________________________
> >Clirr-devel mailing list
> >Cli...@li...
> >https://lists.sourceforge.net/lists/listinfo/clirr-devel
> >
> >
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Clirr-devel mailing list
> Cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clirr-devel

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

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

Vincent Massol wrote:

>>Vincent,
>>
>>clirr
>>+ framework
>>+ integration
>>+ Ant
>>+ Maven
>>+ Eclipse
>>    
>>
>
>You mean:
>
>clirr
>+ framework
>+ integration
>  ++ Ant
>  ++ Maven
>  ++ Eclipse
>
>right?
>  
>

Yes!

Indentation was removed by my mail client when it converted the message 
to plain text. Sorry for any confusion...