clirr-devel — Discussion about the source code of Clirr

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 22:57
Message generated for change (Comment added) made by lkuehne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

>Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 21:42

Message:
Logged In: YES 
user_id=401384
Originator: NO

The catch block for RTE has been added in CVS.

Thanks for the stacktraces, this is an error I can't reproduce in the
current code base because I switched from bcel to asm.

Re the failure reporting: I understand your position, but I think it's
better to clearly signal an unrecoverable problem and then fail the build.
This forces the user to provide a correct classpath which is the long term
solution anyway, instead of forcing all tools in the toolchain to deal with
situations where they can't really do anything useful.


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 21:25

Message:
Logged In: YES 
user_id=263845
Originator: YES

Here they are. 

java.lang.ClassNotFoundException: antlr.TreeParser not found.
	at
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:88)
	at
net.sf.clirr.core.internal.checks.InterfaceSetCheck.check(InterfaceSetCheck.java:59)
	at net.sf.clirr.core.Checker.runClassChecks(Checker.java:190)
	at net.sf.clirr.core.Checker.reportDiffs(Checker.java:136)
	at net.sf.clirr.cli.Clirr.run(Clirr.java:155)
	at net.sf.clirr.cli.Clirr.main(Clirr.java:56)
Caused by: java.lang.ClassNotFoundException: antlr.TreeParser not found.
	at
org.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:91)
	at org.apache.bcel.classfile.JavaClass.getSuperClass(JavaClass.java:762)
	at
org.apache.bcel.classfile.JavaClass.getAllInterfaces(JavaClass.java:803)
	at
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:86)
	... 5 more
= xyz.framework.workspace.jar
============================================================

clirr: xyz.rpf.jar
Exception in thread "main" java.lang.Error:
java.lang.ClassNotFoundException: com.ibm.security.auth.PrincipalComparator
not found.
	at
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:88)
	at
net.sf.clirr.core.internal.checks.InterfaceSetCheck.check(InterfaceSetCheck.java:59)
	at net.sf.clirr.core.Checker.runClassChecks(Checker.java:190)
	at net.sf.clirr.core.Checker.reportDiffs(Checker.java:136)
	at net.sf.clirr.cli.Clirr.run(Clirr.java:155)
	at net.sf.clirr.cli.Clirr.main(Clirr.java:56)
Caused by: java.lang.ClassNotFoundException:
com.ibm.security.auth.PrincipalComparator not found.
	at
org.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:91)
	at org.apache.bcel.classfile.JavaClass.getInterfaces(JavaClass.java:788)
	at
org.apache.bcel.classfile.JavaClass.getAllInterfaces(JavaClass.java:804)
	at
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:86)
	... 5 more
= xyz.rpf.jar 


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 21:24

Message:
Logged In: YES 
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but
I print those out to stdout in a format similar to a regular error, but
using a fake category "FAILURE" instead. I think I agree more with the
Checkstyle approach - it is unfortunately very common to see problems with
wrong classpaths and missing classes creeping from the environment to the
tool execution, and it is not easy to recover if the tool won't handle
those gracefully.

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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 21:20

Message:
Logged In: YES 
user_id=401384
Originator: NO

Oh, and I'd love to see the stack trace that you are getting. Having
RuntimeExceptions propagating all up to the container is likely a bug.

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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 21:18

Message:
Logged In: YES 
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but
I print those out to stdout in a format similar to a regular error, but
using a fake category "FAILURE" instead. I think I agree more with the
Checkstyle approach - it is unfortunately very common to see problems with
wrong classpaths and missing classes creeping from the environment to the
tool execution, and it is not easy to recover if the tool won't handle
those gracefully.

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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 21:01

Message:
Logged In: YES 
user_id=401384
Originator: NO

Well, the core engine can't do anything useful when jars or classes are
missing, so I think it's OK to bail out with an exception. In Checkstyle
(where I'm also a committer) we report setup problems along with all the
code problems we find, and this causes an endless stream of support
requests. I'd like to avoid that mistake in Clirr.

If you look at the code for the clirr command line frontend in
net.sf.clirr.cli, you'll find that it catches some expected exceptions and
sets the exit code only in the main method. I should add a catch block for
RuntimeException, that is currently missing, and that is why you see stack
traces. Good catch :-)


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:10

