gwt-console in distribution

[heiko.braun]

The new gwt console[1] is now included in the distribution [2]. It currently works on mock rpc services, but I will finish the process management soon.
We can then have both consoles running in parallel, working on the same jbpm instance.

[1] http://jboss-overlord.blogspot.com/2008/08/first-glimpse-at-new-bpm-console.html
[2] http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3BuildingTheInstaller

Stay tuned.

[thomas.diesler]

Heiko, would it be possible to build the gwt-console as part of the distro profile i.e. in the same way as the userguide?

This would reduce the normal change build test cycle considerably.

[heiko.braun]

Sure, I will take a look at it.

[thomas.diesler]

Thanks, this dropped the build time by 30%

http://jbpm.dyndns.org:8280/hudson/job/jBPM-Matrix/buildTimeTrend

[heiko.braun]

Yes, the gwt:compile take some time. But it's only required for web mode. So if you want to run the console in hosted mode a simple 'mvn compile gwt:gwt' is sufficient. This reduces the turnaround time a lot. Add a "mvn -o" to it and becomes a pleasure to work with.

[camunda]

Hi Heiko.

I didn't get it completly in SVN. The gwt-console path has only DAO's, the MockImplementations are where? Do I need a second project?

Also I didn't find an answer to one important question myself in the code I found (maybe if you point me to the correct sources I will ;-)), so I post it here:

How will the new console access jBPM? Via the CommandService maybe? That would be very nice, this would enable the console to correctly use JTA transactions in the Java EE environment. Something I really miss in the current console! Together with classloading issues I look at at the moment this would make the console much more valuable in a EE/ESB environment!

Thanks
Bernd

[heiko.braun]

The first cut of the console only works on client side mock RPC stubs. I am currently working on the RPC integration, which will probably use REST/Json interfaces between the client and the server. The actual server side implementation can leverage anything that's feasible to access the jBPM data.

I will take a look at the command facade and keep you posted.

If you wait a couple of days I'll check in the new REST/Json interfaces and the server side code based.

[camunda]

ok... I really would appreciate if it uses the CommandService, since that would be consistent to other places in jBPM. And it would be easy to plug it into every environment easily...

[tom.baeyens]

I will take a look at the command facade and keep you posted.

let me know if i can be of assistence.

[kukeltje]

I am currently working on the RPC integration, which will probably use REST/Json interfaces between the client and the server.

Aren't we going to leverage seam here? Or in other places?

[heiko.braun]

I really would appreciate if it uses the CommandService,

The console server backend will have a pluggable DAO layer. Building it upon the CommandService shouldn't be a problem.

[heiko.braun]

Well, currently I don't see the need to leverage a framework like seam for the backend realization. GWT apps are more like fat clients with CRUD calls into the backend. No context/state management on server side necessary.

[kukeltje]

Well, currently I don't see the need to leverage a framework like seam for the backend realization. GWT apps are more like fat clients with CRUD calls into the backend.

I know, but since there already is some nice functionality in seam for remoting (also to be used with GWT afaik, we could also leverage seam identity management, page security etc... and lots of other functionality (ok, not the pdf generation or excel or graphs or hibernate-validator like functionality, email templating, since that requires to use jsf and jBPM is going to use GWT). This was or is going to be all 'custom developed' in the current console or jBPM core.

No context/state management on server side necessary.

[kukeltje]

Sorry, error in quoting... correct response below

Well, currently I don't see the need to leverage a framework like seam for the backend realization. GWT apps are more like fat clients with CRUD calls into the backend.

I know, but since there already is some nice functionality in seam for remoting (also to be used with GWT afaik, we could also leverage seam identity management, page security etc... and lots of other functionality (ok, not the pdf generation or excel or graphs or hibernate-validator like functionality, email templating, since that requires to use jsf and jBPM is going to use GWT). This was or is going to be all 'custom developed' in the current console or jBPM core.

No context/state management on server side necessary.

As mentioned before, Seam does more imo... and it would mean (at least for you guys, since I do not work for JBoss) eat your own dogfood. Which would be good internal marketing I think, but that is just my opinion