Raphaël Luta wrote:
David Sean Taylor wrote:
Raphaël Luta wrote:
What about simply moving the applications code to a different SVN branch,
so that core and apps are checked out separately.
<snip opion 1 & 2>
/portals/components/ -> core portal components
/trunk
/branches
/tags
/portals/applications/ -> useful apps
/trunk
/branches
/tags
/portals/demos/ -> demo stuff
/trunk
/branches
/tags
/portals/jetspeed-2 -> full jetspeed 2 portal
/trunk
svn:externals components /portals/components/trunk
svn:externals applications /portals/applications/trunk
svn:externals bridges /portals/bridges/trunk
svn:externals demos /portals/demos/trunk
(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
- which mailing list(s) gets commits messages for the various directories
My gut says the general list.
- getting some input from other stakeholders like Pluto guys or Cocoon
portal guys (possibly Geronimo) about the optimal directory breakdown
I think it will help spur cooperation between the groups . . .
- figure out a build system that actually works on such a beast
Yes, this is a big consideration if we move everything at once. I
wonder if a better approach is to start with just one of the items (I'd
recomend applications). That seems like a baby step in the right direction.
and then vote and implement the proposal.
Maybe we could start a poropsal draft on the wiki to start formalizing a
precise proposal while the discussion goes on.
I'm all for working through the issues but I also wonder if bighting off
one peice at a time is worth considering. I'm affraid that addressing
things like the mailing lists and redoing builds, and reorganizing
directory structures within jetspeed is more than is required right now.
Simply moving the applications directory is a first step in the right
direction and it gives us a chance to "try" things out before taking on
a much larger effort (modifying the build, etc. . .).
Can we vote and begin to play with applications so that we have some
"working knowledge" for the rest of our discussions?
David
We we're simply trying to give people lots of coding examples using
different Bridges technologies. I think it would be better if we did not
hard code these demo apps into the portal.
Instead Im recommending the default Jetspeed Portal would be made up of
two webapps:
1) the portal itself
2) the jetspeed admin webapp
all other webapps would be optional, and not included in the default
deployment.
I do see the need for an admin portlet, allowing you to download portlet
applications, along with PSML pages, to add to the portal dynamically or
at install time
I can see why you would prefer it like this but we still need to make
sure
it is easy for newbies / prospective users to download a working portal
with enough demo apps to get a feel of what J2 can do for them.
What if we had two different build goals:
1. ee (enterprise edition)
2. me (micro (lightweight) edition)
I don't know if build goals are really the best tool to "configure"
jetspeed.
As far as I understand the situation, different "jetspeed packages"
could possibly vary from one to another based on:
- the spring assembly files used (that would control the portal features
and select appropriate component implementations for the target
environment)
- the portal applications bundled within the package
- the bundled runtime environment (defaults users, permissions, themes
and pages)
IMO, some of these choices should be made at the source repository level
(like assembly files), some at compile time (maybe runtime app server
target) and some at runtime (choosing which apps to deploy or choosing
whther to create default user environment or not ?)
Having only build goals to manage this complexity will probably lead
to issues later with an exponentional number of possible combinations.
If we go with svn:externals as proposed above, it could be possible to
link diferrent config dirs to handle the source repository level
flexibility:
/portals/configs/
jetspeed-ee/
jetspeed-me/
pluto-driver/
/portals/jetspeed-2/
trunk/
svn:externals components /portals/components/trunk
svn:externals applications /portals/applications/trunk
svn:externals bridges /portals/bridges/trunk
svn:externals config /configs/jetspeed-ee/
...
/portals/jetspeed-light/
trunk/
svn:externals components /portals/components/trunk
svn:externals bridges /portals/bridges/trunk
svn:externals config /configs/jetspeed-me/
...
/portals/pluto-driver/
trunk/
svn:externals components /portals/components/trunk
svn:externals config /configs/pluto-driver/
...
This is something like the minDeploy and quickStart goals currently
existing, but I think it would be more clear to have goals for specific
configurations, or even app server specific builds:
1. ee-geronimo-portal
2. ee-tomcat-portal
3. ee-jetty-portal
4. me-geronimo-portal
5. me-tomcat-portal
6. me-jetty-portal
Also remember that we have an installer now, and Ate is working on
enhancements to that
Cool, I will have to try it one of these days... :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
