Preparing the Pluto Release

[cziegeler]

Hi,

I've cleaned up current trunk in order to make the release (hopefully)
easier. But unfortunately I ran into problems (see below).

The idea is to release the separate modules as maven artifacts (in
binary form with attached source, javadocs artifacts), a big source
release of the whole pluto trunk and for convenience a binary version of
Pluto containing Tomcat.

While the first two seem to work now (I also ran the RAT profile), the
last one is giving me some problems as I don't understand at all how
this is supposed to work :)
There is the ant file doing all the magic, the ant file itself starts
maven to build the whole project. It also uses the maven pluto plugin to
install the war files (portal and testsuite) but for some reason the
testsuite war file doesn't get rewritten. Unfortunately does neither the
util code nor the plugin itself have any log output. I think as soon as
we have fixed this rewriting, we are ready for release.

Does anyone have a good clue? (I'll need to do a break for some hours,
if not I guess I have to debug the maven plugin).

Regards
Carsten
--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

Carsten Ziegeler wrote:

> Hi,
>
> I've cleaned up current trunk in order to make the release (hopefully)
> easier. But unfortunately I ran into problems (see below).
>
> The idea is to release the separate modules as maven artifacts (in
> binary form with attached source, javadocs artifacts), a big source
> release of the whole pluto trunk and for convenience a binary version of
> Pluto containing Tomcat.
>
> While the first two seem to work now (I also ran the RAT profile), the
> last one is giving me some problems as I don't understand at all how
> this is supposed to work :)
> There is the ant file doing all the magic, the ant file itself starts
> maven to build the whole project. It also uses the maven pluto plugin to
> install the war files (portal and testsuite) but for some reason the
> testsuite war file doesn't get rewritten. Unfortunately does neither the
> util code nor the plugin itself have any log output. I think as soon as
> we have fixed this rewriting, we are ready for release.
>
> Does anyone have a good clue? (I'll need to do a break for some hours,
> if not I guess I have to debug the maven plugin).

Hi Carsten,

No, I don't have a good clue yet.
But I can try to look at it too.
Can you post the exact command(s) you're running so I can replay myself?

Regards,

Ate

>
> Regards
> Carsten

[cziegeler]

Ate Douma wrote:

> Carsten Ziegeler wrote:
>> Hi,
>>
>> I've cleaned up current trunk in order to make the release (hopefully)
>> easier. But unfortunately I ran into problems (see below).
>>
>> The idea is to release the separate modules as maven artifacts (in
>> binary form with attached source, javadocs artifacts), a big source
>> release of the whole pluto trunk and for convenience a binary version of
>> Pluto containing Tomcat.
>>
>> While the first two seem to work now (I also ran the RAT profile), the
>> last one is giving me some problems as I don't understand at all how
>> this is supposed to work :)
>> There is the ant file doing all the magic, the ant file itself starts
>> maven to build the whole project. It also uses the maven pluto plugin to
>> install the war files (portal and testsuite) but for some reason the
>> testsuite war file doesn't get rewritten. Unfortunately does neither the
>> util code nor the plugin itself have any log output. I think as soon as
>> we have fixed this rewriting, we are ready for release.
>>
>> Does anyone have a good clue? (I'll need to do a break for some hours,
>> if not I guess I have to debug the maven plugin).
> Hi Carsten,
>
> No, I don't have a good clue yet.
> But I can try to look at it too.
> Can you post the exact command(s) you're running so I can replay myself?
>

Hi Ate,

great, I'm just doing an
"ant -f dist-build.xml" in the root dir; this downloads tomcat, builds
everything and creates a dist under target/dist.
The dist itself looks good, apart from the fact that testsuite is not
rewritten for pluto.
So I invoked the pluto maven plugin directly in the testsuite module:
mvn org.apache.portals.pluto:maven-pluto-plugin:2.0.0-SNAPSHOT:install
-DinstallDir={PATH to the /target/dist/apache-tomcat-6.0.18 dir}

This copies over the webapp to the tomcat dir (/PlutoDomain sub dir),
but the resulting war is not rewritten.

Regards
Carsten
--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

