I'm in favor of having a portals applications branch that would be a
different repository than Jetspeed. We should follow the same path as
portals-bridges.
Jetspeed is the portal framework that includes everything that's needed
to setup and configure the WebPortal. Portals applications should
include applications that can be deployed into any portal.
Separating the applications from the framework code will be appealing to
application developers which like to contribute applications but don't
like to deal with building/installing the portal before they can start
developing an portlet application.
The Demo stuff could be a subset of applications.
Roger
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
- getting some input from other stakeholders like Pluto guys or Cocoon
portal guys (possibly Geronimo) about the optimal directory breakdown
- figure out a build system that actually works on such a beast
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.
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]
