clirr-devel — Discussion about the source code of Clirr

Re: [Clirr-devel] MethodSetCheck: changing argument count

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

On Mon, 2004-07-05 at 18:04, Lars K=FChne wrote:
> Hi Simon,
>=20
> sorry for the late answer.

Euro 2004 football finals are over, right? :-)

And what a surprise result...I think it's great to see Greece take the
cup away.

That's a nice leadup to the Olympics.

RE: [Clirr-devel] Maven plugin: filtering error messages

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Simon Kitching
> Sent: lundi 5 juillet 2004 01:15
> To: cli...@li...
> Subject: [Clirr-devel] Maven plugin: filtering error messages
> 
> Hi,
> 
> On Friday I sent an email regarding the Ant task. This could apply to
> the Maven plugin too, so here's the original comment for your
> consideration...
> 
> On Fri, 2004-07-02 at 15:09, Simon Kitching wrote:
> 
> > One thing that should now be fairly easy to support if you wish to is
> > adding some stuff to the Ant task to allow users to selectively ignore
> > certain messages. Because each message has a unique id, it should be
> > simple to support tags in the ant file like:
> >
> >   <ignore-error class="com.acme.widget" message-id="7001"/>
> >
> > When a build "clirrs" (in your suggested terminology :-), but the user
> > doesn't care about that particular problem, they could add a tag like
> > this to suppress the error-counting for that problem. And it will work
> > for any locale, because the message-ids don't change by locale.
> >
> > Just a thought....

I completely agree that we need a way to tell Clirr to ignore some checks.
However, I'd prefer that this ignore list be specified with the name of the
check (check id) instead of the message id. But I could live with both
solutions.

Thanks
-Vincent

Re: [Clirr-devel] maven plugin

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

On Mon, 2004-07-05 at 17:47, Lars K=FChne wrote:
> Simon Kitching wrote:
> >
>=20
> OK, so the plan is to have two top level modules, core and maven.
>=20
> The top level package structure is not affected by that move, I don't=20
> think Maven requires the module name to occur as a package name. This=20
> means we can have:
>=20
> 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 frontend=
s)
> + n.s.c.core.internal.checks (dito)
> + n.s.c.cli
> + n.s.c.ant
>=20

Sorry, what do you mean by "module"?

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

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

>=20
> On our web site we can follow Vincent's suggestion and have a toplevel=20
> menu entry like
>=20
> Integrations
> + Ant
> + Command Line
> + Maven

Yep, looks nice.

> >I've been thinking it's about time for a 0.4 release. If you're
> >interested in getting others to use clirr then it might be a good idea
> >to get this new release out the door.
> >
> > =20
> >
>=20
> Yep, let's get that Maven plugin ready and then release 0.4.

I think the ant/maven enhancement I suggested in recent emails is
*really important* for users.=20

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

Cheers,

Simon

[Clirr-devel] Handling private/package-scope changes

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

Hi Lars,

In the original clirr design, all package and private classes, members &
fields were ignored, because they were irrelevant to the goal of
detecting "binary incompatibilities".

I added the *option* to include private and package things in clirr's
processing in order to be able to generate complete change reports.
However this currently has the effect of reporting binary
compatibilities for things like changing the type of a private field or
package-scope method return type when reporting on private items is
enabled.

I would like to keep the ability to generate complete change reports,
but restore the original behaviour of reporting ERROR and WARNING stuff
only for public/protected things, ie stuff that is intended to be
visible to "users" of the package.

What I have done is added the following methods to AbstractDiffReporter:
  public Severity getSeverity(JavaClass clazz, Severity s);
  public Severity getSeverity(JavaClass clazz, Method m, Severity s);
  public Severity getSeverity(JavaClass clazz, Field f, Severity s);

These methods are called from just about anywhere an ApiDifference is
reported from, and they "reduce" the severity from ERROR/WARN to info if
the specified class, method, or field is package or private scope.

Is this change ok by you?

Regards,

Simon

Re: [Clirr-devel] MethodSetCheck: changing argument count

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

Hi Simon,

sorry for the late answer.

Simon Kitching wrote:

>Hi Lars,
>
>Re the check for "Method argument count changed".
>
>I suggest it would be better to remove the "heuristic" code in the
>"similarity" section which tries to pair up methods which have different
>numbers of parameters.
>
>If this code was removed, then 
>
>old class:  
>  foo(int i);
>
>new class: 
>  foo(String s, Object o);
>
>would report
> * removed method "foo(int i)"
> * added method "foo(String s, Object o)"
>rather than
> * changed # of arguments in method foo
>
>Are these two different versions of method Foo *really* "the same method
>with different number of arguments"? I think the answer is "sometimes
>yes, sometimes no".
>
>And what do we report if the old version of Foo was overriding an
>inherited method, and the new version is not?
>
>By reporting a method removed + a method added, we may miss an
>opportunity to be "clever", but we won't ever report "method changed
>argument count" when the user sees the two variants as really being
>different methods.
>
>  
>

