clirr-devel — Discussion about the source code of Clirr

[Clirr-devel] [ clirr-Feature Requests-961229 ] Error messages raised on a class that hasn't changed

[SourceForge.net <no...@so...>]

Feature Requests item #961229, was opened at 2004-05-26 23:54
Message generated for change (Comment added) made by scolebourne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961229&group_id=89627

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Colebourne (scolebourne)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error messages raised on a class that hasn't changed

Initial Comment:
Not sure why, but these errors seem wrong as the code 
hasn't changed.

Commons collections 3.0-HEAD

ERROR: Method 'public java.lang.Object next()' has been 
removed in 
org.apache.commons.collections.map.AbstractLinkedMap$
LinkIterator
ERROR: Method 'public java.lang.Object previous()' has 
been removed in 
org.apache.commons.collections.map.AbstractLinkedMap$
LinkIterator

ERROR: Method 'public java.lang.Object next()' has been 
removed in 
org.apache.commons.collections.map.AbstractHashedMap
$HashIterator



----------------------------------------------------------------------

>Comment By: Stephen Colebourne (scolebourne)
Date: 2004-06-03 23:49

Message:
Logged In: YES 
user_id=408725

HEAD file too big to attach. Try:
http://cvs.apache.org/builds/jakarta-
commons/nightly/commons-collections/

Javadoc on left (3.0 and HEAD)
http://jakarta.apache.org/commons/collections/

----------------------------------------------------------------------

Comment By: Stephen Colebourne (scolebourne)
Date: 2004-06-03 23:48

Message:
Logged In: YES 
user_id=408725

HEAD file too big to attach. Try:
http://cvs.apache.org/builds/jakarta-
commons/nightly/commons-collections/

Javadoc on left (3.0 and HEAD)
http://jakarta.apache.org/commons/collections/

----------------------------------------------------------------------

Comment By: Stephen Colebourne (scolebourne)
Date: 2004-06-03 23:46

Message:
Logged In: YES 
user_id=408725

Collections 3.0 vs CVS HEAD jar (attached)

----------------------------------------------------------------------

Comment By: Lars Kühne (lkuehne)
Date: 2004-06-02 09:40

Message:
Logged In: YES 
user_id=401384

Which versions of commons-collections are you testing
against, and where can I find precompiled binaries and the
javadoc for those versions?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961229&group_id=89627

[Clirr-devel] [ clirr-Feature Requests-961229 ] Error messages raised on a class that hasn't changed

[SourceForge.net <no...@so...>]

Feature Requests item #961229, was opened at 2004-05-26 23:54
Message generated for change (Comment added) made by scolebourne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961229&group_id=89627

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Colebourne (scolebourne)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error messages raised on a class that hasn't changed

Initial Comment:
Not sure why, but these errors seem wrong as the code 
hasn't changed.

Commons collections 3.0-HEAD

ERROR: Method 'public java.lang.Object next()' has been 
removed in 
org.apache.commons.collections.map.AbstractLinkedMap$
LinkIterator
ERROR: Method 'public java.lang.Object previous()' has 
been removed in 
org.apache.commons.collections.map.AbstractLinkedMap$
LinkIterator

ERROR: Method 'public java.lang.Object next()' has been 
removed in 
org.apache.commons.collections.map.AbstractHashedMap
$HashIterator



----------------------------------------------------------------------

>Comment By: Stephen Colebourne (scolebourne)
Date: 2004-06-03 23:48

Message:
Logged In: YES 
user_id=408725

HEAD file too big to attach. Try:
http://cvs.apache.org/builds/jakarta-
commons/nightly/commons-collections/

Javadoc on left (3.0 and HEAD)
http://jakarta.apache.org/commons/collections/

----------------------------------------------------------------------

Comment By: Stephen Colebourne (scolebourne)
Date: 2004-06-03 23:46

Message:
Logged In: YES 
user_id=408725

Collections 3.0 vs CVS HEAD jar (attached)

----------------------------------------------------------------------

