+1 on your plan. Cool!

Woonsan


----- Original Message ----
> From: Ate Douma <[email protected]>
> To: Jetspeed Developers List <[email protected]>
> Cc: Bridges Developers List <[email protected]>
> Sent: Fri, April 9, 2010 9:55:53 AM
> Subject: Re: edit_defaults
> 
> On 04/09/2010 01:13 AM, David Sean Taylor wrote:
> On Thu, Apr 8, 2010 at 
> 4:06 PM, Ate Douma<
> href="mailto:[email protected]";>[email protected]>  wrote:
>> On 
> 04/08/2010 06:17 AM, David Sean Taylor wrote:
>>>
>>> A 
> minor complication to any portlets using the Velocity Bridge 
> with
>>> the edit_defaults auto switch, seems we need to patch the 
> bridge in
>>> GenericVelocityPortlet.java
>>> And 
> require another release of this bridge if we want to properly
>>> 
> support edit_defaults auto switch .....
>>
>> Maybe we should 
> consider upgrading bridges also to use portals-pom and
>> release using 
> Nexus.
>> If we combine that will separated and independent release 
> versions for each
>> bridges component like we now do with APA, e.g. 
> start defining versions like
>> bridges-common-1.0.5, 
> bridges-velocity-1.0.5 etc. in APA JIRA, and have them
>> all have 
> their separate svn trunk/branches/tags folder, we could turn out a
>> 
> bridges-velocity-1.0.5 (and at least bridges-common-1.0.5 for proper 
> Maven-2
>> dependency resolution) pretty quickly.
>> Doing the 
> ground work starting with only bridges-common and bridges-velocity
>> 
> probably can be done in matter of hours.
>> WDYT?
>>
> 
> +1 on velocity and common bridges
OK.
Assuming lazy consensus on this for 
> now then I'll start on this right away.

Actually I already did some 
> preliminary work locally and got things converted and working within half an 
> hour :)
The restructuring of svn itself probably will take most of the 
> time.
As I think these new bridges versions should all assume portlet 2.0 
> runtime environments, we better bump their major version to indicate 
this, 
> e.g. bridges-common-2.0 and bridges-velocity-2.0

I plan to do the 
> following:
- create a PB JIRA issue for all this
- create new PB JIRA 
> versions bridges-pom-1.0, bridges-common-2.0, bridges-velocity-2.0 and 
> bridges-site as a start
- create a new portals svn site subproject for 
> bridges and (start) moving the little bridges xdocs we have over (maven-2, no 
> multiproject)
- create new svn /bridges-pom, /bridges-common and 
> /bridges-velocity project trees with their own trunk/branches/tags folders
- 
> create a new bridges-pom:1.0:pom project
- move current bridges/trunk 
> /common/* under /bridges-common/trunk and /velocity/* under 
> bridges-velocity/trunk,
- for commons and velocity, remove their maven-1 
> configurations *and* their xdocs and update their maven-2 pom.xml
- adjust 
> the current bridges/trunk maven-1 and maven-2 projects to accomodate for 
> these 
> components been moved out

All in all, this should take a few hours the 
> most and allow us to release new bridges-pom, bridges-common and 
> bridges-velocity shortly.
Other bridges which qualify for updating and 
> subsequent 2.x releases like maybe struts and groovy can follow later 
> on.

Regards,

Ate
>
> I've only tested with the 
> velocity bridge with regards to the
> edit_defaults issue. Perhaps I 
> should test some other bridges as
> well....
>
> 
> ---------------------------------------------------------------------
> To 
> unsubscribe, e-mail: 
> ymailto="mailto:[email protected]"; 
> href="mailto:[email protected]";>[email protected]
> 
> For additional commands, e-mail: 
> ymailto="mailto:[email protected]"; 
> href="mailto:[email protected]";>[email protected]
>


---------------------------------------------------------------------
To 
> unsubscribe, e-mail: 
> ymailto="mailto:[email protected]"; 
> href="mailto:[email protected]";>[email protected]
For 
> additional commands, e-mail: 
> ymailto="mailto:[email protected]"; 
> href="mailto:[email protected]";>[email protected]


      

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to