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
