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]