I think I implemented that heuristic as a response to a feature request 
from Stephen Colebourne.

>I think this is particularly important when there are a number of
>overloaded variants with the same method name.
>
>One possible compromise is to report "method changed argument count"
>only when new arguments have been added to the end of the list of
>arguments for the old method version. But frankly even this seems to
>introduce more complexity than needed. 
>
>What do you think?
>  
>

I agree the algorithm it's not perfect. Not sure if this is reason 
enough to remove it completely, maybe it's not that difficult to improve it?

I'd suggest leaving it in there, release 0.4 and wait for user feedback.

Lars

Re: [Clirr-devel] maven plugin

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

Simon Kitching wrote:

>[...]
>
>I have only one (minor) reservation about your original proposal. I did
>raise this by email, but didn't see any response. It is the matter of
>moving the "cli" stuff into a subpackage. I think the command
>  java net.sf.clirr.cli.Clirr
>is already quite long enough without moving the cli stuff into a
>subpackage :-).
>
>  
>

If we create an uberjar that includes our dependencies that problem goes 
away - you can do

java -jar clirr-uberjar.jar

But still you're right - in a small project like this it should not be 
necessary to have too many package levels.

>[...]
>  
>
>>The simplest thing is to create a module 'core' and simply move 
>>everything we have now (including cli and ant) into that module. You can 
>>then start committing the Maven plugin into a different module, so we 
>>end up with two multiproject modules, 'core' and 'maven'.
>>    
>>
>
>That would make the start command for the cli into this?
>  java net.sf.clirr.core.cli.Clirr 
>
>  
>

No, that's not what I meant, see below.

>>I'm not convinced anyway that it makes sense to have cli and ant in 
>>different packages: the jar would basically consist of one class file... 
>>If someone disagrees we can do further split-up later.
>>    
>>
>
>I tend to agree.
>
>  
>

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

On our web site we can follow Vincent's suggestion and have a toplevel 
menu entry like

Integrations
+ Ant
+ Command Line
+ Maven

[...]

>>I can understand your frustration, and I think we should start using 
>>multiproject next weekend (or earlier if everyone agrees - Simon, please 
>>speak up).
>>    
>>
>
>Fine by me. Don't worry about causing any problems for code I've got
>outstanding; I can deal with any problems that turn up.
>
>  
>

OK, I have saved my local changes (check method exceptions) in a patch 
that I can apply after the code has moved. It seems everybody is ready 
for the move, so I'll make it official:

!! Please do not commit anything into the old structure from this point, 
you might risk losing your work. !!

Vincent, you can start moving core to it's sub-module and add the maven 
plugin. Do you need help or is it easier for you if you do it alone?

>>>On a positive note, I'd really like to try using Clirr on my project at
>>>work. I've convinced other people that we should try it. As we're using
>>>Maven, I'd like to have a Maven plugin working quickly.
>>>      
>>>
>
>I've been thinking it's about time for a 0.4 release. If you're
>interested in getting others to use clirr then it might be a good idea
>to get this new release out the door.
>
>  
>

Yep, let's get that Maven plugin ready and then release 0.4.

Lars

Re: [Clirr-devel] maven plugin

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

On Sun, 2004-07-04 at 18:29, Lars K=FChne wrote:
> Vincent Massol wrote:
> >>>
> >>>I've tried 3 times to garner interest in refactoring the clirr direc=
tory
> >>>structure in order to support integration modules such as Ant, Eclip=
se
> >>>plugin, Maven plugin, Cli, etc. I've even spent time showing what it
> >
[stuff removed]

I'm also keen to see a Maven plugin, and agree Clirr is the best place
to host it.

I have only one (minor) reservation about your original proposal. I did
raise this by email, but didn't see any response. It is the matter of
moving the "cli" stuff into a subpackage. I think the command
  java net.sf.clirr.cli.Clirr
is already quite long enough without moving the cli stuff into a
subpackage :-).

Still, if (for some reason) moving the cli "main" class is absolutely
necessary to implement a Maven plugin, I could live with it.

Apart from that, I'm all for integrating the maven code as soon as
possible.


> The simplest thing is to create a module 'core' and simply move=20
> everything we have now (including cli and ant) into that module. You ca=
n=20
> then start committing the Maven plugin into a different module, so we=20
> end up with two multiproject modules, 'core' and 'maven'.

That would make the start command for the cli into this?
  java net.sf.clirr.core.cli.Clirr=20

>=20
> I'm not convinced anyway that it makes sense to have cli and ant in=20
> different packages: the jar would basically consist of one class file..=
.=20
> If someone disagrees we can do further split-up later.

I tend to agree.

>=20
> Simon, do you have uncommitted changes on your hard drive?

There's nothing I can't modify fairly easily. Don't let this stop you
from getting started...

>=20
> >>    * the Maven plugin should be hosted by Clirr itself, because that
> >>      would improve the user experience (one-stop shopping) a lot!
> >>   =20
> >>
> >
> >Cool. I also think so.

