Ate Douma wrote:
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.
By "custom portal product" I assume you mean something like WebSphere
Portal that can use Jetspeed as its engine and add all the bells and
whistles to make it into what I said I wanted in my previous post?
Obviously, I feel that Jetspeed should provide enough of that that
Jetspeed is sufficient. However, in rereading what you wrote I don't
think we are really that far apart. If Jetspeed is delivered as
packages Maven can certainly use them as dependencies and embelish
them. I do this today for our Cocoon-based product. Cocoon 2.1 is a
PITA when it comes to building your own product - precisely because it
DOESN'T use Maven. Because of that we have to deliver source and require
end users to compile it. Well, I build a war and check it into our
repository. Then all the builds that need it unwar it and add their own
stuff to it and then create a new war as their product. This is trivial
with Maven.
Some of our users "assemble" a custom portal ear, already customized
for their app server
like Websphere.
Wouldn't it be nicer to just have your own project with only the needed
assemblies in it and then have Jetspeed as a dependency, perhaps with
some options to customize it for Websphere (or JBoss or whatever) for
you? We do this with our product builds today because at one time we
deployed on Weblogic and then decided to switch to JBoss.
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.
I have a lot of experience with Maven 1. I used to work a lot with GNU
make files. Ant reminds me a lot of that. Tons of raw ability with no
real structure or reuse capability. Maven's real strength isn't the
maven core - it is all the plugins. It is the standardization you get
so that after you've worked with a single Maven project you can grasp
any Maven based project. You can't say that with Ant. IMO, Maven 1's
problems were 1) jelly and 2) lack of transitive dependencies. Both of
these have been addressed in Maven 2. Since I have not had the
opportunity to build a Maven 2 project yet it remains to be seen if they
have gone too far or have hit the mark for me.
Now, pretend you are not using Maven. Aren't you going to have to define
some rules and guidelines about where things have to be placed and what
has to be configured in order to have an Ant-based build script work for
all of Jetspeed's customers to do what you have described? How, is that
any different than what Maven achieves?
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?
You should already know the answer to that. Because it creates
uniformity. Developers can go from project to project and not have to
learn how the build works.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
