Preparing the Pluto Release

[cziegeler]

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
cziegeler@...

[Ate Douma]

Carsten Ziegeler wrote:

> 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".

Yes, I think I can get it to work with a custom assembly.
I'm on route to office right now and will be there shortly.
If you can give me an hour or so, I can try it out and commit a solution.

Ate


>
> Regards
> Carsten

[cziegeler]

Ate Douma wrote
> Yes, I think I can get it to work with a custom assembly.
> I'm on route to office right now and will be there shortly.
> If you can give me an hour or so, I can try it out and commit a solution.
Great, thanks Ate!

Carsten

--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

Carsten Ziegeler wrote:
> Ate Douma wrote
>> Yes, I think I can get it to work with a custom assembly.
>> I'm on route to office right now and will be there shortly.
>> If you can give me an hour or so, I can try it out and commit a solution.
Done!

It took a little more time and some dirty "hacking" than I expected because the assembly-plugin always merges multiple descriptor
configurations. So, adding just our custom assembly still also produced the -project archives as you already found out.

I "fixed" this by configuring a *non-existing* predefined assembly instead which *does* override the "project" configuration.
To make this build however we also need to configure ignoreMissingDescriptor=true.
All this really is a dirty hack of course.
We will have to update the portals-pom to either not configure any predefined assembly and/or wait for the next assembly-plugin release
which hopefully will fix these deficiencies.

Anyway, I ran mvn release:prepare -DdryRun and all went fine, so AFAIK Pluto now finally is ready for release.

GO :)

Regards,

Ate

> Great, thanks Ate!
>
> Carsten
>

[cziegeler]

Ate Douma wrote:

> Carsten Ziegeler wrote:
>> Ate Douma wrote
>>> Yes, I think I can get it to work with a custom assembly.
>>> I'm on route to office right now and will be there shortly.
>>> If you can give me an hour or so, I can try it out and commit a
>>> solution.
> Done!
>
> It took a little more time and some dirty "hacking" than I expected
> because the assembly-plugin always merges multiple descriptor
> configurations. So, adding just our custom assembly still also produced
> the -project archives as you already found out.
>
> I "fixed" this by configuring a *non-existing* predefined assembly
> instead which *does* override the "project" configuration.
> To make this build however we also need to configure
> ignoreMissingDescriptor=true.
> All this really is a dirty hack of course.

Great :) I just tested it on my machine and it works here (of course) as
well. Many thanks Ate!

> We will have to update the portals-pom to either not configure any
> predefined assembly and/or wait for the next assembly-plugin release
> which hopefully will fix these deficiencies.
Yepp, one or the other. You could remove it from our parent pom and do a
new release so you're not affected for the Jetspeed release.

> Anyway, I ran mvn release:prepare -DdryRun and all went fine, so AFAIK
> Pluto now finally is ready for release.
>
> GO :)
Yuppie!! :)

Thanks again, Ate!

I'll not try my luck with Nexus...

Regards
Carsten
--
Carsten Ziegeler
cziegeler@...