Greg Buchanan wrote:
I completely agree with Ralph's comments below.
This thread begs the question, "what is the target audience and mission of
the jetspeed portal ?"
If you look at the adoption rates of the various portals out there (both
open source and commercial license), those with the greatest market share
are also those most easily installed and implements.
My focus is on the content that I need to deliver and the benefits of the
underlying infrastructure. If I have to "build" the portal to change a
header, footer, general layout or something else that should either be done
in configuration files or an administration tool -- it's time to look at
other alternatives.
Well, I've already responded to that wrong interpretation Ralph made, but I
want to say it again: this is *not* what I was talking about.
You don't need to "rebuild" Jetspeed for those purposes. Actually, custom
headers,
footers and general layout can be hot "deployed" at runtime within Jetspeed :)
Case in point --- a company wants to change a tag line or other simplistic
item. They may have test, development, qa and production environments.
Replicating an entire WAR file across all of these environments would be
unacceptable to many of my customers -- particularyl for a trivial change.
I agree. And you don't need to (although I do know customers who even for things
like that require a full deployment of a newly build ear)!
Just my 2c worth.
Thanks.
Ate Douma wrote:
I keep seeing this point of view coming back again and again. Let me
repeat what has been said before: this is *not* the (most) intended
usage of jetspeed.
If Jetspeed were a "blackbox" product one installs and uses as is,
then I'd say this whole
build system discussion would be pointless anyway.
AFAIK, the Jetspeed committers themselves never had big problems
building Jetspeed *locally*
for their specific environment using maven.
Neither was building a demo/binary with Tomcat and using an embedded
database.
What I don't understand is why so many think that is all what is
needed!
As soon as one really is going to *use* Jetspeed, e.g. install your
own portal and tweak it
to your own requirements like the simplest of all customizations:
using your own portal name
instead of jetspeed, you're gonna need to *build* your own portal.
Create a new jetspeed.war (with probably a different name), use
different databases, add
services, change assembly settings, deploy on different platforms and
application servers, etc.
If that is really true then I picked the wrong portal. Doing what you
described should not require me to rebuild Jetspeed itself. I may
require Jetspeed interfaces to build my "plug-ins", but I shouldn't have
to modify Jetspeed's build process at all.
Now please, if the maven advocates here can provide us with this neat
maven extension which
supports all of the above customizations (and more!), is flexible
enough for all our different
systems and requirements, easy to use and understand and, most
importantly, just WORKS, then
you *might* get my vote.
To me, that just involves providing a build process so that Jetspeed
"customers" can build their own pluggable components and then install them.
Oh, and it should also nicely integrate in our IDEs so we can finally
properly debug and run our
unit tests again using it...
I don't care for all the other nice projects which so perfectly build
using maven.
I say most, if not all, don't need customization *by the users* like
Jetspeed.
But, if someone can point me to a solution, or even better provide
one, which proves the contrary,
I'll give it my highest attention.
As I said before (I think it was on the dev list though), for
companies which have a strict policy
and a high to absolute control on the development environments, maven
might be a gift from heaven.
But you'll need dedicated attention on keeping your environments
healthy and in sync with external updates.
We, as Jetspeed committers, are not so lucky we can predict all end
users wishes, nor are we able
(and certainly not willing) to enforce or limit to one way of using it.
That would negate one of the most important features Apache and
Jetspeed provide: freedom of usage.
Like someone else said, its open source. If someone really wants to
build Jetspeed from scratch they can. But most of us should be able to
take a binary build, modify some configuration and drop it in Tomcat or
JBoss or whatever and run it. Then I should be able to add my plugins
and my portlets and have what I want.
I'll stick to my vote for dropping maven and move to ant for now.
Well, at least you get a vote.
Regards, Ate
Ralph
---------------------------------------------------------------------
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]
