buildr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (BUILDR-5) EarTask implementation
Date Wed, 09 Jan 2008 07:20:36 GMT

     [ https://issues.apache.org/jira/browse/BUILDR-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Assaf Arkin resolved BUILDR-5.
------------------------------

    Resolution: Fixed

Now in SVN, including test cases and documentation, with a minor change that the :dir option
is now called :path, for consistency with include on JAR/ZIP.

> EarTask implementation
> ----------------------
>
>                 Key: BUILDR-5
>                 URL: https://issues.apache.org/jira/browse/BUILDR-5
>             Project: Buildr
>          Issue Type: New Feature
>            Reporter: Victor Hugo Borja
>            Assignee: Assaf Arkin
>             Fix For: 1.3
>
>         Attachments: 0001-Implemented-EarTask.patch
>
>
> Attached file implements the EarTask  to create an EAR file.
> Currently, this task is not required at load time, this means users may have 
> to require it, either by code, or using --require 'tasks/ear' 
>  The following component types are supported by the EARTask:
>  * :war -- A J2EE Web Application
>  * :ejb -- An Enterprise Java Bean
>  * :jar -- A J2EE Application Client.[1]
>  * :lib -- An ear scoped shared library[2] (for things like logging, spring, etc) common
to the ear components
>  The EarTask uses the "Mechanism 2: Bundled Optional Classes" as described on [2]. All
>  specified libraries are added to the EAR archive and the Class-Path manifiest entry
is
>  modified for each EAR component. Special care is taken with WebApplications, as they
can
>  contain libraries on their WEB-INF/lib directory, libraries already included in a war
file
>  are not referenced by the Class-Path entry of the war in order to avoid class collissions
>  EarTask supports all the same options as JarTask, in additon to these two options:
>  * :display_name -- The displayname to for this ear on application.xml
>  * :dirs -- A Hash used to determine the default directory used for each EAR
>                  component type. Default value is Hash.new { |h, k| k.to_s }
>                  this means, wars will be in the "war/" directory inside the ear,
>                  ejbs under "ejb/" and so on. You can customize this like so:
>                        package(:ear).dirs[:war] = "web-applications" 
>                        package(:ear).dirs[:lib] = nil # store shared libraries on root
of archive
>  EAR components are added by means of the EarTask#add, EarTask#<<, EarTask#push
methods
>  Component type is determined from the artifact's type. 
>       package(:ear) << project(:coolWebService).package(:war)
>  The << method is just an alias for push, with the later you can add multiple components
>  at the same time. For example.. 
>       package(:ear).push "org.springframework:spring:jar:2.6", 
>                                    projects(:reflectUtils, :springUtils),
>                                    project(:coolerWebService).package(:war)
>  The add method takes a single component with an optional hash. You can use it to override
>  some component attributes.
>  You can override the component type for a particular artifact. The following example
>  shows how you can tell the EarTask to treat a jar as an ejb.
>       # will add an ejb entry for the-cool-ejb-2.5.jar in application.xml
>       package(:ear).add "org.coolguys:the-cool-ejb:jar:2.5", :type => :ejb
>       # A better syntax for this is: 
>       package(:ear).add :ejb => "org.coolguys:the-cool-ejb:jar:2.5"
>  For WebApplications (:war)s, you can customize the context-root to be generated on 
>  application.xml. The following example also specifies a different directory inside the
EAR
>  where to store the webapp.
>       package(:ear).add project(:remoteService).package(:war), 
>                                  :dir => 'web-services', :context_root => '/Some/URL/Path'
>  VERY IMPORTANT NOTE:
>  As described on [1] an EAR can have "J2EE Application Clients", these components are
>  identified by a :jar component-type. A <jar> entry for each of these components
is 
>  generated on the application.xml descriptor.
>  However, as these <jar> components are not so frecuent on EAR archives, the EarTask
uses
>  a special design desicion:
>  
>    Artifacts having a 'jar' type are treated by the EarTask as :lib components.
>    This means.. doing something like:
>            
>            project(:ear) << "spring:spring:jar:1.2" << "~/lib/java/log4j-1.0.jar"
>    .. will add both spring-1.2.jar and log4j-1.0.jar under the "lib/" directory, adding
>   them to the Class-Path attribute on ejb|war|jar components.
>  
>  Because of this, If you want to add a "J2EE Application Client" you must be explicit
>  about the component type to use:
>           project(:ear).add :jar => "org.application:client:jar:2.0"
>  [1] http://java.sun.com/j2ee/sdk_1.2.1/techdocs/guides/ejb/html/Overview5.html#10106
>  [2] http://java.sun.com/j2ee/verified/packaging.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message