[weld-dev] Weld archetypes in the spotlight

Sun Feb 7 13:25:26 EST 2010

I think it is already possible to approach Grails-style development on JEE6
with a mix of Maven archetypes, CDI portable extensions and servlet 3 web
fragments.
I remember there is an option somewhere in Maven to allow an archetype being
applied on an existing project, so the archetype would bring the dependency
on the PE jar, a web fragment for necessary framework servlets and maybe a
few necessary default configuration files (for example an empty process
definition for jBPM).

If you compare this with Grails, here's how that would compare the extension
possibilities  :
- various artifacts, such as js files, images, or example classes =>
possible with Maven archetypes.
- doWithSpring : add Spring beans before app init => doable with CDI beans
scan or by a PE.
- doWithApplicationContext : configure or modify existing Spring beans =>
doable with CDI by a PE.
- doWithWebDescriptor : add elements to web.xml => doable with servlet 3
web-fragment.
- doWithDynamicMethods : dynamically change of the Groovy meta-model. This
is for example how CRUD functionality is added by plugins, this is extremely
powerful but depends on the Groovy language. However I think that most
interesting things could by done by PEs in pure Java by using interceptors /
decorators, and I guess nothing would prevent a Groovy PE to modify the
meta-model of a CDI application built in Groovy.
- events : don't know as they are build-time hooks that are triggered when a
file is updated, packaged or something like this, there is maybe something
similar in Maven.

In the end I think it is already possible to implement something like :
mvn archetype:generate weld-jsf
mvn archetype:generate seam-jbpm
mvn archetype:generate seam-itext
...

Having played a bit with Grails, I can understand why people like it. It's
ultra-simple to get started and simple things are simple. It would be great
to achieve a similar development experience with JEE6/CDI. Too bad Maven is
almost unavoidable now but the archetype thing is really interesting.

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.
>
> In another words, I think that some way of simplifying the process of
> adding libraries and configuring them could be useful.
>
> I did not consider the idea of CRUD, but it could be nice as well.
>
> Bottom line is that I'd like us to explore ways to simplify and standardize
> as many aspects of EE development as possible. I see this as a really good
> selling point for the technology.
>
>
>
> On Fri, Feb 5, 2010 at 9:27 PM, Steven Boscarine <
> steven.boscarine at childrens.harvard.edu> wrote:
>
>>  One significant difference is that an archetype gives you a starter
>> application, but really knows nothing about your application.  A mojo can be
>> run at different points of the maven lifecycle, but doesn't know much about
>> the app it's being run on.  It's up to the mojo writer to turn the
>> collection of classes and resources into meaningful pieces of an
>> application.
>>
>> I can't speak for rails, but I know Grails actually is aware of your data
>> and has a much richer model.  Grails can apply a template per each entity or
>> database table in your application.  Maven, as of 2.2 (haven't looked at 3.0
>> yet), has no idea what your domain is.
>>
>> For example, if you wanted to create a plugin that generated a CRUD app
>> per each entity in your application, your Maven2 mojo would have to start
>> from scratch and determine what your entities are.  It is my understanding
>> that Grails plugins have convenient hooks to that data, controllers,
>> service, etc (although someone who has actually written a Grails plugin
>> before would be a better source of details on the subject).
>>
>>
>>
>> On 02/05/2010 06:06 PM, Arbi Sookazian wrote:
>>
>> That's interesting.
>> The Basics of Creating Rails Plugins
>>
>> A Rails plugin is either an extension or a modification of the core
>> framework. Plugins provide:
>>
>>    - a way for developers to share bleeding-edge ideas without hurting
>>    the stable code base
>>    - a segmented architecture so that units of code can be fixed or
>>    updated on their own release schedule
>>    - an outlet for the core developers so that they don’t have to include
>>    every cool new feature under the sun
>>
>> http://guides.rubyonrails.org/plugins.html
>>
>> Sounds like CDI PEs (portable extensions) was a ripoff of this idea...
>> And wasn't seam-gen alarmingly similar to Grails in terms of quick project
>> setup/startup?
>>
>> PE is strikingly similar to Rails plugins based on the above description
>> when you think of Seam 3 having Weld as its new core and the "extras" like
>> jBPM integration, remoting, iText, PDF, Excel, etc.
>>
>> Maven 2 already has the concept of MOJO (Maven POJO) and plugins:
>>
>> http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
>>
>> Not sure what added-value you're suggesting??
>>
>>
>> On Fri, Feb 5, 2010 at 2:34 PM, Piotr Steininger <
>> piotr.steininger at gmail.com> wrote:
>>
>>> I totally agree. Weld archetypes are probably the best polished ones I
>>> have ever seen. They remind me of some of the Rails semantics (get up and
>>> running in minutes).
>>>
>>>  These similarities got me thinking about another aspect of Rails -
>>> Plugins or gems (which I think is a mixed bag). The promise of plugins/gems
>>> is that you can quickly add dependent code and do some setup in minutes as
>>> well. I think that maven could very well be a platform to do the same.
>>> Currently one has to add dependencies by hand and quite often tweak the
>>> exclusions. With the introduction of maven console plugin, I think the door
>>> became open to create maven plugins/console scripts to make this a more
>>> automated process.
>>>
>>>  I don't have the expertise to create a prototype. I also don't know if
>>> this is really something that could be useful in the community (or simply
>>> serve as a tool for Maven newbies).
>>>
>>>  In any case, I wanted to see what the community thinks about this.
>>>
>>>
>>>
>>>  On Fri, Feb 5, 2010 at 5:06 PM, Dan Allen <dan.j.allen at gmail.com>wrote:
>>>
>>>>  The Weld archetype initiative has had a further reaching impact than
>>>> just the community of developers interested in using CDI (via Weld). A
>>>> recent blog entry on Sonatype cites the Weld archetypes as "the perfect case
>>>> study of how using Archetypes benefits the community." Steven is
>>>> acknowledged for his effort to identify the need of archetypes and
>>>> ultimately get them promoted to Maven central for all to use.
>>>>
>>>>
>>>> http://www.sonatype.com/people/2010/01/maven-archetypes-and-nexus-there-is-no-faster-way/
>>>>
>>>> Although archetypes are rather technically simple, it's important to
>>>> recognize the impact they can have by starting people off on the right foot.
>>>>
>>>> -Dan
>>>>
>>>> --
>>>> Dan Allen
>>>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>>> Registered Linux User #231597
>>>>
>>>> http://mojavelinux.com
>>>> http://mojavelinux.com/seaminaction
>>>> http://www.google.com/profiles/dan.j.allen
>>>>
>>>>  _______________________________________________
>>>> weld-dev mailing list
>>>> weld-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>
>>
>>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100207/8f3750bc/attachment.html 