Re: JetSpeed2 Development Logistics

2004-08-12 Thread Philip Saville 
My approach was to use the Maven plugin to build the initial Portal 
environment, with starting customized (enterprise specific) PSML. I can 
remove the default PSML files using the delete maven tags (not sure if its 
Jelly or other tags), then include my own files over the original places.

The problem I find with Jetspeed 1.5, as soon as a user logs on, a new PSML 
file is created to represent the new role based rolled-up structure they 
see. I have disabled all customizations for users not in admin/webmaster 
roles, in that case, I would like those users to always see the latest role 
based PSML merged for the different (content) groups they are members.

How does Jetspeed2 behave? I haven't had change to move my own custom portal 
maven project to work with Jetspeed2 yet.

Thanks,
Philip

From: David Sean Taylor <[EMAIL PROTECTED]>
Reply-To: "Jetspeed Users List" <[EMAIL PROTECTED]>
To: "Jetspeed Users List" <[EMAIL PROTECTED]>
Subject: Re: JetSpeed2 Development Logistics
Date: Thu, 12 Aug 2004 12:20:51 -0700
On Aug 12, 2004, at 11:43 AM, Randy Watler wrote:
Scott/David,
Thanks for the clarification.
I was describing how to develop portlet applications and resources,
and pointing out that J2 separates portal from portlet application,
something J1 did not.
Right. Even from what little I know now, decoupling Portal and Portlet
development/deployment seems like a very nice feature in J2.
The goal is to develop resources separate from the portal, and to
deploy and undeploy them separately.
From what I understand, what Scott is describing is how to setup an
environment for developing components to use inside of J2.
This can be used by more advanced users to create a customized portal
Ok... the line between Portal and Portlet development is still a little
blurry for me, (no doubt due to my limited understanding at this point).
Thats because we are not doing a good job of communicating this information 
to you, or because its still not clear with me.

So, editing things like SimpleLayoutHeader.jsp or adding a customized
component would seem to require a portal image/merge.
For something like SimpleLayoutHeader, this should be a part of a 
deployable resource jar.
A customized component can be built using a maven project generated by the 
J2 plugin.

 Is the intention
that PSML resources be deployable in the future, (or are they now)? The
reason I ask is that it seems that the PSML defines the
decorations/layouts used within the Portal, (i.e. the layout-decorator,
portlet-decorator, and decorator attributes in defaults/fragment tags).
It seems that one would want to deploy portlets and decorations/layouts
and then deploy a PSML update to use them, no?
PSML is best managed by the portal customizer.
This ensures that you only reference decorators or layouts
My plans were to store all PSML in the database, but due to my current work 
load, that may not happen for the first release.
Anyway I would leave a default file-based PSML implementation for those who 
prefer that method.

At the risk of partly answering my own question, I have to assume that
the Customizer would eventually allow all of the PSML to be managed. If
that is true then, would PSML generally be considered data? That might
explain why some would like to be saving PSML in the database. Others
might want to configure the PSML simply as files because it is primarily
fixed in their scenarios. As things stand today, should I assume that
PSML development/deployment should be done with the maven plugin merge
as outlined by Scott?
PSML is a live data. Maybe we should define a deployment model for 
deploying pages (and folders) to the system.


Just feeling around in the dark guys.. thanks for the patience!
Randy Watler

--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
[office]   +01 707 773-4646
[mobile] +01 707 529 9194

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JetSpeed2 Development Logistics

2004-08-12 Thread Randy Watler 
David/Scott:

OK, thanks to your input, I think I am finally ready to dig in. Here 
would be my initial development guidelines:

Portlets -> WEB-INF/deploy
Decorations/Layouts Resources -> WEB-INF/deploy
Jetspeed2 Component Customization/Configuration -> Jetspeed2 Maven 
Plugin merge/deploy
Other Resources -> treat as editable data files that will eventually be 
deployable
PSML -> treat as editable data files that will eventually be deployable 
as files and/or stored in the database as live data

Only modifications that will be contributed to the Jetspeed2 project 
should be made in the native Jetspeed2 product trees/sandbox.

Thanks guys,

Randy Watler

Re: JetSpeed2 Development Logistics

