Hi Gonzalo,
Nice to see you here and being interested in Rave.
First of all, thank you for your serious feedback and suggestions!
And to be clear upfront, I recognize and experience many if not most of the pain
points you report. But I might have a different view on why we have them and how
some can or should be solved, or not :)
Before trying to respond in more detail below, let me make a general observation
upfront which IMO is important to note.
A project like Jetspeed, or Rave, is quite different when compared to many other
projects you'll find at Apache.
And that difference comes from the very different and diverse audiences or type
of users:
- core developers, working on base or low level features
- UI/frontend developers, working on end-user experiences or
customization/theming capabilities thereof
- initial or casual reviewers needing a demo or a quick (and dirty)
out-of-the-box starting point to play with and prototype possible use-cases
- product users like integrators, mostly using the project 'as-is', only
slightly customized to their needs or tastes
- downstream developers using the project embedded, as building block or
platform to build a new product on top
Such a high diversity on *type* of users is not very common, and very unlike
you'll typically find with other projects, like Wicket.
A more fair project comparison (that is: from this perspective) would be against
projects like Liferay, JBoss Portal or within Apache maybe projects like
Geronimo, OFBiz, etc.
The above is not an excuse but should be taken into account why projects like
Jetspeed, Rave, etc. turn out to be more complex than for instance a casual
developer/user would wish for. But simplifying it for one type of audience, like
(only) for such developers, easily will make life much more miserable for
others. And figuring out an 'easy fix' which takes into account all or most of
the needs and requirements of the difference users, isn't so easy.
All that said, I do agree building Rave today (again) is probably more
complicated than needed in some areas. Or maybe some technology choices should
be reconsidered (if not already under reconsideration, please subscribe to the
dev@ list as we tend to more discuss these things there). So you're feedback is
very much appreciated and to be considered carefully by the team.
On 02/14/2013 05:39 PM, Gonzalo Aguilar Delgado wrote:
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!
I kind of agree with most reasons and arguments you give above. And I don't like
JSP and/or Tiles either. But replacing it with Wicket isn't the 'golden bullet'
either IMO.
Wicket is a cool project and very feasible for many things. But I wouldn't
choose it here and then force it upon every Rave downstream projects and users.
There already has been several but minor discussions (mainly on the dev@ list)
about front-end and server-side technology choices. I think currently the idea
is more to move in the direction of mostly state-less server-side (REST)
services and leverage them from smart client-side javascript based aggregation
solutions, than picking (again) another, and more state-full, server-side web
framework.
Note: I do like the Wicket component and hierarchical aggregation capabilities,
but IMO it is more fit for dedicated application oriented solutions but less for
generic platform and service orchestration.
[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?
Actually, it is or was intended to 'help' Eclipse users. Optionally, not
required. I'm no longer an Eclipse user though, and I don't think many Rave
developers are, so to be honest I have no idea if or how that works today.
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.
Well, certainly not intentional. Please also realize and recognize the fact that
it helped a lot of *other* people to use that project.
But I fully agree with your general comment. We must strive to keep it as simple
and easy as possible. And backtrack when something doesn't work out, or turns
out no longer to be needed or used. This might be such a case.
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?
This is a very specific question, but without more specific information
impossible to answer. Please raise a separate issue or question if you still
need or want this answered.
Also please note that the mavenfilesync plugin configuration you mentioned above
was provided exactly because of this use-case (automatically synchronize Eclipse
file changes into the cargo deploy env).
Concerning the 'whatever' IDE support in general.
While I agree this really is a pain point, other than providing, checking in and
maintaining IDE specific configurations, it is very difficult to generalize and
standardize how to manage and debug a multi-war build/deploy configuration
across IDEs. Single war projects typically are much easier, could use an
embedded servlet engine even, but this is not our 'minimal' setup. We need at
least two, three or even more webapps running concurrently (Shindig, Rave and
optionally Wookie, other gadgets apps).
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.
Well for this it should be obvious.
Our multi-war deployment setup is the logical consequence of a portal platform
where gadget/widget services like Shindig and Wookie are serviced through an
separate (web) application, and necessarily so. They might also be running on a
different host. In practice and in production they most likely are.
So while it *might* be possible to 'merge' (or worse: overlay) multiple of these
wars into one for IDE development/debugging convenience, its a
non-realistic/practical case. And IMO also technically undesirable (dependency
conflict hell).
Anyway, it doesn't mean it cannot be made easier, but I expect it'll require
more IDE specifics then. And we'll then have to deal with many different
solutions, for Eclipse, Netbeans, IntelliJ IDEA, etc.
And it needs volunteers willing to set this up, and maintain it...
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?
That's Shindig which is deployed by default (because its 'easier') to ROOT.
You'll find the mapping and deployment configuration in the cargo plugin.
There is also a cargocpc context. That seems todo nothing... Can it be?
The cargocpc is a minimal app injected by cargo to help the plugin to be
notified about the startup/shutdown of the container. Its the lightest possible
app and should really not cause any side-effect or be in the way. So it is used
and needed, but only during development and local cargo deploy.
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?]
I agree the Wookie integration isn't ideal yet. Which also has been raised
before on the dev@ list, just need some more attention to improve upon. And as
we have several Wookie committers also on the Rave team, further discussing this
and coordinating on it should be not a problem. And further input and proposal
to improve it much appreciated.
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.
I agree we need to 'fix' the Wookie deployment and (database) management issues.
But also note that this concerns the demo and/or development setup only. And for
those purposes I think integrating with Wookie, and demonstrating it, is very
relevant, although using Wookie is optional and should remain so.
It might be possible maybe to provide some different development 'profiles' to
include/exclude some components like Wookie. But we use Maven primarily, still,
and Maven profiles are typically not recognized or appreciated well by IDEs
either. But if you suggestions how to solve such things, please let us know!
----------------
----------------
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.
I think we will :)
Looks promising! I will surely fork it to see if I can contribute something.
Great, looking forward to it!
Thanks a lot!
PS: Just for reference in JIRA I missed the list in first place... ;-)
https://issues.apache.org/jira/browse/RAVE-892
I think I'll close that issue as it is more appropriate to discuss these things
on the mailing list (and maybe better dev@ in this case).
JIRA really shouldn't be used for open discussions IMO.