Message:
Logged In: YES 
user_id=263845
Originator: YES

I am using the command-line - have not tried the others.

By killing the process I mean not handling runtime errors when running
clirr, and calling System.exit. This is not so bad for me now because I am
calling Clirr multiple times, one for each jar, since I want to be able to
group the generated messages. 

But the output to stderr and the stack traces for uncaught exceptions are
problematic. 


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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 13:58

Message:
Logged In: YES 
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean
by "kill the Clirr process"?


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

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

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

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

Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/cli
In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv17732/src/java/net/sf/clirr/cli

Modified Files:
	Clirr.java 
Log Message:
added catch block for RTE, in response to RFE #1710276

Index: Clirr.java
===================================================================
RCS file: /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/cli/Clirr.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Clirr.java	15 Apr 2007 05:10:42 -0000	1.9
+++ Clirr.java	1 May 2007 19:38:16 -0000	1.10
@@ -162,16 +162,26 @@
         }
         catch (CheckerException ex)
         {
-            System.err.println("Unable to complete checks:" + ex.getMessage());
+            System.err.println("Unable to complete checks: " + ex.getMessage());
             System.exit(1);
         }
         catch (MalformedURLException ex)
         {
-            System.err.println("Unable to create classloader for 3rd party classes:" + ex.getMessage());
+            System.err.println("Unable to create classloader for 3rd party classes: " + ex.getMessage());
             System.err.println("old classpath: " + oldClassPath);
             System.err.println("new classpath: " + newClassPath);
             System.exit(1);
         }
