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 David Jencks <da...@yahoo.com> on 2005/12/29 04:42:42 UTC
Some mean-spirited whining about the build...
I thought I'd have some fun looking at how to do the geronimo
security integration, so I started out by trying to build jetspeed
and get it running on something. Here are a few comments that might
help out other new users.
The documentation uniformly claims that hslqldb is the default db,
but the build appears to use derby. This makes me distrust
everything the documentation says.
The build forces me to set a bunch of parameters relating to where
tomcat is, but AFAICT they are never used in the main build. After I
set them and run maven allBuild, my tomcat install is unchanged. I'm
not sure why someone who wants to run jetspeed on say jetty should be
forced to set a lot of parameters that are tomcat specific. Perhaps
the only checks for these parameters being set could be when the part
of the plugin that uses them is executed?
The maven plugin seems to require quite a few dependencies that are
not listed as maven dependencies. The plugin expects them to be in
~/.maven/repository/org.apache.portals.bridges/wars
but on cvs.apache.org they are in
http://cvs.apache.org/repository/org.apache.portals.bridges/
which definitely seems like a mistake to me.
I also wonder why the maven plugin has so many portlet apps to deploy
hardcoded into it. This seems contrary to the purpose of a plugin to
me. Another design choice might be to have a plugin goal to iterate
through the dependencies in the project.xml and deploy specially
marked dependencies. Then you could have a couple of example
projects using the plugin that deployed the full or min set of
portlet apps. Although I'm not yet familiar with what the plugin is
supposed to do I think this might provide a useful prototype for
people to build other portals off of.
Many thanks,
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Some mean-spirited whining about the build...
Posted by Roger Ruttimann <ro...@earthlink.net>.
David Jencks wrote:
> I thought I'd have some fun looking at how to do the geronimo
> security integration, so I started out by trying to build jetspeed
> and get it running on something. Here are a few comments that might
> help out other new users.
>
> The documentation uniformly claims that hslqldb is the default db,
> but the build appears to use derby. This makes me distrust
> everything the documentation says.
>
> The build forces me to set a bunch of parameters relating to where
> tomcat is, but AFAICT they are never used in the main build. After I
> set them and run maven allBuild, my tomcat install is unchanged. I'm
> not sure why someone who wants to run jetspeed on say jetty should be
> forced to set a lot of parameters that are tomcat specific. Perhaps
> the only checks for these parameters being set could be when the part
> of the plugin that uses them is executed?
We should clearly separate build and deployment properties so that a
build can be run without having tomcat (jetty in the future) available
on the build machine.
Since we plan to update the build procedure we should keep that in mind.
In addition a build (checkout) should run without any settings in the
~/build.properties file.
>
> The maven plugin seems to require quite a few dependencies that are
> not listed as maven dependencies. The plugin expects them to be in
>
> ~/.maven/repository/org.apache.portals.bridges/wars
>
> but on cvs.apache.org they are in
>
> http://cvs.apache.org/repository/org.apache.portals.bridges/
>
> which definitely seems like a mistake to me.
>
> I also wonder why the maven plugin has so many portlet apps to deploy
> hardcoded into it. This seems contrary to the purpose of a plugin to
> me. Another design choice might be to have a plugin goal to iterate
> through the dependencies in the project.xml and deploy specially
> marked dependencies. Then you could have a couple of example
> projects using the plugin that deployed the full or min set of
> portlet apps. Although I'm not yet familiar with what the plugin is
> supposed to do I think this might provide a useful prototype for
> people to build other portals off of.
>
> Many 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 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
Re: Reorganizing Jetspeed repository
Posted by Raphaël Luta <ra...@apache.org>.
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 (Was Re: Some mean-spirited
whining about the build...)
Posted by Ate Douma <at...@douma.nu>.
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
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.
> - 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.
> - 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?
<snip/>
>
>>Also remember that we have an installer now, and Ate is working on
>>enhancements to that
After being offline for a considerable time I'm going to look into the installer again
starting tomorrow.
I already have several changes and fixes locally which involves moving back to the izPack
installer (now fully ASF 2.0 compliant).
I found ant-installer immature and not comparable feature-wise with izPack by far.
>
>
> 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
Re: Reorganizing Jetspeed repository (Was Re: Some mean-spirited
whining about the build...)
Posted by Raphaël Luta <ra...@apache.org>.
Roger Ruttimann wrote:
> 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.
>
It all depends what you mean by "follow the same path as
portals-bridges". If we're talking only about the repository move then
defintiely +1 but I'd be very wary of creating specific community tools
for the moved code (ie mailing lists, jira, etc...) at least until
there's a known interest from an applications-only community.
> 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 - 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 (Was Re: Some mean-spirited
whining about the build...)
Posted by Roger Ruttimann <ro...@earthlink.net>.
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
Re: Reorganizing Jetspeed repository (Was Re: Some mean-spirited
whining about the build...)
Posted by Raphaël Luta <ra...@apache.org>.
David Sean Taylor wrote:
> Raphaël Luta wrote:
>
>>> 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
>
>
> Could you explain a little more about the svn:externals feature?
>
I'm no SVN expert. I've used some codebases that were using externals
for storing different config sets and read the svnbook about it:
http://svnbook.red-bean.com/en/1.0/ch07s03.html
That's about all I know. I'll ask for support on infra@.
> Im also going to read up on Maven-2 profiles.
>
>>
>> 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 ?)
>>
> I like this idea. It clearly defines what we are building instead of
> hiding that information deep inside of a maven jelly plugin
>
> I see the different configs being the basic equivalent of the src/webapp
> directory in Jetspeed. Almost all of these directories can be tailored
> to a custom configuration, although we may want to factor out things
> like decorations and layouts since they can be used across all
> configurations.
>
+1. I think we have the same vision here, the issue is how to make it
work ;)
> IM just wondering how we should start this refactoring.
> Its going to require a new build for one.
> Maybe DDW has a point: lets try moving out applications first, and try
> to build them with Maven-2 and svn:externals. But Im just wondering if
> the components should be factored out first, since everything is
> dependent on components.
>
Yeah, build worries me. As I stated before, as long as the people that
are going to bear the burden of the change (ie the active committers)
are ok with any experimentation step, then I'm definitely +1.
--
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 (Was Re: Some mean-spirited
whining about the build...)
Posted by David Sean Taylor <da...@bluesunrise.com>.
Raphaël Luta wrote:
>>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
Could you explain a little more about the svn:externals feature?
Im also going to read up on Maven-2 profiles.
>
> 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 ?)
>
I like this idea. It clearly defines what we are building instead of
hiding that information deep inside of a maven jelly plugin
I see the different configs being the basic equivalent of the src/webapp
directory in Jetspeed. Almost all of these directories can be tailored
to a custom configuration, although we may want to factor out things
like decorations and layouts since they can be used across all
configurations.
IM just wondering how we should start this refactoring.
Its going to require a new build for one.
Maybe DDW has a point: lets try moving out applications first, and try
to build them with Maven-2 and svn:externals. But Im just wondering if
the components should be factored out first, since everything is
dependent on components.
---------------------------------------------------------------------
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 (Was Re: Some mean-spirited
whining about the build...)
Posted by Roger Ruttimann <ro...@earthlink.net>.
Raphaël Luta wrote:
>Roger Ruttimann wrote:
>
>
>>Raphaël Luta wrote:
>><snip>
>>
>>
>>>>>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?
>>>>
>>>>
>>>>
>>>If there's a consensus from the current active developers to go this way
>>>and move applications as a test, I'm definitely +1 but then I'm not
>>>active very often on the code so I'm not really the one impacted.
>>>
>>>
>>>
>>How much work is involved in setting up a subversion project for
>>applications? If we all agree to move applications into it's own
>>repository we should go ahead instead of doing it in baby steps which
>>might be confusing to portal users/developers.
>>
>>I volunteer to step-in in creating and maintaining the applications
>>subproject (svn/jira).
>>
>>
>>
>
>If we're talking just moving SVN to /portals/applications and having the
>commits made to current jetspeed-dev list then the work is very small
>(just a svn move and some svn configuration edit done by Santiago). The
>main issue possibly being that applications can be built alone, without
>being included in the jetspeed-2 tree.
>
>
>
I don't think this is a big deal. Just having the dependencies figured out.
---------------------------------------------------------------------
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 (Was Re: Some mean-spirited
whining about the build...)
Posted by Raphaël Luta <ra...@apache.org>.
Roger Ruttimann wrote:
> Raphaël Luta wrote:
> <snip>
>>
>>>> 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?
>>>
>>
>> If there's a consensus from the current active developers to go this way
>> and move applications as a test, I'm definitely +1 but then I'm not
>> active very often on the code so I'm not really the one impacted.
>>
> How much work is involved in setting up a subversion project for
> applications? If we all agree to move applications into it's own
> repository we should go ahead instead of doing it in baby steps which
> might be confusing to portal users/developers.
>
> I volunteer to step-in in creating and maintaining the applications
> subproject (svn/jira).
>
If we're talking just moving SVN to /portals/applications and having the
commits made to current jetspeed-dev list then the work is very small
(just a svn move and some svn configuration edit done by Santiago). The
main issue possibly being that applications can be built alone, without
being included in the jetspeed-2 tree.
--
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 (Was Re: Some mean-spirited
whining about the build...)
Posted by Roger Ruttimann <ro...@earthlink.net>.
Raphaël Luta wrote:
<snip>
>
>
>>>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?
>>
>>
>>
>
>If there's a consensus from the current active developers to go this way
>and move applications as a test, I'm definitely +1 but then I'm not
>active very often on the code so I'm not really the one impacted.
>
>
>
How much work is involved in setting up a subversion project for
applications? If we all agree to move applications into it's own
repository we should go ahead instead of doing it in baby steps which
might be confusing to portal users/developers.
I volunteer to step-in in creating and maintaining the applications
subproject (svn/jira).
Roger
---------------------------------------------------------------------
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 (Was Re: Some mean-spirited
whining about the build...)
Posted by "David H. DeWolf" <dd...@apache.org>.
Raphaël Luta wrote:
>>>
>>>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.
>>
>
>
> I'm not sure, general is meant for healthy discussion on global Portals
> not commit reviews :)
> If the goal is to broaden the participation of the whole Portals
> developer tto these various components, I'd then rather have a
> commits@portals.apache.org that gets commit messages from *all* the
> /portals sub-directories instead of the current jetspeed-dev,
> bridges-commits and pluto-scm.
>
> That would make a lot of sense to me and could be a baby step towards
> more cooperation between the different sub-projects.
Ok, I agree!
>
>
>>>- 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 . . .
>>
>
>
> yeah, but where would Pluto fit in such an organisation, after all with
> 1.1, it's also a Spring component based application, no ?
> Maybe it would make sense to reorg Pluto at the same time.
Yes, definately. I've I don't have my hands 100% around what pluto can
leverage, but I definately think that there's overlap to be gotten rid of.
>
>
>>>- 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.
>>
>
>
> Even if we don't move everything at once, I'm not comfortable enough
> with svn:externals to be sure that there are no side-effects to such a move.
>
Fair enough.
> I'm all for incremental change instead of big bang, I'd just like to
> know for a fact that the end goal is actually realistic and that we're
> not going to land too roughly. Reorg/build change is disruptive so we
> should aim for a stable situation that suits everyone as soon as possible.
>
> I think I'll go and ask for help on the infra@ list. Some people
> probably have experiences on svn:extrenals on a ASF-like repository
> structure.
I remember discussions about this on the struts mailing lists a while
back. I believe that the struts-chain branch uses (or used) them. A
quick google on "apache svn:externals" indicates that maven, and struts
use them and cocoon had a discussion about it. I wonder if any of the
cocoon guys on this list want to fill us in on their experience with
externals.
David
>
>
>>>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?
>>
>
>
> If there's a consensus from the current active developers to go this way
> and move applications as a test, I'm definitely +1 but then I'm not
> active very often on the code so I'm not really the one impacted.
>
---------------------------------------------------------------------
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 (Was Re: Some mean-spirited
whining about the build...)
Posted by Raphaël Luta <ra...@apache.org>.
David H. DeWolf wrote:
> 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.
>
I'm not sure, general is meant for healthy discussion on global Portals
not commit reviews :)
If the goal is to broaden the participation of the whole Portals
developer tto these various components, I'd then rather have a
commits@portals.apache.org that gets commit messages from *all* the
/portals sub-directories instead of the current jetspeed-dev,
bridges-commits and pluto-scm.
That would make a lot of sense to me and could be a baby step towards
more cooperation between the different sub-projects.
>> - 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 . . .
>
yeah, but where would Pluto fit in such an organisation, after all with
1.1, it's also a Spring component based application, no ?
Maybe it would make sense to reorg Pluto at the same time.
>> - 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.
>
Even if we don't move everything at once, I'm not comfortable enough
with svn:externals to be sure that there are no side-effects to such a move.
I'm all for incremental change instead of big bang, I'd just like to
know for a fact that the end goal is actually realistic and that we're
not going to land too roughly. Reorg/build change is disruptive so we
should aim for a stable situation that suits everyone as soon as possible.
I think I'll go and ask for help on the infra@ list. Some people
probably have experiences on svn:extrenals on a ASF-like repository
structure.
>>
>> 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?
>
If there's a consensus from the current active developers to go this way
and move applications as a test, I'm definitely +1 but then I'm not
active very often on the code so I'm not really the one impacted.
--
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 (Was Re: Some mean-spirited
whining about the build...)
Posted by "David H. DeWolf" <dd...@apache.org>.
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
Reorganizing Jetspeed repository (Was Re: Some mean-spirited whining
about the build...)
Posted by Raphaël Luta <ra...@apache.org>.
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
Re: Some mean-spirited whining about the build...
Posted by "David H. DeWolf" <dd...@apache.org>.
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.
>>
>> 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?
+1, Yes.
>
>>
>> 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)
Just to start to get people thinking (realizing that it may not be time
for this yet. . .)
I think that in the Maven2 world that the approach we'd want to take for
this is to utilize the same goals but with a different "profile".
>
> 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
>
I'd also like to see an appserver independent build -- perhaps it would
only work for the me version.
> Also remember that we have an installer now, and Ate is working on
> enhancements to that
Yea!
>
>
> ---------------------------------------------------------------------
> 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: Some mean-spirited whining about the build...
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
Re: Some mean-spirited whining about the build...
Posted by Raphaël Luta <ra...@apache.org>.
David Sean Taylor wrote:
> David Jencks wrote:
>> <snip>
>> The build forces me to set a bunch of parameters relating to where
>> tomcat is, but AFAICT they are never used in the main build. After I
>> set them and run maven allBuild, my tomcat install is unchanged. I'm
>> not sure why someone who wants to run jetspeed on say jetty should be
>> forced to set a lot of parameters that are tomcat specific. Perhaps
>> the only checks for these parameters being set could be when the part
>> of the plugin that uses them is executed?
>
>
> My vote is to remove ALL properties required in the
> $HOME/build.properties. That causes lots of user issues
>
Definitely +1 on this. It is a pain for the casual developer of Jetspeed
like me.
>
> <snip>
>
>> I also wonder why the maven plugin has so many portlet apps to deploy
>> hardcoded into it. This seems contrary to the purpose of a plugin to
>> me. Another design choice might be to have a plugin goal to iterate
>> through the dependencies in the project.xml and deploy specially
>> marked dependencies. Then you could have a couple of example
>> projects using the plugin that deployed the full or min set of
>> portlet apps. Although I'm not yet familiar with what the plugin is
>> supposed to do I think this might provide a useful prototype for
>> people to build other portals off of.
>>
> I think you may have hit upon one of the major misconceptions with
> Jetspeed, that it is very big. The demo apps take up a lot of space, and
> in my opinion the demo apps, since they are not Jetspeed specific,
> should be moved out of the Jetspeed repo and into Portals Applications,
> where they can be downloaded individually if selected.
>
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)
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)
> 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.
--
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: Some mean-spirited whining about the build...
Posted by David Sean Taylor <da...@bluesunrise.com>.
Mean-spirited Whining!? Ut oh lookout!
I thought you were taking a vacation?
I took off this week, much better for it, not feeling so mean spirited :-)
David Jencks wrote:
> I thought I'd have some fun looking at how to do the geronimo security
> integration, so I started out by trying to build jetspeed and get it
> running on something. Here are a few comments that might help out
> other new users.
>
> The documentation uniformly claims that hslqldb is the default db, but
> the build appears to use derby. This makes me distrust everything the
> documentation says.
Yup. We missed a few places in the Derby conversion thanks
>
> The build forces me to set a bunch of parameters relating to where
> tomcat is, but AFAICT they are never used in the main build. After I
> set them and run maven allBuild, my tomcat install is unchanged. I'm
> not sure why someone who wants to run jetspeed on say jetty should be
> forced to set a lot of parameters that are tomcat specific. Perhaps
> the only checks for these parameters being set could be when the part
> of the plugin that uses them is executed?
My vote is to remove ALL properties required in the
$HOME/build.properties. That causes lots of user issues
The reason for Tomcat specific parameters is that our source build only
deploys and works with Tomcat. Not Jetty or anything else.
We do plan to rewrite the build this month.
We are leaning towards Maven-2 and entirely rewriting the current plugin
Thus your comments are very timely and appreciated
>
> The maven plugin seems to require quite a few dependencies that are not
> listed as maven dependencies. The plugin expects them to be in
>
> ~/.maven/repository/org.apache.portals.bridges/wars
>
> but on cvs.apache.org they are in
>
> http://cvs.apache.org/repository/org.apache.portals.bridges/
>
> which definitely seems like a mistake to me.
>
fixed.
> I also wonder why the maven plugin has so many portlet apps to deploy
> hardcoded into it. This seems contrary to the purpose of a plugin to
> me. Another design choice might be to have a plugin goal to iterate
> through the dependencies in the project.xml and deploy specially marked
> dependencies. Then you could have a couple of example projects using
> the plugin that deployed the full or min set of portlet apps. Although
> I'm not yet familiar with what the plugin is supposed to do I think
> this might provide a useful prototype for people to build other portals
> off of.
>
I think you may have hit upon one of the major misconceptions with
Jetspeed, that it is very big. The demo apps take up a lot of space, and
in my opinion the demo apps, since they are not Jetspeed specific,
should be moved out of the Jetspeed repo and into Portals Applications,
where they can be downloaded individually if selected.
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
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Some mean-spirited whining about the build...
Posted by Philip Mark Donaghy <ph...@gmail.com>.
On 12/29/05, David Jencks <da...@yahoo.com> wrote:
> I thought I'd have some fun looking at how to do the geronimo
> security integration, so I started out by trying to build jetspeed
> and get it running on something. Here are a few comments that might
> help out other new users.
>
> The documentation uniformly claims that hslqldb is the default db,
> but the build appears to use derby. This makes me distrust
> everything the documentation says.
I will patch the places in the documention where hsqldb is mentioned.
>
> The build forces me to set a bunch of parameters relating to where
> tomcat is, but AFAICT they are never used in the main build. After I
> set them and run maven allBuild, my tomcat install is unchanged. I'm
> not sure why someone who wants to run jetspeed on say jetty should be
> forced to set a lot of parameters that are tomcat specific. Perhaps
> the only checks for these parameters being set could be when the part
> of the plugin that uses them is executed?
That is a good idea. I'll look into that.
>
> The maven plugin seems to require quite a few dependencies that are
> not listed as maven dependencies. The plugin expects them to be in
>
> ~/.maven/repository/org.apache.portals.bridges/wars
>
> but on cvs.apache.org they are in
>
> http://cvs.apache.org/repository/org.apache.portals.bridges/
>
> which definitely seems like a mistake to me.
>
> I also wonder why the maven plugin has so many portlet apps to deploy
> hardcoded into it. This seems contrary to the purpose of a plugin to
> me. Another design choice might be to have a plugin goal to iterate
> through the dependencies in the project.xml and deploy specially
> marked dependencies. Then you could have a couple of example
> projects using the plugin that deployed the full or min set of
> portlet apps. Although I'm not yet familiar with what the plugin is
> supposed to do I think this might provide a useful prototype for
> people to build other portals off of.
>
> Many thanks,
> david jencks
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--
Philip Donaghy
donaghy.blogspot.com del.icio.us/donaghy/philip
Skype: philipmarkdonaghy
Office: +33 5 56 60 88 02
Mobile: +33 6 20 83 22 62
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org