Hide Forgot
Date of First Response: 2007-12-17 02:07:52 project_key: SOA Followup to SOA-191 The initial SOA-P release will pacakage the jBPM runtime to support the creation of new jBPM process projects - to avoid users having to perform a separate download. The requirement for this packaging to include jPBM source should be revisited post GA - how to avoid having to package the source to support new project creation?
Link: Added: This issue depends SOA-191
Why is this a bad thing to bundle the jbpm framework ?
It seems counter intuitive that you have to bundle the source of the project for which you're selling the binary.
eh - src is just a small part of the bundle. What about additional docs and instructions for toolings where to find templates etc. which is not part of jbpm.jar
docs and instructions are fine. But src for the project doesn't make sense.
Coming back to this issue. How do you want to solve the problem of a tool supporting multiple runtimes at the same time and offering code completion and 'ctrl-click' functionality to view sources of classes if you don't include these sources? Also, this is really only a matter of what you want to offer your users. If you don't include the sources, than the editor and the create process wizard will still work, only they will not be able to create 'jbpm projects'.
koen - is it actually *all* the sources that is needed or is it like with seamgen in seam where we will extract the "template" part to use for tooling independent of the runtimes... anyway this is a general problem we have that the runtimes are not dev-friendly, but primary prod-friendly. Something we should find a good solution for since it is relevant for all projects.
If you don't consider 'ctrl-click' functionality to navigate to the sources, the needed files are indeed not really dependent on the actual runtime. But the information in the file is.
Is src attachement to classpath the *only* feature this is for ? I thought you had some templates or something you needed from the distribution ?
this would be a big work. i don't think it's worth doing it on the jBPM 3 codebase. we will make sure that this works in jPDL 4. but the solution is not yet clear to me. on the one hand, you want the plugin not to have a dependency on the runtime for creating a new template process eclipse project. on the other hand, we want the jpdl runtime download to contain a command line tool for creating a new template process eclipse project so do we want to end up with 2 versions of the runtime ? one that is contained within the designer and one on the filesystem ? here's my thoughts on this: * if the designer needs things from a runtime, it should get it from a runtime installation on the file system. * runtime should be able to create a new eclipse template project for working with processes (command line tool) * designer should be able to invoke that command line tool from the designer * optionally, the designer could have a new process project that doesn't have a dependency on the runtime. this would be the case for process modelling only. at this point we're not sure yet to what extend this will be realized in the next jPDL 4 designer version.
+1 This indeed sums up why the runtime is needed from the plugin. And I don't think that can be changed in jPDL 4. Or maybe if the new jBPM project wizard etc. would appear in a separate plugin which is then not shipped with the SOA platform. But then this platform would need its own wizard to 'add' jbpm functionality to the SOA project or something along these lines.
Who wants command line creation of jbpm specific projects ? I still have not understood what the dependency is all about except the wish to have source attachements in the classpath container - that is not a critical thing and should be handled in a different way IMO (but again that is a future thing) So I ask again: What is the *exact* dependency on the runtime dir in jbpm (besides source attachments) ? e..g for Seam it iis that we tempaltes in the seam-gen dir that we use in our Eclipse Wizards - main functionallity that would not work without a "runtime dir".