Hi Ate, I will join to the dev list so because I think I can contribute a little bit to the project. Though I'm still analyzing how this project can fit in my requirements. :-)
About complexity. You are right. This project can be grow huge. But as you said the difficult part is to ease the life of each group of target users without making life more miserable for the others... This is really difficult but not impossible. I recently checked out Firefox Marketplace project. That is a HUGE project. Aside technology used (truly different). It builds, compiles dependencies, downloads artifacts and runs smoothly. Really! I'm able to work on it after just a few seconds after it finished configuring. Everything seems to be clear. And looks impressive! :-P And while templating system they are using remembers me a lot to velocity (I hate templating, even PHP language switched away this approach). They make clear that this technology is used and how it's used. Let me introduce at least a little doubt about jsp and templating in the dev maillist so we can discuss it. Maybe there is a good point on it. I hope so. :D El vie, 15-02-2013 a las 12:58 +0100, Ate Douma escribió: > 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. >
