[
https://issues.apache.org/jira/browse/RAVE-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma closed RAVE-892.
--------------------------
Resolution: Invalid
Fix Version/s: (was: sandbox)
This discussion now has been brought to the mailing list and is further
discussed there, therefore closing it here.
> Avoid Jetspeed Mistakes
> -----------------------
>
> Key: RAVE-892
> URL: https://issues.apache.org/jira/browse/RAVE-892
> Project: Rave
> Issue Type: Improvement
> Components: build & development
> Affects Versions: sandbox
> Environment: Linux, Java 1.6, JPA
> Reporter: Gonzalo Aguilar
> Labels: features
>
> 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!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
