You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jacek Laskowski <ja...@laskowski.net.pl> on 2007/09/16 12:27:21 UTC
Maven 2 Remote Resource Plugin is in - we're ready for the release, are we?
Hi,
Just committed the changes for using mrrp to the branch (3.0-beta-1)
and the trunk. The issue of generating and including proper LICENSE
and NOTICE files is considered closed (see OPENEJB-685 Use Maven 2
Remote Resources Plugin to manage LICENSE/NOTICE files).
It's been the main showstopper so unless I made a mistaken with some
licenses or there're some issues that should really be included in the
3.0 release we're ready to go and release the puppy. I'm aware of some
issues that have been reported to be fixed in 3.0, but I think we can
handle it later in 3.0.1 too. No need to wait if the server boots up
properly and let people play with EJBs in a simple manner. Once we
gather feedback from our users we can concentrate on things that are
really important and useful for...our end users not us.
Comments?
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Maven 2 Remote Resource Plugin is in - we're ready for the release, are we?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 9/16/07, Karan Malhi <ka...@gmail.com> wrote:
> Since you mentioned licenses, I noticed that one of the .properties
> file still does not have the ASL 2.0 license in it. I don't know how
> many more of these files are in there.
Ah, you're right. Completely forgot about it. I should be using RAT as
well to make sure all's fine (before having claimed we're ready when
we were not). I remember I saw a couple of files that broke RAT due to
missing the license header. I'll see what I can do to work it out.
Thanks for reporting!
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Maven 2 Remote Resource Plugin is in - we're ready for the release, are we?
Posted by Karan Malhi <ka...@gmail.com>.
Jacek,
Tremendous effort!!
Since you mentioned licenses, I noticed that one of the .properties
file still does not have the ASL 2.0 license in it. I don't know how
many more of these files are in there.
> Hi,
>
> Just committed the changes for using mrrp to the branch (3.0-beta-1)
> and the trunk. The issue of generating and including proper LICENSE
> and NOTICE files is considered closed (see OPENEJB-685 Use Maven 2
> Remote Resources Plugin to manage LICENSE/NOTICE files).
>
> It's been the main showstopper so unless I made a mistaken with some
> licenses or there're some issues that should really be included in the
> 3.0 release we're ready to go and release the puppy. I'm aware of some
> issues that have been reported to be fixed in 3.0, but I think we can
> handle it later in 3.0.1 too. No need to wait if the server boots up
> properly and let people play with EJBs in a simple manner. Once we
> gather feedback from our users we can concentrate on things that are
> really important and useful for...our end users not us.
>
> Comments?
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
--
Karan Singh Malhi
Re: Maven 2 Remote Resource Plugin is in - we're ready for the release, are we?
Posted by David Blevins <db...@visi.com>.
Ok, I've severely trimmed down the dependencies that we have. We're
down to a 12mb footprint for the openejb-3.0-xxx.zip.
I've created a notice file for assembly/openejb-standalone largely
cribbed from the geronimo one with our remaining deps added. Didn't
update the assembly/openejb-tomcat binaries yet, will do that tomorrow.
Give it a look over.
-David
Re: Maven 2 Remote Resource Plugin is in - we're ready for the release, are we?
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 16, 2007, at 3:51 PM, David Blevins wrote:
> So it looks like after removing all the apache stuff, here's what's
> left in our lib/ dir:
Well, you can't ignore the Apache stuff. You have to pay attention to
their NOTICE files.
>
> activation-1.1.jar
> asm-2.2.3.jar
> asm-commons-2.2.3.jar
> asm-tree-2.2.3.jar
> backport-util-concurrent-2.1.jar
> cglib-nodep-2.1_3.jar
> dom4j-1.6.1.jar
> hsqldb-1.8.0.7.jar
> icu4j-2.6.1.jar
> jaxb-api-2.0.jar
> jaxb-impl-2.0.3.jar
> jaxen-1.1.1.jar
> jdom-1.0.jar
> jmdns-1.0-RC2.jar
> jsr173_api-1.0.jar
> mail-1.4.jar
> serp-1.11.0.jar
> spring-2.0.jar
> stax-api-1.0.1.jar
> swizzle-stream-1.0.1.jar
> wstx-asl-3.2.1.jar
> xom-1.0.jar
> xpp3_min-1.1.3.4.O.jar
> xstream-1.2.1.jar
>
> I know for sure we need these:
>
> asm-2.2.3.jar
> asm-commons-2.2.3.jar
> asm-tree-2.2.3.jar
> backport-util-concurrent-2.1.jar
> cglib-nodep-2.1_3.jar
> hsqldb-1.8.0.7.jar
> jaxb-api-2.0.jar
> jaxb-impl-2.0.3.jar
> serp-1.11.0.jar
I don't think we have asm-tree or jaxb-api. Have to check, but would
expect they'll be identical to the existing asm/jaxb notices.
>
> We can get started adding these to the NOTICE file. Geronimo will
> have them all already in it's NOTICE file, except hsqldb, so we can
> grab the text from there.
Heh. I sure hope so... ;-)
--kevan
Re: Maven 2 Remote Resource Plugin is in - we're ready for the release, are we?
Posted by David Blevins <da...@visi.com>.
So it looks like after removing all the apache stuff, here's what's
left in our lib/ dir:
activation-1.1.jar
asm-2.2.3.jar
asm-commons-2.2.3.jar
asm-tree-2.2.3.jar
backport-util-concurrent-2.1.jar
cglib-nodep-2.1_3.jar
dom4j-1.6.1.jar
hsqldb-1.8.0.7.jar
icu4j-2.6.1.jar
jaxb-api-2.0.jar
jaxb-impl-2.0.3.jar
jaxen-1.1.1.jar
jdom-1.0.jar
jmdns-1.0-RC2.jar
jsr173_api-1.0.jar
mail-1.4.jar
serp-1.11.0.jar
spring-2.0.jar
stax-api-1.0.1.jar
swizzle-stream-1.0.1.jar
wstx-asl-3.2.1.jar
xom-1.0.jar
xpp3_min-1.1.3.4.O.jar
xstream-1.2.1.jar
I know for sure we need these:
asm-2.2.3.jar
asm-commons-2.2.3.jar
asm-tree-2.2.3.jar
backport-util-concurrent-2.1.jar
cglib-nodep-2.1_3.jar
hsqldb-1.8.0.7.jar
jaxb-api-2.0.jar
jaxb-impl-2.0.3.jar
serp-1.11.0.jar
We can get started adding these to the NOTICE file. Geronimo will
have them all already in it's NOTICE file, except hsqldb, so we can
grab the text from there.
We need to figure out what's pulling in the rest and see if we can
delete the deps. Don't know if I can get back to this today, but
the technique I usually use to find who is pulling in something is to
delete the jar from my maven repo then build the module (in this case
assembly/openejb-standalone) offline and see what maven spits out.
-David
Re: Maven 2 Remote Resource Plugin is in - we're ready for the release, are we?
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 16, 2007, at 6:27 AM, Jacek Laskowski wrote:
> Hi,
>
> Just committed the changes for using mrrp to the branch (3.0-beta-1)
> and the trunk. The issue of generating and including proper LICENSE
> and NOTICE files is considered closed (see OPENEJB-685 Use Maven 2
> Remote Resources Plugin to manage LICENSE/NOTICE files).
Hi Jacek,
As I told you and David Jencks on IRC, the m-r-r-p (at least as
currently configured) is not generating valid NOTICE files. There
seems to be some mistaken belief that it will automatically generate
valid NOTICE information. That's not the case. It may be that it can
be configured to generate valid NOTICE files. CXF seems to do some
additional configuration. I'll see if I can figure out what they do,
but also have my sunday chores to contend with...
I've also noticed that the artifacts being generated in assemblies do
not properly aggregate LICENSE files. In fact there's no collection/
aggregation of licenses, at all. For example, assembly/openejb-tomcat/
target/openejb-tomcat-3.0-beta-1-bin.zip only contains an ALv2
license file. However, the zip file contains artifacts that are
covered by a number of licenses. Each of these licenses must be
reproduced.
I've obviously not done a very good job of explaining the NOTICE
problem. Hopefully the following will help fix this...
First a few relevant pieces of the Apache License v2.0 (http://
www.apache.org/licenses/LICENSE-2.0.txt).
Definition of Derivative Work:
"Derivative Works" shall mean any work, whether in Source or
Object
form, that is based on (or derived from) the Work and for
which the
editorial revisions, annotations, elaborations, or other
modifications
represent, as a whole, an original work of authorship. For the
purposes
of this License, Derivative Works shall not include works that
remain
separable from, or merely link (or bind by name) to the
interfaces of,
the Work and Derivative Works thereof.
Rules for redistribution:
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
<snip>
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You
distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file
distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative
Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The
contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute,
alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
I think that makes things pretty simple. If you distribute a
derivative work, you must reproduce the relevant attributions from
the original work's NOTICE files. If a project redistributes another
project's jar files, they are creating a derivative work. They must
reproduce the relevant attributions from the NOTICE file. If a
project takes classes from another project's jar files and packages
them in a jar file, then the resultant jar file is a derivative work.
The NOTICE file in the resultant jar file must reproduce the relevant
attributions in its NOTICE file.
Here's a hypothetical example...
Assume that there is a project P. P distributes it's binary output as
P.zip. All artifacts in P.zip are ALv2.
P.zip contains:
LICENSE
NOTICE(P)
lib/a.jar
lib/b.jar
lib/c.jar
a.jar contains
META-INF/LICENSE
META-INF/NOTICE(a)
A.class
b.jar contains
META-INF/LICENSE
META-INF/NOTICE(b)
B.class
Assume that b has a dependency on a. For example, B.class refers to
A.class (e.g. "import B;" and "new B()").
c.jar contains:
META-INF/LICENSE
META-INF/NOTICE(c)
A.class
C.class
c not only has a dependency on a, but also includes artifacts from
a.jar in c.jar.
NOTICE(a) contains:
This is the notice information for a.jar. Per AL2, any derivative
works must reproduce this notice information.
NOTICE(b) would contain:
This is the notice information for b.jar. Per AL2, any derivative
works must reproduce this notice information.
Note: NOTICE(b) does not need to contain any reference or attribution
to project A. "use" of an AL2 library does not require attribution. m-
r-r-p seems to assume that a a reference is required. Perhaps because
it doesn't know if the jar will be "referenced" or if it will be
"included" in the jar.
NOTICE(c) would contain:
This is the notice information for c.jar. Per AL2, any derivative
works must reproduce this notice information.
This is the notice information for a.jar. Per AL2, any derivative
works must reproduce this notice information.
Note: since c.jar "includes" artifacts from a.jar, it *must*
reproduce the relevant NOTICE information from a.jar. It is not
sufficient to merely refer to project a.
NOTICE(P) should contain:
This is the notice information for a.jar. Per AL2, any derivative
works must reproduce this notice information.
This is the notice information for b.jar. Per AL2, any derivative
works must reproduce this notice information.
This is the notice information for c.jar. Per AL2, any derivative
works must reproduce this notice information.
Again: since A.zip contains a, b, and c artifacts. It must reproduce
the NOTICE attributions from these artifacts. Merely referring to
their project is not sufficient.
Currently, the m-r-r-p and the project configurations are generating
something like the following:
NOTICE(a)
This is the notice information for a.jar. Per AL2, any derivative
works must reproduce this notice information.
NOTICE(b)
This is the notice information for b.jar. Per AL2, any derivative
works must reproduce this notice information.
This product includes/uses software, a, developed by
The A Project (http://www.a.org/).
Note that the reference to 'a' is unecessary, IMO, it's also
confusing. You aren't sure if b.jar includes 'a' artifacts or simply
references them.
NOTICE(c)
This is the notice information for c.jar. Per AL2, any derivative
works must reproduce this notice information.
This product includes/uses software, a, developed by
The a Project (http://www.a.org/).
Note that NOTICE(c) does not contain the attribution for 'a'. This is
a violation of ALv2. It's also not clear if c.jar includes or merely
references artifacts from project a.
NOTICE.P
This is the notice information for P. Per AL2, any derivative
works must reproduce this notice information,
unless the notice information does not pertain to the derivative
work.
This product includes software, a, developed by
The A Project (http://www.a.org/).
This product includes software, b, developed by
The B Project (http://www.b.org/).
This product includes software, c, developed by
The C Project (http://www.c.org/).
Note that NOTICE.P does not reproduce the attributions from NOTICE(b)
or NOTICE(c). Yet P.zip is a derivative work. Again, this is a
violation of ALv2.
--kevan