You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bridges-dev@portals.apache.org by Santiago Gala <sg...@apache.org> on 2005/10/18 17:37:30 UTC
PROPOSAL: Further build simplification for Jetspeed
Jetspeed build is too big and unwieldy, mostly because of historical
reasons:
- different technologies and demos have been tried, and the code has
been accumulating in the main build
- we abuse the SNAPSHOT dependency mechanism, and we have not been able
to isolate changes in different artifacts until recently
A partial solution came with the movement of a substantial part of the
code to the bridges repository. Basically, the bridges repository
contains portals code which is independent of jetspeed or pluto, code
which serves to enable portlet development with other servlet frameworks
or even cgi based code.
This simplified the build a lot, but the job is not yet finished.
jetspeed builds several demo/showcase webapps together with the core:
- php-demo, a demo of the php bridge
- perl-demo, a demo of the perl bridge
- struts-demo, a demo of the struts bridge
- jpetstore, another struts application that works as a portlet
- jsf-demo, including small JSF demos
- jsf-demo-myfaces, small JSF demos using myfaces
- demo, assorted small portlets
- rss, two different rss demos
- gems (?)
In addition, there are internal webapps:
- layout-portlets/jetspeed-layout
- security
- palm
- pam
To be honest, the maintenance and handling of dependencies for such a
big set is driving us crazy. We need to do something.
My proposal is as follows:
In a first stage, make people taking care of a given bridge take care of
the associated demos too. They would serve as black-box tests, as well
as enabling quick examples of the bridge use. The only reasonable way to
attain this goal is to move the projects at applications/* to
portals-bridges/, and change the jetspeed build so that it imports, if
any, the .war(s) produced by the bridge. Before (or after) we move the
demos to bridges, some refactoring might be justified, for instance
grouping together the two jsf demo wars, deleting some irrelevant
portlets, grouping, commenting, etc. Also, where the framework is
already supporting reasonably a bridge, we could just use their demos,
and do some social work so that they release and maintain a demo war
that we can simply use for test and demo purpose. Don't forget that,
while the demo portlets started mainly to test and explore the
frameworks, currently their main goal is to serve to people new to
portals to learn by example.
In addition, as we release J2-M4, we could release bridges-0.4, and as
soon as this is done, stop using SNAPSHOT artifacts as dependencies, and
have jetspeed-2 and the different bridges release independently. I.E.,
the struts bridge and jsf bridge release cycles would be fully
independent, starting their releases with the 0.4 release. Bugs and
updates to the bridges code would bring new releases of just the
involved artifacts, not pulling a big release of J2 or bridges as a
whole.
For this to be workable in the short term, if would be handy to have a
way for the involved bridges demo to deliver PSML pages showing the
portlets demoed. While this is not portable as of JSR-168, the PSML
format is simple enough to be used as a mean to understand what is
intended for demo in a war file. As already commented, we could just use
pages in /WEB-INF/pages in the war, and the deployer *could* take care
of creating them in the portal, or else the build process could take
them from there to construct the demo portal.
In following steps, we could try to have a repository where complex
webapps could be maintained, starting with the admin portlets themselves
(security, pam, palm)
Also, to clean, document and make sure that demo portlets are actually
showcasing core portlet-api and jetspeed features, and that they serve
this purpose with minimal fuss.
I'd recommend starting with the easy steps: moving php, perl,
struts-demo, jpetstore, jsf-demo, and jsf-demo-myfaces to places under
portals-bridges/ In a first go, the psml pages using those portlets
would remain in jetspeed/src/webapp/WEB-INF/pages
I had the idea to move the wars to bridges/<framework>/src/webapp ...,
but it would possibly be better something like
bridges/<framework>/<framework>-demo instead. This can be done with a
simple server side move, but the project.xml /properties would need some
adjustment, both for jetspeed to depend and take the war artifacts in
the "full" goals, and for bridges to build them.
What do you think?
Santiago
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
Re: PROPOSAL: Further build simplification for Jetspeed
Posted by David Sean Taylor <da...@bluesunrise.com>.
Santiago Gala wrote:
> El mié, 19-10-2005 a las 13:43 +0200, Ate Douma escribió:
>
>>David Sean Taylor wrote:
>>
>>>Santiago Gala wrote:
>>>
>>>
>>>>In following steps, we could try to have a repository where complex
>>>>webapps could be maintained, starting with the admin portlets
>>
>>themselves
>>
>>>>(security, pam, palm)
>>>>
>>>
>>>When you say repository, you mean a remote maven repo?
>>
>>It is not clear to me either what Santiago meant by this, but I
>>definitely would
>>like to see us going to use the apache maven repo at
>>http:/cvs.apache.org/repository
>>for the -SNAPSHOT and/or -dev builds and the ibiblio repo for
>>Milestone, RC and FINAL
>>releases for both bridges and J2 itself.
>
>
> I was meaning either the local maven repositoy (if you are developing a
> war and build it) or a remote repository for the builds that include
> them.
>
> Basically a war will be a build artifact produced in the Apache Portals
> project, which can be released as such. README, LICENSE and NOTICE files
> can be inside WEB-INF, and docs can be served as static content.
>
> Binary releases can bundle wars or not, depending on what we want to
> release. My only concerns is that PSML pages are in synchrony with the
> actual portlets they reference.
>
Santiago, do we need a vote on this?
If so, cross posting is confusing me as to what list to vote on.
Maybe it requires voting on both lists since its a cross project move.
I'd like to formally agree with your proposal on moving all the portlet
applications to their respective bridges projects, and additionally
combining the security, pam and palm applications into one
jetspeed-admin.war. The demo app is pretty much testing stuff, not sure
if there's much useful there anyway.
The initial first-time startup time for the application server, is a bad
user experience. We could consider bundling all the common stuff across
Jetspeed's distribution in the shared/lib. This will take some testing
as we have had class loader issues before with this approach.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: PROPOSAL: Further build simplification for Jetspeed
Posted by David Sean Taylor <da...@bluesunrise.com>.
Santiago Gala wrote:
> El mié, 19-10-2005 a las 13:43 +0200, Ate Douma escribió:
>
>>David Sean Taylor wrote:
>>
>>>Santiago Gala wrote:
>>>
>>>
>>>>In following steps, we could try to have a repository where complex
>>>>webapps could be maintained, starting with the admin portlets
>>
>>themselves
>>
>>>>(security, pam, palm)
>>>>
>>>
>>>When you say repository, you mean a remote maven repo?
>>
>>It is not clear to me either what Santiago meant by this, but I
>>definitely would
>>like to see us going to use the apache maven repo at
>>http:/cvs.apache.org/repository
>>for the -SNAPSHOT and/or -dev builds and the ibiblio repo for
>>Milestone, RC and FINAL
>>releases for both bridges and J2 itself.
>
>
> I was meaning either the local maven repositoy (if you are developing a
> war and build it) or a remote repository for the builds that include
> them.
>
> Basically a war will be a build artifact produced in the Apache Portals
> project, which can be released as such. README, LICENSE and NOTICE files
> can be inside WEB-INF, and docs can be served as static content.
>
> Binary releases can bundle wars or not, depending on what we want to
> release. My only concerns is that PSML pages are in synchrony with the
> actual portlets they reference.
>
Santiago, do we need a vote on this?
If so, cross posting is confusing me as to what list to vote on.
Maybe it requires voting on both lists since its a cross project move.
I'd like to formally agree with your proposal on moving all the portlet
applications to their respective bridges projects, and additionally
combining the security, pam and palm applications into one
jetspeed-admin.war. The demo app is pretty much testing stuff, not sure
if there's much useful there anyway.
The initial first-time startup time for the application server, is a bad
user experience. We could consider bundling all the common stuff across
Jetspeed's distribution in the shared/lib. This will take some testing
as we have had class loader issues before with this approach.
--
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: PROPOSAL: Further build simplification for Jetspeed
Posted by Santiago Gala <sg...@apache.org>.
El mié, 19-10-2005 a las 13:43 +0200, Ate Douma escribió:
> David Sean Taylor wrote:
> > Santiago Gala wrote:
> >
> >> In following steps, we could try to have a repository where complex
> >> webapps could be maintained, starting with the admin portlets
> themselves
> >> (security, pam, palm)
> >>
> > When you say repository, you mean a remote maven repo?
> It is not clear to me either what Santiago meant by this, but I
> definitely would
> like to see us going to use the apache maven repo at
> http:/cvs.apache.org/repository
> for the -SNAPSHOT and/or -dev builds and the ibiblio repo for
> Milestone, RC and FINAL
> releases for both bridges and J2 itself.
I was meaning either the local maven repositoy (if you are developing a
war and build it) or a remote repository for the builds that include
them.
Basically a war will be a build artifact produced in the Apache Portals
project, which can be released as such. README, LICENSE and NOTICE files
can be inside WEB-INF, and docs can be served as static content.
Binary releases can bundle wars or not, depending on what we want to
release. My only concerns is that PSML pages are in synchrony with the
actual portlets they reference.
(...)
Regards
Santiago
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
Re: PROPOSAL: Further build simplification for Jetspeed
Posted by Santiago Gala <sg...@apache.org>.
El mié, 19-10-2005 a las 13:43 +0200, Ate Douma escribió:
> David Sean Taylor wrote:
> > Santiago Gala wrote:
> >
> >> In following steps, we could try to have a repository where complex
> >> webapps could be maintained, starting with the admin portlets
> themselves
> >> (security, pam, palm)
> >>
> > When you say repository, you mean a remote maven repo?
> It is not clear to me either what Santiago meant by this, but I
> definitely would
> like to see us going to use the apache maven repo at
> http:/cvs.apache.org/repository
> for the -SNAPSHOT and/or -dev builds and the ibiblio repo for
> Milestone, RC and FINAL
> releases for both bridges and J2 itself.
I was meaning either the local maven repositoy (if you are developing a
war and build it) or a remote repository for the builds that include
them.
Basically a war will be a build artifact produced in the Apache Portals
project, which can be released as such. README, LICENSE and NOTICE files
can be inside WEB-INF, and docs can be served as static content.
Binary releases can bundle wars or not, depending on what we want to
release. My only concerns is that PSML pages are in synchrony with the
actual portlets they reference.
(...)
Regards
Santiago
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
RE: PROPOSAL: Further build simplification for Jetspeed
Posted by Scott T Weaver <sc...@binary-designs.net>.
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Wednesday, October 19, 2005 7:44 AM
> To: Jetspeed Developers List
> Cc: bridges-dev@portals.apache.org
> Subject: Re: PROPOSAL: Further build simplification for Jetspeed
...
> like to see us going to use the apache maven repo at
> http:/cvs.apache.org/repository
> for the -SNAPSHOT and/or -dev builds and the ibiblio repo for Milestone,
> RC and FINAL
> releases for both bridges and J2 itself.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: PROPOSAL: Further build simplification for Jetspeed
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
> Santiago Gala wrote:
>
>> In following steps, we could try to have a repository where complex
>> webapps could be maintained, starting with the admin portlets themselves
>> (security, pam, palm)
>>
> When you say repository, you mean a remote maven repo?
It is not clear to me either what Santiago meant by this, but I definitely would
like to see us going to use the apache maven repo at http:/cvs.apache.org/repository
for the -SNAPSHOT and/or -dev builds and the ibiblio repo for Milestone, RC and FINAL
releases for both bridges and J2 itself.
Pluto is already doing this and I think we should use one standard solution
for all of portals.
And then all committers can update/release new artifacts when needed, especially
to the apache repo like when the maven plugin is updated.
The Bluesunrise repo as generously provided by David has been very valuable, and
I'd expect it to remain so for things like patched or non-ACL supported artifacts,
but providing our main artifacts through the apache and ibiblio repositories will
lessen the burden on David to constantly update his and also the load on his server.
With the new way of building a portal using the maven plugin, downloading of the
artifacts from the remote repositories will increase (a lot) more and more.
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: PROPOSAL: Further build simplification for Jetspeed
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
> Santiago Gala wrote:
>
>> In following steps, we could try to have a repository where complex
>> webapps could be maintained, starting with the admin portlets themselves
>> (security, pam, palm)
>>
> When you say repository, you mean a remote maven repo?
It is not clear to me either what Santiago meant by this, but I definitely would
like to see us going to use the apache maven repo at http:/cvs.apache.org/repository
for the -SNAPSHOT and/or -dev builds and the ibiblio repo for Milestone, RC and FINAL
releases for both bridges and J2 itself.
Pluto is already doing this and I think we should use one standard solution
for all of portals.
And then all committers can update/release new artifacts when needed, especially
to the apache repo like when the maven plugin is updated.
The Bluesunrise repo as generously provided by David has been very valuable, and
I'd expect it to remain so for things like patched or non-ACL supported artifacts,
but providing our main artifacts through the apache and ibiblio repositories will
lessen the burden on David to constantly update his and also the load on his server.
With the new way of building a portal using the maven plugin, downloading of the
artifacts from the remote repositories will increase (a lot) more and more.
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: PROPOSAL: Further build simplification for Jetspeed
Posted by David Sean Taylor <da...@bluesunrise.com>.
Santiago Gala wrote:
> To be honest, the maintenance and handling of dependencies for such a
> big set is driving us crazy. We need to do something.
>
So its not just me?
Glad to hear that :)
>
> For this to be workable in the short term, if would be handy to have a
> way for the involved bridges demo to deliver PSML pages showing the
> portlets demoed. While this is not portable as of JSR-168, the PSML
> format is simple enough to be used as a mean to understand what is
> intended for demo in a war file. As already commented, we could just use
> pages in /WEB-INF/pages in the war, and the deployer *could* take care
> of creating them in the portal, or else the build process could take
> them from there to construct the demo portal.
I like this. Or maybe it would be as simple as dropping in psml files
into the WEB-INF/deploy directory. I think either way will work
With the new DB PSML manager (in developmental stages), we plan to
support PSML 'drop in' via the deploy directory that will then import
the PSML XML file into the database.
>
> In following steps, we could try to have a repository where complex
> webapps could be maintained, starting with the admin portlets themselves
> (security, pam, palm)
>
When you say repository, you mean a remote maven repo?
> Also, to clean, document and make sure that demo portlets are actually
> showcasing core portlet-api and jetspeed features, and that they serve
> this purpose with minimal fuss.
>
> I'd recommend starting with the easy steps: moving php, perl,
> struts-demo, jpetstore, jsf-demo, and jsf-demo-myfaces to places under
> portals-bridges/ In a first go, the psml pages using those portlets
> would remain in jetspeed/src/webapp/WEB-INF/pages
+1
>
> I had the idea to move the wars to bridges/<framework>/src/webapp ...,
> but it would possibly be better something like
> bridges/<framework>/<framework>-demo instead. This can be done with a
> simple server side move, but the project.xml /properties would need some
> adjustment, both for jetspeed to depend and take the war artifacts in
> the "full" goals, and for bridges to build them.
>
> What do you think?
>
>
> Santiago
The demo code could be stored in bridges/<framework>/<framework-demo>,
or if the application is useful enough, and is NOT just a demo, I prefer
storing useful applications at Portals Applications, such as the RSS
portlets for example are not really demos but more ready-to-use portlets.
The internal PAs (security, palm, pam) should remain in Jetspeed-2 svn.
However I recommend merging them all into one war, such as "jetspeed-admin"
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: PROPOSAL: Further build simplification for Jetspeed
Posted by David Sean Taylor <da...@bluesunrise.com>.
Santiago Gala wrote:
> To be honest, the maintenance and handling of dependencies for such a
> big set is driving us crazy. We need to do something.
>
So its not just me?
Glad to hear that :)
>
> For this to be workable in the short term, if would be handy to have a
> way for the involved bridges demo to deliver PSML pages showing the
> portlets demoed. While this is not portable as of JSR-168, the PSML
> format is simple enough to be used as a mean to understand what is
> intended for demo in a war file. As already commented, we could just use
> pages in /WEB-INF/pages in the war, and the deployer *could* take care
> of creating them in the portal, or else the build process could take
> them from there to construct the demo portal.
I like this. Or maybe it would be as simple as dropping in psml files
into the WEB-INF/deploy directory. I think either way will work
With the new DB PSML manager (in developmental stages), we plan to
support PSML 'drop in' via the deploy directory that will then import
the PSML XML file into the database.
>
> In following steps, we could try to have a repository where complex
> webapps could be maintained, starting with the admin portlets themselves
> (security, pam, palm)
>
When you say repository, you mean a remote maven repo?
> Also, to clean, document and make sure that demo portlets are actually
> showcasing core portlet-api and jetspeed features, and that they serve
> this purpose with minimal fuss.
>
> I'd recommend starting with the easy steps: moving php, perl,
> struts-demo, jpetstore, jsf-demo, and jsf-demo-myfaces to places under
> portals-bridges/ In a first go, the psml pages using those portlets
> would remain in jetspeed/src/webapp/WEB-INF/pages
+1
>
> I had the idea to move the wars to bridges/<framework>/src/webapp ...,
> but it would possibly be better something like
> bridges/<framework>/<framework>-demo instead. This can be done with a
> simple server side move, but the project.xml /properties would need some
> adjustment, both for jetspeed to depend and take the war artifacts in
> the "full" goals, and for bridges to build them.
>
> What do you think?
>
>
> Santiago
The demo code could be stored in bridges/<framework>/<framework-demo>,
or if the application is useful enough, and is NOT just a demo, I prefer
storing useful applications at Portals Applications, such as the RSS
portlets for example are not really demos but more ready-to-use portlets.
The internal PAs (security, palm, pam) should remain in Jetspeed-2 svn.
However I recommend merging them all into one war, such as "jetspeed-admin"
--
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: PROPOSAL: Further build simplification for Jetspeed
Posted by Scott T Weaver <sc...@binary-designs.net>.
David,
The installer is a couple weeks old and kinda big. Do you have some place I
can upload it to, like an FTP server? Also, I don't currently have the
selection screen for the DB in place, so it always uses MySQL, this is very
easy to add. I just didn't have the time to invest in it.
-Scott
> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Tuesday, October 18, 2005 3:00 PM
> To: Jetspeed Developers List
> Subject: Re: PROPOSAL: Further build simplification for Jetspeed
>
> Scott T Weaver wrote:
> > I would also like to add that we start making nightly builds available.
> I
> > also would like to see weekly/-bi-weekly binary installer builds. I
>
> +1 on a automated builds
>
> > recently put together a Jetspeed installer using AntInstaller,
> > http://antinstaller.sourceforge.net/, which uses a standard ant build
> script
> > coupled with a very simple page-defining xml to generate a very nice
> > executable jar installer. The installer contains both Tomcat and
> Jetspeed.
>
> Sounds good.
> Can you create a demo we can look at?
>
> > The installer does everything from grabbing the correct JDBC driver off
> of
> > the local file system all the way to initializing the user's DB of
> choice.
>
> wow, sounds impressive.
>
> > In fact, now I have all my developers just use this instead of wasting
> their
> > time with the overly complicated build we have now.
>
> I am supporting quite a few developers over several projects.
> Lets just say that our build is killing me.
> Its partially Maven issues, but I really think we can simplify the build
> also.
>
> >
> > Also, IMO, the move to SVN has complicated things greatly in that no one
> > outside of the open source community (read companies) uses SVN and
> having to
> > make developers be concerned with both Maven AND SVN, well let's just
> say I
> > have been cussed at a lot and one developer seriously almost cried after
> > fighting with it for 2 days.
> >
>
> I know. Believe me I've seen it.
> People can't get Jetspeed-2 to build. Its too difficult.
> Hell, there are days when the plugin cache nails me to the cross :)
>
>
> --
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: PROPOSAL: Further build simplification for Jetspeed
Posted by David Sean Taylor <da...@bluesunrise.com>.
Scott T Weaver wrote:
> I would also like to add that we start making nightly builds available. I
> also would like to see weekly/-bi-weekly binary installer builds. I
+1 on a automated builds
> recently put together a Jetspeed installer using AntInstaller,
> http://antinstaller.sourceforge.net/, which uses a standard ant build script
> coupled with a very simple page-defining xml to generate a very nice
> executable jar installer. The installer contains both Tomcat and Jetspeed.
Sounds good.
Can you create a demo we can look at?
> The installer does everything from grabbing the correct JDBC driver off of
> the local file system all the way to initializing the user's DB of choice.
wow, sounds impressive.
> In fact, now I have all my developers just use this instead of wasting their
> time with the overly complicated build we have now.
I am supporting quite a few developers over several projects.
Lets just say that our build is killing me.
Its partially Maven issues, but I really think we can simplify the build
also.
>
> Also, IMO, the move to SVN has complicated things greatly in that no one
> outside of the open source community (read companies) uses SVN and having to
> make developers be concerned with both Maven AND SVN, well let's just say I
> have been cussed at a lot and one developer seriously almost cried after
> fighting with it for 2 days.
>
I know. Believe me I've seen it.
People can't get Jetspeed-2 to build. Its too difficult.
Hell, there are days when the plugin cache nails me to the cross :)
--
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: PROPOSAL: Further build simplification for Jetspeed
Posted by Scott T Weaver <sc...@binary-designs.net>.
I would also like to add that we start making nightly builds available. I
also would like to see weekly/-bi-weekly binary installer builds. I
recently put together a Jetspeed installer using AntInstaller,
http://antinstaller.sourceforge.net/, which uses a standard ant build script
coupled with a very simple page-defining xml to generate a very nice
executable jar installer. The installer contains both Tomcat and Jetspeed.
The installer does everything from grabbing the correct JDBC driver off of
the local file system all the way to initializing the user's DB of choice.
In fact, now I have all my developers just use this instead of wasting their
time with the overly complicated build we have now.
Also, IMO, the move to SVN has complicated things greatly in that no one
outside of the open source community (read companies) uses SVN and having to
make developers be concerned with both Maven AND SVN, well let's just say I
have been cussed at a lot and one developer seriously almost cried after
fighting with it for 2 days.
Regards,
-Scott
> -----Original Message-----
> From: Santiago Gala [mailto:sgala@apache.org]
> Sent: Tuesday, October 18, 2005 11:38 AM
> To: jetspeed-dev; bridges-dev@portals.apache.org
> Subject: PROPOSAL: Further build simplification for Jetspeed
>
> Jetspeed build is too big and unwieldy, mostly because of historical
> reasons:
>
> - different technologies and demos have been tried, and the code has
> been accumulating in the main build
> - we abuse the SNAPSHOT dependency mechanism, and we have not been able
> to isolate changes in different artifacts until recently
>
> A partial solution came with the movement of a substantial part of the
> code to the bridges repository. Basically, the bridges repository
> contains portals code which is independent of jetspeed or pluto, code
> which serves to enable portlet development with other servlet frameworks
> or even cgi based code.
>
> This simplified the build a lot, but the job is not yet finished.
> jetspeed builds several demo/showcase webapps together with the core:
> - php-demo, a demo of the php bridge
> - perl-demo, a demo of the perl bridge
> - struts-demo, a demo of the struts bridge
> - jpetstore, another struts application that works as a portlet
> - jsf-demo, including small JSF demos
> - jsf-demo-myfaces, small JSF demos using myfaces
> - demo, assorted small portlets
> - rss, two different rss demos
> - gems (?)
>
> In addition, there are internal webapps:
> - layout-portlets/jetspeed-layout
> - security
> - palm
> - pam
>
> To be honest, the maintenance and handling of dependencies for such a
> big set is driving us crazy. We need to do something.
>
> My proposal is as follows:
> In a first stage, make people taking care of a given bridge take care of
> the associated demos too. They would serve as black-box tests, as well
> as enabling quick examples of the bridge use. The only reasonable way to
> attain this goal is to move the projects at applications/* to
> portals-bridges/, and change the jetspeed build so that it imports, if
> any, the .war(s) produced by the bridge. Before (or after) we move the
> demos to bridges, some refactoring might be justified, for instance
> grouping together the two jsf demo wars, deleting some irrelevant
> portlets, grouping, commenting, etc. Also, where the framework is
> already supporting reasonably a bridge, we could just use their demos,
> and do some social work so that they release and maintain a demo war
> that we can simply use for test and demo purpose. Don't forget that,
> while the demo portlets started mainly to test and explore the
> frameworks, currently their main goal is to serve to people new to
> portals to learn by example.
>
> In addition, as we release J2-M4, we could release bridges-0.4, and as
> soon as this is done, stop using SNAPSHOT artifacts as dependencies, and
> have jetspeed-2 and the different bridges release independently. I.E.,
> the struts bridge and jsf bridge release cycles would be fully
> independent, starting their releases with the 0.4 release. Bugs and
> updates to the bridges code would bring new releases of just the
> involved artifacts, not pulling a big release of J2 or bridges as a
> whole.
>
> For this to be workable in the short term, if would be handy to have a
> way for the involved bridges demo to deliver PSML pages showing the
> portlets demoed. While this is not portable as of JSR-168, the PSML
> format is simple enough to be used as a mean to understand what is
> intended for demo in a war file. As already commented, we could just use
> pages in /WEB-INF/pages in the war, and the deployer *could* take care
> of creating them in the portal, or else the build process could take
> them from there to construct the demo portal.
>
> In following steps, we could try to have a repository where complex
> webapps could be maintained, starting with the admin portlets themselves
> (security, pam, palm)
>
> Also, to clean, document and make sure that demo portlets are actually
> showcasing core portlet-api and jetspeed features, and that they serve
> this purpose with minimal fuss.
>
> I'd recommend starting with the easy steps: moving php, perl,
> struts-demo, jpetstore, jsf-demo, and jsf-demo-myfaces to places under
> portals-bridges/ In a first go, the psml pages using those portlets
> would remain in jetspeed/src/webapp/WEB-INF/pages
>
> I had the idea to move the wars to bridges/<framework>/src/webapp ...,
> but it would possibly be better something like
> bridges/<framework>/<framework>-demo instead. This can be done with a
> simple server side move, but the project.xml /properties would need some
> adjustment, both for jetspeed to depend and take the war artifacts in
> the "full" goals, and for bridges to build them.
>
> What do you think?
>
>
> Santiago
> --
> VP and Chair, Apache Portals (http://portals.apache.org)
> Apache Software Foundation
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org