portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: Some mean-spirited whining about the build...
Date Mon, 02 Jan 2006 17:41:07 GMT
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.
> 
> It can be either:
> 
> /portals/jetspeed-2/ -> portal core
> 	/trunk
> 	/branches
> 	/tags
> /portals/applications/ ->applications
> 	/trunk
> 	/branches
> 	/tags
> 
> (2 different checkouts)
> 
> or
> 
> /portals/jetspeed-2/
> 	core/
> 		trunk/
> 		branches/
> 		tags/
> 	applications/
> 		trunk
> 		branches/
> 		tags/
> 
> (either one full checkout or 2 separate checkouts)
> 
> or even better
> 
> /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?

> 
> We have many options to try and make jetspeed 2 codebase less
> intimidating/cumbersome to first-time users/developers.
> (I like the 3rd approach best if we can make it work as expected as it makes it
> trivial for other portals efforts to reuse and collaborate on the different
> components without getting the full J2 package)
> 
I agree

> 
>>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)

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


---------------------------------------------------------------------
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