Comment By: Lars Kühne (lkuehne)
Date: 2004-06-02 09:40

Message:
Logged In: YES 
user_id=401384

Which versions of commons-collections are you testing
against, and where can I find precompiled binaries and the
javadoc for those versions?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961229&group_id=89627

[Clirr-devel] [ clirr-Feature Requests-961229 ] Error messages raised on a class that hasn't changed

[SourceForge.net <no...@so...>]

Feature Requests item #961229, was opened at 2004-05-26 23:54
Message generated for change (Comment added) made by scolebourne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961229&group_id=89627

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Colebourne (scolebourne)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error messages raised on a class that hasn't changed

Initial Comment:
Not sure why, but these errors seem wrong as the code 
hasn't changed.

Commons collections 3.0-HEAD

ERROR: Method 'public java.lang.Object next()' has been 
removed in 
org.apache.commons.collections.map.AbstractLinkedMap$
LinkIterator
ERROR: Method 'public java.lang.Object previous()' has 
been removed in 
org.apache.commons.collections.map.AbstractLinkedMap$
LinkIterator

ERROR: Method 'public java.lang.Object next()' has been 
removed in 
org.apache.commons.collections.map.AbstractHashedMap
$HashIterator



----------------------------------------------------------------------

>Comment By: Stephen Colebourne (scolebourne)
Date: 2004-06-03 23:46

Message:
Logged In: YES 
user_id=408725

Collections 3.0 vs CVS HEAD jar (attached)

----------------------------------------------------------------------

Comment By: Lars Kühne (lkuehne)
Date: 2004-06-02 09:40

Message:
Logged In: YES 
user_id=401384

Which versions of commons-collections are you testing
against, and where can I find precompiled binaries and the
javadoc for those versions?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961229&group_id=89627

[Clirr-devel] [ clirr-Feature Requests-961229 ] Error messages raised on a class that hasn't changed

[SourceForge.net <no...@so...>]

Feature Requests item #961229, was opened at 2004-05-27 00:54
Message generated for change (Comment added) made by lkuehne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961229&group_id=89627

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Colebourne (scolebourne)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error messages raised on a class that hasn't changed

Initial Comment:
Not sure why, but these errors seem wrong as the code 
hasn't changed.

Commons collections 3.0-HEAD

ERROR: Method 'public java.lang.Object next()' has been 
removed in 
org.apache.commons.collections.map.AbstractLinkedMap$
LinkIterator
ERROR: Method 'public java.lang.Object previous()' has 
been removed in 
org.apache.commons.collections.map.AbstractLinkedMap$
LinkIterator

ERROR: Method 'public java.lang.Object next()' has been 
removed in 
org.apache.commons.collections.map.AbstractHashedMap
$HashIterator



----------------------------------------------------------------------

>Comment By: Lars Kühne (lkuehne)
Date: 2004-06-02 10:40

Message:
Logged In: YES 
user_id=401384

Which versions of commons-collections are you testing
against, and where can I find precompiled binaries and the
javadoc for those versions?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961229&group_id=89627

[Clirr-devel] [ clirr-Feature Requests-961222 ] Removing constants can be OK

[SourceForge.net <no...@so...>]

Feature Requests item #961222, was opened at 2004-05-27 00:48
Message generated for change (Comment added) made by lkuehne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961222&group_id=89627

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Colebourne (scolebourne)
>Assigned to: Lars Kühne (lkuehne)
Summary: Removing constants can be OK

Initial Comment:
Clirr objects when a static final constant is removed 
from a class. However, this is permitted if the type of 
the constant is primitive or a String.

See commons-collections 3.0-HEAD ReferenceMap

----------------------------------------------------------------------

>Comment By: Lars Kühne (lkuehne)
Date: 2004-06-02 10:37

Message:
Logged In: YES 
user_id=401384

You mean that compile time constants are inlined into the
client code and removing them will not affect compiled clients?

Which constant in ReferenceMap do you mean?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961222&group_id=89627