Me too. If only the UN could agree so easily :-)


> I can understand your frustration, and I think we should start using=20
> multiproject next weekend (or earlier if everyone agrees - Simon, pleas=
e=20
> speak up).

Fine by me. Don't worry about causing any problems for code I've got
outstanding; I can deal with any problems that turn up.

> >On a positive note, I'd really like to try using Clirr on my project a=
t
> >work. I've convinced other people that we should try it. As we're usin=
g
> >Maven, I'd like to have a Maven plugin working quickly.

I've been thinking it's about time for a 0.4 release. If you're
interested in getting others to use clirr then it might be a good idea
to get this new release out the door.

> >
> >>I suggest we meet on IRC right now or (if you
> >>want to give Simon a chance to participate) Sunday morning, 9:30 AM C=
EST.

I don't think that it's necessary to get me involved. You guys just go
ahead.


Cheers,

Simon

[Clirr-devel] Maven plugin: filtering error messages

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

Hi,

On Friday I sent an email regarding the Ant task. This could apply to
the Maven plugin too, so here's the original comment for your
consideration...

On Fri, 2004-07-02 at 15:09, Simon Kitching wrote:

> One thing that should now be fairly easy to support if you wish to is
> adding some stuff to the Ant task to allow users to selectively ignore
> certain messages. Because each message has a unique id, it should be
> simple to support tags in the ant file like:
> 
>   <ignore-error class="com.acme.widget" message-id="7001"/>
> 
> When a build "clirrs" (in your suggested terminology :-), but the user
> doesn't care about that particular problem, they could add a tag like
> this to suppress the error-counting for that problem. And it will work
> for any locale, because the message-ids don't change by locale.
> 
> Just a thought....

Cheers,

Simon

Re: [Clirr-devel] maven plugin

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

Vincent Massol wrote:

>  
>
>>-----Original Message-----
>>From: cli...@li... [mailto:clirr-devel-
>>ad...@li...] On Behalf Of Lars Kühne
>>Sent: samedi 3 juillet 2004 15:54
>>To: cli...@li...
>>Subject: Re: [Clirr-devel] maven plugin
>>
>>Vincent Massol wrote:
>>
>>    
>>
>>>Hi guys,
>>>
>>>I've tried 3 times to garner interest in refactoring the clirr directory
>>>structure in order to support integration modules such as Ant, Eclipse
>>>plugin, Maven plugin, Cli, etc. I've even spent time showing what it
>>>      
>>>
>>would
>>    
>>
>>>look like by sending a zip. Without much success it seems... ;-) (but I
>>>acknowledge you're busy on other things!).
>>>
>>>It's now been more than 1 month. I have also sent an email explaining
>>>      
>>>
>>that I
>>    
>>
>>>had coded a Maven plugin for Clirr. It seems there's not much interest
>>>      
>>>
>>from
>>    
>>
>>>you guys which is understandable as you may not be Maven users or fans :-
>>>      
>>>
>>)
>>    
>>
>>>Let me know if you're still uninterested. I have absolutely no problem
>>>committing the Maven plugin code in some other project (although I think
>>>it's a pity for the Clirr project). However I can't let it sit idle on my
>>>machine for too long lest it'll be obsolete (which it probably is and
>>>      
>>>
>>that
>>    
>>
>>>will cost me some more merging energy).
>>>
>>>Thanks
>>>-Vincent
>>>
>>>
>>>
>>>
>>>      
>>>
>>Vincent,
>>
>>I can assure you that I am still interested:
>>
>>    * we should get the infrastructure in place to start IDE plugin
>>      development
>>    
>>
>
>Yep. Is there any outstanding question preventing us from doing it right
>away?
>
>  
>


The simplest thing is to create a module 'core' and simply move 
everything we have now (including cli and ant) into that module. You can 
then start committing the Maven plugin into a different module, so we 
end up with two multiproject modules, 'core' and 'maven'.

I'm not convinced anyway that it makes sense to have cli and ant in 
different packages: the jar would basically consist of one class file... 
If someone disagrees we can do further split-up later.

We simply need to agree on the timing of the module restructuring move, 
so the files are not moved away under our feet when Simon or I have 
uncommitted changes.

Vincent, please tell us when you have the time to actually make that change.
I've started to implement checking of method exceptions, but these are 
only minor changes.
Simon, do you have uncommitted changes on your hard drive?

>>    * the Maven plugin should be hosted by Clirr itself, because that
>>      would improve the user experience (one-stop shopping) a lot!
>>    
>>
>
>Cool. I also think so.
>
>  
>
>>I have had a look at the zip file you sent and had a few remaining
>>questions. I sent those question on 06/13 in the "New directory
>>organziation" thread, but never saw any answer. Maybe this is due to the
>>email problems you had, maybe I missed your response (sorry if I did)...
>>    
>>
>
>It's true that I had some email problems. Here are the answers I have sent
>back (attached). Let me know why ones are still unanswered and I'll answer
>them quickly.
>
>  
>

