Ate Douma schrieb: > Carsten Ziegeler wrote: >> With the great help from Ate, I think we're really ready for a release >> now. It would be great if someone could also have a look at the current >> trunk and check if we might have forgotten/overseen something, >> especially the license stuff for the war file and the tomcat >> distribution. >> >> You can build the distribution with "ant -f dist-build.xml". > Hi Carsten, > > I've took a brief look at both the license and legal files and the > resulting distribution and have a few comments. > > 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 :) > > 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> > > 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. I can't get the custom assembly to work. It seems that it's still trying to build the -project (inherited from the parent pom?) in addition to the custom.
If you know how do it we can use our custom one, if not, I think we should just go with the "-project". Regards Carsten -- Carsten Ziegeler [email protected]
