Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.3
    • Component/s: Packaging
    • Labels:
      None

      Description

      EAR descriptor must be generated under target as anything generated by buildr.

      update_classpath method was modifying inherited manifest, thus causing EAR packages to contain Class-Path entries themselves, according to the specs ear packages may not have a Class-Path on their manifest.

      Improvements on EAR package DSL, also fixed Class-Path generated entries according to the Jar specification at http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html

      1. buildfile
        11 kB
        Victor Hugo Borja
      2. 0001-Outstanding-EAR-packaging-bug-fixes.patch
        10 kB
        Victor Hugo Borja

        Activity

        Hide
        Victor Hugo Borja added a comment -

        [PATCH] 0001-Fixed-ZipTask-to-pass-Buildr-Packaging-war-should.patch
        Fixed ZipTask to pass 'Buildr::Packaging war should ignore webapp directory if missing' example.

        Show
        Victor Hugo Borja added a comment - [PATCH] 0001-Fixed-ZipTask-to-pass-Buildr-Packaging-war-should.patch Fixed ZipTask to pass 'Buildr::Packaging war should ignore webapp directory if missing' example.
        Hide
        Victor Hugo Borja added a comment -

        [PATCH] 0002-EAR-packaging-additions.patch
        EAR packaging additions:

        • Modified Project#packages to take a list of package filters
          renamed :type option to :as, adding components to EAR is more natural.
        1. Add all jars produced by remoteInterfaces as ejbs on the EAR
          package(:ear).add project('remoteInterfaces').packages(:type => :jar), :as => :ejb
        • Modified packaging.textile to add more examples using the new packages selectors
        • push became an alias for the add method.
        • Multiple component types can be added at once using type=>component mapping style:

        package(:ear).add :war => project('coolWebservice').package(:war),
        :ejb => projects('fooInterface', 'barInterface') # add jars produced by both projects as EJBs

        • Added more EAR spec examples
        Show
        Victor Hugo Borja added a comment - [PATCH] 0002-EAR-packaging-additions.patch EAR packaging additions: Modified Project#packages to take a list of package filters renamed :type option to :as, adding components to EAR is more natural. Add all jars produced by remoteInterfaces as ejbs on the EAR package(:ear).add project('remoteInterfaces').packages(:type => :jar), :as => :ejb Modified packaging.textile to add more examples using the new packages selectors push became an alias for the add method. Multiple component types can be added at once using type=>component mapping style: package(:ear).add :war => project('coolWebservice').package(:war), :ejb => projects('fooInterface', 'barInterface') # add jars produced by both projects as EJBs Added more EAR spec examples
        Hide
        Victor Hugo Borja added a comment -

        [PATCH] 0003-Made-each-EAR-components-classpath-relative-to-the.patch
        Made each EAR components' classpath relative to the shared libraries location.

        According to http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html, the Class-Path entry must be a list of RELATIVE paths (from the Jar referencing other Jars).

        Show
        Victor Hugo Borja added a comment - [PATCH] 0003-Made-each-EAR-components-classpath-relative-to-the.patch Made each EAR components' classpath relative to the shared libraries location. According to http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html , the Class-Path entry must be a list of RELATIVE paths (from the Jar referencing other Jars).
        Hide
        Assaf Arkin added a comment -

        "For the bundled optional packages mechanism, each web module uses the manifest file and Class-Path attribute to point to the same location for the JAR file bundled within the EAR file."

        The examples also shows two paths that are relative to the EAR:
        http://java.sun.com/j2ee/verified/packaging.html

        Show
        Assaf Arkin added a comment - "For the bundled optional packages mechanism, each web module uses the manifest file and Class-Path attribute to point to the same location for the JAR file bundled within the EAR file." The examples also shows two paths that are relative to the EAR: http://java.sun.com/j2ee/verified/packaging.html
        Hide
        Victor Hugo Borja added a comment -

        Assaf,

        Sorry for the very-late response, I've been a little busy at work.

        I've made a very simple buildfile to test deployment of ear packages using buildr with all attached patches. It seems JAVAEE 5 application servers require Class-Path entries to be relative to each component.

        Please read the comments on the end of the buildifle.

        If you want to deploy them yourself, you can either run the package task or download the ears from app*/target directories at

        http://lainsoft.org/pub/vic/poc/

        Show
        Victor Hugo Borja added a comment - Assaf, Sorry for the very-late response, I've been a little busy at work. I've made a very simple buildfile to test deployment of ear packages using buildr with all attached patches. It seems JAVAEE 5 application servers require Class-Path entries to be relative to each component. Please read the comments on the end of the buildifle. If you want to deploy them yourself, you can either run the package task or download the ears from app*/target directories at http://lainsoft.org/pub/vic/poc/
        Hide
        Assaf Arkin added a comment -

        From Ingo Schmidt:

        >> I am adding a WAR and an EJB to my EAR like so:
        >> package(:ear).add :war=>project("webapp-war").package(:war)
        >> package(:ear).add :ejb=>project("my-ejb").package(:jar)
        >> I run the build and the result is as expected. Now I comment out
        >> the line add the EJB to my EAR and run buildr again (no clean
        >> task). But my application.xml still has the entry for the EJB.
        >> Why is this so? I have seen this happen in other places in buildr,
        >> too. Too bad, I didn't write those cases down.

        Here's a possible solution, need to see if it will work:

        Add the buildfile (Rake.application.rakefile) as a prerequisite for the application.xml task, forcing this task to run every time the build file changes. This will detect changes like removing a component, the downside is that it will re-build the EAR every single time the buildfile changes.

        Improve on it by creating the XML in memory, comparing it to the contents of the existing application.xml, and only writing the file if there's a change. That way, the application.xml task will run every time the buildfile changes, but the EAR task will only run if there's a substantial change to application.xml.

        >> Is there any way to add a WAR to my EAR as open directory and not
        >> as *.war file?
        >> I need this because I don't think you can tell IIS to use a *.war file
        >> as document root...
        >> Is there any way to change/modify the EAR task to do this for me?
        >> Would be very handy, because the EAR task so nicely builds the
        >> application.xml on the fly.
        >> Currently I need to unzip the WAR and modify application.xml by
        >> hand. It would just be so much nicer to have it all automated.

        Ideas?

        Show
        Assaf Arkin added a comment - From Ingo Schmidt: >> I am adding a WAR and an EJB to my EAR like so: >> package(:ear).add :war=>project("webapp-war").package(:war) >> package(:ear).add :ejb=>project("my-ejb").package(:jar) >> I run the build and the result is as expected. Now I comment out >> the line add the EJB to my EAR and run buildr again (no clean >> task). But my application.xml still has the entry for the EJB. >> Why is this so? I have seen this happen in other places in buildr, >> too. Too bad, I didn't write those cases down. Here's a possible solution, need to see if it will work: Add the buildfile (Rake.application.rakefile) as a prerequisite for the application.xml task, forcing this task to run every time the build file changes. This will detect changes like removing a component, the downside is that it will re-build the EAR every single time the buildfile changes. Improve on it by creating the XML in memory, comparing it to the contents of the existing application.xml, and only writing the file if there's a change. That way, the application.xml task will run every time the buildfile changes, but the EAR task will only run if there's a substantial change to application.xml. >> Is there any way to add a WAR to my EAR as open directory and not >> as *.war file? >> I need this because I don't think you can tell IIS to use a *.war file >> as document root... >> Is there any way to change/modify the EAR task to do this for me? >> Would be very handy, because the EAR task so nicely builds the >> application.xml on the fly. >> Currently I need to unzip the WAR and modify application.xml by >> hand. It would just be so much nicer to have it all automated. Ideas?
        Hide
        Victor Hugo Borja added a comment -

        Lots of changes (merged with HEAD), see the 0006 patch for details. All HEAD specs passing, although more specs are comming.

        • Fixed the EAR descriptor dependency problem. Choosed 2nd suggestion from Assaf. Thanks to Ingo for reporting it.
        • Expandable archives (WAR, EAR)
        • PackagingTypes inherited in project hierarchies.
        Show
        Victor Hugo Borja added a comment - Lots of changes (merged with HEAD), see the 0006 patch for details. All HEAD specs passing, although more specs are comming. Fixed the EAR descriptor dependency problem. Choosed 2nd suggestion from Assaf. Thanks to Ingo for reporting it. Expandable archives (WAR, EAR) PackagingTypes inherited in project hierarchies.
        Hide
        Assaf Arkin added a comment -

        Can you split this in two independent patches? The EAR would be easy to apply.

        PackagingType is a major change, should be its own issue, discussed separately.

        Show
        Assaf Arkin added a comment - Can you split this in two independent patches? The EAR would be easy to apply. PackagingType is a major change, should be its own issue, discussed separately.
        Hide
        Victor Hugo Borja added a comment -

        Attachment: 0001-Outstanding-EAR-packaging-bug-fixes.patch

        This patch includes only high priority bug fixes for EAR packaging, new features/improvements added by previous patches will be submitted on their own JIRA issues as needed.

        Show
        Victor Hugo Borja added a comment - Attachment: 0001-Outstanding-EAR-packaging-bug-fixes.patch This patch includes only high priority bug fixes for EAR packaging, new features/improvements added by previous patches will be submitted on their own JIRA issues as needed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Victor Hugo Borja
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development