Thanks for resending, I never saw the original email. Regarding the 
multiproject build, everything is clear now, and yes, the cactus/eclipse 
page you refererred to is what I meant.

>>Your motivation is really important to me, so I'd really like to get
>>this sorted out quickly. 
>>    
>>
>
>Cool. Sorry about the tone of my email. It's just that I've been trying to
>make progress on this front in the very limited amount of time I have and it
>has not progressed a lot.
>
>  
>

I can understand your frustration, and I think we should start using 
multiproject next weekend (or earlier if everyone agrees - Simon, please 
speak up).

/Lars

>On a positive note, I'd really like to try using Clirr on my project at
>work. I've convinced other people that we should try it. As we're using
>Maven, I'd like to have a Maven plugin working quickly.
>
>  
>
>>I suggest we meet on IRC right now or (if you
>>want to give Simon a chance to participate) Sunday morning, 9:30 AM CEST.
>>    
>>
>
>Sorry, can't just now (I'm going out with the kids). Also, I'm currently on
>a 56kbps telephone line (I've moved flat and I'm fighting to get my ADSL
>connection restored - it's taking much longer than planned - It seems I
>won't have it before 1 month... :-(
>
>Thanks Lars for your encouraging email! :-)
>-Vincent
>  
>

[Clirr-devel] CVS: clirr/src/java/net/sf/clirr Checker.java,1.21,1.22

[<lk...@us...>]

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

Modified Files:
	Checker.java 
Log Message:
ClassChangeCheck is now allowed to throw CheckerException
Useful in case the check needs to load a class, which might fail

Index: Checker.java
===================================================================
RCS file: /cvsroot/clirr/clirr/src/java/net/sf/clirr/Checker.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- Checker.java	2 Jul 2004 02:40:43 -0000	1.21
+++ Checker.java	3 Jul 2004 16:06:35 -0000	1.22
@@ -311,7 +311,7 @@
      * @param currentVersion the classes that are checked for
      *        compatibility with compatibilityBaseline
      */
-    private void reportDiffs(ClassSet compatibilityBaseline, ClassSet currentVersion)
+    private void reportDiffs(ClassSet compatibilityBaseline, ClassSet currentVersion) throws CheckerException
     {
         fireStart();
         runClassChecks(compatibilityBaseline, currentVersion);
@@ -319,6 +319,7 @@
     }
 
     private void runClassChecks(ClassSet compatBaseline, ClassSet currentVersion)
+            throws CheckerException
     {
         JavaClass[] compat = compatBaseline.toArray();
         JavaClass[] current = currentVersion.toArray();

[Clirr-devel] CVS: clirr/src/java/net/sf/clirr/framework ClassChangeCheck.java,1.4,1.5

[<lk...@us...>]

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

Modified Files:
	ClassChangeCheck.java 
Log Message:
ClassChangeCheck is now allowed to throw CheckerException
Useful in case the check needs to load a class, which might fail

Index: ClassChangeCheck.java
===================================================================
RCS file: /cvsroot/clirr/clirr/src/java/net/sf/clirr/framework/ClassChangeCheck.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ClassChangeCheck.java	18 Jun 2004 06:52:10 -0000	1.4
+++ ClassChangeCheck.java	3 Jul 2004 16:06:35 -0000	1.5
@@ -23,5 +23,5 @@
 
 public interface ClassChangeCheck
 {
-    boolean check(JavaClass compatBaseline, JavaClass currentVersion);
+    boolean check(JavaClass compatBaseline, JavaClass currentVersion) throws CheckerException;
 }

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: samedi 3 juillet 2004 15:54
> To: cli...@li...
> Subject: Re: [Clirr-devel] maven plugin
>=20
> Vincent Massol wrote:
>=20
> >Hi guys,
> >
> >I've tried 3 times to garner interest in refactoring the clirr =
directory
> >structure in order to support integration modules such as Ant, =
Eclipse
> >plugin, Maven plugin, Cli, etc. I've even spent time showing what it
> would
> >look like by sending a zip. Without much success it seems... ;-) (but =
I
> >acknowledge you're busy on other things!).
> >
> >It's now been more than 1 month. I have also sent an email explaining
> that I
> >had coded a Maven plugin for Clirr. It seems there's not much =
interest
> from
> >you guys which is understandable as you may not be Maven users or =
fans :-
> )
> >
> >Let me know if you're still uninterested. I have absolutely no =
problem
> >committing the Maven plugin code in some other project (although I =
think
> >it's a pity for the Clirr project). However I can't let it sit idle =
on my
> >machine for too long lest it'll be obsolete (which it probably is and
> that
> >will cost me some more merging energy).
> >
> >Thanks
> >-Vincent
> >
> >
> >
> >
>=20
> Vincent,
>=20
> I can assure you that I am still interested:
>=20
>     * we should get the infrastructure in place to start IDE plugin
>       development