Hi Carsten,

Build should be working again I think. I just committed some testsuite/pom.xml fixes restoring maven-war-plugin and maven-plugin-plugin
configurations which were lost somehow.

In addition, I've added a maven-remote-resources-plugin fix to correct where the legal files are put. With that fix the override of the
ianal-maven-plugin isn't needed anymore.
I haven't had time to review the other changes to the build yet (will do so shortly), possibly the above might also apply there.

Ate

Carsten Ziegeler wrote:

> Ate Douma wrote:
>> Carsten Ziegeler wrote:
>>> Hi,
>>>
>>> I've cleaned up current trunk in order to make the release (hopefully)
>>> easier. But unfortunately I ran into problems (see below).
>>>
>>> The idea is to release the separate modules as maven artifacts (in
>>> binary form with attached source, javadocs artifacts), a big source
>>> release of the whole pluto trunk and for convenience a binary version of
>>> Pluto containing Tomcat.
>>>
>>> While the first two seem to work now (I also ran the RAT profile), the
>>> last one is giving me some problems as I don't understand at all how
>>> this is supposed to work :)
>>> There is the ant file doing all the magic, the ant file itself starts
>>> maven to build the whole project. It also uses the maven pluto plugin to
>>> install the war files (portal and testsuite) but for some reason the
>>> testsuite war file doesn't get rewritten. Unfortunately does neither the
>>> util code nor the plugin itself have any log output. I think as soon as
>>> we have fixed this rewriting, we are ready for release.
>>>
>>> Does anyone have a good clue? (I'll need to do a break for some hours,
>>> if not I guess I have to debug the maven plugin).
>> Hi Carsten,
>>
>> No, I don't have a good clue yet.
>> But I can try to look at it too.
>> Can you post the exact command(s) you're running so I can replay myself?
>>
> Hi Ate,
>
> great, I'm just doing an
> "ant -f dist-build.xml" in the root dir; this downloads tomcat, builds
> everything and creates a dist under target/dist.
> The dist itself looks good, apart from the fact that testsuite is not
> rewritten for pluto.
> So I invoked the pluto maven plugin directly in the testsuite module:
> mvn org.apache.portals.pluto:maven-pluto-plugin:2.0.0-SNAPSHOT:install
> -DinstallDir={PATH to the /target/dist/apache-tomcat-6.0.18 dir}
>
> This copies over the webapp to the tomcat dir (/PlutoDomain sub dir),
> but the resulting war is not rewritten.
>
> Regards
> Carsten

[cziegeler]

Ate Douma wrote:
> Hi Carsten,
>
> Build should be working again I think. I just committed some
> testsuite/pom.xml fixes restoring maven-war-plugin and
> maven-plugin-plugin configurations which were lost somehow.
Ah, I guess I accidentally removed them while trying to clean up all the
poms. Thanks!!

> In addition, I've added a maven-remote-resources-plugin fix to correct
> where the legal files are put. With that fix the override of the
> ianal-maven-plugin isn't needed anymore.
Ok, I have no preference if we have to reconfigure the remote resources
plugin or the ianal plugin.

> I haven't had time to review the other changes to the build yet (will do
> so shortly), possibly the above might also apply there.
I think the portal webapp needs the same config then; I can take care of
that.

I'm now trying the dist build.


Many thanks, Ate

Carsten
--
Carsten Ziegeler
cziegeler@...

[cziegeler]

I now get the same NPE in every portlet from the testsuite:

java.lang.NullPointerException
        at org.apache.pluto.testsuite.TestPortlet.getTestId(TestPortlet.java:340)
        at org.apache.pluto.testsuite.TestPortlet.doHeaders(TestPortlet.java:135)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:248)


Looking at the code, the only reason for this could be that the "tests"
instance variable is null. But this can only happen if the init() method
has never been called. I did a quick test and initialized the variable
directly in the definition and the NPE disappears, but of course the
portlet is not working.

Carsten
--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

