Mean-spirited Whining!? Ut oh lookout!
I thought you were taking a vacation?
I took off this week, much better for it, not feeling so mean spirited :-)
David Jencks wrote:
I thought I'd have some fun looking at how to do the geronimo security
integration, so I started out by trying to build jetspeed and get it
running on something. Here are a few comments that might help out
other new users.
The documentation uniformly claims that hslqldb is the default db, but
the build appears to use derby. This makes me distrust everything the
documentation says.
Yup. We missed a few places in the Derby conversion thanks
The build forces me to set a bunch of parameters relating to where
tomcat is, but AFAICT they are never used in the main build. After I
set them and run maven allBuild, my tomcat install is unchanged. I'm
not sure why someone who wants to run jetspeed on say jetty should be
forced to set a lot of parameters that are tomcat specific. Perhaps
the only checks for these parameters being set could be when the part
of the plugin that uses them is executed?
My vote is to remove ALL properties required in the
$HOME/build.properties. That causes lots of user issues
The reason for Tomcat specific parameters is that our source build only
deploys and works with Tomcat. Not Jetty or anything else.
We do plan to rewrite the build this month.
We are leaning towards Maven-2 and entirely rewriting the current plugin
Thus your comments are very timely and appreciated
The maven plugin seems to require quite a few dependencies that are not
listed as maven dependencies. The plugin expects them to be in
~/.maven/repository/org.apache.portals.bridges/wars
but on cvs.apache.org they are in
http://cvs.apache.org/repository/org.apache.portals.bridges/
which definitely seems like a mistake to me.
fixed.
I also wonder why the maven plugin has so many portlet apps to deploy
hardcoded into it. This seems contrary to the purpose of a plugin to
me. Another design choice might be to have a plugin goal to iterate
through the dependencies in the project.xml and deploy specially marked
dependencies. Then you could have a couple of example projects using
the plugin that deployed the full or min set of portlet apps. Although
I'm not yet familiar with what the plugin is supposed to do I think
this might provide a useful prototype for people to build other portals
off of.
I think you may have hit upon one of the major misconceptions with
Jetspeed, that it is very big. The demo apps take up a lot of space, and
in my opinion the demo apps, since they are not Jetspeed specific,
should be moved out of the Jetspeed repo and into Portals Applications,
where they can be downloaded individually if selected.
We we're simply trying to give people lots of coding examples using
different Bridges technologies. I think it would be better if we did not
hard code these demo apps into the portal.
Instead Im recommending the default Jetspeed Portal would be made up of
two webapps:
1) the portal itself
2) the jetspeed admin webapp
all other webapps would be optional, and not included in the default
deployment.
I do see the need for an admin portlet, allowing you to download portlet
applications, along with PSML pages, to add to the portal dynamically or
at install time
--
David Sean Taylor
Bluesunrise Software
[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]
