RE: Database registry implementation status

[Kristofer Eriksson]

David,

Yes, it's a tag, not a branch, sorry

Actually what I meant with implement the Hybrid Registry Service alone was
to build just that service (implementation) and configure Jetspeed to use
it.

Anyway, I will now build the lot, and use the instructions to configure it
properly.

Thanks


Kristofer Eriksson

-Original Message-
From: David Sean Taylor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 11, 2004 11:52 PM
To: Jetspeed Users List
Subject: Re: Database registry implementation status


On Aug 11, 2004, at 1:24 AM, Kristofer Eriksson wrote:

> David,
>
> Thanks for the quick answer. For me that sounds really interesting so  
> if I
> want to be able to use this, and I "cant" wait for the 1.6 release,  
> what is
> the best to do, try to implement the Hybrid Registry Service alone or  
> check
> out the JS1-6-2004-07-23-spring-start branch and use it? How much
> implications would that have any implications on the stability in  
> general?
>
Its not a branch, just a tag
Not necessary to use that
Just go straight to the CVS head for now as that is most stable  
regarding this feature
When you say implement the Hybrid Registry Service, I assume you mean  
implement the remaining registries (skins, controls, controllers.  
mediatypes)?

> And would it be possible to share with us how to configure the Hybrid
> Registry Service? What config files needs to be changed and/or added?
>
Look at the JetspeedResources.properties


Instructions for Building Jetspeed with DB Registry


1. Checkout from the CVS head

2. Set these properties in your $HOME/build.properties:

database = YOUR DATABASE (oracle|mysql) etc

Here is for MS SQL for example

# MS SQL
torque.database.url =
jdbc:microsoft:sqlserver://localhost:1433;databaseName=jetspeed
torque.database.driver =torque.database.url =
com.microsoft.jdbc.sqlserver.SQLServerDriver
torque.database.user = jetspeed
torque.database.password = *
org.apache.jetspeed.test.jdbc.j1.drivers.path=${HOME}/bluesunrise/ 
apache/jdbc/
msbase.jar
org.apache.jetspeed.test.jdbc.j1.drivers.path2=${HOME}/bluesunrise/ 
apache/
jdbc/msutil.jar
org.apache.jetspeed.test.jdbc.j1.drivers.path3=${HOME}/bluesunrise/ 
apache/
jdbc/mssqlserver.jar

3. Update the Torque properties in WEB-INF/conf

torque.database.default.adapter=mssql
torque.dsfactory.default.connection.driver =
com.microsoft.jdbc.sqlserver.SQLServerDriver
torque.dsfactory.default.connection.url =
jdbc:microsoft:sqlserver://localhost:1433;databaseName=jetspeed
torque.dsfactory.default.connection.user =  jetspeed
torque.dsfactory.default.connection.password = *

4. Build Jetspeed

maven -Dmaven.test.skip=true clean war

4b.

maven torque:sql

This will generate the new SQL script:

target/classes/sql/registry-schema.sql

Run this script using isql.exe or another tool

5. Change over to Registry DB, edit JetspeedResources.properties:

# uncomment these lines
services.Registry.database.default.Security=DATABASE
services.Registry.database.default.Portlet=DATABASE

# choose the Hybrid Service
#
#  
services.Registry.classname=org.apache.jetspeed.services.registry.Castor
RegistryService
services.Registry.classname=org.apache.jetspeed.services.registry.Hybrid
RegistryService

6. Run the importer

maven -o registry-import

7. after successful import, delete the old registry files

admin.xreg
demo-portlets.xreg
email.xreg
fusion.xreg
portlets.xreg
security.xreg
wml-examples.xreg

8. Deploy

maven deploy


-
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

[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: Nested Tab or Menu Layouts

[Raphaël Luta]

Randy Dillon wrote:
I have a portal with tabbed panes and when I put all my portlets on their own panes, 
it all works fine.  When I try to combine portlet functionality by creating a tab or
> menu layout on the pane of one of the outer tab, such that 3 of the original
> portlets  are nested under one of the outer tabs, it seems to work until I 
navigate to
> another outer tab and then come back to the outer tab that contains the
> nested menus (or tabs).  At that point, regardless of which portlet's 
menu/tab is
> selected, the browser displays the exception shown below. The nested menus/tabs
> and the active portlet display properly under the exception stack trace.
> Can anyone help me fix this?
Error encountered processing a template: /navigations//html/top_loggedIn.jsp
> org.apache.jasper.JasperException
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:254)
> 
What you describe does not make a lot of sense to me, especially since the 
exception you is related to the top navigation.
Can you try the following things:
- try switching to Velocity as default and report if you experience the same issues
- try commenting out the page select box in /navigations/html/top_loggedIn.jsp 
and see if this fix your issue.

