Marc Veary wrote:
Excellent!
I have been going through the trunk over the past 4-6 months
converting the obvious, doing a code tidying and amending javadocs
where necessary (this is not meant to be rude to other developers or
imply anything bad) - I simply started to do this as I wanted to
understand what the code was doing and found the learning curve steep.
I can submit some of these changes if it would be helpful?
Absolutely!
The best thing to do is to open a Jira issue and then submit patches on
that issue.
I don't know exactly what a good sized patch would be (or even if that
is an issue). I don't think we'd want one big mega patch, but maybe
patches scoped to a group of related packages (e.g.
org.apache.pluto.core.*). It just makes it a little easier to review
and apply.
Others please chime in if you disagree -
How does this sound?
Elliot
I now check all revisions committed to the trunk as I reflect these
changes (if the change required) in the code I compile and use.
Kind regards,
--
Marc
On 7/2/07, Elliot Metsger <[EMAIL PROTECTED]> wrote:
Marc,
I hear you on finals - we just haven't been using them throughout the
codebase, though that is something we could change.
Trunk does require Java 1.5, so yes, developers are able to use 1.5
features. However, the 1.1.x branch needs to maintain 1.4 compat.
Since a lot of patches are being applied to both the 1.1.x branch and
the trunk, the code in trunk hasn't really begun to take advantage of
1.5 features. However, before 1.2.0 (trunk) is released, we do plan to
convert to generics, at least for many of the interfaces.
Sound good?
Thanks,
Elliot
Marc Veary wrote:
> You can leave out the finals - is there an issue with using finals? I
> use them all the time - you would be surprised at the issues it
> prevents.
>
> Also the annotations, please omit them - I do not mind in the least.
>
> Are you converting the loops to the newer format?
>
> On 7/2/07, Elliot Metsger <[EMAIL PROTECTED]> wrote:
>> Nope,
>>
>> Not forward at all.
>>
>> Can I leave out the 'final's or do you want them for some reason? We
>> also haven't been putting in the Java 5 annotations.
>>
>> What do you think?
>>
>> Elliot
>>
>> Marc Veary wrote:
>> > Cool.
>> >
>> > Can I submit this:
>> >
>> > @SuppressWarnings("unchecked")
>> > public Map getUserInfo( final PortletRequest request ) throws
>> > PortletContainerException
>> > {
>> > final String remoteUser = request.getRemoteUser();
>> > if( remoteUser != null )
>> > {
>> > final Map info = (Map)this.userInfoMap.get( remoteUser );
>> > if( info == null )
>> > {
>> > return Collections.EMPTY_MAP;
>> > }
>> > return info;
>> > }
>> > return Collections.EMPTY_MAP;
>> > }
>> >
>> > I hope this is not too forward of me.
>> >
>> > Keep up the good work!
>> >
>> > Kind regards,
>> > --
>> > Marc
>> >
>> > On 7/2/07, Elliot Metsger <[EMAIL PROTECTED]> wrote:
>> >> Good catch Marc,
>> >>
>> >> Not enough sleep and too much coffee on my part. :-)
>> >>
>> >> Fixed r552420, 552421.
>> >>
>> >> Thanks!
>> >> Elliot
>> >>
>> >>
>> >>
>> >> Marc Veary wrote:
>> >> > Hi All,
>> >> > Just got the HEAD from SVN and was checking over the changes as I
>> try
>> >> > to keep this in sync with the code I am using. I noticed the
>> >> > following does not seem to be correct:
>> >> >
>> >> > public Map getUserInfo(PortletRequest request)
>> >> > throws PortletContainerException {
>> >> > if ( request.getRemoteUser() != null ) {
>> >> > Map info =
(Map)userInfoMap.get(request.getRemoteUser());
>> >> > if ( info == null ) {
>> >> > return Collections.EMPTY_MAP;
>> >> > }
>> >> > }
>> >> > return new HashMap();
>> >> > }
>> >> >
>> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous version
>> >> > returned the userInfoMap from the request. I think the attempt
>> was to
>> >> > return an empty map if the 'info' was null?
>> >> >
>> >> > Kind regards,
>> >> > --
>> >> > Marc
>> >>
>>
