Possible pluto release?

[djencks]

I've seen rumors on general portlas of an impending pluto release.   I  
assume this would be of trunk.

I glanced at the svn tree for a minute and see some things that either  
need to be or IMO should be changed before release.

Required....

There needs to be an accurate NOTICE file in svn at the root that  
applies to the actual source code you get when you check out from  
svn.  AFAIK this is just the standard apache NOTICE.

Desirable...

use up to date portals-pom as parent.  Hopefully this will be 1.2
clean up pom plugin dependencies -- most of these should be specified  
in parents.
I think it might be a good idea to provide osgi metadata by using the  
maven-bundle-plugin.  On the other hand I'm not prepared to test if it  
is accurate yet.
I don't think specifying all dependency versions as properties is  
considered good maven practice.

I don't think we necessarily want the KEYS file here.  I'd think in a  
common location for portals would be better.

I suspect that pluto.xsi is not functional, I don't see any obvious  
updates since pluto 1.

I'd really prefer using maven tools rather than ant to assembly the  
binary distros including tomcat. Such an assembly would be in an  
additional subproject, not the top level pom.

I  ran into some unwarranted classloading assumptions in pluto 1, see  
PLUTO-555.  I think it would be great if we could fix the remaining  
one in pluto trunk before release, but I'm not entirely sure what the  
correct fix really is.  In pluto 1.x I did this in ToolTips.java:

-    private static final ResourceBundle BUNDLE =  
ResourceBundle.getBundle("ToolTips");
+    private static final ResourceBundle BUNDLE =  
ResourceBundle.getBundle("ToolTips", Locale.US,  
Thread.currentThread().getContextClassLoader());

but it seems rather unlikely that the Locale.US is appropriate.  
Anyone have an idea?

thanks
david jencks

[Ate Douma]

David Jencks wrote:

> I've seen rumors on general portlas of an impending pluto release.   I
> assume this would be of trunk.
>
> I glanced at the svn tree for a minute and see some things that either
> need to be or IMO should be changed before release.
>
> Required....
>
> There needs to be an accurate NOTICE file in svn at the root that
> applies to the actual source code you get when you check out from svn.  
> AFAIK this is just the standard apache NOTICE.
>
> Desirable...
>
> use up to date portals-pom as parent.  Hopefully this will be 1.2
> clean up pom plugin dependencies -- most of these should be specified in
> parents.
> I think it might be a good idea to provide osgi metadata by using the
> maven-bundle-plugin.  On the other hand I'm not prepared to test if it
> is accurate yet.

I'd like to postponing that to a next (minor) release of Pluto 2.0.x
Starting reviewing and ensuring the osgi metadata is actually correct could amount to a lot of work and time,
and most likely would hold up the release.
I don't want anything but critial issues to further delay the initial 2.0 release, following up releases however could be made quickly
thereafter.

> I don't think specifying all dependency versions as properties is
> considered good maven practice.
Possibly, and FYI the same is done in Jetspeed-2.
However, personally I find it very conveniently and don't see any real problem with it either, is there?

>
> I don't think we necessarily want the KEYS file here.  I'd think in a
> common location for portals would be better.
+1, and there already is http://www.apache.org/dist/portals/pluto/KEYS
>
> I suspect that pluto.xsi is not functional, I don't see any obvious
> updates since pluto 1.
I think its no longer maintained, +1 for removing it.

>
> I'd really prefer using maven tools rather than ant to assembly the
> binary distros including tomcat. Such an assembly would be in an
> additional subproject, not the top level pom.
I agree, however I don't know how much work it would be to convert the existing ant based assembly.
Carsten seems familiar with it (I'm not), so I'd say its up to him for this to release to decide.

>
> I  ran into some unwarranted classloading assumptions in pluto 1, see
> PLUTO-555.  I think it would be great if we could fix the remaining one
> in pluto trunk before release, but I'm not entirely sure what the
> correct fix really is.
I never really used Pluto Portal other than for testing and running the TCKs, but on first impression it seems to me the real problem is the
technical design to use a static final initializer for the ResourceBundle. There's no way to switch to a different locale this way, and
neither is catered for passing in a locale in the usage API (forMode/forWindowState).
Properly refactoring of that of course is possible and imo should be done if you properly want to make use of this.
But for now, I think your patch should be fine for the 2.0 trunk too. At least, should be no different than what is already applied to the
1.1.6 branch.

> In pluto 1.x I did this in ToolTips.java:
>
> -        private static final ResourceBundle BUNDLE =
> ResourceBundle.getBundle("ToolTips");
> +        private static final ResourceBundle BUNDLE =
> ResourceBundle.getBundle("ToolTips", Locale.US,
> Thread.currentThread().getContextClassLoader());
>
> but it seems rather unlikely that the Locale.US is appropriate.  Anyone
> have an idea?

No specific hard coded Locale would be appropriate here, you really want to use the current request Locale for this.
But passing that in will require quite some more changes.
If you really like to have this committed in the 2.0 release already, locale.US probably is fine for now.

Regards,

Ate
>
> thanks
> david jencks
>
>
>

[David Sean Taylor]

The build is broken, seems the IANAL plugin is checking all files. Why  
do we have this zip file here anyway?

ERROR] BUILD ERROR
[INFO]  
------------------------------------------------------------------------
[INFO] Artifact does not contain any legal files: pluto-
container-2.0.0-SNAPSHOT-project.zip