[Clirr-devel] [ clirr-Feature Requests-961227 ] Move method to superclass

[SourceForge.net <no...@so...>]

Feature Requests item #961227, was opened at 2004-05-27 00:51
Message generated for change (Comment added) made by lkuehne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961227&group_id=89627

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Colebourne (scolebourne)
>Assigned to: Lars Kühne (lkuehne)
Summary: Move method to superclass

Initial Comment:
Clirr currently objects if a method is removed from one 
class and added/exposed on the superclass if the 
superclass is package scoped.

eg. commons collections 3.0-HEAD 
TransformedMap/PredicatedMap
entrySet() previously on each class, now on new 
package scoped superclass

----------------------------------------------------------------------

>Comment By: Lars Kühne (lkuehne)
Date: 2004-06-02 10:27

Message:
Logged In: YES 
user_id=401384

I've started working on this one, a unit test is ready and
currently fails.

----------------------------------------------------------------------

Comment By: Stephen Colebourne (scolebourne)
Date: 2004-05-27 00:55

Message:
Logged In: YES 
user_id=408725

Actually this bug seems to affect any remove of a method 
from a subclass to be replaced by the same signature on a 
superclass

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=961227&group_id=89627

[Clirr-devel] CVS: clirr/xdocs anttask.xml,1.5,1.6

[Lars K?h. <lk...@us...>]

Update of /cvsroot/clirr/clirr/xdocs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30773

Modified Files:
	anttask.xml 
Log Message:
changed layout of preformated source to make it fit into the "source code" box.
Necessary for Maven 1.0-RC3, which changed the HTML layout of preformated code.

Index: anttask.xml
===================================================================
RCS file: /cvsroot/clirr/clirr/xdocs/anttask.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- anttask.xml	23 May 2004 08:58:37 -0000	1.5
+++ anttask.xml	2 Jun 2004 07:53:31 -0000	1.6
@@ -25,20 +25,27 @@
             <source>
 &lt;target name="checkbinarycompatibility" depends="build"&gt;
 
-  &lt;!-- buildtools.classpath should contain clirr.jar and the libraries it depends on --&gt;
+  &lt;!-- buildtools.classpath should contain
+        clirr.jar and the libraries it depends on --&gt;
 
-  &lt;taskdef classpathref="buildtools.classpath" resource="clirrtask.properties"/&gt;
-
-  &lt;property name="jar.baseline" value="${ant.project.name}-${compatibility.baseline.version}.jar"/&gt;
-
-  &lt;get src="${url.libbase}/${ant.project.name}/${jar.baseline}" dest="build/tmp/${jar.baseline}"/&gt;
+  &lt;taskdef
+        classpathref="buildtools.classpath"
+        resource="clirrtask.properties"/&gt;
+
+  &lt;property
+        name="jar.baseline"
+        value="${ant.project.name}-${compatibility.baseline.version}.jar"/&gt;
+
+  &lt;get
+        src="${url.libbase}/${ant.project.name}/${jar.baseline}"
+        dest="build/tmp/${jar.baseline}"/&gt;
 
   &lt;clirr&gt;
-    &lt;origfiles dir="build/tmp" includes="${jar.baseline}"/&gt;
-    &lt;newfiles dir="build/lib" includes="${jar.buildresult}"/&gt;
+        &lt;origfiles dir="build/tmp" includes="${jar.baseline}"/&gt;
+        &lt;newfiles dir="build/lib" includes="${jar.buildresult}"/&gt;
 
-    &lt;!-- &lt;formatter type="xml" outfile="build/clirr.xml" /&gt; --&gt;
-    &lt;!-- TODO: example for 3rd party classpath --&gt;
+        &lt;!-- &lt;formatter type="xml" outfile="build/clirr.xml" /&gt; --&gt;
+        &lt;!-- TODO: example for 3rd party classpath --&gt;
   &lt;/clirr&gt;
 
 &lt;/target&gt;

Re: [Clirr-devel] Patch: increase flexibility of scope selection

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

Hi Simon,