2004-08-12 Thread David Sean Taylor 
On Aug 12, 2004, at 11:43 AM, Randy Watler wrote:
Scott/David,
Thanks for the clarification.
I was describing how to develop portlet applications and resources,
and pointing out that J2 separates portal from portlet application,
something J1 did not.
Right. Even from what little I know now, decoupling Portal and Portlet
development/deployment seems like a very nice feature in J2.
The goal is to develop resources separate from the portal, and to
deploy and undeploy them separately.
From what I understand, what Scott is describing is how to setup an
environment for developing components to use inside of J2.
This can be used by more advanced users to create a customized portal
Ok... the line between Portal and Portlet development is still a little
blurry for me, (no doubt due to my limited understanding at this 
point).
Thats because we are not doing a good job of communicating this 
information to you, or because its still not clear with me.

So, editing things like SimpleLayoutHeader.jsp or adding a customized
component would seem to require a portal image/merge.
For something like SimpleLayoutHeader, this should be a part of a 
deployable resource jar.
A customized component can be built using a maven project generated by 
the J2 plugin.

 Is the intention
that PSML resources be deployable in the future, (or are they now)? The
reason I ask is that it seems that the PSML defines the
decorations/layouts used within the Portal, (i.e. the layout-decorator,
portlet-decorator, and decorator attributes in defaults/fragment tags).
It seems that one would want to deploy portlets and decorations/layouts
and then deploy a PSML update to use them, no?
PSML is best managed by the portal customizer.
This ensures that you only reference decorators or layouts
My plans were to store all PSML in the database, but due to my current 
work load, that may not happen for the first release.
Anyway I would leave a default file-based PSML implementation for those 
who prefer that method.

At the risk of partly answering my own question, I have to assume that
the Customizer would eventually allow all of the PSML to be managed. If
that is true then, would PSML generally be considered data? That might
explain why some would like to be saving PSML in the database. Others
might want to configure the PSML simply as files because it is 
primarily
fixed in their scenarios. As things stand today, should I assume that
PSML development/deployment should be done with the maven plugin merge
as outlined by Scott?

PSML is a live data. Maybe we should define a deployment model for 
deploying pages (and folders) to the system.


Just feeling around in the dark guys.. thanks for the patience!
Randy Watler

--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
[office]   +01 707 773-4646
[mobile] +01 707 529 9194

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JetSpeed2 Development Logistics

2004-08-12 Thread Randy Watler 
Scott/David,

Thanks for the clarification.

>
> I was describing how to develop portlet applications and resources, 
> and pointing out that J2 separates portal from portlet application, 
> something J1 did not. 

Right. Even from what little I know now, decoupling Portal and Portlet 
development/deployment seems like a very nice feature in J2.

>
> The goal is to develop resources separate from the portal, and to 
> deploy and undeploy them separately.
> From what I understand, what Scott is describing is how to setup an 
> environment for developing components to use inside of J2.
> This can be used by more advanced users to create a customized portal

Ok... the line between Portal and Portlet development is still a little 
blurry for me, (no doubt due to my limited understanding at this point). 
So, editing things like SimpleLayoutHeader.jsp or adding a customized 
component would seem to require a portal image/merge. Is the intention 
that PSML resources be deployable in the future, (or are they now)? The 
reason I ask is that it seems that the PSML defines the 
decorations/layouts used within the Portal, (i.e. the layout-decorator, 
portlet-decorator, and decorator attributes in defaults/fragment tags). 
It seems that one would want to deploy portlets and decorations/layouts 
and then deploy a PSML update to use them, no?

At the risk of partly answering my own question, I have to assume that 
the Customizer would eventually allow all of the PSML to be managed. If 
that is true then, would PSML generally be considered data? That might 
explain why some would like to be saving PSML in the database. Others 
might want to configure the PSML simply as files because it is primarily 
fixed in their scenarios. As things stand today, should I assume that 
PSML development/deployment should be done with the maven plugin merge 
as outlined by Scott?

Just feeling around in the dark guys.. thanks for the patience!

Randy Watler

Re: JetSpeed2 Development Logistics