[djencks]

On May 14, 2009, at 2:53 PM, David Sean Taylor wrote:

> The build is broken, seems the IANAL plugin is checking all files.  
> Why do we have this zip file here anyway?


I'll look, but I think this is probably the required source distro.  
Most likely there are no LICENSE and NOTICE files at the svn checkout  
root and ianal is telling us to fix it before trying an invalid release.

david jencks

>
>
> ERROR] BUILD ERROR
> [INFO]  
> ------------------------------------------------------------------------
> [INFO] Artifact does not contain any legal files: pluto-
> container-2.0.0-SNAPSHOT-project.zip
>
>

[djencks]

I hacked around on the pluto build and got it to complete, see rev  
774969.

We may have introduced some problems with putting the assembly plugin  
configuration for the source distros into portals-pom  
pluginManagement.  We may also be able to fix the problems by  
requiring maven 2.1 or 2.0.10.  I'll investigate.

The m-r-r-p doesn't do too well with war files, it puts the license/
notice files in WEB-INF/classses/META-INF where they appear (to me at  
least) to apply to the classes in WEB-INF/classes rather than to the  
entire war.  We need to do something either to relocate the legal  
files or make the ianal plugin happier with their location.

I'm pretty confused by the intentions in the pluto build.  It  
certainly needs a __lot__ of cleanup if we use the portals-pom as  
parent, many many plugins are respecified.

The main non-straightforward-question for me is why the root pom that  
builds everything isn't also the parent pom.  I think the intention is  
to release all the pluto stuff at once at the same version; in this  
case I think the standard maven structure is to have the root pom be  
also the parent of all the modules.  If the intention is to make the  
modules independently releasable then the root pom needs a really  
prominent notice that it must not be used for releases.

thanks
david jencks


On May 14, 2009, at 3:42 PM, David Jencks wrote:

>
> On May 14, 2009, at 2:53 PM, David Sean Taylor wrote:
>
>> The build is broken, seems the IANAL plugin is checking all files.  
>> Why do we have this zip file here anyway?
>
>
> I'll look, but I think this is probably the required source distro.  
> Most likely there are no LICENSE and NOTICE files at the svn  
> checkout root and ianal is telling us to fix it before trying an  
> invalid release.
>
> david jencks
>
>>
>>
>> ERROR] BUILD ERROR
>> [INFO]  
>> ------------------------------------------------------------------------
>> [INFO] Artifact does not contain any legal files: pluto-
>> container-2.0.0-SNAPSHOT-project.zip
>>
>>
>

[cziegeler]

David Jencks wrote:

> I hacked around on the pluto build and got it to complete, see rev 774969.
>
> We may have introduced some problems with putting the assembly plugin
> configuration for the source distros into portals-pom pluginManagement.
> We may also be able to fix the problems by requiring maven 2.1 or
> 2.0.10.  I'll investigate.
>
> The m-r-r-p doesn't do too well with war files, it puts the
> license/notice files in WEB-INF/classses/META-INF where they appear (to
> me at least) to apply to the classes in WEB-INF/classes rather than to
> the entire war.  We need to do something either to relocate the legal
> files or make the ianal plugin happier with their location.
>
> I'm pretty confused by the intentions in the pluto build.  It certainly
> needs a __lot__ of cleanup if we use the portals-pom as parent, many
> many plugins are respecified.
>
> The main non-straightforward-question for me is why the root pom that
> builds everything isn't also the parent pom.  I think the intention is
> to release all the pluto stuff at once at the same version; in this case
> I think the standard maven structure is to have the root pom be also the
> parent of all the modules.  If the intention is to make the modules
> independently releasable then the root pom needs a really prominent
> notice that it must not be used for releases.
>

Yes, I realized this yesterday (after I changed it) as well; I think we
release all the pluto stuff at once in the same version. Therefore I'll
revert the changes and make the root pom the parent pom.

As we do release everything in one go, there is imho no need to have a
bin or product artifact on a per module base. So I think we release the
separate modules as maven artifacts (jar, source jar, javadoc jar), a
complete source dist of the whole tree and a bin dist.

I'll have a look at it today.

Carsten
--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

David Jencks wrote:
> I hacked around on the pluto build and got it to complete, see rev 774969.
>
<snip/>

> The m-r-r-p doesn't do too well with war files, it puts the
> license/notice files in WEB-INF/classses/META-INF where they appear (to
> me at least) to apply to the classes in WEB-INF/classes rather than to
> the entire war.  We need to do something either to relocate the legal
> files or make the ianal plugin happier with their location.
We encountered the same problem for APA war projects.
I've found a "fix" or better, workaround, to get the files put in the right place.
The following works for the APA dbbrowser/dbbrowser-war project:

    <build>

      <finalName>apa-dbbrowser</finalName>

      <plugins>
       <plugin>
         <!-- workaround for war processing of m-r-r-plugin causing the generated NOTICE and LICENSE file to be put under
              WEB-INF/classes/META-INF -->
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-remote-resources-plugin</artifactId>
         <executions>
           <execution>
             <goals>
               <goal>process</goal>
             </goals>
             <configuration>
               <outputDirectory>${project.build.directory}/${build.finalName}</outputDirectory>
               <attached>false</attached>
             </configuration>
           </execution>
         </executions>
       </plugin>
      </plugins>

   </build>


Regards,

Ate