in general ScopeSelector looks like a good idea to clean up the 
implementation. I don't know whether public/protected is also hardwired 
in the logic anywhere, so we should do some testing first before we make 
it public in the Ant task.

Two minor points:

    * MethodSetCheck.getMethodId() is supposed to return the method
      sigmature as it appears in the code / Javadoc. With the
      ScopeSelector changes, it returns an extra "package" for package
      visible methods.
    * In most calls to ScopeSelector the flags are determined by the
      calling code only to pass them to the called ScopeSelector method.
      Could the code be simplified further by passing the AccessFlags
      object (JavaClass, Method, Field) directly?

If you can update the tests and fix getMethodId(), I think we can commit 
ScopeSelector.

Thanks,
Lars

PS: I think your encoding problems are related to your editor settings. 
In the license header of ScopeSelector there is a question mark instead 
of the umlaut character...


Simon Kitching wrote:

>Hi,
>
>Well, here's my first patch proposal for your consideration.
>
>When generating reports, users may want to see differences in package or
>even private-scope objects. Currently, clirr hardwires "public|private"
>in a number of places. This patch is intended to introduce a more
>flexible way of managing what objects get selected.
>
>The unit tests don't currently pass. I believe this is just because the
>"report" message strings are now a little different. I will try to
>figure out the easiest way to update these in the unit tests soon. In
>the meantime, any feedback on this code would be appreciated.
>
>The ScopeSelector.java file belongs in the "event" package.
>
>I do need to write some unit tests for this code, but wanted to get some
>feedback on the initial code first.
>
>NB: the diffs also report the line with "Lars Kuhne" has changed in this
>file. This is some side-effect of the fact that the u-umlaut cannot be
>represented in ascii. It's either CVS or jedit that's having problems
>with this char, probably also related to my system language setting. 
>
>If you like this patch, then some code should probably be written to
>allow ANT options to select the scope.
>
>My next patch proposal will provide a way to run tests from the
>command-line, rather than needing to be invoked from Ant, and will
>provide a way to set the selected scope. It's almost ready.
>
>Cheers,
>
>Simon
>
>  
>

Re: [Clirr-devel] Initial questions

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

Simon Kitching wrote:

>Hi,
>
>Can someone let me know the answers to the following?
>
>* 
>What Java version is clirr required to be compatible with?
>eg are java1.4-specific features allowed in the clirr codebase?
>
>I'm particularly thinking about XSL-related features. I would like to
>generate reports using xslt. Java 1.4 introduced the first built-in
>support for xslt. Can this support be assumed to be present or not?
>
>  
>

Personally I'm OK with 1.4 if it , at work I don't use 1.3 anymore. 
However for our potential target projects like jakarta commons, log4j, 
etc. I'm not really sure. I think their libraries are designed to work 
with 1.3, but I don't know about their build process - is it required 
that every build target (like "run-clirr") in jakarta commons will work 
with Java 1.3?

For your particular question, XSLT support can be added to Java 1.3 
simply by adding some libaries to the classpath. I suppose it's easy to 
add support for 1.3 later if required - go ahead and assume 1.4 for now.

>*
>I would like to add a class to allow clirr to be run from the
>command-line. Is this ok? And is it ok to add a dependency on
>jakarta-commons-cli for this purpose?
>
>  
>

Vincent and I were discussing different integration frontends for clirr 
recently (Ant, Maven, Eclipse) and command line is just another one. 
Yes, a command line interface is most welcome. Please put it in it's own 
package, just like the Ant task has it's own package.

Does jakarta-commons-cli have additional dependencies (like 
commons-logging, commons-lang, etc.)? If not, I'm OK with using commons-cli.

>*
>I had trouble compiling the code initially due to the non-ascii
>"u-umlaut" character in the name "Lars Kuhne". In the ant buildfile I
>had to add "encoding='ISO-8859-1'" in order to compile.[NB: I created an
>ant buildfile by hand as I had problems with Maven].
>
>  
>

