Implementing new project templates

[rovrevik]

I have implemented the capability to supplement the existing project/maven addon with additional templates.
With this new functionality, one can easily add new templates defined by resources contained in an external addon while still using the core project command.

Like: project --topLevelPackage c –template SOME_WACKY_PROJ

Is there any interest in creating a JIRA feature request for this?

[Ben Alex]

It would be good to gain a better understanding of the use case you're trying to achieve. Where possible we make the templates expressed by the project command as generic as possible, relying on subsequent Roo commands to fine-tune them. The present --template option allows fundamentally different types of projects, currently a choice between a normal user project or a Roo add-on. This needs addressing at the --template stage just because we have assembly requirements that are fundamentally different. So if you could expand on your use case it would be appreciated, so we can explore whether it might be possible to instead achieve this using finer-grained Roo commands after the initial stubbing is complete. One idea is a general-purpose "unzip" style command that unzips a ZIP into the project; that might be a nicer fit potentially....

[rovrevik]

Well, I am not sure that the existing high-level use cases are affected.

I am guessing the current use cases are something like:
• Roo shall provide the user with the capability to create fully configured projects.
• Roo shall provide the addon developer with the capability of extending roo with new commands to create projects.

The additional use case might be:
• Roo shall provide the addon developer with the capability of supplementing the default template options of the base project command.

I started to create a normal addon that made modifications to the files resulting for the project command and the STANDARD_PROJECT template.
I thought it would be easier to create an addon command that simply created the files the way I wanted them instead of making changes to existing files. This was easier but, the code for the resulting addon command was almost a complete copy and paste of the org.springframework.roo.addon.maven package.

For most projects the structure and roles of the files produced using the STANDARD_PROJECT are sufficient (pom, standard maven file hierarchy, application context, and logging configuration). Since most of the content of the produced files is static, providing the capability for the addon developer with a way to execute the included maven/project command with different source files would cut down on the custom code implemented in the new addon.

Additionally, a subtle benefit of an addon supplementing the list of template options is that the roo user would not need to explore the new addon commands and options to discover how to create a project.

[Ben Alex]

Hi Ryan

Apologies, this slipped off my radar.

Stefan has been doing some design work in this regard (templates). While his template focus is on the delivery of web components in a reusable, package-ready form, the core concept should be usable for other project resources.

How does your patch to trunk (mentioned in your email to me) work? Perhaps you could lodge it against a Jira ticket (preferably created using the 'svn patch' command against the current SVN revision). If you do that we can take a look at the approach and see whether it overlaps with Stefan's work or not and go from there.

[rovrevik]

Sorry... I created the patch and didn't attach it to the email.
I didn't see what appeared to be a similar jira issue to attach it to so I put it here.

Thanks,
Ryan

[Ben Alex]

Would you mind putting it against http://issues.springframework.org/browse/ROO-38. I'll also need to grab a CLA from you, but I'll write to you separately about that once it's in Jira (need it in Jira as part of the process).

[rovrevik]

Would you mind putting it against http://issues.springframework.org/browse/ROO-38. I'll also need to grab a CLA from you, but I'll write to you separately about that once it's in Jira (need it in Jira as part of the process).

Attached as requested. Looking forward to your email.

Thanks,
Ryan Ovrevik