portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject Re: Reorganizing Jetspeed repository (Was Re: Some mean-spirited whining about the build...)
Date Mon, 02 Jan 2006 19:55:42 GMT


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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message