Ralph Goers wrote:
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, that depends on what your view of the build process is.
I'm *not* talking here about compiling the Jetspeed java source files and
spitting
out all the jetspeed component jars. That's the (relatively) simple part maven
*can*
handle for us. Right now this also works with maven-2 thanks to Randy.
I'm talking about "building" a custom portal product. This involves tweaking
the jetspeed assemblies/configuration files, adapting the database scripts,
adding custom services, plugin-ins, maybe replacing or extending a jetspeed
component or two, etc.
Jetspeed as a portal really is an "assembled" product. Maybe we shouldn't use
the
word "build" but "assembling" in this discussion.
Some of our users "assemble" a custom portal ear, already customized for their
app server
like Websphere.
All those things you have to do offline: modifying or assembling your own custom
portal. Now, I think this is one of the biggest strengths of Jetspeed: its
customizability.
The problem we're discussing here is how to make it easy for the users to make
full use of
this strength. Our maven-1 based attempt to support that (the custom maven
plugin) has not
been a big success to say the least. And I simply don't see, nor belief, how
maven-2 is going
to improve (a lot) on that.
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.
Well, as you might have gathered from my comment above: that's not what I was
talking about.
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.
So, why would you use or even need maven (or any other build tool) for that
then?
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]
