buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: EAR task
Date Thu, 13 Dec 2007 18:18:17 GMT
Sweet!  The more the merrier :)

A patch + test cases would be gladly accepted!

alex



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.
>
> Greetings!
> --
>  vic
>
>
> Quaerendo invenietis.

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