buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: EAR task
Date Fri, 14 Dec 2007 00:16:02 GMT
On 12/13/07, Victor Hugo Borja <vic.borja@gmail.com> wrote:
>
> Hi,
>
> Just wanted to give thanks again for such a cool project!, I'll never look
> back at ant/maven :)
> In my current project I needed to build an ear from various subprojects.
> So I've added the EarTask.
>
> The EarTask takes care of updating the MANIFEST' Class-Path for each ear
> component.
> Special check is made for webapplications, so that if a jar is already on
> it's WEB-INF/lib directory
> it's not added to the war Class-Path attribute.
>
> After saving it under tasks/ directory, things became as simple as:
>
> define "dragsterApp" do
>
>   define "util" do
>     compile.with Jar.spring, Jar.commons_logging
>     package(:jar)
>   end
>
>   define "webservice" do
>     compile.with projects(:cis, :core)
>     package(:war)
>   end
>
>   define "ear" do
>
>     package(:ear).wars.with "/DragsterWS" =>
> project(:webservice).package(:war)
>     package(:ear).libs << Jar.spring
>
>   end
>
> end
>
> Here is a brief of EarTask rdoc:
>
>   # Supports all the same options as JarTask, in addition to these
> options:
>   #
>   #  * :display_name - The display name for this ear to be used on
> application.xml
>   #                  defaults to the project name.
>   #
>   #  * :libs -- An array of files, tasks, artifact specifications, etc
> that will be
>   #                  added to the EAR archive and will be referenced by
> component's
>   #                  Class-Path attribute. The main usage of this feature
> is to allow two
>   #                  or more components to share a common library stored
> inside the ear.
>   #                  For webapplication components, special check is
> performed so that
>   #                  only those libs not present at WEB-INF/lib are added
> to the war's
>   #                  Class-Path manifest attribute.
>   #
>   #                    package(:ear).libs << "
> org.springframework:spring:jar:2.5 "
>   #
>   #  * :wars -- An array of files, tasks, artifact specifications, etc
> that will be
>   #                  added to the EAR archive as web-applications. This
> component is
>   #                  added to the application.xml descriptor with a
> default context_root
>   #                  equal to the archive name without extension. You may
> also want to
>   #                  specify the context_root to use with:
>   #
>   #                     package(:ear).wars.with "/remoteService" =>
> project(:some_webservice).package(:war),
>   #                                                         "/SomeGUI" =>
> project(:someGUI).package(:war)
>   #  * :ejbs - An array of files, tasks, artifact specifications, etc that
> will be added
>   #                 as ejb components to the resulting Ear archive.
>   #
>   #                    package(:ear).ejbs <<
> project(:fooEjb).package(:jar)
>   #
>   #  * :jars - An array of files, tasks, artifact specifications, etc that
> will be added
>   #                 as jar components to the resulting Ear archive.
>   #
>   #                    package(:ear).jars <<
> project(:bazJar).package(:jar)
>
> I hope this can be of use to some one else. I've been using it with
> buildr+JRuby (with my jruby patch applied), but I think this may also work
> with MRI.
>
> If buildr-devs would like to add this task to trunk, I'll be happy to
> submit it as a patch + testcases on JIRA.


Definitely!

A few questions.  Adding WARs has its own syntax, different from adding EJBs
and JARs.  Wouldn't it be possible to use the same array accessors for all
three, so you can use << or package(:war).with(:jars=>..., :wars=>...)?

Jars vs lib.  Is WEB-INF/lib actually used in WARs, or should we just have
one of these options?

The "/remoteService" shortcut is a nice tought.  I'm not big on the syntax,
though, it looks like a path name which besides being a valid argument
(dependencies are all files) is also confusing.  But I would like to see
this feature, we just need to find a good syntax for it.

I'm thinking maybe a spec shortcut  :remoteService:war that will try to
resolve to lookup that archive type on another project?  That could be added
to the artifacts method and used elsewhere.

Assaf

Greetings!
> --
>  vic
>
>
> Quaerendo invenietis.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message