To the extent that my vote counts, I'd vote for more structure. Maven compatibility is a plus.
More structure is better. In particular I would like to see it support the same structure as the jBPM and Drools plugins, which have in addition:
Thanks for the feedback!
So, unless anyone objects, we'll go with the "maven" like directory structure and add the rules and jpdl directories.
Should we be able to run the project standalone, or is it enough that the project produces a <project_name>.esb archive?
This would let us clear out some of the configuration files.
The directory structure is deliberately mirrored on the quickstarts, please do not change this. We can look again at changing the structure at a later date but this must coincide with changing *all* the quickstarts.
The generated project must link into conf/base-build.xml and must demonstrate the deployment options supported by the quickstarts.
Sure, we can leave it as it is.
I was under the impression that this plugin was to be something that we could use in real projects and was the reason I wanted to see a different directory structure.
How about I create a separate plugin for this?
What I'd like to see is a plugin that creates the directory structure as discussed above.
And ANT targets for building and deploying the artifact generated by the project. This would only be the <project-name>.esb.
Any other suggestions?
The problem with going down this route is that the generated build.xml file could easily become inconsistent with what is required to compile/execute the quickstarts.
At the moment these dependencies are handled within base-build.xml for all quickstarts, including the correct base-build.xml automatically pulls in the correct dependencies. To remove this would require setting up a 'context' for every version of the ESB we release (platform and project).
We could certainly look at supporting this but I would then want to see this used by the quickstarts themselves. If the plugin and quickstarts use the same mechanism then we know that the plugin will work in all those cases.
What I was trying to say with my last posting was the following :)
If you feel that you can change this structure, and make the quickstarts consistent, then please make it happen. I agree that the quickstart structure is not ideal, and that we should change it, but it is important that these changes are consistent.
A little bit late to this discussion, but I'm never a fan of flat hierarchies. Structure is better.
yeah, I agree with you that the quickstarts should look the same as the projects created by the template plugin. I'll try modifying one quickstart locally to see how much is involved in this.
One thing that I'm probably missing is how the current template plugin is/was supposed to be used.
Was it only intended to help generate new quickstarts?
I have to admit that I have never used it. When I create a new quickstart I copy one that is similar to what I need and make updates :(
My thought was that the "new" template plugin should not have any dependencies to the quickstarts structure at all. And that jar dependencies should be used from the chosen esb server during project configuration.
The first version just recreated the helloworld example, IIRC, and may have been updated when the base-build.xml was created. Everything was a C&P prior to the base-build.xml, it was a maintenance nightmare.
Having the new plugin independent from the quickstarts would be a good move as the dependency mechanism should not really reside within the quickstarts. I would like the plugin and quickstarts to share the mechanism though.
Thanks for going the structured directories and including the rules and jdpl folders. I am currently conducting a SOA workshop for a client, and it is a bit clumsy creating a rule project or a jbpm project in Eclipse with one directory structure and then a second project that mimics the quickstart folder structure.
Drools plugin has a nice feature that you can add the required jars through a menu option "Convert to Drools Project". When the user creates a jBPM project it uses a jBPM Runtime that the user has previously configured in preferences.