Why is the console a different repos

[camunda]

Hi!

Maybe I missed something, but I wonder why the jbpm4 gwt console is not part of the jbpm repos? I searched for some time before I realized it is a complete download. And I have to build it seperately. Any reason for this?

Shouldn't it be a module directory in jpbm4? Would make life a bit easier...

Cheers
Bernd

[camunda]

And checked out the wrong one first ;-) Really a bit hard to find...

[heiko.braun]

it is a complete download. And I have to build it seperately. Any reason for this?

it's a project on it's own that's not only used by jbpm. jbpm has a dependency on the console and not vice versa.

[kukeltje]

If it is a project on its own and not only used in jbpm, shouldn't it be a completely different project in general like it already has it's own separate forum etc..?

[camunda]

Currently I still try to understand first WHY the jbpm console is a project on its own?

[kukeltje]

http://blog.athico.com/2009/05/drools-flow-51-preview-1-web-console.html

[tom.baeyens]

given that they want to compete, i don't think we should be sharing our console.

[camunda]

For me the important issue is, that being generic doesn't slow down the development of the console and features required for jbpm.
Or make it harder to use or understand (like levels of indirection tend to introduce).

I think, the most important goal is a really useful, cool jbpm console, like from professionell (means expensive) bpm engines. Since the web console is one of the first things you see of the product...

[tom.baeyens]

generic will always limit our ability to make progress.
and of course it always costs more effort to have make things pluggable and generic.

[heiko.braun]

i don't think we should be sharing our console.

tom, that's childish. it's both open source projects, run by the same company. and most importantly: both projects expose the same management requirements.

we didn't put any effort in making it available to drools flow. although it was designed to allow for different engines in the first place, kris did the adoption on his own.

IMO it's a good thing for the console, because we share QA and verification of requirements. For users that are unaffected by the "drools vs. jbpm" discussion, it's definitely a benefit to have a similar management console.

[heiko.braun]

generic will always limit our ability to make progress.

haha, hence the PVM in the first place, right?

[heiko.braun]

I think you guys should relax. We are approaching GA, the console does require more QA, but basically contains everything it requires. It looks nice, uses impressive technology. So what's the problem?

[tom.baeyens]

we are relaxed. we just want to keep it that way.

[kukeltje]

Childish or not, the fact that a *serious* company like JBoss is *developing* 2 workflow/bpm/... solutions is outright weird. Now if they e.g. bought Bea and in that process acquired an additional engine/framework/system in this area but no.... And what about all the independent consultants that get questions from customers? If I worked for Oracle/IBM/... I'd say that JBoss does this on purpose to sell training. Or mention somewhere that JBoss has no confidence in it's own products... But I know that this is not the case.

But hey, I'm not the CTO/Enterprise Architect/.... over there.

[camunda]

True.

A clear statement why two engines exist would be necessary to stop confusion among JBoss users... I got that question already a couple of times.

But I think, thats not for us to discuss, it would be a JBoss management task.