portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Reorganizing Jetspeed repository
Date Tue, 03 Jan 2006 11:48:10 GMT
Raphaël Luta wrote:
> Ate Douma wrote:
> 
>>Raphaël Luta wrote:
>>
>>>David Sean Taylor wrote:
>>>
>>>>Raphaël Luta wrote:
>>>>
>>>>><snip svn:externals based reorg>
>>>>>(ie manage everything in separate hierarchies and tie everything under
>>>>>jetspeed-2 using svn externals property)
>>>>
>>>>+1
>>>>Should a propose a formal vote on this reorg?
>>>
>>>Before a full blown proposal suitable for a vote I think there are quite
>>>a few detaiuls to work out, like:
>>>- making sure the svn:externals actually work as expected in the ASF
>>>setup
>>
>>Question: how are we going to provide specific tags and/or branches for
>>jetspeed-2
>>with such "trunk" links inside a tree?
>>I'm no svn guru, but it seems like that won't be a simple svn copy
>>action then anymore.
>>
> 
> 
> As far as I understand it, you'd have to create the tags in the "main"
> hierarchies /portals/components, /portals/apps, etc... and then update
> the svn:externals properties in your /porals/jetspeed-2/tags/xxx entry.
> 
> It's definitely a bit more complex and error prone.
Seems tricky indeed.
If it provides us with all the benefits we hope for, I'm +1, but we should
investigate how other groups within ASF handle these things first.

> 
> 
>>>- which mailing list(s) gets commits messages for the various directories
>>>- getting some input from other stakeholders like Pluto guys or Cocoon
>>>portal guys (possibly Geronimo) about the optimal directory breakdown
>>
>>+1
>>
>>I don't want to restart the discussion we had about this subject last
>>month on
>>the general@ list, but I'd like to see a more architectural discussion
>>first which
>>components are to be considered not j2-specific or portals generic
>>before we
>>start moving things around.
>>
> 
> 
> I think the focus here is how to reorg the j2 tree along with a new build
> system to allow the configuation flexibility some are looking for here.
> The fact that it also helps other communities reuse parts of J2 is a
> valuable bonus, but ultimately just a bonus.
> Please remember that there's no such thing as a "jetspeed committer",
> "pluto committer", "bridges committer", etc... we're all Portals committers
> with write access to the whole SVN /portals so I'm not sure it makes
> sense to have a j2-specific/portals generic distinction.
I *do* know this.
I've no problem with sharing J2, but I think we should be careful with the outside view
on Portals and J2 in particular.
When we move large parts of J2 under /portals/components while they are (still)
very much J2 specific, we're might be blurring the distinction between Portals and J2
for the rest of the community.

> What would be your criteria for separation and how stable such a distinction
> would be in time ?
I think there should be a strong use-case for independent usage of a component
to have it qualify for separation.

> IMO, it's easier to decide that /portals/components is just a part of
> J2 to start with and put all components there.
I can see its easier, but what I don't see is what benefit it will bring us
(the whole Portals community) right now.
It'll make the build much more complex, and as of now nobody has yet even tried to
use any specific component outside J2. I'd love to see that happen, but why not
let it happen first? All J2 components are already available as individual maven
project artifacts so there is no technical reason preventing reuse outside J2.

Creating a /portals/components tree already so we have a predefined location where
to move generic components to once we identified them is fine by me though.

A related issue might be the packaging of such portals components.
Currently our J2 components all live under "org.apache.jetspeed.".
If they need to move to /portals/components should their packaging change too?

> 
> 
>>>- figure out a build system that actually works on such a beast
>>
>>I definitely would like to see it working first!
>>
>>Maybe we can create something like a "/reorg-test" branch copied from
>>our /portals root
>>to test these things out?
>>
> 
> 
> Sure, no need to mess the trunk ! Especially in this branch also serves as
> a testbed for the new build system.
> 
So, where would we create such a branch: under /portals/jetspeed-2/branches or
/portals/branches? Note: there isn't a portals/branches yet.

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message