The build.xml file is created automatically during the release build, 
it's not maintained by hand. Vincent is a Maven comitter, I assume we 
can resolve any problems with Maven quite easily. You should really be 
able to do a CVS checkout and type "cd clirr; maven jar". What exactly 
were your problems?

>Is there any chance this could be converted to an ascii "u"? (yes, I
>realise it would technically be a mis-spelling).
>
>  
>

What are the values of your $LANG environment variable and your 
file.encoding Java system property? Some Linux distributions do have 
some pretty weird defaults...

If our build tools have a problem with non-ascii characters, my 
preference is to fix the build tools. Most other countries in Europe use 
special characters as well (France, Spain, Scandinavia), so this should 
really work reliably.

However, to get you up to speed we can temporarily change "ü" to "ue" 
(the correct transformation in case umlauts are not available) until the 
problem in Maven/Ant is fixed. Exactly which occurence would you like to 
change?

Lars

[Clirr-devel] Patch: increase flexibility of scope selection

[Simon K. <si...@ec...>]

Hi,

Well, here's my first patch proposal for your consideration.

When generating reports, users may want to see differences in package or
even private-scope objects. Currently, clirr hardwires "public|private"
in a number of places. This patch is intended to introduce a more
flexible way of managing what objects get selected.

The unit tests don't currently pass. I believe this is just because the
"report" message strings are now a little different. I will try to
figure out the easiest way to update these in the unit tests soon. In
the meantime, any feedback on this code would be appreciated.

The ScopeSelector.java file belongs in the "event" package.

I do need to write some unit tests for this code, but wanted to get some
feedback on the initial code first.

NB: the diffs also report the line with "Lars Kuhne" has changed in this
file. This is some side-effect of the fact that the u-umlaut cannot be
represented in ascii. It's either CVS or jedit that's having problems
with this char, probably also related to my system language setting. 

If you like this patch, then some code should probably be written to
allow ANT options to select the scope.

My next patch proposal will provide a way to run tests from the
command-line, rather than needing to be invoked from Ant, and will
provide a way to set the selected scope. It's almost ready.

Cheers,

Simon

[Clirr-devel] Initial questions

[Simon K. <si...@ec...>]

Hi,

Can someone let me know the answers to the following?

* 
What Java version is clirr required to be compatible with?
eg are java1.4-specific features allowed in the clirr codebase?

I'm particularly thinking about XSL-related features. I would like to
generate reports using xslt. Java 1.4 introduced the first built-in
support for xslt. Can this support be assumed to be present or not?

*
I would like to add a class to allow clirr to be run from the
command-line. Is this ok? And is it ok to add a dependency on
jakarta-commons-cli for this purpose?

*
I had trouble compiling the code initially due to the non-ascii
"u-umlaut" character in the name "Lars Kuhne". In the ant buildfile I
had to add "encoding='ISO-8859-1'" in order to compile.[NB: I created an
ant buildfile by hand as I had problems with Maven].

Is there any chance this could be converted to an ascii "u"? (yes, I
realise it would technically be a mis-spelling).


Thanks,

Simon

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...

[Clirr-devel] CVS: clirr/src/java/net/sf/clirr/event XmlDiffListener.java,1.9,1.10

[Lars K?h. <lk...@us...>]

Update of /cvsroot/clirr/clirr/src/java/net/sf/clirr/event
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30533/src/java/net/sf/clirr/event

Modified Files:
	XmlDiffListener.java 
Log Message:
XML formatter did not write method and field attributes correctly.

Index: XmlDiffListener.java
===================================================================
RCS file: /cvsroot/clirr/clirr/src/java/net/sf/clirr/event/XmlDiffListener.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- XmlDiffListener.java	22 May 2004 13:26:03 -0000	1.9
+++ XmlDiffListener.java	27 May 2004 16:10:50 -0000	1.10
@@ -44,7 +44,7 @@
         PrintStream out = getOutputStream();
         out.print("  <" + DIFFERENCE);
         out.print(" severity=\"" + difference.getSeverity() + "\"");
