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. 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. 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]
