portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Ruttimann <roger.ruttim...@earthlink.net>
Subject Re: Reorganizing Jetspeed repository (Was Re: Some mean-spirited whining about the build...)
Date Mon, 02 Jan 2006 22:06:16 GMT
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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message