Yep. Is there any outstanding question preventing us from doing it right
away?

>     * the Maven plugin should be hosted by Clirr itself, because that
>       would improve the user experience (one-stop shopping) a lot!

Cool. I also think so.

>=20
> I have had a look at the zip file you sent and had a few remaining
> questions. I sent those question on 06/13 in the "New directory
> organziation" thread, but never saw any answer. Maybe this is due to =
the
> email problems you had, maybe I missed your response (sorry if I =
did)...

It's true that I had some email problems. Here are the answers I have =
sent
back (attached). Let me know why ones are still unanswered and I'll =
answer
them quickly.

>=20
> Your motivation is really important to me, so I'd really like to get
> this sorted out quickly.=20

Cool. Sorry about the tone of my email. It's just that I've been trying =
to
make progress on this front in the very limited amount of time I have =
and it
has not progressed a lot.

On a positive note, I'd really like to try using Clirr on my project at
work. I've convinced other people that we should try it. As we're using
Maven, I'd like to have a Maven plugin working quickly.

> I suggest we meet on IRC right now or (if you
> want to give Simon a chance to participate) Sunday morning, 9:30 AM =
CEST.

Sorry, can't just now (I'm going out with the kids). Also, I'm currently =
on
a 56kbps telephone line (I've moved flat and I'm fighting to get my ADSL
connection restored - it's taking much longer than planned - It seems I
won't have it before 1 month... :-(

Thanks Lars for your encouraging email! :-)
-Vincent

Re: [Clirr-devel] maven plugin

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

Vincent Massol wrote:

>Hi guys,
>
>I've tried 3 times to garner interest in refactoring the clirr directory
>structure in order to support integration modules such as Ant, Eclipse
>plugin, Maven plugin, Cli, etc. I've even spent time showing what it would
>look like by sending a zip. Without much success it seems... ;-) (but I
>acknowledge you're busy on other things!).
>
>It's now been more than 1 month. I have also sent an email explaining that I
>had coded a Maven plugin for Clirr. It seems there's not much interest from
>you guys which is understandable as you may not be Maven users or fans :-)
>
>Let me know if you're still uninterested. I have absolutely no problem
>committing the Maven plugin code in some other project (although I think
>it's a pity for the Clirr project). However I can't let it sit idle on my
>machine for too long lest it'll be obsolete (which it probably is and that
>will cost me some more merging energy).
>
>Thanks
>-Vincent
>
>
>  
>

Vincent,

I can assure you that I am still interested:

    * we should get the infrastructure in place to start IDE plugin
      development
    * the Maven plugin should be hosted by Clirr itself, because that
      would improve the user experience (one-stop shopping) a lot!

I have had a look at the zip file you sent and had a few remaining 
questions. I sent those question on 06/13 in the "New directory 
organziation" thread, but never saw any answer. Maybe this is due to the 
email problems you had, maybe I missed your response (sorry if I did)...

Your motivation is really important to me, so I'd really like to get 
this sorted out quickly. I suggest we meet on IRC right now or (if you 
want to give Simon a chance to participate) Sunday morning, 9:30 AM CEST.

Lars

[Clirr-devel] maven plugin

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

Hi guys,

I've tried 3 times to garner interest in refactoring the clirr directory
structure in order to support integration modules such as Ant, Eclipse
plugin, Maven plugin, Cli, etc. I've even spent time showing what it would
look like by sending a zip. Without much success it seems... ;-) (but I
acknowledge you're busy on other things!).

It's now been more than 1 month. I have also sent an email explaining that I
had coded a Maven plugin for Clirr. It seems there's not much interest from
you guys which is understandable as you may not be Maven users or fans :-)

Let me know if you're still uninterested. I have absolutely no problem
committing the Maven plugin code in some other project (although I think
it's a pity for the Clirr project). However I can't let it sit idle on my
machine for too long lest it'll be obsolete (which it probably is and that
will cost me some more merging energy).

Thanks
-Vincent

[Clirr-devel] CVS: clirr/xdocs changes.xml,1.14,1.15

[<lk...@us...>]

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

Modified Files:
	changes.xml 
Log Message:
added german translations for error messages

Index: changes.xml
===================================================================
RCS file: /cvsroot/clirr/clirr/xdocs/changes.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- changes.xml	27 Jun 2004 14:21:43 -0000	1.14
+++ changes.xml	3 Jul 2004 11:22:27 -0000	1.15
@@ -47,6 +47,9 @@
             Note: Ant task attribute names and the output format of the XML formatter
             have changed to support this feature.
         </action>
+        <action dev="lkuehne" type="add">
+            Error messages are now localized. Initial supported languages are english and german.
+        </action>
     </release>
 
     <release version="0.3" date="2004-05-23">

[Clirr-devel] CVS: clirr/src/conf/net/sf/clirr/event EventMessages_de.properties,NONE,1.1

[<lk...@us...>]

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

Added Files:
	EventMessages_de.properties 
Log Message:
added german translations for error messages

