Daniel Kulp wrote:
+1 to maven as well.. :-)
There is also the jbossall-client.jar in the source tree. I believe that
is LGPL or part LGPL, also not allowed as part of a distribution at
apache.
I understand that we may have these licenses in the tool chain or test
suite, but they
On 07/11/06, Daniel Kulp [EMAIL PROTECTED] wrote:
+1 to maven as well.. :-)
There is also the jbossall-client.jar in the source tree. I believe that
is LGPL or part LGPL, also not allowed as part of a distribution at
apache.
I've been chatting with the Maven folks today about the
Hi All,
I just wanted to highlight a couple of points about M1, and my view of why
we're doing it now.
The key motivator for M1 is that we have users out there who have deployed
onto Qpid (Java). For that reason alone, we need to get an M1 of the java
broker/client out to support them going
On 06/11/06, Steve Vinoski [EMAIL PROTECTED] wrote:
+1 to maven, which I've been working on for awhile. So far in doing
the maven work I've been surprised by both 1) the number of
dependencies, which is much higher than I expected, and 2) the
dependencies which aren't really legal. The JMS jar
I've included the full text of the license with the jms.jar and the
slf4j, backport and junit. The Saxon website says there code is open
source but not what license. I found an RPM of saxon that claimed to
be MPL, so we could include that. The rest of the libs are all apache.
Do we really need a
Getting license details correct is critical.
It may be that we have to ship a build without these files and provide the
end user with an ANT or Maven task that fetches them.
That way it is the user doing the getting and complying with the license
concerned and its not our issue.
Does ActiveMQ
The sun fscontext is fine to include from Sun's point of view:
Sun grants you a non-exclusive,
non-transferable, limited license to reproduce and
distribute the Software in binary form only,
provided that you (i) distribute the Software
complete and unmodified and only bundled
On Tuesday November 07 2006 3:58 am, Robert Greig wrote:
On 06/11/06, Steve Vinoski [EMAIL PROTECTED] wrote:
+1 to maven, which I've been working on for awhile. So far in doing
the maven work I've been surprised by both 1) the number of
dependencies, which is much higher than I expected,
Martin,
We can only include ASF compatible licenses (and thats decided by Apache
Legal).
I am sure the sun license are not covered.
If you are not sure, you can talk to Cliff as he handles legal stuff.
If we submit with this one we are going to have a time with the incubator
PMC.
I suggest we
We can confirm from Cliff, but AFIK we need to include license.txt for all
jars.
I guess Dan just mentioned that on the list.
-Rajith
On 11/7/06, Martin Ritchie [EMAIL PROTECTED] wrote:
I've included the full text of the license with the jms.jar and the
slf4j, backport and junit. The Saxon
We don't need to hand write code.
The Geronimo spec project allready has done that.
We can use the following release by them
dependency
groupIdgeronimo-spec/groupId
artifactIdgeronimo-spec-jms/artifactId
version1.1-rc4/version
scopecompile/scope
+1 to maven, which I've been working on for awhile. So far in doing
the maven work I've been surprised by both 1) the number of
dependencies, which is much higher than I expected, and 2) the
dependencies which aren't really legal. The JMS jar is one. Another
is the Sun fscontext stuff,
12 matches
Mail list logo
