11:56 a.m.
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