--- NEW FILE ---
# Translations for messages generated by the check classes.
#
# {0} --> full class name of affected class
# {1} --> full method prototype of affected method
# {2} --> full field declaration of affected field
# {3}..{n} --> check-specific parameters


#-----------------------------------------------------------------------------
# ClassScopeCheck messages
#-----------------------------------------------------------------------------
m1000=Sichtbarkeit der Klasse wurde von {3} auf {4} erweitern
m1001=Sichtbarkeit der Klasse wurde von {3} auf {4} eingeschränkt
m1002=Kann Klassen-Scope nicht bestimmen: {3} in der alten Version
m1003=Kann Klassen-Scope nicht bestimmen: {3} in der neuen Version

#-----------------------------------------------------------------------------
# GenderChangeCheck messages
#-----------------------------------------------------------------------------
m2000=Klasse ist jetzt ein Interface
m2001=Interface ist jetzt eine Klasse

#-----------------------------------------------------------------------------
# ClassModifierCheck messages
#-----------------------------------------------------------------------------
m3000=Kann nicht herausfinden ob Klasse private ist
m3001=Der 'final' Modifier der Klasse wurde entfernt
m3002=Der Klasse wurde ein 'final' Modifier hinzugefügt, sie war bisher allerdings nicht ableitbar
m3003=Der Klasse wurde ein 'final' Modifier hinzugefügt
m3004=Der 'abstract' Modifier der Klasse wurde entfernt
m3005=Der Klasse wurde ein 'abstract' Modifier hinzugefügt

#-----------------------------------------------------------------------------
# InterfaceSetCheck messages
#-----------------------------------------------------------------------------
m4000=Das Interface {3} wird jetzt implementiert
m4001=Das Interface {3} wird nicht mehr implementiert

#-----------------------------------------------------------------------------
# ClassHierarchyCheck messages
#-----------------------------------------------------------------------------
m5000=Neue Oberklasse {3}
m5001={3} ist keine Oberklasse mehr

#-----------------------------------------------------------------------------
# FieldSetCheck messages
#-----------------------------------------------------------------------------
m6000={3} field {2} hinzugefügt
m6001=Das Feld {2} wurde entfernt
m6002=Der Wert von Feld {2} ist keine Compilezeit-Konstante mehr
m6003=Der Wert der Compilezeit-Konstanten {2} wurde geändert
m6004=Der Typ des Feldes {2} wurde von {3} zu {4} geändert
m6005=Das Feld {2} ist jetzt non-final
m6006=Das Feld {2} ist jetzt final
m6007=Das Feld {2} ist jetzt non-static
m6008=Das Feld {2} ist jetzt static
m6009=Sichtbarkeit des Feldes {2} wurde von {3} auf {4} erhöht
m6010=Sichtbarkeit des Feldes {2} wurde von {3} auf {4} herabgesetzt

#-----------------------------------------------------------------------------
# MethodSetCheck messages
#-----------------------------------------------------------------------------
# MethodSetCheck messages
m7000=Die Methode ''{1}'' ist jetzt durch die Oberklasse {3} implementiert
m7001=Die abstrakte methode ''{1}'' ist jetzt im implementierten Interface {3} spezifiziert
m7002=Method ''{1}'' wurde entfernt
#m7003 no longer used
m7004=In der Methode ''{1}'' hat sich die Anzahl der Argumente geändert
m7005=Parametertyp {3} von ''{1}'' wurde zu {4} geändert
m7006=Rückgabetyp der Methode ''{1}'' wurde zu {3} geändert
m7007=Methode ''{1}'' wurde als deprecated markiert
m7008=Methode ''{1}'' ist nicht mehr deprecated
m7009=Sichtbarkeit von Methode ''{1}'' wurde von {3} auf {4} reduziert
m7010=Sichtbarkeit der Methode ''{1}'' wurde von {3} auf {4} erhöht
m7011=Methode ''{1}'' wurde hinzugefügt
m7012=Methode ''{1}'' wurde zum Interface hinzugefügt
m7013=Abstract Methode ''{1}'' wurde hinzugefügt

#-----------------------------------------------------------------------------
# Core Check messages
#-----------------------------------------------------------------------------
m8000=Klasse {0} wurde hinzugefügt
m8001=Klasse {0} wurde entfernt

[Clirr-devel] CVS: clirr/src/java/net/sf/clirr/event EventMessages.java,NONE,1.1 MessageTranslator.java,1.1,1.2

[<lk...@us...>]

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

Modified Files:
	MessageTranslator.java 
Added Files:
	EventMessages.java 
Log Message:
replaced root package event-messages.properties with EventMessages bundle
solves the problem described in https://sourceforge.net/tracker/index.php?func=detail&aid=594469&group_id=29721&atid=397078

--- NEW FILE ---
//////////////////////////////////////////////////////////////////////////////
// Clirr: compares two versions of a java library for binary compatibility
// Copyright (C) 2003 - 2004  Lars Kühne
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
// Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
//////////////////////////////////////////////////////////////////////////////

