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. > 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! Regards Carsten -- Carsten Ziegeler [email protected]