2004-08-12 Thread David Sean Taylor 
On Aug 12, 2004, at 7:09 AM, Randy Watler wrote:
Scott,
Yes, I did find the jetspeed2:deploy.portal and related goals in the
Jetspeed2 Maven Plugin. The detail you provided fills open questions I 
had
about how it shoudl be used. However, David stated that this "merge" 
should
not be used with Jetspeed2 by design on a previous thread:

http://marc.theaimsgroup.com/?l=jetspeed-user&m=109222938119408&w=2
It appears that the live deployment strategy is preferred in general, 
but
that it may not cover everything that one would like to modify at this
point, (?). In this case, I am specifically asking about two kinds of
customization: PSML hacking and Component development. Apparently, 
Porlet
and decoration/layout are deployable now...

As you know, I am trying to document the "proper" way to develop a 
Jetspeed2
portal in an attempt to get some kind of tutorial off the ground. Of 
course,
I will follow whatever methodology the Jetspeed2 team prefers. David?

I was describing how to develop portlet applications and resources, and 
pointing out that J2 separates portal from portlet application, 
something J1 did not.
The goal is to develop resources separate from the portal, and to 
deploy and undeploy them separately.
From what I understand, what Scott is describing is how to setup an 
environment for developing components to use inside of J2.
This can be used by more advanced users to create a customized portal



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JetSpeed2 Development Logistics

2004-08-12 Thread Randy Watler 
Scott,

Yes, I did find the jetspeed2:deploy.portal and related goals in the
Jetspeed2 Maven Plugin. The detail you provided fills open questions I had
about how it shoudl be used. However, David stated that this "merge" should
not be used with Jetspeed2 by design on a previous thread:

http://marc.theaimsgroup.com/?l=jetspeed-user&m=109222938119408&w=2

It appears that the live deployment strategy is preferred in general, but
that it may not cover everything that one would like to modify at this
point, (?). In this case, I am specifically asking about two kinds of
customization: PSML hacking and Component development. Apparently, Porlet
and decoration/layout are deployable now...

As you know, I am trying to document the "proper" way to develop a Jetspeed2
portal in an attempt to get some kind of tutorial off the ground. Of course,
I will follow whatever methodology the Jetspeed2 team prefers. David?

Randy Watler 

-Original Message-
From: Scott T. Weaver
To: Jetspeed Users List
Sent: 8/12/04 7:35 AM
Subject: Re: JetSpeed2 Development Logistics

Hi Randy,

Actually, the Jetspeed 2 maven plugin actually does have somewhat of a 
merging capability. Just create a new directory structure similar to 
that under /portal in your project:

This is all you really need to get started:
src/java
src/webapp
src/webapp/WEB-INF

Create a maven project.xml in the root of you project. Now you can start

adding/overriding files. When you are ready to build call "maven 
jetspeed2:build.portal" this will build a full jetspeed war file with 
all of your new/overridden files in place on top of jetspeed. Next you 
can call "maven jetspeed2:deploy.portal" which is very similar to "maven

quickStart" except it does not create the db for you. If you need to 
initialize the db you can call "maven jetspeed2:db.create".

Notes on your project.xml build file. You do not necessarily need to add

the Jetspeed 2 jar dependencies to your project.xml the maven plugin 
will merge the correct jars at build time. However, if you start 
extending or creating your own components you will then have to add the 
relevant jetspeed jars to your project.xml so your classes compile 
correctly.

Randy Watler wrote:

> David,
>
> You wrote:
>
>> Our goal is to make all resources deployable:
>>
>> - layouts
>> - decorators
>> - portlet applications
>>
>> If you develop a portlet application, simply drop it into the auto 
>> deploy directory
>>
> Got it. It appears that decorators/layouts can be similarly dropped 
> into the jetspeed/WEB-INF/deploy directory, no?
>
>> You are right, you should not edit the portal or components 
>> directories unless you are planning on submitting a patch
>> However if you develop your own component, such as the Portal's 
>> NavigationState Component or Aggregator Component for example, then
>> you can extend the existing Jetspeed component if necessary, and 
>> develop your own component and assemble it in the jetspeed-spring.xml
>> You can also assemble pipelines of request execution in the 
>> pipelines.xml, also based on Spring components
>>
> How would Jetspeed2 find my custom component classes/jars, (i.e. where

> should these be installed)? I generally understand the configuration 
> being done in jetspeed-spring.xml and pipelines.xml. Would I edit 
> these configuration files in the deployed jetspeed/WEB-INF/assembly 
> directly?
>
>> To create your own portal layout on a page, you will still need to 
>> manually edit the PSML until our customizer is ready
>> We have made some progress in the customizer recently, but its still 
>> not quite there
>>
> Right. Editing PSML is certainly not a big deal. I suppose adding and 
> deleting pages falls into the same category. However, I am still 
> hesitant to modify the deployed jetspeed webapp... is that the 
> intended development strategy? Obviously, there are numerous jetspeed 
> configuration and content files that one might wish to 
> edit/delete/create. I am trying to understand how to approach making 
> these changes in the jetspeed2 environment for a formal production 
> portal/development process, (despite the fact that jetspeed2 is just 
> entering first alpha). Basically, if I am going to write a tutorial 
> for the Wiki, I'd like to get it "right" from the start!
>
> Thanks,
>
> Randy Watler
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
***
*   Scott T. Weaver   *
* <

Re: JetSpeed2 Development Logistics

2004-08-12 Thread Scott T. Weaver 
Hi Randy,
Actually, the Jetspeed 2 maven plugin actually does have somewhat of a 
merging capability. Just create a new directory structure similar to 
that under /portal in your project:

This is all you really need to get started:
src/java
src/webapp
src/webapp/WEB-INF
Create a maven project.xml in the root of you project. Now you can start 
adding/overriding files. When you are ready to build call "maven 
jetspeed2:build.portal" this will build a full jetspeed war file with 
all of your new/overridden files in place on top of jetspeed. Next you 
can call "maven jetspeed2:deploy.portal" which is very similar to "maven 
quickStart" except it does not create the db for you. If you need to 
initialize the db you can call "maven jetspeed2:db.create".

Notes on your project.xml build file. You do not necessarily need to add 
the Jetspeed 2 jar dependencies to your project.xml the maven plugin 
will merge the correct jars at build time. However, if you start 
extending or creating your own components you will then have to add the 
relevant jetspeed jars to your project.xml so your classes compile 
correctly.

Randy Watler wrote:
David,
You wrote:
Our goal is to make all resources deployable:
- layouts
- decorators
- portlet applications
If you develop a portlet application, simply drop it into the auto 
deploy directory

Got it. It appears that decorators/layouts can be similarly dropped 
into the jetspeed/WEB-INF/deploy directory, no?

You are right, you should not edit the portal or components 
directories unless you are planning on submitting a patch
However if you develop your own component, such as the Portal's 
NavigationState Component or Aggregator Component for example, then
you can extend the existing Jetspeed component if necessary, and 
develop your own component and assemble it in the jetspeed-spring.xml
You can also assemble pipelines of request execution in the 
pipelines.xml, also based on Spring components

How would Jetspeed2 find my custom component classes/jars, (i.e. where 
should these be installed)? I generally understand the configuration 
being done in jetspeed-spring.xml and pipelines.xml. Would I edit 
these configuration files in the deployed jetspeed/WEB-INF/assembly 
directly?

To create your own portal layout on a page, you will still need to 
manually edit the PSML until our customizer is ready
We have made some progress in the customizer recently, but its still 
not quite there

Right. Editing PSML is certainly not a big deal. I suppose adding and 
deleting pages falls into the same category. However, I am still 
hesitant to modify the deployed jetspeed webapp... is that the 
intended development strategy? Obviously, there are numerous jetspeed 
configuration and content files that one might wish to 
edit/delete/create. I am trying to understand how to approach making 
these changes in the jetspeed2 environment for a formal production 
portal/development process, (despite the fact that jetspeed2 is just 
entering first alpha). Basically, if I am going to write a tutorial 
for the Wiki, I'd like to get it "right" from the start!

Thanks,
Randy Watler
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
***
*   Scott T. Weaver   *
* <[EMAIL PROTECTED]> *
* *
* --  *
*   Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container  *
* *
* OpenEditPro, Website Content Management *
* *
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JetSpeed2 Development Logistics

2004-08-12 Thread Bo van Weert 

Acuse de recibo
   