package net.sf.clirr.event;

import java.util.ResourceBundle;
import java.util.Locale;
import java.util.Enumeration;

/**
 * ResourceBundle that implements the default locale by delegating to the english bundle.
 * This solves the bug described in
 * https://sourceforge.net/tracker/index.php?func=detail&aid=594469&group_id=29721&atid=397078
 * without having to duplicate any resource bundles, leading to a simpler build and a smaller jar.
 *
 * @author lkuehne
 */
public class EventMessages extends ResourceBundle
{
    /**
     * The base name of the resource bundle from which message descriptions
     * are read.
     */
    public static final String RESOURCE_NAME = EventMessages.class.getName();

    private ResourceBundle delegate = null;

    /**
     * Control variable used in synchronized blocks that delegate to the {@link #delegate} bundle.
     * The delegate bundle has "this" as it's parent.
     * To prevent infinite loops in the lookup process when searching for
     * non-existent keys we set isUsingDelegate to true to break out of the loop.
     */
    private boolean isUsingDelegate = false;

    /**
     * Constructor.
     * @deprecated Typical user code never calls this directly but uses
     * {@link ResourceBundle#getBundle(String)} or one of it's variants instead.
     */
    public EventMessages()
    {
    }

    private ResourceBundle getDelegate()
    {
        if (delegate == null)
        {
            delegate = ResourceBundle.getBundle(RESOURCE_NAME, Locale.ENGLISH);
        }
        return delegate;
    }

    /** @see ResourceBundle#handleGetObject */
    protected final synchronized Object handleGetObject(String key)
    {
        try
        {
            if (isUsingDelegate)
            {
                // the underlying bundle is delegating the call back to us
                // this means that the key is unknown, so we return null
                return null;
            }
            else
            {
                isUsingDelegate = true;
                return getDelegate().getObject(key);
            }
        }
        finally
        {
            isUsingDelegate = false;
        }
    }

    /** @see ResourceBundle#getKeys */
    public final synchronized Enumeration getKeys()
    {
        try
        {
            if (isUsingDelegate)
            {
                // the underlying bundle is delegating the call back to us
                // this means that the key is unknown, so we return null
                return null;
            }
            else
            {
                isUsingDelegate = true;
                return getDelegate().getKeys();
            }
        }
        finally
        {
            isUsingDelegate = false;
        }
    }

    /** @see ResourceBundle#getLocale */
    public final Locale getLocale()
    {
        return getDelegate().getLocale();
    }

}

Index: MessageTranslator.java
===================================================================
RCS file: /cvsroot/clirr/clirr/src/java/net/sf/clirr/event/MessageTranslator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MessageTranslator.java	2 Jul 2004 02:25:55 -0000	1.1
+++ MessageTranslator.java	3 Jul 2004 10:57:44 -0000	1.2
@@ -34,7 +34,7 @@
      * The default base name of the resource bundle from which message
      * descriptions are read.
      */
-    public static final String DFLT_RESOURCE_NAME = "event-messages";
+    public static final String DFLT_RESOURCE_NAME = EventMessages.class.getName();
 
     private Locale locale = Locale.getDefault();
     private String resourceName = DFLT_RESOURCE_NAME;

[Clirr-devel] CVS: clirr/src/conf/net/sf/clirr/event EventMessages_en.properties,NONE,1.1

[<lk...@us...>]

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

Added Files:
	EventMessages_en.properties 
Log Message:
replaced root package event-messages.properties with EventMessages bundle
solves the problem described in https://sourceforge.net/tracker/index.php?func=detail&aid=594469&group_id=29721&atid=397078

--- NEW FILE ---
# Translations for messages generated by the check classes.
#
# {0} --> full class name of affected class
# {1} --> full method prototype of affected method
# {2} --> full field declaration of affected field
# {3}..{n} --> check-specific parameters


#-----------------------------------------------------------------------------
# ClassScopeCheck messages
#-----------------------------------------------------------------------------
m1000=Increased visibility of class from {3} to {4}
m1001=Decreased visibility of class from {3} to {4}
m1002=Unable to determine class scope: {3} in old class version
m1003=Unable to determine class scope: {3} in new class version

#-----------------------------------------------------------------------------
# GenderChangeCheck messages
#-----------------------------------------------------------------------------
m2000=Changed from class to interface
m2001=Changed from interface to class

#-----------------------------------------------------------------------------
# ClassModifierCheck messages
#-----------------------------------------------------------------------------
m3000=Unable to determine whether class is private
m3001=Removed final modifier from class
m3002=Added final modifier to class, but class was effectively final anyway
m3003=Added final modifier to class
m3004=Removed abstract modifier from class
m3005=Added abstract modifier to class

#-----------------------------------------------------------------------------
# InterfaceSetCheck messages
#-----------------------------------------------------------------------------
m4000=Added {3} to the set of implemented interfaces
m4001=Removed {3} from the set of implemented interfaces

