[RAVE-892] Avoid Jetspeed Mistakes

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Invalid
• Affects Version/s: sandbox
• Component/s: build & development
• Labels: features
• Environment: Linux, Java 1.6, JPA
• Assignee: Unassigned
• Reporter: Gonzalo Aguilar
• Created: 14/Feb/13 12:34
• Updated: 15/Feb/13 12:50
• Resolved: 15/Feb/13 12:50

Description

Hello,

I recently switched my attention to this project. Please let me do a short introduction so I can explain me better.

I'm triying to build a marketing system from 2 years on. I was looking at most advanced arquitectures that can grow with time. One of my elections was jetspeed. Now I know it was a big mistake. Let me introduce why.

I found that the system is complex and overbloated. To change just the theme you have to go through a nightmare of velocity templates, jsps, and javascript all mixed on. No one designer wanted to take it and change it. Belive me. Nor do I. [I created a component to render with wicket, it worked and was great to build a new gui with it but I then realized that it would be a lot of effort for an obsolete system, this is my opinion].

To make it worse you have to deal with a tailormade build system that only works when ran from the command line, if something goes wrong you are out of luck. If you want to implement some feature you have to deal with "overlays". Basicly the build system copies the original version and then does a unzip of your package over it. This is a pain to handle.

So I was thinking to build my own system based on Gadgets, Services, and a lightweight interface. This is where rave comes in.

Rave is the project I was looking for.

But when I tried to use I found almost the same problems.

[First] The system is based on plan old JSP, and Tiles?:

Please, don't make same mistakes. Use wicket. Let me explain why.

1.- You can work with talented gui designers, web specialists. Otherway you can't. Nobody is going to take JSP and change it, nobody is going to update tiles. It will look much better if you can get some talented designers. Will sell a lot more
2.- You can separate completly the logic form the design. Let's make UI attractive. This is a must!
3.- Is an apache project.
4.- Is well supported.
5.- Supports html5 + ajax. This is again a must!

[Second] Keep it simple.

The build system is again overcomplex. Why do you do all this kind of stuff?

What's the "com.googlecode.mavenfilesync" stuff? Why it's all required?

I suppose it's not. Please do not make harder to new developers help. This was something it was done in jetspeed that kept a lot of people out of the project.

It must be handled/deployed in eclipse/netbeans or whatever ide easily. I found that maven cargo:deploy worked but I cannot start the application because something failed in the configuration. Since everything was packed into wars I had to:
1.- Deploy it.
2.- Look at it failing bad.
3.- Try to fix it over the deployed instance.
4.- Copy changed to the main project.

Well I wasn't able to inmediatly track it down. Because of the complexity of the build system. When I try deploy it with eclipse, some files are missing. I don't know why they appears when I do maven cargo:deploy. Where are they?

Of course I cannot debug because the cargo deployment is outside my eclipse config. So I have to move things around to make them run from the vm instance it's running inside eclipse.

Having 5 wars deployed for just a demo seems to be a lot. I'm sure there is a explanation. But nothing seems to be obvious.

There is a ROOT context that seems to be the portal, because has a lot of html and jps, but it can't be because there is already a portal context, so What's this for?

There is also a cargocpc context. That seems todo nothing... Can it be?

Also wookie is deployed. Since it looks good because the project rely on wookie for the gadgets, it's not. It seems to have a dependency on the persistence libraries deployed with the project that makes it fail on start. [Maybe the previous config fault?]

In my opinion if wookie is not tightly integrated it should run completly decoupled. If it can't be decoupled then do it right: Embed the system with a connector an deploy it with the rest.

----------------
----------------
So for me it leads to two things:

1.- Keep things easy and lightweight. [Wicket = +Designers]
2.- Let others to get hands dirty in the project without much hassle. [Easy to build = More developers]

Hope you have this into account.

Looks promising! I will surely fork it to see if I can contribute something.

Thanks a lot!