maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: Findbugs plugin and LGPL Licensing?
Date Wed, 03 Sep 2003 09:01:27 GMT
Ben,

Can you review the changes I made to the maven-plugins version?  I tried to
incorporate the best of yours.  I also filed an upload request for the
custom bcel, called findbugs-bcel-0.6.5.jar.  It IS a custom version, and
the developers aren't sure when CVS head of BCEL will release.  However,
they will let me know when the bcel catches up.  Also an upload request for
the coreplugin to be versioned as well.

Dom4j-1.4 is fine however.

So, according to Brian, does that mean that we are agreed that the findbugs
plugin needs to live at maven-plugins?  If you are happy with the changes I
made to reflect the best of both, then let's nuke the version in maven cvs.

Also, what we need is some sort of plugin installer similar to how eclipse
or jedit work to pull in plugins from every repo, maybe tied to a master
list of possible repos...  Dreaming outloud...

Eric

> -----Original Message-----
> From: Ben Walding [mailto:ben@walding.com]
> Sent: Wednesday, September 03, 2003 2:01 AM
> To: Maven Developers List
> Subject: Re: Findbugs plugin and LGPL Licensing?
>
>
> Yeah I wasn't happy with how that was done, but the ant task
> makes life
> moderately difficult (and I only saw that you could avoid requiring a
> home dir just now).  You might want to check that the home
> arg needs to
> be set, because my reading of the ant task says that it
> shouldn't be -
> it stops the classpath you pass in from being used.
>
> 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 license@apache...
>
>
> 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:ben@walding.com]
> >>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: bwalding@apache.org [mailto:bwalding@apache.org]
> >>>>Sent: Saturday, August 30, 2003 1:15 AM
> >>>>To: maven-cvs@apache.org
> >>>>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: dev-unsubscribe@maven.apache.org
> >>>>For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>-----------------------------------------------------------
> ----------
> >>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message