#-----------------------------------------------------------------------------
# ClassHierarchyCheck messages
#-----------------------------------------------------------------------------
m5000=Added {3} to the list of superclasses
m5001=Removed {3} from the list of superclasses

#-----------------------------------------------------------------------------
# FieldSetCheck messages
#-----------------------------------------------------------------------------
m6000=Added {3} field {2}
m6001=Removed field {2}
m6002=Value of field {2} is no longer a compile-time constant
m6003=Value of compile-time constant {2} has been changed
m6004=Changed type of field {2} from {3} to {4}
m6005=Field {2} is now non-final
m6006=Field {2} is now final
m6007=Field {2} is now non-static
m6008=Field {2} is now static
m6009=Accessability of field {2} has been increased from {3} to {4}
m6010=Accessability of field {2} has been weakened from {3} to {4}

#-----------------------------------------------------------------------------
# MethodSetCheck messages
#-----------------------------------------------------------------------------
m7000=Method ''{1}'' is now implemented in superclass {3}
m7001=Abstract method ''{1}'' is now specified by implemented interface {3}
m7002=Method ''{1}'' has been removed
#m7003 no longer used
m7004=In method ''{1}'' the number of arguments has changed
m7005=Parameter {3} of ''{1}'' has changed its type to {4}
m7006=Return type of method ''{1}'' has been changed to {3}
m7007=Method ''{1}'' has been deprecated
m7008=Method ''{1}'' is no longer deprecated
m7009=Accessability of method ''{1}'' has been decreased from {3} to {4}
m7010=Accessability of method ''{1}'' has been increased from {3} to {4}
m7011=Method ''{1}'' has been added
m7012=Method ''{1}'' has been added to an interface
m7013=Abstract method ''{1}'' has been added


#-----------------------------------------------------------------------------
# Core Check messages
#-----------------------------------------------------------------------------
m8000=Class {0} added
m8001=Class {0} removed

[Clirr-devel] CVS: clirr/src/conf event-messages.properties,1.4,NONE

[<lk...@us...>]

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

Removed Files:
	event-messages.properties 
Log Message:
replaced root package event-messages.properties with EventMessages bundle
solves the problem described in https://sourceforge.net/tracker/index.php?func=detail&aid=594469&group_id=29721&atid=397078

[Clirr-devel] CVS: clirr/src/conf/net/sf/clirr/event - New directory

[<lk...@us...>]

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

Log Message:
Directory /cvsroot/clirr/clirr/src/conf/net/sf/clirr/event added to the repository

[Clirr-devel] CVS: clirr/src/conf/net/sf/clirr - New directory

[<lk...@us...>]

Update of /cvsroot/clirr/clirr/src/conf/net/sf/clirr
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18558/clirr

Log Message:
Directory /cvsroot/clirr/clirr/src/conf/net/sf/clirr added to the repository

[Clirr-devel] CVS: clirr/src/conf/net/sf - New directory

[<lk...@us...>]

Update of /cvsroot/clirr/clirr/src/conf/net/sf
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18436/sf

Log Message:
Directory /cvsroot/clirr/clirr/src/conf/net/sf added to the repository

[Clirr-devel] CVS: clirr/src/conf/net - New directory

[<lk...@us...>]

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

Log Message:
Directory /cvsroot/clirr/clirr/src/conf/net added to the repository

[Clirr-devel] CVS: clirr/src/test/net/sf/clirr/event MessageTest.java,1.2,1.3

[<lk...@us...>]

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

Modified Files:
	MessageTest.java 
Log Message:
use JDK constant for english locale

Index: MessageTest.java
===================================================================
RCS file: /cvsroot/clirr/clirr/src/test/net/sf/clirr/event/MessageTest.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MessageTest.java	2 Jul 2004 03:02:22 -0000	1.2
+++ MessageTest.java	3 Jul 2004 10:44:39 -0000	1.3
@@ -41,7 +41,7 @@
 
         // check the english locale
         MessageTranslator translator = new MessageTranslator();
-        translator.setLocale(new Locale("en"));
+        translator.setLocale(Locale.ENGLISH);
         translator.checkComplete(messages);
     }
 }

[Clirr-devel] Phew! Message-related commits complete

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

Hi Lars,

Well I think those commit emails should have filled your email inbox
nicely by now :-).

I think that's all done. Now I just need to update the xdocs to document
each of these possible errors...should keep me busy for a while. Of
course if you wish to share the fun ...

One thing that should now be fairly easy to support if you wish to is
adding some stuff to the Ant task to allow users to selectively ignore
certain messages. Because each message has a unique id, it should be
simple to support tags in the ant file like:

  <ignore-error class="com.acme.widget" message-id="7001"/>

When a build "clirrs" (in your suggested terminology :-), but the user
doesn't care about that particular problem, they could add a tag like
this to suppress the error-counting for that problem. And it will work
for any locale, because the message-ids don't change by locale.

Just a thought....

Regards,

Simon