portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaël Luta <raph...@apache.org>
Subject Reorganizing Jetspeed repository (Was Re: Some mean-spirited whining about the build...)
Date Mon, 02 Jan 2006 19:33:17 GMT
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... :)

-- 
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/

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