I'd also prefer that we used tagged version of dom4j / bcel rather than the mystical versions that are distributed with findbugs - to try and minimise downloads where possible. Unfortunately, I haven't had any response as to the correct versions, and the latest versions don't work properly together.
I await the response from [EMAIL PROTECTED]
Cheers,
Ben
Eric Pugh wrote:
Ben,
I looked at your version, and mine I think is better on the referencing of findbugs jars, while yours actually generates a report!
Can someone verify that even though there are no import statements, the usage of the lgpl jar prevents it from being ASF compatible. This is related to that LGPL is Viral? thread on slashdot a while ago. I believe that all of the plugins on maven-plugins only really exist there because they use LGPL jars.
Could someone else maybe speak up on this? Dion in an email on Aug 7th specified that it couldn't go in.. I guess we need to make a decision and decide which way to go!
Eric
-----Original Message----- From: Ben Walding [mailto:[EMAIL PROTECTED] Sent: Sunday, August 31, 2003 11:31 PM To: Maven Developers List Subject: Re: cvs commit: maven/src/plugins-build/findbugs plugin.jelly
I missed discussion of the previous version unfortunately. And it isn't listed on the main page at the maven-plugins.sf.net site - only in CVS.
Usually the major sticking point for our use of LGPL is if we have to import code (i.e. import com.* statements). Since neither of the findbugs plugins do this, I'd wager that it being lgpl isn't an issue. If it is, then we're going to have to take yet another look at plugins - checkstyle is LGPL and it is an included plugin.
Once external plugin handling is simplified, it won't be an issue, but for now - core plugins have far more exposure than anything else.
I agree there should only be 1 findbugs plugin. I don't really care which one dies / is folded into the other.
Cheers,
Ben
Eric Pugh wrote:
Ben,
I suggested a while back a findbugs plugin I had written,
and was told that
because of the lgpl licensing issues, it needed to go
elsewhere. So it is
currently living at maven-plugins.sf.net. I have talked to
the developers,
and they are evaluating switching to an ASF friendly license
that would
allow findbugs to be run in the core.
Now, while some people may think that if 1 findbugs plugin
is good, then 2
must be better, I take the approach that we should merge the
best idea's out
of both of our efforts!
Do you want to review what I did and figure out how to take
the best of
both? Also, if the lgpl think isn't an issue, I would
prefer to have the
plugin be part of maven core to increase usage.
Eric Pugh
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, August 30, 2003 1:15 AM To: [EMAIL PROTECTED] Subject: cvs commit: maven/src/plugins-build/findbugs plugin.jelly
bwalding 2003/08/29 16:15:15
Modified: src/plugins-build/findbugs plugin.jelly Log: Was using incorrect sourcepath variable
Revision Changes Path 1.2 +4 -4 maven/src/plugins-build/findbugs/plugin.jelly
Index: plugin.jelly
===================================================================
RCS file:
/home/cvs/maven/src/plugins-build/findbugs/plugin.jelly,v
retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- plugin.jelly 29 Aug 2003 01:55:48 -0000 1.1 +++ plugin.jelly 29 Aug 2003 23:15:15 -0000 1.2 @@ -21,10 +21,10 @@
<findbugs home="${maven.build.dir}/findbugshome" output="text" - debug="false"><!-- - outputFile="${maven.build.dir}/findbugs.xml"--> - <sourcePath path="${maven.compile.src.set}" /> - <class location="${maven.build.dest}" /> + debug="false" + outputFile="${maven.build.dir}/findbugs.xml"> + <sourcePath path="${pom.build.sourceDirectory}"/> + <class location="${maven.build.dest}"/>
<j:forEach var="lib" items="${pom.artifacts}"> <auxClasspath path="${maven.repo.local}/${lib.urlPath}"/>
------------------------------------------------------------
---------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
