Carsten Ziegeler wrote:
Hi Ate,
Ate Douma wrote:
I've took a brief look at both the license and legal files and the
resulting distribution and have a few comments.
THanks for reviewing!
Maybe I'm wrong, but I think the NOTICE file(s) for particulary the wars
and the binary distribution are supposed to "notice" all third party
usages which require a license/copyright notice in the corresponding
NOTICE file.
I see you added the redistribution license files for JAXB and SLF4J, but
see no notice remark fore these, nor for some other (even while being
ASL 2.0 licensed) third party redistributed products (jars) like
Springframework etc.
See for instance the NOTICE file "embedded" within the Tomcat based
distribution which provides some notices, but those only cover the
Tomcat provided redistribution of third party products, none of the
Pluto added ones.
I don't want to be nitpicking here and definitely am not an expert on
these ASF legal requirements, so if you think the current configuration
is/should be good enough, lets not make it more complicated then it
already is :)
I think the way it is right now is correct :) But I'll recheck the
licenses. An entry in the notice file should only be made if the
included license really requires this. If including the license is
enough, no entry should be made in the notice file. At least this was
the outcome of a very long license/notifce file checking session with
Roy and others in Sling last year.
Right.
If that's true, it would have been nice to have known this when Vivek and I
were preparing for the APA release.
Dealing with those NOTICE files took a *lot* of time...
Well, for the upcoming Jetspeed release it is a relief to know this now :)
It is unclear to me how you plan to provide the required formal ASF
source distribution: manually (e.g. by simply archiving the full source
tree), or plan to use the "maven" way, using the portals-pom configured
maven-assembly-plugin with the "project" descriptor like what we did for
the portlet-spec and APA releases?
In the latter case, you will still need to add a "apache-release"
profile to the root pom like the following:
<profiles>
<profile>
<id>apache-release</id>
<build>
<plugins>
<plugin>
<!-- only include this in top level project poms -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Ah, yes, you're right, this change sits on my machine but I never
committed it :)
and commit that first before you can run the maven release:prepare.
Additionally, if you want to (try) the above, be aware of some current
"caveats" of this procedure and the current maven-assembly-plugin for
which I already created issue http://jira.codehaus.org/browse/MASSEMBLY-409
Those "caveats" are not all that critical really (and we've decided to
accept them while doing the the portlet-spec and APA releases).
But take note specifically of the fact that the resulting assembled
source distro(s) will have a "-project" postfix (classifier), e.g. end
up to be like pluto-2.0.0-project.zip, not what you might expect (or
want) pluto-2.0.0-src.zip
This is also under discussion on the Maven dev list for the next
revision of the assembly-plugin, see:
http://www.nabble.com/Update-on-ASF-Release-requirements-td23379350.html
Personally, I don't very much like the -project postfix as end users
might be looking for the typical -src postfix instead.
For that reason, and because a new version of the maven-assembly-plugin
won't be available in time for us, I'm considering if we should use our
own custom "project" assembly configuration in Jetspeed (and can also be
done for Pluto) to work around the MASSEMBLY-409 issues for our upcoming
release (only).
Such a custom assembly configuration would be pretty easy and quick to
setup and I can provide that for Pluto if you want on short notice.
With hindsight, I think we might better have done that too for the
portlet-spec and APA releases, but well, we needed those releases be
done then.
Ok, I'll create an own assembly then. I agree that "-src" is the better
suffix. Thanks for reminding!
Cool.
Ate
Regards
Carsten
