Frank Villarreal wrote:
Ralph Goers said:
Having said all that, I'm not sure why a Jetspeed customer really needs
to know about any build tool. I should be able to download a war or ear
file, install it into my container (perhaps with a configuration script)
and run it. I really should only be concerned about the build tool if I
want to modify Jetspeed source.
WOW. There sure are a LOT of assumptions in that paragraph. Have you
worked with many portal projects in an enterprise environment for very long?
If so then you should probably know that more times than not, you end up
customizing big pieces of the code in order to integrate with pre-existing
infrastructure ... not necessarily by choice. How many projects in the
history of software development have accomplished 100% of what everyone
wanted, 100% of the time? I'll tell you the answer is ZERO. So yes, people
need to modify the source. By nature, open source projects are ... guess
what ... OPEN!?! Meaning users (customers as you put it) can and should be
concerned about the build tool if they need or want to modify the source.
If you buy into maven's way of doing things then you only have to write
"build logic" for things that are unique to your project. With ant you
have to write everything.
Once again, this assumes that the developers have thought of everything and
will designate the "pockets of code" that can be customized. Then when this
turns out not to be the case (99% of the time), anyone wanting to customize
the source has to learn the complexities of these monstrous NESTED maven
scripts.
From my experience, Frank's use case seems about right.
I want to point out that Jetspeed is a component architecture, so the
goal is to have a component build where you override target components.
I find it best to have two kinds of projects in an overall Jetspeed
integration project:
1) portlet application projects
2) jetspeed integration projects (component overrides)
With the first kind of project, you simply write your portlets to the
Portlet API and perhaps integrate with a Jetspeed service or two. I
don't see many problems in that area.
The second kind of project is a little more complicated.
It requires building and/or deploying the portal, and integrating key
pieces, overriding configuration, setting up the database with custom
settings.
What I've found in the development cycle, is that we make a change to
core, and then an integrator wants to pickup the change. We can achieve
this with:
a) having the integrator rebuild the source code
b) have some kind of 'binary' integration (no compilation of source)
c) an installer
While an installer is good for initial evaluations of Jetspeed, or
perhaps even for someone using Jetspeed out of the box, real life
projects have an integration life cycle. I think we need to identify
this life cycle, and try to create a tool for people to tap into that
life cycle with the least amount of disruption to their project as possible.
Binary integration is probably best.
Our Maven-1 plugin attempted to solve this.
In my opinion, it failed. Maven is just too much of an all-or-nothing
buy in to impose on integrators.
With Maven-2, we were planning on building Jetspeed with Maven-2, and
then doing binary integrations with Ant. As Ralph pointed out,
integrators usually don't need the source, but we have found that, since
our integration procedure (Maven-1 plugin) was always breaking, everyone
was resorting to building the source instead.
I think that integration pieces should be written in Ant.
I think we should really consider strong Elipse integration as a priority.
And, for the reasons repeatedly stated here by end users (and we should
*really* listen to our end users, its stupid to repeat the same mistake
twice), we should not force the "Maven way" on integrators and end users.
As for using Maven-2 in the Jetspeed build, I think there is still a
valid argument to take this approach. As suggested more than once on the
dev list, maybe the problem isn't Maven, its really us. Anyone at
Mergere want to send the Jetspeed team and users to a Maven-2 training
session?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