Carsten Ziegeler wrote:
> I now get the same NPE in every portlet from the testsuite:
>
> java.lang.NullPointerException
> at org.apache.pluto.testsuite.TestPortlet.getTestId(TestPortlet.java:340)
> at org.apache.pluto.testsuite.TestPortlet.doHeaders(TestPortlet.java:135)
> at javax.portlet.GenericPortlet.render(GenericPortlet.java:248)
>
Weird, after my commit I even ran the JSR-286 TCK and all passed.

>
> Looking at the code, the only reason for this could be that the "tests"
> instance variable is null. But this can only happen if the init() method
> has never been called. I did a quick test and initialized the variable
> directly in the definition and the NPE disappears, but of course the
> portlet is not working.
Maybe make sure to do a clean install first and I'll update to your latest changes here and try again too.

Ate

>
> Carsten

[Ate Douma]

Ate Douma wrote:

> Carsten Ziegeler wrote:
>> I now get the same NPE in every portlet from the testsuite:
>>
>> java.lang.NullPointerException
>>     at
>> org.apache.pluto.testsuite.TestPortlet.getTestId(TestPortlet.java:340)
>>     at
>> org.apache.pluto.testsuite.TestPortlet.doHeaders(TestPortlet.java:135)
>>     at javax.portlet.GenericPortlet.render(GenericPortlet.java:248)
>>
> Weird, after my commit I even ran the JSR-286 TCK and all passed.
>
>>
>> Looking at the code, the only reason for this could be that the "tests"
>> instance variable is null. But this can only happen if the init() method
>> has never been called. I did a quick test and initialized the variable
>> directly in the definition and the NPE disappears, but of course the
>> portlet is not working.
> Maybe make sure to do a clean install first and I'll update to your
> latest changes here and try again too.

Just done that and cannot reproduce your error.
My guess is you need a mvn clean install first.

>
> Ate
>
>>
>> Carsten
>
>

[cziegeler]

Ate Douma wrote:
>> Maybe make sure to do a clean install first and I'll update to your
>> latest changes here and try again too.
> Just done that and cannot reproduce your error.
> My guess is you need a mvn clean install first.
No, I tried this before, and the ant script is doing this also. Still
the same problem.
Are you testing the generated tomcat installation from the ant script or
something different?

Regards
Carsten
--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

Carsten Ziegeler wrote:
> Ate Douma wrote:
>>> Maybe make sure to do a clean install first and I'll update to your
>>> latest changes here and try again too.
>> Just done that and cannot reproduce your error.
>> My guess is you need a mvn clean install first.
> No, I tried this before, and the ant script is doing this also. Still
> the same problem.
> Are you testing the generated tomcat installation from the ant script or
> something different?
Oh, no. I just tested using against my local Tomcat installation using:

   mvn pluto2:install -DinstallDir=<my Tomcat dir>

There must be something wrong in the ant script then.
I can help looking into that in a few minutes.

NB: I haven't reviewed the ant based assembly yet, but if its not complex, maybe it might be easier replacing it with a
maven-assembly-plugin based one? That would even allow "attaching" it to the build and get it "released" with the project together, similar
to the source release distros.

Ate

>
> Regards
> Carsten

[cziegeler]

Just did another try with a clean maven repo, but still I get the same
error.

Carsten


Carsten Ziegeler wrote:

> Ate Douma wrote:
>>> Maybe make sure to do a clean install first and I'll update to your
>>> latest changes here and try again too.
>> Just done that and cannot reproduce your error.
>> My guess is you need a mvn clean install first.
> No, I tried this before, and the ant script is doing this also. Still
> the same problem.
> Are you testing the generated tomcat installation from the ant script or
> something different?
>
> Regards
> Carsten

--
Carsten Ziegeler
cziegeler@...

[cziegeler]

Ate Douma wrote:

> Carsten Ziegeler wrote:
>> Ate Douma wrote:
>>>> Maybe make sure to do a clean install first and I'll update to your
>>>> latest changes here and try again too.
>>> Just done that and cannot reproduce your error.
>>> My guess is you need a mvn clean install first.
>> No, I tried this before, and the ant script is doing this also. Still
>> the same problem.
>> Are you testing the generated tomcat installation from the ant script or
>> something different?
> Oh, no. I just tested using against my local Tomcat installation using:

