Grokbase Groups Maven users May 2003
FAQ
Going through the examples on maven's site, along with articles from IBM
developerworks, I'm trying to package an ear file using dependencies.

Setting my dependencies with these properties causes Resource not found
error.

<ear.bundle.ejb>true</ear.bundle.ejb>

<ear.bundle.war>true</ear.bundle.war>



how can the ear goal pick up my ejb and war files?



Ryan Sonnek

J2EE Application Developer

Brown Printing Company

(507) 835-0803

ryan.sonnek@bpc.com

Search Discussions

  • Sonnek, Ryan at May 20, 2003 at 6:10 pm
    Solved my own problem on this one. After going through the project
    descriptor, I saw that you could set the dependency "type" and "jar" for
    non-standard named files. The war file is named without the version number
    and the ejb file is a 'ejb type' but with a .jar suffix.
    Setting the type to ejb and war, and explicitly setting the jar name works
    for me now.

    Ryan

    -----Original Message-----
    From: Sonnek, Ryan
    Sent: Tuesday, May 20, 2003 1:02 PM
    To: 'Maven Users List'
    Subject: packaging ear files

    Going through the examples on maven's site, along with articles from IBM
    developerworks, I'm trying to package an ear file using dependencies.

    Setting my dependencies with these properties causes Resource not found
    error.

    <ear.bundle.ejb>true</ear.bundle.ejb>

    <ear.bundle.war>true</ear.bundle.war>



    how can the ear goal pick up my ejb and war files?



    Ryan Sonnek

    J2EE Application Developer

    Brown Printing Company

    (507) 835-0803

    ryan.sonnek@bpc.com




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Michal Maczka at May 20, 2003 at 7:12 pm
    Subject to discuss:

    I changed a bit ear plugin in Maven HEAD
    (before beta 10 I would like to make it also backward compatible and add
    deprecation warnings).


    More and more I think about

    <ear.bundle.ejb> (which now is just <ear.bundle>) or
    <war.bundle.jar>

    I become convinced that those things should become much more simplified.

    Project which are producing artifacts like jars/wars/ears
    are producing one such artifact. It's rather unusual
    (and is not recommended that one project produces jar and war or war and ear
    etc..)

    Let's concentrated on war plugin. I experience with my projects
    that when I am creating war I want to bundle almost every
    artifact, with few exceptions.
    And it will be much easier for me to exclude artifacts then explicitly
    include them.


    So I want to propose such solutions:

    WAR plugin should bundle artifacts in two modes:
    "exclusion" mode and "inclusion" mode.


    In Exclusion mode artifacts marked with

    <war.exclude> will be not bundled in war. All others will.

    In Inclusion mode only artifacts marked with

    <war.include> will be packed in war.


    "Exclusion" mode will be default one.


    I think that this will make using those plugins much simpler than it is now.

    I am awaiting comments.
    If there are no objections I will try to implement such mechanism in both
    ear and war plugin.

    Other things I will look into:
    - separate a code which generates MANIFEST file from POM (so the code can be
    shared among plugins)
    - snapshot deployment of war/ejb

    Michal









    -----Original Message-----
    From: Sonnek, Ryan
    Sent: Tuesday, May 20, 2003 8:02 PM
    To: 'Maven Users List'
    Subject: packaging ear files


    Going through the examples on maven's site, along with articles from IBM
    developerworks, I'm trying to package an ear file using dependencies.

    Setting my dependencies with these properties causes Resource not found
    error.

    <ear.bundle.ejb>true</ear.bundle.ejb>

    <ear.bundle.war>true</ear.bundle.war>



    how can the ear goal pick up my ejb and war files?



    Ryan Sonnek

    J2EE Application Developer

    Brown Printing Company

    (507) 835-0803

    ryan.sonnek@bpc.com





    ----------------------------------------------------------------------
    Gdzie rozmawia WARSZAWA? >>> http://link.interia.pl/f1728


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Rafal Krzewski at May 21, 2003 at 7:20 am

    Michal Maczka wrote:
    Subject to discuss:

    I changed a bit ear plugin in Maven HEAD
    (before beta 10 I would like to make it also backward compatible and add
    deprecation warnings).


    More and more I think about

    <ear.bundle.ejb> (which now is just <ear.bundle>) or
    <war.bundle.jar>

    I become convinced that those things should become much more simplified.

    Project which are producing artifacts like jars/wars/ears
    are producing one such artifact. It's rather unusual
    (and is not recommended that one project produces jar and war or war and ear
    etc..)
    Very true, but at the same time sigle project usually produces:
    - binary package (jar, war, ear etc.)
    - source package
    - documentation (website) package
    Shouldn't we think about more artifact-oriented handling of the latter two?
    Let's concentrated on war plugin. I experience with my projects
    that when I am creating war I want to bundle almost every
    artifact, with few exceptions.
    And it will be much easier for me to exclude artifacts then explicitly
    include them.
    <snip>

    Did you mean dependencies? I think that it would be better to get back
    to the concept of compilation/runtime/testing dependencies.
    All of the dependencies declared as runtime need to be packaged into
    war/ear, end of story. It will also make POM dependency lists more
    meaningful too IMHO.
    Other things I will look into:
    - separate a code which generates MANIFEST file from POM (so the code can be
    shared among plugins)
    +0 (Non commiter'r +1, really ;-))
    - snapshot deployment of war/ejb
    +0 deployment/snapshot deployment of all artifact types should be
    handled uniformly.

    R.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Michal.maczka at May 21, 2003 at 8:40 am

    -----Original Message-----
    From: Rafal Krzewski
    Sent: Wednesday, May 21, 2003 9:20 AM
    To: Maven Users List
    Subject: Re: packaging ear files


    Michal Maczka wrote:
    Subject to discuss:

    I changed a bit ear plugin in Maven HEAD
    (before beta 10 I would like to make it also backward compatible and add
    deprecation warnings).


    More and more I think about

    <ear.bundle.ejb> (which now is just <ear.bundle>) or
    <war.bundle.jar>

    I become convinced that those things should become much more simplified.

    Project which are producing artifacts like jars/wars/ears
    are producing one such artifact. It's rather unusual
    (and is not recommended that one project produces jar and war
    or war and ear
    etc..)
    Very true, but at the same time sigle project usually produces:
    - binary package (jar, war, ear etc.)
    - source package
    - documentation (website) package
    Shouldn't we think about more artifact-oriented handling of the
    latter two?
    Let's concentrated on war plugin. I experience with my projects
    that when I am creating war I want to bundle almost every
    artifact, with few exceptions.
    And it will be much easier for me to exclude artifacts then explicitly
    include them.
    <snip>

    Did you mean dependencies? I think that it would be better to get back
    to the concept of compilation/runtime/testing dependencies.
    All of the dependencies declared as runtime need to be packaged into
    war/ear, end of story. It will also make POM dependency lists more
    meaningful too IMHO.
    I agree that this would be the best.
    The problem is that currently those two things don't necesserly overlap
    Probably some people are using the same project (POM)
    for creating both ear and war. If this idea were applied
    such things simply would not be possible anymore.

    Michal


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Rafal Krzewski at May 21, 2003 at 10:05 am

    michal.maczka wrote:
    I agree that this would be the best.
    The problem is that currently those two things don't necesserly overlap
    Probably some people are using the same project (POM)
    for creating both ear and war. If this idea were applied
    such things simply would not be possible anymore.
    And this is obviosuly bad practice... I think it's better to educate
    users how to structure their projects correctly than to support the
    hacky-whacky setup we have right now. I think that the commonly accepted
    best practice is:

    /master project (reactor etc.)
    /common (POM to extend by master,lib,war)
    /lib (builds a jar)
    /war (depends on & bundles lib)
    /ear (depends on & bundles war)

    In this setup bundling artifacts can be handled cleanly by marking them
    as runtime dependencies.

    R.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Mauro Talevi at May 21, 2003 at 8:13 am

    Michal Maczka wrote:
    Subject to discuss:

    I changed a bit ear plugin in Maven HEAD
    (before beta 10 I would like to make it also backward compatible and add
    deprecation warnings).


    More and more I think about

    <ear.bundle.ejb> (which now is just <ear.bundle>) or
    <war.bundle.jar>

    I become convinced that those things should become much more simplified.
    good idea :-)
    Project which are producing artifacts like jars/wars/ears
    are producing one such artifact. It's rather unusual
    (and is not recommended that one project produces jar and war or war and ear
    etc..)
    I would tend to agree on wars and ears - not on jars.
    think - eg of api/impl separation or separate jar for purely build-time
    classes such as stubs.
    but it's wars and ears that we're on about here.
    WAR plugin should bundle artifacts in two modes:
    "exclusion" mode and "inclusion" mode.


    In Exclusion mode artifacts marked with

    <war.exclude> will be not bundled in war. All others will.

    In Inclusion mode only artifacts marked with

    <war.include> will be packed in war.


    "Exclusion" mode will be default one.
    look nice and clean to be but I would make Inclusion the default.
    Most of the dependencies will need to bundled/included.
    Other things I will look into:
    - separate a code which generates MANIFEST file from POM (so the code can be
    shared among plugins)
    - snapshot deployment of war/ejb
    good ones!

    Cheers, Mauro



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Michal.maczka at May 21, 2003 at 8:40 am

    -----Original Message-----
    From: news On Behalf Of Mauro Talevi
    Sent: Wednesday, May 21, 2003 10:14 AM
    To: users@maven.apache.org
    Subject: Re: packaging ear files


    Michal Maczka wrote:
    Subject to discuss:

    I changed a bit ear plugin in Maven HEAD
    (before beta 10 I would like to make it also backward compatible and add
    deprecation warnings).


    More and more I think about

    <ear.bundle.ejb> (which now is just <ear.bundle>) or
    <war.bundle.jar>

    I become convinced that those things should become much more simplified.
    good idea :-)
    Project which are producing artifacts like jars/wars/ears
    are producing one such artifact. It's rather unusual
    (and is not recommended that one project produces jar and war
    or war and ear
    etc..)
    I would tend to agree on wars and ears - not on jars.
    think - eg of api/impl separation or separate jar for purely build-time
    classes such as stubs.
    but it's wars and ears that we're on about here.
    WAR plugin should bundle artifacts in two modes:
    "exclusion" mode and "inclusion" mode.


    In Exclusion mode artifacts marked with

    <war.exclude> will be not bundled in war. All others will.

    In Inclusion mode only artifacts marked with

    <war.include> will be packed in war.


    "Exclusion" mode will be default one.
    look nice and clean to be but I would make Inclusion the default.
    Most of the dependencies will need to bundled/included.
    That's why exlusion mode could be default one. In this mode everything
    except
    artifacts which are marked with "exclude" flag will be included.


    Michal


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Plim at May 23, 2003 at 1:29 am
    Hi folks,

    I'm just about getting started to convert our ant-build-system to use
    maven.
    I've been reading up on Maven from the online docs but I'm having
    trouble getting things to work.

    We have a central directory where we put all the libraries needed by our
    software.

    /java /jdom
    /xerces
    /xalan
    /axis
    /junit
    /nmr
    /sp
    /common
    Where nmr, sp and common are our internal libraries. The rest are 3rd
    party libraries.
    In our build environment, we manually download release zips and tars of
    the 3rd party libraries from their websites and install/explode them
    into the central directory.

    Our software build.xml references the jars under those directories to
    build the <classpath> tag.

    As far as I understand, our central directory is what you call the
    "repository".
    So how do I configure my project.xml to use the 3rd party libraries
    within Maven's repository? and,..
    How do I get my own libraries into the repository so that the Maven
    build can reference them?

    My apologise if this too trivial.
    Many thanks in advance.

    pengster





    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Brett Porter at May 23, 2003 at 1:42 am

    As far as I understand, our central directory is what you call the
    "repository".
    So how do I configure my project.xml to use the 3rd party libraries
    within Maven's repository? and,..
    eg:
    <dependency>
    <groupId>xalan</groupId>
    <artifactId>xalan</artifactId>
    <version>2.4.1</version>
    </dependency>

    This gets xalan-2.4.1.jar from a repository, specified by
    maven.repo.remote, which by default points to http://www.ibiblio.org
    How do I get my own libraries into the repository so that the Maven
    build can reference them?
    To put your own JARs in your local repo, just copy them into groupId/jars/artifactId-version.jar

    eg
    repository/com.mycompany/jars/nmr-1.4.jar

    Corresponds to groupId = com.mycompany, artifactID = nmr, version = 1.4

    If that project is mavenised, maven jar:install does this.

    I like to set up a HTTP server or file location for a local repository
    that isn't directly what Maven uses. To do this, setup the URL of it in
    maven.repo.remote in ~/build.properties.

    If your project is mavenised, you would then use maven jar:deploy to put
    your artifacts into that repository.

    Cheers.
    Brett


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • James CE Johnson at May 21, 2003 at 11:01 am

    michal.maczka wrote:
    I agree that this would be the best.
    The problem is that currently those two things don't necesserly overlap
    Probably some people are using the same project (POM)
    for creating both ear and war. If this idea were applied
    such things simply would not be possible anymore.
    And this is obviosuly bad practice... I think it's better to educate
    users how to structure their projects correctly than to support the
    hacky-whacky setup we have right now. I think that the commonly accepted
    best practice is:

    /master project (reactor etc.)
    /common (POM to extend by master,lib,war)
    /lib (builds a jar)
    /war (depends on & bundles lib)
    Is there a 'war:install' (like 'jar:install') that will put the output
    of /war somewhere that the /ear can find it for inclusion?
    /ear (depends on & bundles war)

    In this setup bundling artifacts can be handled cleanly by marking them
    as runtime dependencies.
    This may have been covered earlier in the thread but... How about jar
    files of EJBs that also need to go into the ear?

    /master project
    /ejb-set-one
    /ejb-set-two
    ...
    /ear

    The maven.xml in /ear uses maven:copy-deps to pull in the jars from the
    ejb projects so that those jars have all of the classpath entries they
    need.

    Is the the Best Practice or is there a better way?


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Rafal Krzewski at May 21, 2003 at 11:32 am

    James CE Johnson wrote:

    /master project (reactor etc.)
    /common (POM to extend by master,lib,war)
    /lib (builds a jar)
    /war (depends on & bundles lib)
    Is there a 'war:install' (like 'jar:install') that will put the output
    of /war somewhere that the /ear can find it for inclusion?
    Frankly I don't know. I think that at this moment maven supports fully
    only jar artifacts. There definetely should be war:install and
    war:install-snapshot goals.
    This may have been covered earlier in the thread but... How about jar
    files of EJBs that also need to go into the ear?

    /master project
    /ejb-set-one
    /ejb-set-two
    ...
    /ear

    The maven.xml in /ear uses maven:copy-deps to pull in the jars from the
    ejb projects so that those jars have all of the classpath entries they
    need.

    Is the the Best Practice or is there a better way?
    Ejb jars would be marekd as runtime dependencies of the ear project, and
    thus be eligible for bundling in the resulting ear. The ear plugin would
    probably use maven:copy-deps for that -- this tag definetly needs to be
    aware of what artifact is a runtime dependency, to avoid bundling jars
    needed only for testing etc.

    R.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Lester Ward at May 23, 2003 at 1:55 pm

    So how do I configure my project.xml to use the 3rd party libraries
    within Maven's repository? and,..
    If your project is mavenised, you would then use maven
    jar:deploy to put your artifacts into that repository.
    If the lib isn't Mavenized, I usually do this after invoking its build
    script (using velocity as an example):

    <!-- A property that identifies your local code directory. -->
    <property name="jakarta.root" value="<whereever your local source code
    is>"/>

    <!-- A property locating the output artifact of the library -->
    <property name="velocity.output"
    value="${jakarta.root}/jakarta-velocity/bin/velocity-1.3.jar"/>

    <!-- Velocity builds using Ant, so execute its build process -->
    <ant dir="${jakarta.root}/jakarta-velocity/build" inheritAll="false"/>

    <!-- Copy the resulting jar file into the Maven directory, so other
    projects use the one that got compiled instead of some other one. -->
    <copy overwrite="true" file="${velocity.output}"
    todir="${maven.repo.local}/velocity/jars"/>


    Note that all of the tags used in this process happen to be Ant tags, one of
    the nice things about Maven.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Plim at May 26, 2003 at 5:28 pm
    Thanks brett and lester.
    My 3rd party libs seems to be working finally,
    but my own libs are still giving me problems.
    Guess I can't avoid maven-ising them as well.
    pengster



    -----Original Message-----
    From: Lester Ward
    Sent: Friday, May 23, 2003 6:50 AM
    To: 'Maven Users List'
    Subject: RE: Newbie: How to configure 3rd party and internal
    dependencies in project.xml

    So how do I configure my project.xml to use the 3rd party libraries
    within Maven's repository? and,..
    If your project is mavenised, you would then use maven
    jar:deploy to put your artifacts into that repository.
    If the lib isn't Mavenized, I usually do this after invoking its build
    script (using velocity as an example):

    <!-- A property that identifies your local code directory. --> <property
    name="jakarta.root" value="<whereever your local source code
    is>"/>

    <!-- A property locating the output artifact of the library -->
    <property name="velocity.output"
    value="${jakarta.root}/jakarta-velocity/bin/velocity-1.3.jar"/>

    <!-- Velocity builds using Ant, so execute its build process --> <ant
    dir="${jakarta.root}/jakarta-velocity/build" inheritAll="false"/>

    <!-- Copy the resulting jar file into the Maven directory, so other
    projects use the one that got compiled instead of some other one. -->
    <copy overwrite="true" file="${velocity.output}"
    todir="${maven.repo.local}/velocity/jars"/>


    Note that all of the tags used in this process happen to be Ant tags,
    one of the nice things about Maven.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmaven
postedMay 20, '03 at 6:02p
activeMay 26, '03 at 5:28p
posts14
users9
websitemaven.apache.org
irc#maven

People

Translate

site design / logo © 2019 Grokbase