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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
