Mailing-List: contact dev-help@uima.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@uima.apache.org
Received-SPF: pass (nike.apache.org: domain of msa@schor.com designates
 67.18.66.25 as permitted sender)
Message-ID: <5115810E.3060005@schor.com>
Date: Fri, 08 Feb 2013 17:49:50 -0500
From: Marshall Schor <msa@schor.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: dev@uima.apache.org
Subject: Re: [VOTE] Apache UIMA TextMarker RC4 AND Composite Repository
References: <511277D3.3040408@uni-wuerzburg.de>
 <5114F748.5070903@uni-wuerzburg.de>
In-Reply-To: <5114F748.5070903@uni-wuerzburg.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


On 2/8/2013 8:02 AM, Peter Kl�gl wrote:
> After another round of reviewing:
> - (known issue) additional files LICENSE.txt and NOTICE.txt in
> textmarker-ep-engine-2.0.0\META-INF. However, files LICENSE and NOTICE are OK.

I poked around and saw that this happens when the unpacking of dependent JARs
into target/classes is done.  Some of these Jars have their own MANIFEST
directory, and at least one of them has a LICENSE.txt and NOTICE.txt files (the
org.apache.commons commons-lang3 version 3.1 Jar).

Of course, any of the included JARs could have their own LICENSE and NOTICE
files, and they would "overlay" one another during the unpacking.  This is why I
had earlier suggested finding a way to not do the unpacking.  :-)  I finally
tracked down where we did a change like this in UIMA-2176; if you want (at some
point) to pursue doing something similar, it could provide an example.  The
separate build for OSGi bundles was removed in UIMA-2184.  You can see the build
in the uima-wide parent pom in the profile with id "build OSGi bundle for
annotator".

Dependent jars are put into a /lib/ directory without unpacking them.  Then, an
instruction:

<Bundle-ClassPath> is set up to include those Jars.

This approach lets each Dependent Jar keep its own LICENSE and NOTICE files :-).

I'm unsure how important it is to avoid having the embedded/unpacked JARs have
their LICENSE/NOTICE files potentially overridden. I suppose if all of the
embedded JARs were manually checked to "bubble up" any LICENSEs / NOTICEs, then
it would be OK.   If there were no LICENSEs / NOTICEs in an enbedded JAR, then I
think we would need to get this info from the project itself.  You've probably
done all this already; I'm just coming behind and checking...

-Marshall