--
Raphael Luta - [EMAIL PROTECTED]
Apache Jetspeed - Enterprise Portal in Java
http://portals.apache.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Database registry implementation status

[Kristofer Eriksson]

Hi again David,

Building Jetspeed with DB Registry works fine but what I don't get to work
is the registry import. When I run maven I get the error

[java] org.apache.jetspeed.om.registry.RegistryException: Exception Fetching
Extent for Portlet org.apache.torque.TorqueException: java.sql.SQLException:
No suitable driver

Not being the maven expert, I assume I have not configured the db settings
correct, or in the correct place. Any ideas?

Regards

Kristofer Eriksson

-Original Message-
From: David Sean Taylor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 11, 2004 11:52 PM
To: Jetspeed Users List
Subject: Re: Database registry implementation status


On Aug 11, 2004, at 1:24 AM, Kristofer Eriksson wrote:

> David,
>
> Thanks for the quick answer. For me that sounds really interesting so  
> if I
> want to be able to use this, and I "cant" wait for the 1.6 release,  
> what is
> the best to do, try to implement the Hybrid Registry Service alone or  
> check
> out the JS1-6-2004-07-23-spring-start branch and use it? How much
> implications would that have any implications on the stability in  
> general?
>
Its not a branch, just a tag
Not necessary to use that
Just go straight to the CVS head for now as that is most stable  
regarding this feature
When you say implement the Hybrid Registry Service, I assume you mean  
implement the remaining registries (skins, controls, controllers.  
mediatypes)?

> And would it be possible to share with us how to configure the Hybrid
> Registry Service? What config files needs to be changed and/or added?
>
Look at the JetspeedResources.properties


Instructions for Building Jetspeed with DB Registry


1. Checkout from the CVS head

2. Set these properties in your $HOME/build.properties:

database = YOUR DATABASE (oracle|mysql) etc

Here is for MS SQL for example

# MS SQL
torque.database.url =
jdbc:microsoft:sqlserver://localhost:1433;databaseName=jetspeed
torque.database.driver =torque.database.url =
com.microsoft.jdbc.sqlserver.SQLServerDriver
torque.database.user = jetspeed
torque.database.password = *
org.apache.jetspeed.test.jdbc.j1.drivers.path=${HOME}/bluesunrise/ 
apache/jdbc/
msbase.jar
org.apache.jetspeed.test.jdbc.j1.drivers.path2=${HOME}/bluesunrise/ 
apache/
jdbc/msutil.jar
org.apache.jetspeed.test.jdbc.j1.drivers.path3=${HOME}/bluesunrise/ 
apache/
jdbc/mssqlserver.jar

3. Update the Torque properties in WEB-INF/conf

torque.database.default.adapter=mssql
torque.dsfactory.default.connection.driver =
com.microsoft.jdbc.sqlserver.SQLServerDriver
torque.dsfactory.default.connection.url =
jdbc:microsoft:sqlserver://localhost:1433;databaseName=jetspeed
torque.dsfactory.default.connection.user =  jetspeed
torque.dsfactory.default.connection.password = *

4. Build Jetspeed

maven -Dmaven.test.skip=true clean war

4b.

maven torque:sql

This will generate the new SQL script:

target/classes/sql/registry-schema.sql

Run this script using isql.exe or another tool

5. Change over to Registry DB, edit JetspeedResources.properties:

# uncomment these lines
services.Registry.database.default.Security=DATABASE
services.Registry.database.default.Portlet=DATABASE

# choose the Hybrid Service
#
#  
services.Registry.classname=org.apache.jetspeed.services.registry.Castor
RegistryService
services.Registry.classname=org.apache.jetspeed.services.registry.Hybrid
RegistryService

6. Run the importer

maven -o registry-import

7. after successful import, delete the old registry files

admin.xreg
demo-portlets.xreg
email.xreg
fusion.xreg
portlets.xreg
security.xreg
wml-examples.xreg

