You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Raphaël Luta <ra...@apache.org> on 2006/01/03 09:45:09 UTC
Re: Reorganizing Jetspeed repository
Ate Douma wrote:
> Raphaël Luta wrote:
>> David Sean Taylor wrote:
>>> Raphaël Luta wrote:
>>>> <snip svn:externals based reorg>
>>>> (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
>
> Question: how are we going to provide specific tags and/or branches for
> jetspeed-2
> with such "trunk" links inside a tree?
> I'm no svn guru, but it seems like that won't be a simple svn copy
> action then anymore.
>
As far as I understand it, you'd have to create the tags in the "main"
hierarchies /portals/components, /portals/apps, etc... and then update
the svn:externals properties in your /porals/jetspeed-2/tags/xxx entry.
It's definitely a bit more complex and error prone.
>> - 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
>
> +1
>
> I don't want to restart the discussion we had about this subject last
> month on
> the general@ list, but I'd like to see a more architectural discussion
> first which
> components are to be considered not j2-specific or portals generic
> before we
> start moving things around.
>
I think the focus here is how to reorg the j2 tree along with a new build
system to allow the configuation flexibility some are looking for here.
The fact that it also helps other communities reuse parts of J2 is a
valuable bonus, but ultimately just a bonus.
Please remember that there's no such thing as a "jetspeed committer",
"pluto committer", "bridges committer", etc... we're all Portals committers
with write access to the whole SVN /portals so I'm not sure it makes
sense to have a j2-specific/portals generic distinction.
What would be your criteria for separation and how stable such a distinction
would be in time ?
IMO, it's easier to decide that /portals/components is just a part of
J2 to start with and put all components there.
>> - figure out a build system that actually works on such a beast
>
> I definitely would like to see it working first!
>
> Maybe we can create something like a "/reorg-test" branch copied from
> our /portals root
> to test these things out?
>
Sure, no need to mess the trunk ! Especially in this branch also serves as
a testbed for the new build system.
--
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
Re: Reorganizing Jetspeed repository
Posted by Roger Ruttimann <ro...@earthlink.net>.
David Sean Taylor wrote:
> Ate Douma wrote:
>
>>>>
>>>> I don't want to restart the discussion we had about this subject last
>>>> month on
>>>> the general@ list, but I'd like to see a more architectural discussion
>>>> first which
>>>> components are to be considered not j2-specific or portals generic
>>>> before we
>>>> start moving things around.
>>>>
>>>
> Why don't we move ALL components out to the jetspeed components project?
> Yes, this does mean everything.... but if that makes it easier to
> build the system, and to reuse the components to build different
> configurations of jetspeed, then isnt that a good thing?
Would the configuration drive which components to build?
>
> Im going to give this a try...
>
> /portals
> /jetspeed-components
> /jetspeed-api
> /applications
> /bridges
> /docs
> /installers
> /configuration
> /j2ee-geronimo
> /j2ee-tomcat
> /j2ee-jetty
> /j2ee-jboss
> /j2me-geronimo
> /j2me-tomcat
> /j2me-jetty
> ....
>
>
> Here are the top level directories currently in J2:
>
> app-servers - move to configurations
> applications - move to applications
> archives - do we need this?
> commons - move to jetspeed-components/commons
> components - move to components
> content-server - drop
> design-docs - move to docs
> docs - move to docs
> etc - move to configuration
> graphic_design - move to docs
> installer - move to installers
> installer2 - move to installers
> jetspeed-api - move to jetspeed-api
> layout-portlets -
> maven-plugin - move to configuration
> patched-jars - ?
> portlet-api - drop
> src - move to configurations
> taglibs - move to applications
> xdocs - move to docs
>
> Basically we are breaking Jetspeed apart.
> There will be nothing left but configurations!
> We are victims of our own component architecture :)
> Thats why Im leaving the jetspeed name on both the api and components.
> We could also call these portals-api or portals-components or just
> plain components or api...but I think anything other than the jetspeed
> name seems a bit destructive. I mean do we want to kill the jetspeed
> name just after our final release? :)
> Or is jetspeed now nothing more than just another configuration of
> "components". I think the jetspeed team is in a funny situation. We
> want others to use our api and components, but we don't want to give
> up the ownership.
>
> I also think we need to make a pass over the components
> All of the components found under components/portals should be moved
> to top level components
>
> Are any of the components "jetspeed" specific?
> You could argue that the engine or the pipeline is
>
> As for the build, we need to switch over to Maven-2
> This refactoring and build conversion seems like a lot of work
> Using a branch to do so might be the best solution
> Its either that or we all stop developing against the trunk for a few
> days and work together to migrate
We should work against the trunk since creating a branch and then merge
it back to the trunk seems like a big overhead.
Once we are clear on the structure we could just split the work of
moving components and have it done quickly.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by David Jencks <da...@yahoo.com>.
On Jan 9, 2006, at 4:55 AM, Dr. Michael Lipp wrote:
> I have been using Jetspeed2 with JBoss for quite some while now,
> deploying it as an EAR.
>
> Basically, I agree with David. I use the tomcat-special artifact
> jetspeed.war as a start, split it in its components, reorganize them,
> pack a WAR for Jetspeed and WARs for the portlet applications and
> finally pack all of this in an EAR. All libraries that have to be
> "shared" (i.e. go into the tomcat shared directory) are excluded from
> the WARs, but added to the EAR and loaded as Java modules in the
> application deployment descriptor (application.xml). So, of course,
> I'd
> also rather start with a proper set of libraries, layout directories
> etc. and some assembling instructions. IMHO, this is what would
> constitute a "proper" Jetspeed2 binary distribution.
I like this description.
>
> What I dislike about David's approach is that it is too Geronimo
> specific. IMHO there is a "Servlet"-packing and an "EAR"- or
> "ApplicationServer"-Packing of Jetspeed2. The vendor specific
> deployment
> descriptors of all application servers can co-exist, so we need no
> vendor specific directories for the application server packing. The
> only
> issue that may require vendor specific handling is adding the "bridge"
> that allows the application server to access the user/password/role
> information maintained by Jetspeed2. But from experience, I know that
> several such modules can also co-exist in a single EAR that can be
> deployed in different application servers. (I'm not sure about David's
> approach: if you want to access user/password/roles information
> maintained by the application server in Jetspeed, then things are more
> difficult. But I don't think this is a good approach anyway. And
> thinking about it, it may still be possible...)
>
> So the bottom line is, please do not approach this by focusing on
> geronimo, as this will restrict the possible uses of Jetspeed
> unnecessarily. Whatever you do, do base it on the J2EE standard and do
> it at least for two application servers in parallel. Else you won't
> really notice when you are doing something the moves you away from the
> standard towards some proprietary specialty of the application server
> you use.
I think that is a very good point and I completely agree that biasing
jetspeed toward a particular app server is not a good idea. I do
think that having everything needed to deploy jetspeed in the best
possible way on each app server is a good idea. I was trying to
describe what I got to work in geronimo and explain how i thought it
might be possible to accomodate both geronimo and tomcats needs at
the same time. At this point I don't share your hope that a single
ear can be deployed on several app servers. For instance, geronimo
needs a geronimo-specific jetspeed valve in pipelines.xml. Of course
it may be possible to eliminate this valve by use of JACC directly,
but this remains to be seen: it would certainly require some other
modifications e.g. to the session tracking code.
thanks
david jencks
>
> Regards,
>
> Michael
>
>
> David Jencks wrote:
>>
>> On Jan 8, 2006, at 11:48 AM, David Sean Taylor wrote:
>>
>>> David Jencks wrote:
>>>
>>>> After working on the geronimo integration for a bit I have an
>>>> opinion on what the most important reorganization step is :-)
>>>> The current jetspeed.war is basically a tomcat-specific artifact.
>>>> In order to work in geronimo, I had to build a jetspeed war
>>>> without
>>>> any classes or lib entries. I think the current war should be
>>>> built
>>>> in a module inside app-servers rather than as the top level
>>>> artifact. I also think there needs to be either separate builds
>>>> for including different amounts of lib jars or a way of
>>>> customizing
>>>> the build to include different jars. (In M2 I think profiles
>>>> give
>>>> you some control like this).
>>>
>>>
>>> Just curious, where did you put the jar files if not in WEB-INF/lib?
>>
>>
>> A geronimo serve is constructed out of configurations, which
>> consist of
>> a classloader and some components. The classloader can include
>> classes
>> packed in the configuration and some (external) jars (from the
>> maven-like geronimo repository) and can have multiple parents. For
>> example, a j2ee application (ear file, war file, etc etc) gets
>> turned
>> into a configuration. We can include jars from the repository in
>> the
>> ear configuration rather than including them directly in the ear:
>> this
>> avoids duplication.
>>
>> So, I have one (non-j2ee) base configuration that has the jars
>> that in
>> tomcat go into shared, and an ear that has jetspeed.war and all the
>> portlet apps in it. In order for this to work in geronimo, I
>> have all
>> the jars that for tomcat are packed into jetspeed.war listed as
>> external dependencies of the ear. I could not get the
>> deployment of
>> local portlet apps to work from inside jetspeed.war, so I hacked
>> up the
>> regular jetspeedComponentServlet to accept local wars and determine
>> that they are local by whether they start with jetspeed-.
>>
>> I'm more or less amazed at the number of jars included in
>> jetspeed.war. I strongly suspect that 90% of them are needed
>> only for
>> the portlet apps and wonder if there is some way to make that
>> clearer.
>> In geronimo we can do that easily but that would not work for
>> non-geronimo jetspeed setups.
>>
>>>
>>> But yes, I agree with you - we need to assemble the distribution as
>>> different configurations. Its always more or less the same jars and
>>> classes, but just a different way of packaging for different app
>>> servers. This sounds very much like Raphael's suggestion to have a
>>> different configurations. Here is my interpretation:
>>>
>>> /jetspeed-components
>>> (all the components go here)
>>>
>>> /configurations
>>> /tomcat
>>> /configuration-1
>>> /configuration-2
>>> ...
>>> /geronimo
>>> /configuration-1
>>> /configuration-2
>>>
>>> So if someone wanted to build geronimo with configuratoin-2, they
>>> would build the project under /configuration/geronimo/
>>> configruation-2
>>>
>>>> I'm also not exactly sure what the meaning of most of the stuff in
>>>> jetspeed.war is. My uneducated impression is that there are at
>>>> least one skin and a site layout. Assuming this bears some
>>>> relationship to the actual contents, I think that having these as
>>>> separate modules that are unpacked into the jetspeed war would
>>>> make
>>>> it much easier for someone to either construct additional
>>>> skins or
>>>> assemble a portal with exactly the parts they want to use.
>>>
>>>
>>> the Skins are called decorators, and they are really CSS styles for
>>> pages and portlets
>>> decorators can be re-used by different configurations
>>> they could be stored in a separate project
>>>
>>> /decorators
>>>
>>> Layouts are descriptions of how pages are aggregated such as two
>>> column, three-column, one-column, nested. Layouts could also be
>>> stored as a project
>>>
>>>
>>> /layouts
>>>
>>> A configuration can define its own decorators and layouts (I dont
>>> really see a use case for that though), or include in a
>>> decorator or
>>> layout in the configuration
>>>
>>> The site is made up of pages, folders and subsites
>>> Im thinking that a configuration needs to have a default site with
>>> it, although a big part of customizing your own portal is defining
>>> your own site layout (pages, folders).
>>>
>>> A custom portal configuration is really the combination of all
>>> of the
>>> above, including the application server destination
>>
>>
>> Excellent, thanks for the explanation. I think making this
>> modularity
>> clearer would really help newbies understand how to set up their own
>> portal.
>>
>> thanks
>> david jencks
>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-dev-
>>> help@portals.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by "Dr. Michael Lipp" <Mi...@danet.de>.
I have been using Jetspeed2 with JBoss for quite some while now,
deploying it as an EAR.
Basically, I agree with David. I use the tomcat-special artifact
jetspeed.war as a start, split it in its components, reorganize them,
pack a WAR for Jetspeed and WARs for the portlet applications and
finally pack all of this in an EAR. All libraries that have to be
"shared" (i.e. go into the tomcat shared directory) are excluded from
the WARs, but added to the EAR and loaded as Java modules in the
application deployment descriptor (application.xml). So, of course, I'd
also rather start with a proper set of libraries, layout directories
etc. and some assembling instructions. IMHO, this is what would
constitute a "proper" Jetspeed2 binary distribution.
What I dislike about David's approach is that it is too Geronimo
specific. IMHO there is a "Servlet"-packing and an "EAR"- or
"ApplicationServer"-Packing of Jetspeed2. The vendor specific deployment
descriptors of all application servers can co-exist, so we need no
vendor specific directories for the application server packing. The only
issue that may require vendor specific handling is adding the "bridge"
that allows the application server to access the user/password/role
information maintained by Jetspeed2. But from experience, I know that
several such modules can also co-exist in a single EAR that can be
deployed in different application servers. (I'm not sure about David's
approach: if you want to access user/password/roles information
maintained by the application server in Jetspeed, then things are more
difficult. But I don't think this is a good approach anyway. And
thinking about it, it may still be possible...)
So the bottom line is, please do not approach this by focusing on
geronimo, as this will restrict the possible uses of Jetspeed
unnecessarily. Whatever you do, do base it on the J2EE standard and do
it at least for two application servers in parallel. Else you won't
really notice when you are doing something the moves you away from the
standard towards some proprietary specialty of the application server
you use.
Regards,
Michael
David Jencks wrote:
>
> On Jan 8, 2006, at 11:48 AM, David Sean Taylor wrote:
>
>> David Jencks wrote:
>>
>>> After working on the geronimo integration for a bit I have an
>>> opinion on what the most important reorganization step is :-)
>>> The current jetspeed.war is basically a tomcat-specific artifact.
>>> In order to work in geronimo, I had to build a jetspeed war without
>>> any classes or lib entries. I think the current war should be built
>>> in a module inside app-servers rather than as the top level
>>> artifact. I also think there needs to be either separate builds
>>> for including different amounts of lib jars or a way of customizing
>>> the build to include different jars. (In M2 I think profiles give
>>> you some control like this).
>>
>>
>> Just curious, where did you put the jar files if not in WEB-INF/lib?
>
>
> A geronimo serve is constructed out of configurations, which consist of
> a classloader and some components. The classloader can include classes
> packed in the configuration and some (external) jars (from the
> maven-like geronimo repository) and can have multiple parents. For
> example, a j2ee application (ear file, war file, etc etc) gets turned
> into a configuration. We can include jars from the repository in the
> ear configuration rather than including them directly in the ear: this
> avoids duplication.
>
> So, I have one (non-j2ee) base configuration that has the jars that in
> tomcat go into shared, and an ear that has jetspeed.war and all the
> portlet apps in it. In order for this to work in geronimo, I have all
> the jars that for tomcat are packed into jetspeed.war listed as
> external dependencies of the ear. I could not get the deployment of
> local portlet apps to work from inside jetspeed.war, so I hacked up the
> regular jetspeedComponentServlet to accept local wars and determine
> that they are local by whether they start with jetspeed-.
>
> I'm more or less amazed at the number of jars included in
> jetspeed.war. I strongly suspect that 90% of them are needed only for
> the portlet apps and wonder if there is some way to make that clearer.
> In geronimo we can do that easily but that would not work for
> non-geronimo jetspeed setups.
>
>>
>> But yes, I agree with you - we need to assemble the distribution as
>> different configurations. Its always more or less the same jars and
>> classes, but just a different way of packaging for different app
>> servers. This sounds very much like Raphael's suggestion to have a
>> different configurations. Here is my interpretation:
>>
>> /jetspeed-components
>> (all the components go here)
>>
>> /configurations
>> /tomcat
>> /configuration-1
>> /configuration-2
>> ...
>> /geronimo
>> /configuration-1
>> /configuration-2
>>
>> So if someone wanted to build geronimo with configuratoin-2, they
>> would build the project under /configuration/geronimo/configruation-2
>>
>>> I'm also not exactly sure what the meaning of most of the stuff in
>>> jetspeed.war is. My uneducated impression is that there are at
>>> least one skin and a site layout. Assuming this bears some
>>> relationship to the actual contents, I think that having these as
>>> separate modules that are unpacked into the jetspeed war would make
>>> it much easier for someone to either construct additional skins or
>>> assemble a portal with exactly the parts they want to use.
>>
>>
>> the Skins are called decorators, and they are really CSS styles for
>> pages and portlets
>> decorators can be re-used by different configurations
>> they could be stored in a separate project
>>
>> /decorators
>>
>> Layouts are descriptions of how pages are aggregated such as two
>> column, three-column, one-column, nested. Layouts could also be
>> stored as a project
>>
>>
>> /layouts
>>
>> A configuration can define its own decorators and layouts (I dont
>> really see a use case for that though), or include in a decorator or
>> layout in the configuration
>>
>> The site is made up of pages, folders and subsites
>> Im thinking that a configuration needs to have a default site with
>> it, although a big part of customizing your own portal is defining
>> your own site layout (pages, folders).
>>
>> A custom portal configuration is really the combination of all of the
>> above, including the application server destination
>
>
> Excellent, thanks for the explanation. I think making this modularity
> clearer would really help newbies understand how to set up their own
> portal.
>
> thanks
> david jencks
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by Mikko Wuokko <Mi...@evtek.fi>.
Hi.
I'm not sure if this has come up already on this thread (haven't read it
so thoroughly and bit of topic too ;) ), but I just thought that it
could be wise and handy that all the version number of dependencies and
like so should be introduced as variables so that they could be easily
overridden in custom build.properties.
Like the izpack standalone-compiler version is out of date and the code
in installer/project.xml is like this
<dependencies>
<dependency>
<id>standalone-compiler</id>
<groupId>izpack</groupId>
<version>3.6.1</version>
</dependency>
</dependencies>
if it would changed to something like this
izpack.version=3.8.0
.
.
.
<dependencies>
<dependency>
<id>standalone-compiler</id>
<groupId>izpack</groupId>
<version>${izpack.version}</version>
</dependency>
</dependencies>
Probably most of the versions are defined like this as is in
${jetspeed.project.home}/project.properties, but using them consistently
throughout the project would make the updating to a new component more
simple.
Sorry to bother if this is already under consider.
-Mikko
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: How to receive the minimize, restore, maximize event in portlet
Posted by Pham Tuan Minh <ph...@yahoo.com>.
I'm sorry because of my easy question.
Use getWindowState() funtion to check the state of portlet windows.
Pham Tuan Minh <ph...@yahoo.com> wrote: Hi all,
When user click on maximize button, I'd like to display pictures in 3 columns. Afterthat, When user click on restore button, I'd like to display pictures in 2 columns. I don't know how to receive the minimize, restore, maximize event in portlet. Can you help me, please ?
Thanks.
---------------------------------
Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.
---------------------------------
Yahoo! Photos Showcase holiday pictures in hardcover
Photo Books. You design it and well bind it!
How to receive the minimize, restore, maximize event in portlet
Posted by Pham Tuan Minh <ph...@yahoo.com>.
Hi all,
When user click on maximize button, I'd like to display pictures in 3 columns. Afterthat, When user click on restore button, I'd like to display pictures in 2 columns. I don't know how to receive the minimize, restore, maximize event in portlet. Can you help me, please ?
Thanks.
---------------------------------
Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.
Re: Reorganizing Jetspeed repository
Posted by David Jencks <da...@yahoo.com>.
On Jan 8, 2006, at 11:48 AM, David Sean Taylor wrote:
> David Jencks wrote:
>> After working on the geronimo integration for a bit I have an
>> opinion on what the most important reorganization step is :-)
>> The current jetspeed.war is basically a tomcat-specific artifact.
>> In order to work in geronimo, I had to build a jetspeed war
>> without any classes or lib entries. I think the current war
>> should be built in a module inside app-servers rather than as the
>> top level artifact. I also think there needs to be either
>> separate builds for including different amounts of lib jars or a
>> way of customizing the build to include different jars. (In M2 I
>> think profiles give you some control like this).
>
> Just curious, where did you put the jar files if not in WEB-INF/lib?
A geronimo serve is constructed out of configurations, which consist
of a classloader and some components. The classloader can include
classes packed in the configuration and some (external) jars (from
the maven-like geronimo repository) and can have multiple parents.
For example, a j2ee application (ear file, war file, etc etc) gets
turned into a configuration. We can include jars from the repository
in the ear configuration rather than including them directly in the
ear: this avoids duplication.
So, I have one (non-j2ee) base configuration that has the jars that
in tomcat go into shared, and an ear that has jetspeed.war and all
the portlet apps in it. In order for this to work in geronimo, I
have all the jars that for tomcat are packed into jetspeed.war listed
as external dependencies of the ear. I could not get the
deployment of local portlet apps to work from inside jetspeed.war, so
I hacked up the regular jetspeedComponentServlet to accept local wars
and determine that they are local by whether they start with jetspeed-.
I'm more or less amazed at the number of jars included in
jetspeed.war. I strongly suspect that 90% of them are needed only
for the portlet apps and wonder if there is some way to make that
clearer. In geronimo we can do that easily but that would not work
for non-geronimo jetspeed setups.
>
> But yes, I agree with you - we need to assemble the distribution as
> different configurations. Its always more or less the same jars and
> classes, but just a different way of packaging for different app
> servers. This sounds very much like Raphael's suggestion to have a
> different configurations. Here is my interpretation:
>
> /jetspeed-components
> (all the components go here)
>
> /configurations
> /tomcat
> /configuration-1
> /configuration-2
> ...
> /geronimo
> /configuration-1
> /configuration-2
>
> So if someone wanted to build geronimo with configuratoin-2, they
> would build the project under /configuration/geronimo/configruation-2
>
>> I'm also not exactly sure what the meaning of most of the stuff
>> in jetspeed.war is. My uneducated impression is that there are
>> at least one skin and a site layout. Assuming this bears some
>> relationship to the actual contents, I think that having these as
>> separate modules that are unpacked into the jetspeed war would
>> make it much easier for someone to either construct additional
>> skins or assemble a portal with exactly the parts they want to use.
>
> the Skins are called decorators, and they are really CSS styles for
> pages and portlets
> decorators can be re-used by different configurations
> they could be stored in a separate project
>
> /decorators
>
> Layouts are descriptions of how pages are aggregated such as two
> column, three-column, one-column, nested. Layouts could also be
> stored as a project
>
>
> /layouts
>
> A configuration can define its own decorators and layouts (I dont
> really see a use case for that though), or include in a decorator
> or layout in the configuration
>
> The site is made up of pages, folders and subsites
> Im thinking that a configuration needs to have a default site with
> it, although a big part of customizing your own portal is defining
> your own site layout (pages, folders).
>
> A custom portal configuration is really the combination of all of
> the above, including the application server destination
Excellent, thanks for the explanation. I think making this
modularity clearer would really help newbies understand how to set up
their own portal.
thanks
david jencks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by David Sean Taylor <da...@bluesunrise.com>.
David Jencks wrote:
> After working on the geronimo integration for a bit I have an opinion
> on what the most important reorganization step is :-)
>
> The current jetspeed.war is basically a tomcat-specific artifact. In
> order to work in geronimo, I had to build a jetspeed war without any
> classes or lib entries. I think the current war should be built in a
> module inside app-servers rather than as the top level artifact. I
> also think there needs to be either separate builds for including
> different amounts of lib jars or a way of customizing the build to
> include different jars. (In M2 I think profiles give you some control
> like this).
Just curious, where did you put the jar files if not in WEB-INF/lib?
But yes, I agree with you - we need to assemble the distribution as
different configurations. Its always more or less the same jars and
classes, but just a different way of packaging for different app
servers. This sounds very much like Raphael's suggestion to have a
different configurations. Here is my interpretation:
/jetspeed-components
(all the components go here)
/configurations
/tomcat
/configuration-1
/configuration-2
...
/geronimo
/configuration-1
/configuration-2
So if someone wanted to build geronimo with configuratoin-2, they would
build the project under /configuration/geronimo/configruation-2
>
> I'm also not exactly sure what the meaning of most of the stuff in
> jetspeed.war is. My uneducated impression is that there are at least
> one skin and a site layout. Assuming this bears some relationship to
> the actual contents, I think that having these as separate modules that
> are unpacked into the jetspeed war would make it much easier for
> someone to either construct additional skins or assemble a portal with
> exactly the parts they want to use.
the Skins are called decorators, and they are really CSS styles for
pages and portlets
decorators can be re-used by different configurations
they could be stored in a separate project
/decorators
Layouts are descriptions of how pages are aggregated such as two column,
three-column, one-column, nested. Layouts could also be stored as a
project
/layouts
A configuration can define its own decorators and layouts (I dont really
see a use case for that though), or include in a decorator or layout in
the configuration
The site is made up of pages, folders and subsites
Im thinking that a configuration needs to have a default site with it,
although a big part of customizing your own portal is defining your own
site layout (pages, folders).
A custom portal configuration is really the combination of all of the
above, including the application server destination
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by David Jencks <da...@yahoo.com>.
After working on the geronimo integration for a bit I have an opinion
on what the most important reorganization step is :-)
The current jetspeed.war is basically a tomcat-specific artifact. In
order to work in geronimo, I had to build a jetspeed war without any
classes or lib entries. I think the current war should be built in a
module inside app-servers rather than as the top level artifact. I
also think there needs to be either separate builds for including
different amounts of lib jars or a way of customizing the build to
include different jars. (In M2 I think profiles give you some
control like this).
I'm also not exactly sure what the meaning of most of the stuff in
jetspeed.war is. My uneducated impression is that there are at least
one skin and a site layout. Assuming this bears some relationship to
the actual contents, I think that having these as separate modules
that are unpacked into the jetspeed war would make it much easier for
someone to either construct additional skins or assemble a portal
with exactly the parts they want to use.
I'd be happy to work on a patch for customizing the contents of
jetspeed.war, but I don't think moving the war build into app-
servers is appropriate for a patch since mostly it would be an svn mv
command.
thanks
david jencks
On Jan 8, 2006, at 6:51 AM, David Le Strat wrote:
> David,
>
> What about a common-components section? There ought
> to be common-components between all the projects. For
> instance:
>
> - Component Manager
> - Deploy Tools
> - Rdbms
> - Security (maybe)
> - Prefs (maybe)
>
> Thoughts? Also, can we help out.
>
> Let me know.
>
> Regards,
>
> David Le Strat
>
> --- David Sean Taylor <da...@bluesunrise.com> wrote:
>
>> Ate Douma wrote:
>>>>>
>>>>> I don't want to restart the discussion we had
>> about this subject last
>>>>> month on
>>>>> the general@ list, but I'd like to see a more
>> architectural discussion
>>>>> first which
>>>>> components are to be considered not j2-specific
>> or portals generic
>>>>> before we
>>>>> start moving things around.
>>>>>
>>>>
>> Why don't we move ALL components out to the jetspeed
>> components project?
>> Yes, this does mean everything.... but if that makes
>> it easier to build
>> the system, and to reuse the components to build
>> different
>> configurations of jetspeed, then isnt that a good
>> thing?
>>
>> Im going to give this a try...
>>
>> /portals
>> /jetspeed-components
>> /jetspeed-api
>> /applications
>> /bridges
>> /docs
>> /installers
>> /configuration
>> /j2ee-geronimo
>> /j2ee-tomcat
>> /j2ee-jetty
>> /j2ee-jboss
>> /j2me-geronimo
>> /j2me-tomcat
>> /j2me-jetty
>> ....
>>
>>
>> Here are the top level directories currently in J2:
>>
>> app-servers - move to configurations
>> applications - move to applications
>> archives - do we need this?
>> commons - move to jetspeed-components/commons
>> components - move to components
>> content-server - drop
>> design-docs - move to docs
>> docs - move to docs
>> etc - move to configuration
>> graphic_design - move to docs
>> installer - move to installers
>> installer2 - move to installers
>> jetspeed-api - move to jetspeed-api
>> layout-portlets -
>> maven-plugin - move to configuration
>> patched-jars - ?
>> portlet-api - drop
>> src - move to configurations
>> taglibs - move to applications
>> xdocs - move to docs
>>
>> Basically we are breaking Jetspeed apart.
>> There will be nothing left but configurations!
>> We are victims of our own component architecture :)
>> Thats why Im leaving the jetspeed name on both the
>> api and components.
>> We could also call these portals-api or
>> portals-components or just plain
>> components or api...but I think anything other than
>> the jetspeed name
>> seems a bit destructive. I mean do we want to kill
>> the jetspeed name
>> just after our final release? :)
>> Or is jetspeed now nothing more than just another
>> configuration of
>> "components". I think the jetspeed team is in a
>> funny situation. We want
>> others to use our api and components, but we don't
>> want to give up the
>> ownership.
>>
>> I also think we need to make a pass over the
>> components
>> All of the components found under components/portals
>> should be moved to
>> top level components
>>
>> Are any of the components "jetspeed" specific?
>> You could argue that the engine or the pipeline is
>>
>> As for the build, we need to switch over to Maven-2
>> This refactoring and build conversion seems like a
>> lot of work
>> Using a branch to do so might be the best solution
>> Its either that or we all stop developing against
>> the trunk for a few
>> days and work together to migrate
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
>> jetspeed-dev-help@portals.apache.org
>>
>>
>
>
> ________________________
> David Le Strat
> Blogging @ http://dlsthoughts.blogspot.com
>
>
>
> __________________________________________
> Yahoo! DSL – Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by David Sean Taylor <da...@bluesunrise.com>.
David Le Strat wrote:
> David,
>
> What about a common-components section? There ought
> to be common-components between all the projects. For
> instance:
>
> - Component Manager
> - Deploy Tools
> - Rdbms
> - Security (maybe)
> - Prefs (maybe)
>
Yes it might help to categorize the components
There are so many of them.
Do you want to have a different subversion project for each category, or
are these just directories under the same subversion project?
> Thoughts? Also, can we help out.
>
> Let me know.
You can help out by discussing it and keeping the discussion current.
Otherwise, its going to fall off as I can't do anything with out
everyone's full support. This is a major change.
I will not make any changes until we have a vote, and we have the full
support of all committers.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by David Le Strat <dl...@yahoo.com>.
David,
What about a common-components section? There ought
to be common-components between all the projects. For
instance:
- Component Manager
- Deploy Tools
- Rdbms
- Security (maybe)
- Prefs (maybe)
Thoughts? Also, can we help out.
Let me know.
Regards,
David Le Strat
--- David Sean Taylor <da...@bluesunrise.com> wrote:
> Ate Douma wrote:
> >>>
> >>> I don't want to restart the discussion we had
> about this subject last
> >>> month on
> >>> the general@ list, but I'd like to see a more
> architectural discussion
> >>> first which
> >>> components are to be considered not j2-specific
> or portals generic
> >>> before we
> >>> start moving things around.
> >>>
> >>
> Why don't we move ALL components out to the jetspeed
> components project?
> Yes, this does mean everything.... but if that makes
> it easier to build
> the system, and to reuse the components to build
> different
> configurations of jetspeed, then isnt that a good
> thing?
>
> Im going to give this a try...
>
> /portals
> /jetspeed-components
> /jetspeed-api
> /applications
> /bridges
> /docs
> /installers
> /configuration
> /j2ee-geronimo
> /j2ee-tomcat
> /j2ee-jetty
> /j2ee-jboss
> /j2me-geronimo
> /j2me-tomcat
> /j2me-jetty
> ....
>
>
> Here are the top level directories currently in J2:
>
> app-servers - move to configurations
> applications - move to applications
> archives - do we need this?
> commons - move to jetspeed-components/commons
> components - move to components
> content-server - drop
> design-docs - move to docs
> docs - move to docs
> etc - move to configuration
> graphic_design - move to docs
> installer - move to installers
> installer2 - move to installers
> jetspeed-api - move to jetspeed-api
> layout-portlets -
> maven-plugin - move to configuration
> patched-jars - ?
> portlet-api - drop
> src - move to configurations
> taglibs - move to applications
> xdocs - move to docs
>
> Basically we are breaking Jetspeed apart.
> There will be nothing left but configurations!
> We are victims of our own component architecture :)
> Thats why Im leaving the jetspeed name on both the
> api and components.
> We could also call these portals-api or
> portals-components or just plain
> components or api...but I think anything other than
> the jetspeed name
> seems a bit destructive. I mean do we want to kill
> the jetspeed name
> just after our final release? :)
> Or is jetspeed now nothing more than just another
> configuration of
> "components". I think the jetspeed team is in a
> funny situation. We want
> others to use our api and components, but we don't
> want to give up the
> ownership.
>
> I also think we need to make a pass over the
> components
> All of the components found under components/portals
> should be moved to
> top level components
>
> Are any of the components "jetspeed" specific?
> You could argue that the engine or the pipeline is
>
> As for the build, we need to switch over to Maven-2
> This refactoring and build conversion seems like a
> lot of work
> Using a branch to do so might be the best solution
> Its either that or we all stop developing against
> the trunk for a few
> days and work together to migrate
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@portals.apache.org
>
>
________________________
David Le Strat
Blogging @ http://dlsthoughts.blogspot.com
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by David Sean Taylor <da...@bluesunrise.com>.
Ate Douma wrote:
>>>
>>> I don't want to restart the discussion we had about this subject last
>>> month on
>>> the general@ list, but I'd like to see a more architectural discussion
>>> first which
>>> components are to be considered not j2-specific or portals generic
>>> before we
>>> start moving things around.
>>>
>>
Why don't we move ALL components out to the jetspeed components project?
Yes, this does mean everything.... but if that makes it easier to build
the system, and to reuse the components to build different
configurations of jetspeed, then isnt that a good thing?
Im going to give this a try...
/portals
/jetspeed-components
/jetspeed-api
/applications
/bridges
/docs
/installers
/configuration
/j2ee-geronimo
/j2ee-tomcat
/j2ee-jetty
/j2ee-jboss
/j2me-geronimo
/j2me-tomcat
/j2me-jetty
....
Here are the top level directories currently in J2:
app-servers - move to configurations
applications - move to applications
archives - do we need this?
commons - move to jetspeed-components/commons
components - move to components
content-server - drop
design-docs - move to docs
docs - move to docs
etc - move to configuration
graphic_design - move to docs
installer - move to installers
installer2 - move to installers
jetspeed-api - move to jetspeed-api
layout-portlets -
maven-plugin - move to configuration
patched-jars - ?
portlet-api - drop
src - move to configurations
taglibs - move to applications
xdocs - move to docs
Basically we are breaking Jetspeed apart.
There will be nothing left but configurations!
We are victims of our own component architecture :)
Thats why Im leaving the jetspeed name on both the api and components.
We could also call these portals-api or portals-components or just plain
components or api...but I think anything other than the jetspeed name
seems a bit destructive. I mean do we want to kill the jetspeed name
just after our final release? :)
Or is jetspeed now nothing more than just another configuration of
"components". I think the jetspeed team is in a funny situation. We want
others to use our api and components, but we don't want to give up the
ownership.
I also think we need to make a pass over the components
All of the components found under components/portals should be moved to
top level components
Are any of the components "jetspeed" specific?
You could argue that the engine or the pipeline is
As for the build, we need to switch over to Maven-2
This refactoring and build conversion seems like a lot of work
Using a branch to do so might be the best solution
Its either that or we all stop developing against the trunk for a few
days and work together to migrate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Reorganizing Jetspeed repository
Posted by Ate Douma <at...@douma.nu>.
Raphaël Luta wrote:
> Ate Douma wrote:
>
>>Raphaël Luta wrote:
>>
>>>David Sean Taylor wrote:
>>>
>>>>Raphaël Luta wrote:
>>>>
>>>>><snip svn:externals based reorg>
>>>>>(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
>>
>>Question: how are we going to provide specific tags and/or branches for
>>jetspeed-2
>>with such "trunk" links inside a tree?
>>I'm no svn guru, but it seems like that won't be a simple svn copy
>>action then anymore.
>>
>
>
> As far as I understand it, you'd have to create the tags in the "main"
> hierarchies /portals/components, /portals/apps, etc... and then update
> the svn:externals properties in your /porals/jetspeed-2/tags/xxx entry.
>
> It's definitely a bit more complex and error prone.
Seems tricky indeed.
If it provides us with all the benefits we hope for, I'm +1, but we should
investigate how other groups within ASF handle these things first.
>
>
>>>- 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
>>
>>+1
>>
>>I don't want to restart the discussion we had about this subject last
>>month on
>>the general@ list, but I'd like to see a more architectural discussion
>>first which
>>components are to be considered not j2-specific or portals generic
>>before we
>>start moving things around.
>>
>
>
> I think the focus here is how to reorg the j2 tree along with a new build
> system to allow the configuation flexibility some are looking for here.
> The fact that it also helps other communities reuse parts of J2 is a
> valuable bonus, but ultimately just a bonus.
> Please remember that there's no such thing as a "jetspeed committer",
> "pluto committer", "bridges committer", etc... we're all Portals committers
> with write access to the whole SVN /portals so I'm not sure it makes
> sense to have a j2-specific/portals generic distinction.
I *do* know this.
I've no problem with sharing J2, but I think we should be careful with the outside view
on Portals and J2 in particular.
When we move large parts of J2 under /portals/components while they are (still)
very much J2 specific, we're might be blurring the distinction between Portals and J2
for the rest of the community.
> What would be your criteria for separation and how stable such a distinction
> would be in time ?
I think there should be a strong use-case for independent usage of a component
to have it qualify for separation.
> IMO, it's easier to decide that /portals/components is just a part of
> J2 to start with and put all components there.
I can see its easier, but what I don't see is what benefit it will bring us
(the whole Portals community) right now.
It'll make the build much more complex, and as of now nobody has yet even tried to
use any specific component outside J2. I'd love to see that happen, but why not
let it happen first? All J2 components are already available as individual maven
project artifacts so there is no technical reason preventing reuse outside J2.
Creating a /portals/components tree already so we have a predefined location where
to move generic components to once we identified them is fine by me though.
A related issue might be the packaging of such portals components.
Currently our J2 components all live under "org.apache.jetspeed.".
If they need to move to /portals/components should their packaging change too?
>
>
>>>- figure out a build system that actually works on such a beast
>>
>>I definitely would like to see it working first!
>>
>>Maybe we can create something like a "/reorg-test" branch copied from
>>our /portals root
>>to test these things out?
>>
>
>
> Sure, no need to mess the trunk ! Especially in this branch also serves as
> a testbed for the new build system.
>
So, where would we create such a branch: under /portals/jetspeed-2/branches or
/portals/branches? Note: there isn't a portals/branches yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org