-
1. Re: Why is the console a different repos
camunda Jun 20, 2009 8:32 AM (in response to camunda)And checked out the wrong one first ;-) Really a bit hard to find...
-
2. Re: Why is the console a different repos
heiko.braun Jun 22, 2009 4:31 AM (in response to camunda)
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. -
3. Re: Why is the console a different repos
kukeltje Jun 22, 2009 5:25 AM (in response to camunda)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..?
-
4. Re: Why is the console a different repos
camunda Jun 22, 2009 5:45 AM (in response to camunda)Currently I still try to understand first WHY the jbpm console is a project on its own?
-
6. Re: Why is the console a different repos
tom.baeyens Jun 23, 2009 3:47 AM (in response to camunda)given that they want to compete, i don't think we should be sharing our console.
-
7. Re: Why is the console a different repos
camunda Jun 23, 2009 4:12 AM (in response to 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... -
8. Re: Why is the console a different repos
tom.baeyens Jun 23, 2009 4:15 AM (in response to camunda)generic will always limit our ability to make progress.
and of course it always costs more effort to have make things pluggable and generic. -
9. Re: Why is the console a different repos
heiko.braun Jun 23, 2009 4:27 AM (in response to camunda)
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. -
10. Re: Why is the console a different repos
heiko.braun Jun 23, 2009 4:29 AM (in response to camunda)
generic will always limit our ability to make progress.
haha, hence the PVM in the first place, right? -
11. Re: Why is the console a different repos
heiko.braun Jun 23, 2009 4:31 AM (in response to camunda)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?
-
12. Re: Why is the console a different repos
tom.baeyens Jun 23, 2009 5:00 AM (in response to camunda)we are relaxed. we just want to keep it that way.
-
13. Re: Why is the console a different repos
kukeltje Jun 23, 2009 5:22 AM (in response to camunda)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. -
14. Re: Why is the console a different repos
camunda Jun 23, 2009 5:27 AM (in response to 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.