Okay, I would like to contribute something back to the project as I
use the code in a portal.
What I'll do is submit patches containing one or two classes at a time
- I like the little-and-often paradigm ;-)
Kind regards,
--
Marc
On 7/2/07, Elliot Metsger <[EMAIL PROTECTED]> wrote:
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
>> >> >>
>> >>
>>