-        out.print(" class=\"" + difference.getAffectedClass() + "\">");
+        out.print(" class=\"" + difference.getAffectedClass() + "\"");
         if (difference.getAffectedMethod() != null)
         {
             out.print(" method=\"" + difference.getAffectedMethod() + "\"");
@@ -53,6 +53,7 @@
         {
             out.print(" field=\"" + difference.getAffectedField() + "\"");
         }
+        out.print(">");
         out.print(difference.getReport()); // TODO: XML escapes??
         out.println("</" + DIFFERENCE + '>');
     }

[Clirr-devel] CVS: clirr/xdocs changes.xml,1.7,1.8

[Lars K?h. <lk...@us...>]

Update of /cvsroot/clirr/clirr/xdocs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30533/xdocs

Modified Files:
	changes.xml 
Log Message:
XML formatter did not write method and field attributes correctly.

Index: changes.xml
===================================================================
RCS file: /cvsroot/clirr/clirr/xdocs/changes.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- changes.xml	23 May 2004 15:10:25 -0000	1.7
+++ changes.xml	27 May 2004 16:10:48 -0000	1.8
@@ -7,6 +7,13 @@
   </properties>
   <body>
 
+    <release version="0.4-SNAPSHOT" date="in CVS">
+        <action dev="lkuehne" type="fix">
+            XML formatter did not write method and field attributes
+            correctly.
+        </action>
+    </release>
+
     <release version="0.3" date="2004-05-23">
         <action dev="lkuehne" due-to="Stephen Colebourne" type="fix">
             Fixed a copy + paste error in field modifier comparison logic

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,

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: 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

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

You're right! The following page is actually a download page:

http://sourceforge.net/project/showfiles.php?group_id=3D89627

:-)

-Vincent

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: 26 May 2004 05:29
> To: cli...@li...
> Subject: Re: [Clirr-devel] [Patch] minor improvements
>=20
> Vincent Massol wrote:
>=20
> >http://maven.apache.org/reference/plugins/jboss/downloads.html
> >
> >
>=20
> Hmm.. that doesn't provide new functionality that goes beyond what's
> available on the sf download page that is linked from
> http://clirr.sf.net/downlad.html.
>=20
> I'd say it's not worth the effort to investigate the artifact-id
> problem, and the current download page is OK as it is now.
>=20
> Lars
>=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

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

Vincent Massol wrote:

>http://maven.apache.org/reference/plugins/jboss/downloads.html
>  
>

Hmm.. that doesn't provide new functionality that goes beyond what's 
available on the sf download page that is linked from 
http://clirr.sf.net/downlad.html.

I'd say it's not worth the effort to investigate the artifact-id 
problem, and the current download page is OK as it is now.

Lars

[Clirr-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

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

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

> -----Original Message-----
> From: Vincent Massol [mailto:vm...@pi...]
> Sent: 25 May 2004 09:28
> To: 'cli...@li...'
> Subject: RE: [Clirr-devel] [Patch] minor improvements
> 

[snip]

> Here's an example:

http://maven.apache.org/reference/plugins/jboss/downloads.html

[snip]

-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-...>]

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
>  
>

[Clirr-devel] CVS: clirr project.properties,1.5,1.6

[Lars K?h. <lk...@us...>]

Update of /cvsroot/clirr/clirr
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8410

Modified Files:
	project.properties 
Log Message:
"nonsense link" for development process is gone in Maven 1.0 RC3

Index: project.properties
===================================================================
RCS file: /cvsroot/clirr/clirr/project.properties,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- project.properties	5 Oct 2003 17:51:19 -0000	1.5
+++ project.properties	25 May 2004 04:43:29 -0000	1.6
@@ -10,7 +10,6 @@
 
 # hide irrelevant stuff from the nav bar
 maven.xdoc.poweredby.image=
-# TODO: this still shows a nonsense link. I think that's a bug in Maven - will contact maven-user
 maven.xdoc.developmentProcessUrl=
 
 maven.junit.fork=true