Pre-emptive question on the GPL license issue for dependencies: Since we aren't distributing a WAR, and hence aren't distributing the GPL code, is this a problem for this release?
I think that in the future we will want to distribute a WAR, in which case we clearly must get rid of the GPL dependencies, but since we're not doing it this time around, will this stop the release? Also, sorry I'm not really contributing to this release. I'm in the middle of a month-long go-live at work, so it could be a while until I'm contributing actively again. For now I'll stick with building and testing Dick's releases, watching Hudson, and gardening Jira :-) Thanks, Ethan On Tue, Feb 16, 2010 at 2:56 PM, Richard Hirsch <[email protected]> wrote: > I'll probably start with a "mvn dependency:analyze" to see what I can toss. > I've already found some tests that will have to rewritten. > > I'm hoping that once I get rid of the unneeded dependencies, I can do a "mvn > site" to get the licenses. > > I've got to ask... what is a "version 3 pom"? > > D. > > > > On Tue, Feb 16, 2010 at 8:48 PM, Daniel Kulp <[email protected]> wrote: > >> On Tue February 16 2010 2:39:19 pm Richard Hirsch wrote: >> > Taking this off general ML and back to esme-dev >> > >> > Is there any particular way/location to document what the maven >> > dependencies are and their respective licenses. For example, "specs" ( >> > http://code.google.com/p/specs/) has a MIT License do I add that to our >> > existing MIT-LICENSE.txt >> >> Normally, you could run "mvn site" and the dependency page of the generated >> site would show the licenses that it found in the poms. >> >> However, this doesn't seem to work with ESME as the dependencies pull in >> invalid poms that seem to break it. (more specifically, version 3 poms) >> >> I don't know if you started going through the deps and updating to newer >> versions if that would help or not. >> >> Dan >> >> >> >> > We are going to have to change code based on the removal of GPL-based >> > dependencies. I'll see what the impact is tomorrow when I try and clean >> up >> > our pom.xml >> > >> > All-in-all, Bertrand "-1" is a good thing. I would have loved to have >> > gotten the release through this week but having a clean RC is more >> > important. It will be the basis for all our future releases. >> > >> > D. >> > >> > On Tue, Feb 16, 2010 at 8:12 PM, Richard Hirsch >> <[email protected]>wrote: >> > > Like I said - I'm seeing this first release as a learning experience >> > > (grin, grin) >> > > >> > > On Tue, Feb 16, 2010 at 5:28 PM, Bertrand Delacretaz < >> > > >> > > [email protected]> wrote: >> > >> Hi, >> > >> >> > >> On Mon, Feb 15, 2010 at 4:05 PM, Richard Hirsch < >> [email protected]> >> > >> >> > >> wrote: >> > >> > ...The candidate can be found at: >> > >> > http://people.apache.org/~rhirsch/esme/<http://people.apache.org/%7Erhirsch/esme/> >> <http://people.apache.org/%7Er >> > >> > hirsch/esme/> >> > >> >> > >> Unfortunately I'm -1 on the release, I have a few issues including a >> > >> GPL dependency. >> > >> >> > >> 1) jwebunit dependency is GPL >> > >> The server module depends on >> > >> >> > >> net.sourceforge.jwebunit:jwebunit-htmlunit-plugin:jar:1.4.1:test >> > >> >> > >> which according to http://jwebunit.sourceforge.net/license.html is >> GPL. >> > > >> > > I didn't check any maven dependencies, because they weren't part of >> SVN. >> > > >> > >> 2) The sha1 digest does not match, did I do something wrong? >> > >> >> > >> $ openssl sha1 apache-esme-incubating-1.0-src.tar.gz >> > >> SHA1(apache-esme-incubating-1.0-src.tar.gz)= >> > >> a9ec8d95266d5944d493392a06eb1651c03222f1 >> > >> >> > >> $ cat apache-esme-incubating-1.0-src.tar.gz.sha >> > >> apache-esme-incubating-1.0-src.tar.gz: A53494C8 55474CE3 5AC20516 >> > >> C2448CB6 >> > >> >> > >> 64B3B76C 747BA64A FFC9A836 >> > >> EDAB8D86 4E0735CC AA29ACA9 >> > >> 07767C58 D1C0FEDA CA7E73A3 >> > >> ADA3944D 464314B2 4BE0E476 >> > >> >> > >> I'm assuming I did something wrong. It was my first attempt at >> signing. >> > > >> > > I'll take another shot at it. >> > > >> > >> 3) mvn dependency:analyze of the server module shows lots of unused >> > >> declared dependencies, those should be cleaned up, especially >> > >> openDMK:jdmkrt:jar which according to https://opendmk.dev.java.net/is >> > >> either GPL or CDDL license. Not sure which parts of OpenDMK are which >> > >> license, but as it's unused better remove it. >> > > >> > > OK - I'll take a look at it. >> > > >> > >> 4) When trying to build esme-java-client with "mvn clean install" I >> > >> get "Embedded error: Error while executing the external compiler" if >> > >> JAVA_HOME is not set. >> > > >> > > How can you deal with this via maven? Is this an ESME problem or a >> maven >> > > problem? >> > > >> > >> 5) apache-esme-incubating-1.0-src.tar.gz contains .svn folders, it >> > >> should not have that. You could have created the release using svn >> > >> export of >> > >> >> http://svn.apache.org/repos/asf/incubator/esme/tags/apache-esme-1.0-incu >> > >> bating/ to avoid that. >> > > >> > > OK. Didn't know that. >> > > >> > >> 6) I couldn't find license information for the >> > >> com.twitter:stats:jar:1.3:compile dependency, was that checked to be >> > >> ok? >> > > >> > > Don't know - I'll have to check. This was from our JMX interface . >> > > >> > >> Sorry that I didn't have time to look at that during the ESME podling >> > >> vote. >> > >> >> > >> Apart from the GPL dependency the release preparation looks mostly ok, >> > >> rat reports are good, license/notice are provided, etc. >> > >> >> > >> -Bertrand >> >> -- >> Daniel Kulp >> [email protected] >> http://www.dankulp.com/blog >> >