+        catch (RuntimeException ex)
+        {
+            System.err.println("Unable to complete checks: " + ex.toString());
+            Throwable cause = ex.getCause();
+            if (cause != null)
+            {
+                System.err.println("  caused by : " + cause.toString());
+            }
+            System.exit(2);
+        }
     }
 
     /**

[Clirr-devel] [ clirr-Feature Requests-1710771 ] Clirr missing nested inner classes

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

Feature Requests item #1710771, was opened at 2007-05-01 15:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710771&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clirr missing nested inner classes

Initial Comment:
I thought this was a problem with our build missing the inner classes but I verified that they are in the jar file. Could you please check if Clirr is dealing with doubly nested inner classes properly?

Here is the error message:

Unable to complete checks:Unable to locate enclosing class com.xyz.editor.LogListView$1 for nested class com.xyz.editor.LogListView$1$1

Here is the source code:

LogListView.java
	private synchronized void updateHorizontalScrollbar()
	{
		// This method attempts to update the horizontal scroll bar by looking
		// at
		// the lines in the line cache and adjusting the scrollbar to be wide
		// enough
		// to show the longest one.
		if (mUpdateScrollbarTask != null)
		{
			// if we already have a task, then cancel it
			mUpdateScrollbarTask.cancel();
		}

		// create a new task
		mUpdateScrollbarTask = new TimerTask()
		{

			public void run()
			{
				javax.swing.SwingUtilities.invokeLater(new Runnable()
				{

					public void run()
					{
						// calculate longest line and tell the editor pane to


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

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

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 16:57
Message generated for change (Comment added) made by nascif
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

>Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:25

Message:
Logged In: YES 
user_id=263845
Originator: YES

Here they are. 

java.lang.ClassNotFoundException: antlr.TreeParser not found.
	at
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:88)
	at
net.sf.clirr.core.internal.checks.InterfaceSetCheck.check(InterfaceSetCheck.java:59)
	at net.sf.clirr.core.Checker.runClassChecks(Checker.java:190)
	at net.sf.clirr.core.Checker.reportDiffs(Checker.java:136)
	at net.sf.clirr.cli.Clirr.run(Clirr.java:155)
	at net.sf.clirr.cli.Clirr.main(Clirr.java:56)
Caused by: java.lang.ClassNotFoundException: antlr.TreeParser not found.
	at
org.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:91)
	at org.apache.bcel.classfile.JavaClass.getSuperClass(JavaClass.java:762)
	at
org.apache.bcel.classfile.JavaClass.getAllInterfaces(JavaClass.java:803)
	at
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:86)
	... 5 more
= xyz.framework.workspace.jar
============================================================

clirr: xyz.rpf.jar
Exception in thread "main" java.lang.Error:
java.lang.ClassNotFoundException: com.ibm.security.auth.PrincipalComparator
not found.
	at
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:88)
	at
net.sf.clirr.core.internal.checks.InterfaceSetCheck.check(InterfaceSetCheck.java:59)
	at net.sf.clirr.core.Checker.runClassChecks(Checker.java:190)
	at net.sf.clirr.core.Checker.reportDiffs(Checker.java:136)
	at net.sf.clirr.cli.Clirr.run(Clirr.java:155)
	at net.sf.clirr.cli.Clirr.main(Clirr.java:56)
Caused by: java.lang.ClassNotFoundException:
com.ibm.security.auth.PrincipalComparator not found.
	at
org.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:91)
	at org.apache.bcel.classfile.JavaClass.getInterfaces(JavaClass.java:788)
	at
org.apache.bcel.classfile.JavaClass.getAllInterfaces(JavaClass.java:804)
	at
net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:86)
	... 5 more
= xyz.rpf.jar 


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:24

Message:
Logged In: YES 
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but
I print those out to stdout in a format similar to a regular error, but
using a fake category "FAILURE" instead. I think I agree more with the
Checkstyle approach - it is unfortunately very common to see problems with
wrong classpaths and missing classes creeping from the environment to the
tool execution, and it is not easy to recover if the tool won't handle
those gracefully.

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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 15:20

Message:
Logged In: YES 
user_id=401384
Originator: NO

Oh, and I'd love to see the stack trace that you are getting. Having
RuntimeExceptions propagating all up to the container is likely a bug.

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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:18

Message:
Logged In: YES 
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but
I print those out to stdout in a format similar to a regular error, but
using a fake category "FAILURE" instead. I think I agree more with the
Checkstyle approach - it is unfortunately very common to see problems with
wrong classpaths and missing classes creeping from the environment to the
tool execution, and it is not easy to recover if the tool won't handle
those gracefully.

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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 15:01

Message:
Logged In: YES 
user_id=401384
Originator: NO

Well, the core engine can't do anything useful when jars or classes are
missing, so I think it's OK to bail out with an exception. In Checkstyle
(where I'm also a committer) we report setup problems along with all the
code problems we find, and this causes an endless stream of support
requests. I'd like to avoid that mistake in Clirr.

If you look at the code for the clirr command line frontend in
net.sf.clirr.cli, you'll find that it catches some expected exceptions and
sets the exit code only in the main method. I should add a catch block for
RuntimeException, that is currently missing, and that is why you see stack
traces. Good catch :-)


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 09:10

Message:
Logged In: YES 
user_id=263845
Originator: YES

I am using the command-line - have not tried the others.

By killing the process I mean not handling runtime errors when running
clirr, and calling System.exit. This is not so bad for me now because I am
calling Clirr multiple times, one for each jar, since I want to be able to
group the generated messages. 

But the output to stderr and the stack traces for uncaught exceptions are
problematic. 


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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 07:58

Message:
Logged In: YES 
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean
by "kill the Clirr process"?


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

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

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 16:57
Message generated for change (Comment added) made by nascif
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

>Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:24

Message:
Logged In: YES 
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but
I print those out to stdout in a format similar to a regular error, but
using a fake category "FAILURE" instead. I think I agree more with the
Checkstyle approach - it is unfortunately very common to see problems with
wrong classpaths and missing classes creeping from the environment to the
tool execution, and it is not easy to recover if the tool won't handle
those gracefully.

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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 15:20

Message:
Logged In: YES 
user_id=401384
Originator: NO

Oh, and I'd love to see the stack trace that you are getting. Having
RuntimeExceptions propagating all up to the container is likely a bug.

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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:18

Message:
Logged In: YES 
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but
I print those out to stdout in a format similar to a regular error, but
using a fake category "FAILURE" instead. I think I agree more with the
Checkstyle approach - it is unfortunately very common to see problems with
wrong classpaths and missing classes creeping from the environment to the
tool execution, and it is not easy to recover if the tool won't handle
those gracefully.

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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 15:01

Message:
Logged In: YES 
user_id=401384
Originator: NO

Well, the core engine can't do anything useful when jars or classes are
missing, so I think it's OK to bail out with an exception. In Checkstyle
(where I'm also a committer) we report setup problems along with all the
code problems we find, and this causes an endless stream of support
requests. I'd like to avoid that mistake in Clirr.

If you look at the code for the clirr command line frontend in
net.sf.clirr.cli, you'll find that it catches some expected exceptions and
sets the exit code only in the main method. I should add a catch block for
RuntimeException, that is currently missing, and that is why you see stack
traces. Good catch :-)


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 09:10

Message:
Logged In: YES 
user_id=263845
Originator: YES

I am using the command-line - have not tried the others.

By killing the process I mean not handling runtime errors when running
clirr, and calling System.exit. This is not so bad for me now because I am
calling Clirr multiple times, one for each jar, since I want to be able to
group the generated messages. 

But the output to stderr and the stack traces for uncaught exceptions are
problematic. 


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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 07:58

Message:
Logged In: YES 
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean
by "kill the Clirr process"?


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

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

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 22:57
Message generated for change (Comment added) made by lkuehne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

>Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 21:20

Message:
Logged In: YES 
user_id=401384
Originator: NO

Oh, and I'd love to see the stack trace that you are getting. Having
RuntimeExceptions propagating all up to the container is likely a bug.

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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 21:18

Message:
Logged In: YES 
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but
I print those out to stdout in a format similar to a regular error, but
using a fake category "FAILURE" instead. I think I agree more with the
Checkstyle approach - it is unfortunately very common to see problems with
wrong classpaths and missing classes creeping from the environment to the
tool execution, and it is not easy to recover if the tool won't handle
those gracefully.

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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 21:01

Message:
Logged In: YES 
user_id=401384
Originator: NO

Well, the core engine can't do anything useful when jars or classes are
missing, so I think it's OK to bail out with an exception. In Checkstyle
(where I'm also a committer) we report setup problems along with all the
code problems we find, and this causes an endless stream of support
requests. I'd like to avoid that mistake in Clirr.

If you look at the code for the clirr command line frontend in
net.sf.clirr.cli, you'll find that it catches some expected exceptions and
sets the exit code only in the main method. I should add a catch block for
RuntimeException, that is currently missing, and that is why you see stack
traces. Good catch :-)


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:10

Message:
Logged In: YES 
user_id=263845
Originator: YES

I am using the command-line - have not tried the others.

By killing the process I mean not handling runtime errors when running
clirr, and calling System.exit. This is not so bad for me now because I am
calling Clirr multiple times, one for each jar, since I want to be able to
group the generated messages. 

But the output to stderr and the stack traces for uncaught exceptions are
problematic. 


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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 13:58

Message:
Logged In: YES 
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean
by "kill the Clirr process"?


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

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

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 16:57
Message generated for change (Comment added) made by nascif
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

>Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:18

Message:
Logged In: YES 
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but
I print those out to stdout in a format similar to a regular error, but
using a fake category "FAILURE" instead. I think I agree more with the
Checkstyle approach - it is unfortunately very common to see problems with
wrong classpaths and missing classes creeping from the environment to the
tool execution, and it is not easy to recover if the tool won't handle
those gracefully.

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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 15:01

Message:
Logged In: YES 
user_id=401384
Originator: NO

Well, the core engine can't do anything useful when jars or classes are
missing, so I think it's OK to bail out with an exception. In Checkstyle
(where I'm also a committer) we report setup problems along with all the
code problems we find, and this causes an endless stream of support
requests. I'd like to avoid that mistake in Clirr.

If you look at the code for the clirr command line frontend in
net.sf.clirr.cli, you'll find that it catches some expected exceptions and
sets the exit code only in the main method. I should add a catch block for
RuntimeException, that is currently missing, and that is why you see stack
traces. Good catch :-)


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 09:10

Message:
Logged In: YES 
user_id=263845
Originator: YES

I am using the command-line - have not tried the others.

By killing the process I mean not handling runtime errors when running
clirr, and calling System.exit. This is not so bad for me now because I am
calling Clirr multiple times, one for each jar, since I want to be able to
group the generated messages. 

But the output to stderr and the stack traces for uncaught exceptions are
problematic. 


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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 07:58

Message:
Logged In: YES 
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean
by "kill the Clirr process"?


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

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

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 22:57
Message generated for change (Comment added) made by lkuehne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

>Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 21:01

Message:
Logged In: YES 
user_id=401384
Originator: NO

Well, the core engine can't do anything useful when jars or classes are
missing, so I think it's OK to bail out with an exception. In Checkstyle
(where I'm also a committer) we report setup problems along with all the
code problems we find, and this causes an endless stream of support
requests. I'd like to avoid that mistake in Clirr.

If you look at the code for the clirr command line frontend in
net.sf.clirr.cli, you'll find that it catches some expected exceptions and
sets the exit code only in the main method. I should add a catch block for
RuntimeException, that is currently missing, and that is why you see stack
traces. Good catch :-)


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

Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 15:10

Message:
Logged In: YES 
user_id=263845
Originator: YES

I am using the command-line - have not tried the others.

By killing the process I mean not handling runtime errors when running
clirr, and calling System.exit. This is not so bad for me now because I am
calling Clirr multiple times, one for each jar, since I want to be able to
group the generated messages. 

But the output to stderr and the stack traces for uncaught exceptions are
problematic. 


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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 13:58

Message:
Logged In: YES 
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean
by "kill the Clirr process"?


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

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

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 16:57
Message generated for change (Comment added) made by nascif
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

>Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-05-01 09:10

Message:
Logged In: YES 
user_id=263845
Originator: YES

I am using the command-line - have not tried the others.

By killing the process I mean not handling runtime errors when running
clirr, and calling System.exit. This is not so bad for me now because I am
calling Clirr multiple times, one for each jar, since I want to be able to
group the generated messages. 

But the output to stderr and the stack traces for uncaught exceptions are
problematic. 


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

Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 07:58

Message:
Logged In: YES 
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean
by "kill the Clirr process"?


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

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

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 22:57
Message generated for change (Comment added) made by lkuehne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

>Comment By: Lars Kühne (lkuehne)
Date: 2007-05-01 13:58

Message:
Logged In: YES 
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean
by "kill the Clirr process"?


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

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

[Clirr-devel] [ clirr-Feature Requests-1710276 ] Don't let exceptions kill the build

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

Feature Requests item #1710276, was opened at 2007-04-30 16:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1710276&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't let exceptions kill the build

Initial Comment:
When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports. 

Thanks,
  Nascif



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

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

[Clirr-devel] [ clirr-Feature Requests-1701623 ] Indicate input jar file name in reports

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

Feature Requests item #1701623, was opened at 2007-04-16 11:36
Message generated for change (Comment added) made by nascif
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1701623&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Indicate input jar file name in reports

Initial Comment:
Clirr allows you to specify multiple jar files at once as input, but the output reports (both text and xml) do not differentiate between them. 

In a large code base, the means the consumer of the report might have to do the "detective" work of mapping the packages back to the .jar files that contains them.


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

>Comment By: Nascif Abousalh Neto (nascif)
Date: 2007-04-17 10:36

Message:
Logged In: YES 
user_id=263845
Originator: YES

Hi Lars,

Unfortunately it is not in an open source project. My use case it to add
Clirr to a "repository scanner" that compares the jar files produced by all
the projects in an enterprise against the previous night or week build. In
that case, a large number of .jar files might be provided as input at
once.

But another, more common use case would be any project that creates
multiple jar files as output, that are then aggregated to create a large
application. It would be helpful to be able to identify the source of each
file listed in the Clirr output.


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

Comment By: Lars Kühne (lkuehne)
Date: 2007-04-16 16:55

Message:
Logged In: YES 
user_id=401384
Originator: NO

Nascif, could you provide a use case where this has been a real problem
for you? Was it an open source project I could look at? If not, how many
jars, how many class files, etc? I'm asking to figure out the priority of
this RFE.

Note to implementor: Keep in mind that it's probably not a good idea to
hardcode the notion of a "jar" in the output. I'm thinking about IDE
plugins where the source file would probably be more appropriate, so each
class should have the more general notion of an "origin" instead of a
"jar".

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

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

[Clirr-devel] [ clirr-Feature Requests-1701623 ] Indicate input jar file name in reports

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

Feature Requests item #1701623, was opened at 2007-04-16 17:36
Message generated for change (Comment added) made by lkuehne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1701623&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Indicate input jar file name in reports

Initial Comment:
Clirr allows you to specify multiple jar files at once as input, but the output reports (both text and xml) do not differentiate between them. 

In a large code base, the means the consumer of the report might have to do the "detective" work of mapping the packages back to the .jar files that contains them.


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

>Comment By: Lars Kühne (lkuehne)
Date: 2007-04-16 22:55

Message:
Logged In: YES 
user_id=401384
Originator: NO

Nascif, could you provide a use case where this has been a real problem
for you? Was it an open source project I could look at? If not, how many
jars, how many class files, etc? I'm asking to figure out the priority of
this RFE.

Note to implementor: Keep in mind that it's probably not a good idea to
hardcode the notion of a "jar" in the output. I'm thinking about IDE
plugins where the source file would probably be more appropriate, so each
class should have the more general notion of an "origin" instead of a
"jar".

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

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

[Clirr-devel] [ clirr-Feature Requests-1701623 ] Indicate input jar file name in reports

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

Feature Requests item #1701623, was opened at 2007-04-16 11:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590802&aid=1701623&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Indicate input jar file name in reports

Initial Comment:
Clirr allows you to specify multiple jar files at once as input, but the output reports (both text and xml) do not differentiate between them. 

In a large code base, the means the consumer of the report might have to do the "detective" work of mapping the packages back to the .jar files that contains them.


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

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

[Clirr-devel] CVS: clirr/core/src/java/net/sf/clirr/cli Clirr.java, 1.8, 1.9

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

Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/cli
In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv28526/src/java/net/sf/clirr/cli

Modified Files:
	Clirr.java 
Log Message:
fixed bug 1700298, Classpath parsing was broken with multiple classpath entries in CLI

Index: Clirr.java
===================================================================
RCS file: /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/cli/Clirr.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Clirr.java	16 Mar 2006 22:30:19 -0000	1.8
+++ Clirr.java	15 Apr 2007 05:10:42 -0000	1.9
@@ -239,7 +239,7 @@
         int pos = 0;
         while (pos < path.length())
         {
-            int colonPos = path.indexOf(pos, File.pathSeparatorChar);
+            int colonPos = path.indexOf(File.pathSeparatorChar, pos);
             if (colonPos == -1)
             {
                 files.add(new File(path.substring(pos)));

[Clirr-devel] CVS: clirr/core/xdocs changes.xml,1.16,1.17

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

Update of /cvsroot/clirr/clirr/core/xdocs
In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv28526/xdocs

Modified Files:
	changes.xml 
Log Message:
fixed bug 1700298, Classpath parsing was broken with multiple classpath entries in CLI

Index: changes.xml
===================================================================
RCS file: /cvsroot/clirr/clirr/core/xdocs/changes.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- changes.xml	16 Mar 2006 22:30:19 -0000	1.16
+++ changes.xml	15 Apr 2007 05:10:42 -0000	1.17
@@ -9,6 +9,10 @@
 
     <release version="0.7-dev" date="in CVS">
         <action dev="lkuehne" type="fix">
+            <!-- Bug #1700298-->
+            CLI: Classpath parsing was broken with multiple classpath entries.
+        </action>
+        <action dev="lkuehne" type="fix">
             BCEL was leaking into the Clirr API via our ClassFilter/ClassSelector.
         </action>
         <action dev="lkuehne" type="fix">

[Clirr-devel] [ clirr-Bugs-1700298 ] Error in CLI parsing of classpaths

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

Bugs item #1700298, was opened at 2007-04-13 15:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=590799&aid=1700298&group_id=89627

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Other
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nascif Abousalh Neto (nascif)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in CLI parsing of classpaths

Initial Comment:
In Clirr 0.6, method private File[] pathToFileArray(String path), you have the following call:
  int colonPos = path.indexOf(pos, File.pathSeparatorChar);

The order of the arguments is reversed. From the JavaDoc:
int java.lang.String.indexOf(int ch, int fromIndex)

This is causing the classpath to miss all but the first entry when the CLI is used to invoke Clirr.



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

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

[Clirr-devel] CVS: clirr/xdocs download.xml,1.9,1.10

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

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

Modified Files:
	download.xml 
Log Message:
new sourceforge CVS hostname

Index: download.xml
===================================================================
RCS file: /cvsroot/clirr/clirr/xdocs/download.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- download.xml	10 Sep 2005 12:17:28 -0000	1.9
+++ download.xml	5 Dec 2006 19:26:00 -0000	1.10
@@ -41,8 +41,8 @@
                 for a password for anonymous, simply press the Enter key):
             </p>
 <source><![CDATA[
-cvs -d :pserver:ano...@cv...:/cvsroot/clirr login
-cvs -z3 -d :pserver:ano...@cv...:/cvsroot/clirr checkout clirr
+cvs -d :pserver:ano...@cl...:/cvsroot/clirr login
+cvs -z3 -d :pserver:ano...@cl...:/cvsroot/clirr checkout clirr
 cd clirr
 maven -Dgoal=jar:install multiproject:goal
 maven

[Clirr-devel] CVS: clirr/core project.xml,1.6,1.7

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

Update of /cvsroot/clirr/clirr/core
In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv23986/core

Modified Files:
	project.xml 
Log Message:
new sourceforge CVS hostname

Index: project.xml
===================================================================
RCS file: /cvsroot/clirr/clirr/core/project.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- project.xml	16 Mar 2006 22:30:19 -0000	1.6
+++ project.xml	5 Dec 2006 19:24:10 -0000	1.7
@@ -9,8 +9,8 @@
   <package>net.sf.clirr</package>
 
   <repository>
-    <connection>scm:cvs:pserver:ano...@cv...:/cvsroot/clirr:clirr/core</connection>
-    <url>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/clirr/core</url>
+    <connection>scm:cvs:pserver:ano...@cl...:/cvsroot/clirr:clirr/core</connection>
+    <url>http://clirr.cvs.sourceforge.net/clirr/core</url>
   </repository>
 
   <!-- jar files the project is dependent on -->

[Clirr-devel] CVS: clirr/maven project.xml,1.6,1.7

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

Update of /cvsroot/clirr/clirr/maven
In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv23986/maven

Modified Files:
	project.xml 
Log Message:
new sourceforge CVS hostname

Index: project.xml
===================================================================
RCS file: /cvsroot/clirr/clirr/maven/project.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- project.xml	19 Sep 2005 13:15:27 -0000	1.6
+++ project.xml	5 Dec 2006 19:24:10 -0000	1.7
@@ -15,8 +15,8 @@
   <shortDescription>Maven plugin for Clirr</shortDescription>
   <siteDirectory>/home/groups/c/cl/clirr/htdocs/maven</siteDirectory>
   <repository>
-    <connection>scm:cvs:pserver:ano...@cv...:/cvsroot/clirr/maven:clirr</connection>
-    <url>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/clirr/maven</url>
+    <connection>scm:cvs:pserver:ano...@cl...:/cvsroot/clirr/maven:clirr</connection>
+    <url>http://clirr.cvs.sourceforge.net/clirr/maven</url>
   </repository>
   <dependencies>
     <dependency>

[Clirr-devel] CVS: clirr project.xml,1.30,1.31

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

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

Modified Files:
	project.xml 
Log Message:
new sourceforge CVS hostname

Index: project.xml
===================================================================
RCS file: /cvsroot/clirr/clirr/project.xml,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- project.xml	18 Mar 2006 20:25:52 -0000	1.30
+++ project.xml	5 Dec 2006 19:24:10 -0000	1.31
@@ -51,8 +51,8 @@
        the connection element has the form:
        scm:<system>:<system specific connection string> -->
   <repository>
-    <connection>scm:cvs:pserver:ano...@cv...:/cvsroot/clirr:clirr</connection>
-    <url>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/clirr</url>
+    <connection>scm:cvs:pserver:ano...@cl...:/cvsroot/clirr:clirr</connection>
+    <url>http://clirr.cvs.sourceforge.net/clirr</url>
   </repository>
 
   <versions>

[Clirr-devel] CVS: clirr/core project.properties,1.2,1.3

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

Update of /cvsroot/clirr/clirr/core
In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv12816/core

Modified Files:
	project.properties 
Log Message:
added new repo location for maven 1, see http://blogs.atlassian.com/developer/2006/12/maven_1_repository_changes.html

Index: project.properties
===================================================================
RCS file: /cvsroot/clirr/clirr/core/project.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- project.properties	19 Sep 2005 12:30:35 -0000	1.2
+++ project.properties	5 Dec 2006 18:54:11 -0000	1.3
@@ -1,4 +1,4 @@
-maven.repo.remote=http://www.ibiblio.org/maven,http://maven-plugins.sourceforge.net/maven
+maven.repo.remote=http://mirrors.ibiblio.org/pub/mirrors/maven,http://www.ibiblio.org/maven,http://maven-plugins.sourceforge.net/maven
 
 maven.xdoc.date=left
 maven.xdoc.version=${pom.currentVersion}
@@ -19,6 +19,7 @@
 maven.xdoc.developmentProcessUrl=
 
 maven.junit.fork=true
+maven.test.failure.ignore=true 
 
 # tell tests where testinput is
 maven.junit.sysproperties=testinput

[Clirr-devel] CVS: clirr project.properties,1.9,1.10

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

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

Modified Files:
	project.properties 
Log Message:
added new repo location for maven 1, see http://blogs.atlassian.com/developer/2006/12/maven_1_repository_changes.html

Index: project.properties
===================================================================
RCS file: /cvsroot/clirr/clirr/project.properties,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- project.properties	15 Aug 2004 10:58:07 -0000	1.9
+++ project.properties	5 Dec 2006 18:54:11 -0000	1.10
@@ -1,3 +1,5 @@
+maven.repo.remote=http://mirrors.ibiblio.org/pub/mirrors/maven,http://www.ibiblio.org/maven
+
 maven.xdoc.date=left
 maven.xdoc.version=${pom.currentVersion}
 

Re: [Clirr-devel] project status?

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

Hi Brian,

good to hear a success story from the commercial world, and great that
you even started digging in the code. Contributions to Clirr are really,
really welcome, as all current commiters are quite short of time.

In general, you can contribute your changes in the sourceforge tracker.
Open a ticket in the sourceforge tracker for feature requests and attach
your changes to that ticket. I think this requires a sourceforge
account. If you don't have one you can also simply send your patch to
the devel list, but tracker entries are easier to manage than email.

Please note that I am about to change the license from LGPL to ASL2 (not
sure if that's already partially commited in the trunk), so please make
your contribution available under the ASL2 license.

The project does have a maintainer (me), but unfortunately my spare time
is rather limited lately (small kid, demanding day job, other open
source projects). However I hope to be able to spare some cycles during
the holiday season, so you probably will see some activity in CVS, and
maybe a beta release for the new byte code backend (ASM instead of
BCEL).

Cheers, and thanks in advance for your contribution,
Lars

-----Original Message-----
Date: Wed, 29 Nov 2006 23:10:53 +0100
Subject: [Clirr-devel] project status?
From: "Elliott, Brian"
To: <cli...@li...>

     Hello,
  
 We have started using Clirr at Orbitz with some success.  We are using
a snapshot of the trunk and ended up making a small change that adds
support for class files compiled by rmic.  How do we contribute this
back?  
  
 Also, does this project have any active maintainers?  I don’t think
there’s been any commits for 4 months and was wondering when the next
real version is scheduled for release.
  
 Thanks,
 Brian
  

[Clirr-devel] project status?

[Elliott, B. <BEl...@or...>]

Hello,

=20

We have started using Clirr at Orbitz with some success.  We are using a
snapshot of the trunk and ended up making a small change that adds
support for class files compiled by rmic.  How do we contribute this
back? =20

=20

Also, does this project have any active maintainers?  I don't think
there's been any commits for 4 months and was wondering when the next
real version is scheduled for release.

=20

Thanks,

Brian