8. Deploy

maven deploy


-
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

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

v1.5 Build Prob

[Tod Thomas]

I'm trying to build jetspeed v1.5 using maven and am receiving the
following error:

The build cannot continue because of the following unsatisfied
dependencies:

activation-1.0.1.jar
javamail-1.2.jar
jaxp-1.2.jar
jdbc-2.0.jar
jndi-1.2.1.jar
stratum-1.0-b4-dev.jar
uddi4j-1.0.jar
maven-torque-plugin-3.2.jar

How can I satisfy these dependencies?

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

RE: JetSpeed2 Development Logistics

[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   *
* <[EMAIL PROTECTED]> *
* *
* --  *
*   Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container  *
* *
* OpenEditPro, Website Content Management *
* *
***


---

RE: v1.5 Build Prob

[Jeremy Ford]

Most of these jars are available directly from sun.  Please download them 
and place them into your local maven repository.

Jeremy Ford
[EMAIL PROTECTED]

From: Tod Thomas <[EMAIL PROTECTED]>
Reply-To: "Jetspeed Users List" <[EMAIL PROTECTED]>
To: Jetspeed Users List <[EMAIL PROTECTED]>
Subject: v1.5 Build Prob
Date: Thu, 12 Aug 2004 09:50:06 -0400
I'm trying to build jetspeed v1.5 using maven and am receiving the
following error:
The build cannot continue because of the following unsatisfied
dependencies:
activation-1.0.1.jar
javamail-1.2.jar
jaxp-1.2.jar
jdbc-2.0.jar
jndi-1.2.1.jar
stratum-1.0-b4-dev.jar
uddi4j-1.0.jar
maven-torque-plugin-3.2.jar
How can I satisfy these dependencies?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

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

Re: v1.5 Build Prob

[Tod Thomas]

Jeremy Ford wrote:
> 
> Most of these jars are available directly from sun.  Please download them
> and place them into your local maven repository.

No problem.  I thought maybe there were specific versioning requirements
that necessitated letting Maven handle this task.

Thanks.
 
> Jeremy Ford
> [EMAIL PROTECTED]
> 
> >From: Tod Thomas <[EMAIL PROTECTED]>
> >Reply-To: "Jetspeed Users List" <[EMAIL PROTECTED]>
> >To: Jetspeed Users List <[EMAIL PROTECTED]>
> >Subject: v1.5 Build Prob
> >Date: Thu, 12 Aug 2004 09:50:06 -0400
> >
> >I'm trying to build jetspeed v1.5 using maven and am receiving the
> >following error:
> >
> >The build cannot continue because of the following unsatisfied
> >dependencies:
> >
> >activation-1.0.1.jar
> >javamail-1.2.jar
> >jaxp-1.2.jar
> >jdbc-2.0.jar
> >jndi-1.2.1.jar
> >stratum-1.0-b4-dev.jar
> >uddi4j-1.0.jar
> >maven-torque-plugin-3.2.jar
> >
> >How can I satisfy these dependencies?

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

Re: v1.5 Build Prob

[Scott T. Weaver]

Tod Thomas wrote:
Jeremy Ford wrote:
 

Most of these jars are available directly from sun.  Please download them
and place them into your local maven repository.
   

No problem.  I thought maybe there were specific versioning requirements
that necessitated letting Maven handle this task.
 

The true reason is due to the licensing of the Sun jars which prevents 
them from being hosted on ibiblio or Apache.

Thanks.
 

Jeremy Ford
[EMAIL PROTECTED]
   

From: Tod Thomas <[EMAIL PROTECTED]>
Reply-To: "Jetspeed Users List" <[EMAIL PROTECTED]>
To: Jetspeed Users List <[EMAIL PROTECTED]>
Subject: v1.5 Build Prob
Date: Thu, 12 Aug 2004 09:50:06 -0400
I'm trying to build jetspeed v1.5 using maven and am receiving the
following error:
The build cannot continue because of the following unsatisfied
dependencies:
activation-1.0.1.jar
javamail-1.2.jar
jaxp-1.2.jar
jdbc-2.0.jar
jndi-1.2.1.jar
stratum-1.0-b4-dev.jar
uddi4j-1.0.jar
maven-torque-plugin-3.2.jar
How can I satisfy these dependencies?
 

-
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

[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

[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

[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

[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

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