[weld-dev] Weld archetypes in the spotlight (+ clickframes plug)

[Steven Boscarine]

On 02/05/2010 11:48 PM, Piotr Steininger wrote:
> The application I thought of was aimed at reducing complexity and thus 
> barriers to entry. The particular use case I had in mind was:
> I have a Weld + JSF app.Now I need to add bpm to the mix, so I would 
> add seam-bpm, but that's not the whole story. I need some extra 
> configurations, and maybe some boiler plate code to hook it all up, 
> and possibly create some process definitions and add them to the mix.
>
I agree.  If I read your message correctly, it seems like you're 
describing a modular archetype.  So you could have one minimal archetype 
and add features as needed.  For example, start with the basic JEE 
components, such as Servlet and CDI, and then add components in an à la 
carte fashion.  For example, give a hook to add JPA, JSF2, Wicket, 
seam-bpm, etc to an existing project.

I am pretty certain that Maven 2.2 doesn't have anything that can 
accomplish this.  I haven't looked into Maven 3.0 yet.

That technology would make the archetypes much easier to maintain.  I 
think our currently only option is to make an archive for each 
permutation we want to support.  There's no archetype inheritance, so we 
have to copy and paste between branches.

(obligatory plug for my open source project...that uses the archetypes 
and Weld/CDI)

My division at Children's Hospital in Boston is working on an open 
source project, Clickframes (http://www.clickframes.org) that actually 
addresses that problem and the rich model problem.  We are just starting 
our Java EE 6 support, so the instant I have it generating CDI code, 
I'll let the mailing list know.

If you want to learn more about it and happen to be in Cambridge, MA on 
Feb 22, my team-mate, Vineet Manohar, will be presenting about it at the 
Boston Java Meetup.

Clickframes has both a model for describing an application from a user's 
perspective and an engine to generate artifacts from that model.  In 
order to get started, the  user defines WHAT their application is in a 
language-agnostic manner, such as a page with a form with specific 
fields that transitions to another page when done.  This is presently 
stored in an XML file named appspec.xml (application specification) 
although it uses JAXB, so one could construct it via Java if preferred.

A user then writes plugins that can query the model to generate useful 
artifacts.  For example, when our JSF 2.0 plugin is complete (our 
current plugin is JSF 1.2), it will have a model in which it can query 
for all pages, forms, and fields and then generate the appropriate 
starter code.  There is also a JPA plugin which can generate starter 
code and actually have some insight into the logical entities that 
you've defined for an application.  We're hoping to complete an 
Arquillian plugin if time allows.

If you found that the project was to your liking, you could create a 
plugin in less than an hour (it's super trivial to extend) that would 
generate navigation using seam-bpm instead of JSF 2 navigation logic.

We solve the à la carte feature problem by having a second small 
configuration file named the techspec.xml.  It tells the engine which 
plugins to apply:  JSF2, JSF 1.2,  wicket, JPA, Seam2, Spring WebFlow, 
Spring MVC, etc.

We have a plugin that generates selenium tests, one that generates 
interactive documentation (one of my very favorites), and even one that 
does function point analysis that we use to give estimates to partners 
we work with.

We have used the project internally for nearly 1.5 years now and love 
it.  It's free, open-source and LGPL-licenced.    It had directly led to 
us shipping projects on time and of higher quality than we could have 
done with our budget.  We're excited about the Java EE 6 features we're 
adding an I'll be sure to keep people posted when they're usable.

Thanks,
Steven