You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Sonnek, Ryan" <Ry...@bpc.com> on 2003/05/20 20:02:10 UTC
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
<ma...@bpc.com> ryan.sonnek@bpc.com
RE: packaging ear files
Posted by "michal.maczka" <mi...@cqs.ch>.
> -----Original Message-----
> From: news [mailto:news@main.gmane.org]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
Re: Newbie: How to configure 3rd party and internal dependencies
in project.xml
Posted by Brett Porter <bp...@f2network.com.au>.
> 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
Newbie: How to configure 3rd party and internal dependencies in project.xml
Posted by plim <pe...@correlationtech.com>.
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
Re: packaging ear files
Posted by Mauro Talevi <ma...@aquilonia.org>.
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
Re: packaging ear files
Posted by Rafal Krzewski <Ra...@caltha.pl>.
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
RE: packaging ear files
Posted by "michal.maczka" <mi...@cqs.ch>.
> -----Original Message-----
> From: Rafal Krzewski [mailto:Rafal.Krzewski@caltha.pl]
> 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
Re: packaging ear files
Posted by Rafal Krzewski <Ra...@caltha.pl>.
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
RE: packaging ear files
Posted by Michal Maczka <mm...@interia.pl>.
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 [mailto:Ryan.Sonnek@bpc.com]
> 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
>
> <ma...@bpc.com> 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