buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor Hugo Borja" <>
Subject Re: Merging questions
Date Fri, 08 Feb 2008 17:45:56 GMT
Hi Ingo,

Yes, this does work indeed, thanks. But it has another downside:
> It breaks your EAR task. I cannot anymore simply write:
> package(:ear).add(:war=>project("my_war-war").package(:war))

Ok, the problem here is you are referencing
project("my_war-war").package(:war), You actually need to add the "complete"
package into your EAR,

desc "My Project"
define "my_project" do
  manifest["Implementation-Vendor"] = "Acme"

  define "my_war-war" do
           ## The "complete" package is the one we
          complete = package(:zip, :id => "#{id}-complete", :type => :jar) #
Note, type is "jar" so that file extension is .jar
          artifacts(MY_TEMPLATE).each { |archive| complete.merge(archive) }
          # merge has the same semantics than Hash#merge, it overwrites old
entries with those on merge' argument
          complete.merge(package(:war)) # Finally, add the jsps, classes for
this project at the end.

   define 'application' do
       # If you are using current buildr HEAD
      # BUILDR-44 provides some syntactic sugar for this (not in HEAD
      package(:ear).add :war => project('my_war-war').packages.find { |pkg| =~ /complete/ }

       # Otherwise you need to obtain a reference to the "complete" package
      my_war = project('my_war-war')
      my_war = my_war.package(:zip, :id => "#{}-complete", :type =>
      package(:ear).add :war => my_war

> I then tried the latest version of buildr with your changes concerning
> packaging EARs and utility libs. You now implement "Mechanism 2" of the Java
> 2 Platform 1.4. It is still working nicely, with the only drawback, that I
> am using Jrun4 and that only supports Platform 1.3. And sure enough
> specification is different here, or at least unclear. JRun4 says about
> packaging utility classes, see "Handling J2EE module dependencies" at
> So any utility libs that are common for WARs in the EAR are referenced in
> EAR/META-INF/MANIFEST.MF, like your previous version did (with your previous
> version, I had to disable the manifest for each WAR)
> What JRun4 does here is fine with Platform 1.3 specification. So is there
> any way to maybe support both mechanisms?
> a) Mechanism 2 as in Platform 1.4 Spec (like it is now)
> b) JRun4 way (put utility classes in EAR manifest, but not in WAR's ones)

If  I understand correclty the  "Handling J2EE module dependencies" section
you mention, It says Class-Path attributes are added to the manifest file of
archived modules (read, each of your wars, ejbs, etc), not on the EAR's
manifest. That would mean JRun4 is J2EE 1.4 complaint in this respect.
Updating EAR manifest file was actually a bug on previous versions,  an EAR
must not have a Class-Path entry.

Expanded packages are currently kind of experimental, see BUILDR-34.


Quaerendo invenietis.

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