SuRE: JetSpeed2 Development Logistics  
document   
o: 
   
Ha sido   Boudewijn van Weert/srvNotes 
recibido   
por:   
   
Con   12/08/2004 10.14.45  
fecha: 
   





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JetSpeed2 Development Logistics

2004-08-11 Thread Randy Watler 
Phillip,
Yes, we too are interested in role based PSML configuration, (right?). I 
am glad to see there is general interest in helping the jetspeed2 team 
develop a tutorial and look forward to any and all input. At this point, 
I am trying to lay the foundation for a tutorial by establishing the 
"best" practices for customizing the base build/install. Once there, I 
think I will move immediately on to layout/decoration/page/security 
configuration based on the things I need to do while prototyping our 
Portal. After I get the base content in place and look and feel off the 
ground, I was going to address portlet development/deployment.

I too would like to see more focus on jetspeed2 configuration than was 
developed for jetspeed1.5. However, even our modest portal project will 
require some portlet development! I would guess that a Wiki based 
FAQ/Tutorial that can be contributed to over time will eventually find 
the balanced coverage we all need.

Thanks for the encouragement,
Randy Watler
Philip Saville wrote:
Hi Randy,
If you're thinking of offering input for the Tutorial for Jetspeed 2, I
would like to offer a few comments about the Jetspeed 1.5 tutorial I
hope can be improved.
I found the first few chapters of the original tutorial very helpful in
configuring and customizing the look and feel of the portal. The primary
focus of the tutorial, however, seemed to be about developing portlets,
although it is an excellent way to customize ones portal, the tutorial
did not really explain enough detail about PSML.
My goal is to have a portal based solely on roles. Imagine a portal
designed for hundreds of users where the administration of the content
is managed by a small team, roles are the only sensible solution. Once I
have figured out exactly how I can accomplish this, I would be very
willing to help/ contribute towards a tutorial or publication about the
Jetspeed 2.
Thanks and best regards,
Philip
-Original Message-
From: Randy Watler [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 11, 2004 6:01 PM
To: Jetspeed Users List
Subject: JetSpeed2 Development Logistics

David,
You wrote:
 

Our goal is to make all resources deployable:
- layouts
- decorators
- portlet applications
If you develop a portlet application, simply drop it into the auto 
deploy directory

   

Got it. It appears that decorators/layouts can be similarly dropped into
the jetspeed/WEB-INF/deploy directory, no?
 

You are right, you should not edit the portal or components directories
   

 

unless you are planning on submitting a patch
However if you develop your own component, such as the Portal's 
NavigationState Component or Aggregator Component for example, then
you can extend the existing Jetspeed component if necessary, and 
develop your own component and assemble it in the jetspeed-spring.xml
You can also assemble pipelines of request execution in the 
pipelines.xml, also based on Spring components

   

How would Jetspeed2 find my custom component classes/jars, (i.e. where 
should these be installed)? I generally understand the configuration 
being done in jetspeed-spring.xml and pipelines.xml. Would I edit these 
configuration files in the deployed jetspeed/WEB-INF/assembly directly?

 

To create your own portal layout on a page, you will still need to 
manually edit the PSML until our customizer is ready
We have made some progress in the customizer recently, but its still 
not quite there

   

Right. Editing PSML is certainly not a big deal. I suppose adding and 
deleting pages falls into the same category. However, I am still 
hesitant to modify the deployed jetspeed webapp... is that the intended 
development strategy? Obviously, there are numerous jetspeed 
configuration and content files that one might wish to 
edit/delete/create. I am trying to understand how to approach making 
these changes in the jetspeed2 environment for a formal production 
portal/development process, (despite the fact that jetspeed2 is just 
entering first alpha). Basically, if I am going to write a tutorial for 
the Wiki, I'd like to get it "right" from the start!

Thanks,
Randy Watler
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JetSpeed2 Development Logistics

2004-08-11 Thread Philip Saville 
Hi Randy,

If you're thinking of offering input for the Tutorial for Jetspeed 2, I
would like to offer a few comments about the Jetspeed 1.5 tutorial I
hope can be improved.

I found the first few chapters of the original tutorial very helpful in
configuring and customizing the look and feel of the portal. The primary
focus of the tutorial, however, seemed to be about developing portlets,
although it is an excellent way to customize ones portal, the tutorial
did not really explain enough detail about PSML.

My goal is to have a portal based solely on roles. Imagine a portal
designed for hundreds of users where the administration of the content
is managed by a small team, roles are the only sensible solution. Once I
have figured out exactly how I can accomplish this, I would be very
willing to help/ contribute towards a tutorial or publication about the
Jetspeed 2.

Thanks and best regards,
Philip

-Original Message-
From: Randy Watler [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 11, 2004 6:01 PM
To: Jetspeed Users List
Subject: JetSpeed2 Development Logistics

David,

You wrote:

>Our goal is to make all resources deployable:
>
>- layouts
>- decorators
>- portlet applications
>
>If you develop a portlet application, simply drop it into the auto 
>deploy directory
>
Got it. It appears that decorators/layouts can be similarly dropped into

the jetspeed/WEB-INF/deploy directory, no?

>You are right, you should not edit the portal or components directories

>unless you are planning on submitting a patch
>However if you develop your own component, such as the Portal's 
>NavigationState Component or Aggregator Component for example, then
>you can extend the existing Jetspeed component if necessary, and 
>develop your own component and assemble it in the jetspeed-spring.xml
>You can also assemble pipelines of request execution in the 
>pipelines.xml, also based on Spring components
>
How would Jetspeed2 find my custom component classes/jars, (i.e. where 
should these be installed)? I generally understand the configuration 
being done in jetspeed-spring.xml and pipelines.xml. Would I edit these 
configuration files in the deployed jetspeed/WEB-INF/assembly directly?

>To create your own portal layout on a page, you will still need to 
>manually edit the PSML until our customizer is ready
>  We have made some progress in the customizer recently, but its still 
>not quite there
>
Right. Editing PSML is certainly not a big deal. I suppose adding and 
deleting pages falls into the same category. However, I am still 
hesitant to modify the deployed jetspeed webapp... is that the intended 
development strategy? Obviously, there are numerous jetspeed 
configuration and content files that one might wish to 
edit/delete/create. I am trying to understand how to approach making 
these changes in the jetspeed2 environment for a formal production 
portal/development process, (despite the fact that jetspeed2 is just 
entering first alpha). Basically, if I am going to write a tutorial for 
the Wiki, I'd like to get it "right" from the start!

Thanks,

Randy Watler


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JetSpeed2 Development Logistics

2004-08-11 Thread Randy Watler 
David,
You wrote:
Our goal is to make all resources deployable:
- layouts
- decorators
- portlet applications
If you develop a portlet application, simply drop it into the auto 
deploy directory

Got it. It appears that decorators/layouts can be similarly dropped into 
the jetspeed/WEB-INF/deploy directory, no?

You are right, you should not edit the portal or components directories 
unless you are planning on submitting a patch
However if you develop your own component, such as the Portal's 
NavigationState Component or Aggregator Component for example, then
you can extend the existing Jetspeed component if necessary, and 
develop your own component and assemble it in the jetspeed-spring.xml
You can also assemble pipelines of request execution in the 
pipelines.xml, also based on Spring components

How would Jetspeed2 find my custom component classes/jars, (i.e. where 
should these be installed)? I generally understand the configuration 
being done in jetspeed-spring.xml and pipelines.xml. Would I edit these 
configuration files in the deployed jetspeed/WEB-INF/assembly directly?

To create your own portal layout on a page, you will still need to 
manually edit the PSML until our customizer is ready
 We have made some progress in the customizer recently, but its still 
not quite there

Right. Editing PSML is certainly not a big deal. I suppose adding and 
deleting pages falls into the same category. However, I am still 
hesitant to modify the deployed jetspeed webapp... is that the intended 
development strategy? Obviously, there are numerous jetspeed 
configuration and content files that one might wish to 
edit/delete/create. I am trying to understand how to approach making 
these changes in the jetspeed2 environment for a formal production 
portal/development process, (despite the fact that jetspeed2 is just 
entering first alpha). Basically, if I am going to write a tutorial for 
the Wiki, I'd like to get it "right" from the start!

Thanks,
Randy Watler
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]