which version of Tomcat are you using?

>
>   mvn pluto2:install -DinstallDir=<my Tomcat dir>
>
> There must be something wrong in the ant script then.
> I can help looking into that in a few minutes.
>
> NB: I haven't reviewed the ant based assembly yet, but if its not
> complex, maybe it might be easier replacing it with a
> maven-assembly-plugin based one? That would even allow "attaching" it to
> the build and get it "released" with the project together, similar to
> the source release distros.

Yes, that would be great; atm I have to clue how to do this with maven,
therefore I would go with the ant script for now. ( we just have to move
it to another place so that it gets included in the source maven
artifact, but that should be easy).

Carsten
--
Carsten Ziegeler
cziegeler@...

[cziegeler]

Carsten Ziegeler wrote:

> Ate Douma wrote:
>> Carsten Ziegeler wrote:
>>> Ate Douma wrote:
>>>>> Maybe make sure to do a clean install first and I'll update to your
>>>>> latest changes here and try again too.
>>>> Just done that and cannot reproduce your error.
>>>> My guess is you need a mvn clean install first.
>>> No, I tried this before, and the ant script is doing this also. Still
>>> the same problem.
>>> Are you testing the generated tomcat installation from the ant script or
>>> something different?
>> Oh, no. I just tested using against my local Tomcat installation using:
> which version of Tomcat are you using?

Ok, I just deployed to a local Tomcat 5.5 - and then it works for me as
well. Our dist build uses a Tomcat 6..maybe that's the problem?

Regards
Carsten

>
>>   mvn pluto2:install -DinstallDir=<my Tomcat dir>
>>
>> There must be something wrong in the ant script then.
>> I can help looking into that in a few minutes.
>>
>> NB: I haven't reviewed the ant based assembly yet, but if its not
>> complex, maybe it might be easier replacing it with a
>> maven-assembly-plugin based one? That would even allow "attaching" it to
>> the build and get it "released" with the project together, similar to
>> the source release distros.
> Yes, that would be great; atm I have to clue how to do this with maven,
> therefore I would go with the ant script for now. ( we just have to move
> it to another place so that it gets included in the source maven
> artifact, but that should be easy).
>
> Carsten

--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

Carsten Ziegeler wrote:

> Carsten Ziegeler wrote:
>> Ate Douma wrote:
>>> Carsten Ziegeler wrote:
>>>> Ate Douma wrote:
>>>>>> Maybe make sure to do a clean install first and I'll update to your
>>>>>> latest changes here and try again too.
>>>>> Just done that and cannot reproduce your error.
>>>>> My guess is you need a mvn clean install first.
>>>> No, I tried this before, and the ant script is doing this also. Still
>>>> the same problem.
>>>> Are you testing the generated tomcat installation from the ant script or
>>>> something different?
>>> Oh, no. I just tested using against my local Tomcat installation using:
>> which version of Tomcat are you using?
> Ok, I just deployed to a local Tomcat 5.5 - and then it works for me as
> well. Our dist build uses a Tomcat 6..maybe that's the problem?

Could be.
For Jetspeed we are now using Tomcat 6 by default without problems.
I see you just downgraded the Tomcat version back to 5.5.27 which is OK by me too.
I'll briefly try to see what might be different with Tomcat 6.

>
> Regards
> Carsten
>>>   mvn pluto2:install -DinstallDir=<my Tomcat dir>
>>>
>>> There must be something wrong in the ant script then.
>>> I can help looking into that in a few minutes.
>>>
>>> NB: I haven't reviewed the ant based assembly yet, but if its not
>>> complex, maybe it might be easier replacing it with a
>>> maven-assembly-plugin based one? That would even allow "attaching" it to
>>> the build and get it "released" with the project together, similar to
>>> the source release distros.
>> Yes, that would be great; atm I have to clue how to do this with maven,
>> therefore I would go with the ant script for now. ( we just have to move
>> it to another place so that it gets included in the source maven
>> artifact, but that should be easy).
>>
>> Carsten
>
>

[Ate Douma]

Ate Douma wrote:

