The portal is not yet released - when it is I'll let you know and the site can be added.
I assume you are US based? Thanks for the discussion - hope to chat again soon. Kind regards On 7/2/07, Elliot Metsger <[EMAIL PROTECTED]> wrote:
Marc Veary wrote: > Okay, I would like to contribute something back to the project as I > use the code in a portal. Great! Should it be listed here? http://portals.apache.org/pluto/powered.html > > What I'll do is submit patches containing one or two classes at a time > - I like the little-and-often paradigm ;-) Sounds good! Thanks again, Elliot > > 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 >> >> >> >> >> >> >> >> >> >>