> Carsten Ziegeler wrote:
>> Carsten Ziegeler wrote:
>>> Ate Douma wrote:
>>>> Carsten Ziegeler wrote:
>>>>> Ate Douma wrote:
>>>>>>> Maybe make sure to do a clean install first and I'll update to your
>>>>>>> latest changes here and try again too.
>>>>>> Just done that and cannot reproduce your error.
>>>>>> My guess is you need a mvn clean install first.
>>>>> No, I tried this before, and the ant script is doing this also. Still
>>>>> the same problem.
>>>>> Are you testing the generated tomcat installation from the ant
>>>>> script or
>>>>> something different?
>>>> Oh, no. I just tested using against my local Tomcat installation using:
>>> which version of Tomcat are you using?
>> Ok, I just deployed to a local Tomcat 5.5 - and then it works for me as
>> well. Our dist build uses a Tomcat 6..maybe that's the problem?
> Could be.
> For Jetspeed we are now using Tomcat 6 by default without problems.
> I see you just downgraded the Tomcat version back to 5.5.27 which is OK
> by me too.
> I'll briefly try to see what might be different with Tomcat 6.

I think I already found it.
On startup of the assembled bundle (Tomcat 6) I get the following:

INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
Exception in thread "Timer-3" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
        at org.apache.commons.digester.Digester.<init>(Digester.java:308)
        at org.apache.pluto.testsuite.TestConfigFactory.<init>(TestConfigFactory.java:37)
        at org.apache.pluto.testsuite.TestPortlet.init(TestPortlet.java:96)
        at javax.portlet.GenericPortlet.init(GenericPortlet.java:127)
        at org.apache.pluto.container.driver.PortletServlet.attemptRegistration(PortletServlet.java:211)
        at org.apache.pluto.container.driver.PortletServlet$1.run(PortletServlet.java:166)
        at java.util.TimerThread.mainLoop(Timer.java:512)
        at java.util.TimerThread.run(Timer.java:462)


As I forgot the jcl-over-slf4j for Pluto driver (which you fixed), we also need it for the testsuite war.
I just dropped that jar in the testsuite/WEB-INF/lib and everything worked fine again.

I'll commit adding a dependency for jcl-over-slf4j on the testsuite pom.xml

Ate

>
>>
>> Regards
>> Carsten
>>>>   mvn pluto2:install -DinstallDir=<my Tomcat dir>
>>>>
>>>> There must be something wrong in the ant script then.
>>>> I can help looking into that in a few minutes.
>>>>
>>>> NB: I haven't reviewed the ant based assembly yet, but if its not
>>>> complex, maybe it might be easier replacing it with a
>>>> maven-assembly-plugin based one? That would even allow "attaching"
>>>> it to
>>>> the build and get it "released" with the project together, similar to
>>>> the source release distros.
>>> Yes, that would be great; atm I have to clue how to do this with maven,
>>> therefore I would go with the ant script for now. ( we just have to move
>>> it to another place so that it gets included in the source maven
>>> artifact, but that should be easy).
>>>
>>> Carsten
>>
>>
>
>

[cziegeler]

> As I forgot the jcl-over-slf4j for Pluto driver (which you fixed), we
> also need it for the testsuite war.
> I just dropped that jar in the testsuite/WEB-INF/lib and everything
> worked fine again.
>
> I'll commit adding a dependency for jcl-over-slf4j on the testsuite pom.xml
>
Thanks Ate, works perfectly now with Tomcat 6; I updated the ant script
to use Tomcat 6 again.

Ok, I think we're now done with the release preparation.

Or is there anything else to do?

Regards
Carsten
--
Carsten Ziegeler
cziegeler@...

[cziegeler]

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

If noone stops me :) I'll start the release process tomorrow morning
(CET) - in roughly 16 hours from now.

Regards
Carsten
--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

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.

Anyway, if you want to do it manually, just ignore the above :)

Regards,

Ate


>
> If noone stops me :) I'll start the release process tomorrow morning
> (CET) - in roughly 16 hours from now.
>
> Regards
> Carsten

[cziegeler]

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

[Ate Douma]

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