You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Bielby, Randy J" <RB...@amfam.com> on 2004/06/11 20:32:31 UTC
Jar help
Hello,
First, I'm a newbie and just getting started. I'm trying to proof out
an existing build that is currently using Ant, while also making a
determination of Maven is a good choice for new projects.
I have a situation that I don't believe is unique but I can't seem to
find all the info I'm looking for. I have several projects with a
number of dependent jars. The development team is anywhere from 10-30
developers depending upon the project. We are using WSAD and have as
one of the projects in our workspace a webapp. This webapp contains all
the dependent jars within the WEB-INF/lib folder. All the other project
within the workspace are included as dependent jars in the EAR. I would
prefer that the compile uses the jars in the lib folder. This is the
ensure that the deployed runtime code is the same as what the developers
have developed against. I know this goes against Maven's perferred
method of retrieving dependencies for the repository. I know that I can
override this behavior, but I'm struggling with how to go about it.
I guess I could override the local repository to be the WEB-INF/lib, but
I'm not sure that will work due to the expected folder structure of the
repo. I could also just not use the dependencies and add the jar to the
classpath.
Also, due to corporate defined standards, my jar names cannot contain
the version number (don't ask). So I also need my jar dependencies to
be something like, log4j.jar instead of log4j-1.2.6.jar. I have tried
eliminating the version from the dependency but I get, log4j-.jar
instead.
Randy Bielby
Re: Jar help
Posted by Erik Husby <mh...@broad.mit.edu>.
Bielby, Randy J wrote:
>Hello,
>
>First, I'm a newbie and just getting started. I'm trying to proof out
>an existing build that is currently using Ant, while also making a
>determination of Maven is a good choice for new projects.
>
>I have a situation that I don't believe is unique but I can't seem to
>find all the info I'm looking for. I have several projects with a
>number of dependent jars. The development team is anywhere from 10-30
>developers depending upon the project. We are using WSAD and have as
>one of the projects in our workspace a webapp. This webapp contains all
>the dependent jars within the WEB-INF/lib folder. All the other project
>within the workspace are included as dependent jars in the EAR. I would
>prefer that the compile uses the jars in the lib folder. This is the
>ensure that the deployed runtime code is the same as what the developers
>have developed against. I know this goes against Maven's perferred
>method of retrieving dependencies for the repository. I know that I can
>override this behavior, but I'm struggling with how to go about it.
>
>I guess I could override the local repository to be the WEB-INF/lib, but
>I'm not sure that will work due to the expected folder structure of the
>repo. I could also just not use the dependencies and add the jar to the
>classpath.
>
>Also, due to corporate defined standards, my jar names cannot contain
>the version number (don't ask). So I also need my jar dependencies to
>be something like, log4j.jar instead of log4j-1.2.6.jar. I have tried
>eliminating the version from the dependency but I get, log4j-.jar
>instead.
>
>Randy Bielby
>
>
>
>
>
>
Well one thing you can do which is what I've done for my WebLogic builds
is to copy the dependencies from the repository to the WEB-INF/lib
folder. I do this with
<deploy:copy-deps todir="${wli.app.lib.dir}"/>
Where wli.app.lib.dir is a property pointing at the WEB-INF/lib folder.
As for getting rid of the version numbers, I believe you could do
something like
<j:forEach var="lib" items="${pom.artifacts}">
<j:set var="dep" value="${lib.dependency}"/>
<j:if test="${dep.getProperty('javalib')=='true'}">
<ant:mkdir dir="${maven.war.webapp.dir}/javalib"/>
<j:if test="${dep.type =='jar'}">
<ant:copy file="${lib.path}"
tofile="${maven.war.webapp.dir}/javalib/${dep.artifactId}.jar"
verbose="${squid.verbose}"/>
</j:if>
</j:if>
</j:forEach>
In the above, I have some jars in my dependency list that need to go to
a /javalib directory because they
are used by some applets. I tagged the dependency with the property
"javalib" so I only copy the jars
that need to be in the /javalib directory. I also don't want the
version number on the resulting file which is accomplished by the
${dep.artifactId}.jar name.
A dependency targeted for /javalib looks like
<dependency>
<groupId>Squid</groupId>
<artifactId>taskmaster</artifactId>
<version>${squid.version}</version>
<properties>
<javalib>true</javalib>
</properties>
</dependency>
Hope this helps. I too have embarked on the task of replacing Ant with
Maven, and have been pleased at
how easy it has been.
--
Erik Husby
Team Lead for Software Quality Automation
Broad Institute of MIT and Harvard
Rm. 2192 320 Charles St
Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.258.9227, mhusby@broad.mit.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar help
Posted by John Casey <jd...@commonjava.org>.
First of all, sorry for the long email.
The "right" way according to maven is probably going to seem tedious at
first from your point of view, but in the long run will probably save
you hours of headache:
I understand your desire to use WEB-INF/lib for the source of your
dependencies. However, I have a question about this. When in a
development scenario, are you versioning your dependencies right along
with everything else, such that WEB-INF/lib winds up in version control
too? If so, why?
The way I see it, there are two ways you can go on this. First, you can
choose to stick to the methodology you're using below, and probably use
something other than maven (JAM or ant might be a good choice). Second,
you can change your projects to _build_ the WEB-INF/lib from the
project.xml's set of dependencies, and manage a corporate repository for
proprietary artifacts. The second method is strongly preferred in the
maven world, and I'd like to take a second and try to convince you why
it's a good thing. The name of the jar file is irrelevant to this
choice, and I will explain this later.
If you have multiple projects, you're probably reusing many of the
dependencies in WEB-INF/lib (you even state that you have some
dependencies in the EAR, and probably referenced in the application.xml
or manifest.mf or somesuch). If any of these dependencies is
proprietary, this means that you have to update all the jars in all the
WEB-INF/lib-like locations in all projects in order to incorporate new
versions. It also means that your version control system is experiencing
bloat for storing the same file in different locations. Finally, since
the jar is a derivative of the source code, any proprietary jars are
essentially re-versioning a derivative of code you can already recover
via the sources (which are in version control themselves). From a
version control / codebase maintenance perspective, it's much easier to
centralize your storage of project artifacts (jars) and select from
these in order to make other artifacts (more jars, or wars, or ears, or
whatever).
Additionally, if you chose to publish a full description of your
project, including things like static code check results, and maybe
something like a dependency list, how would you produce this? This is
where the project.xml really becomes a powerful item. If you have the
name and version of a dependency, you can give a full description of
exactly what files are needed to run your code. For the sake of clarity
and recoverability, this can be invaluable. When you place the
project.xml under version control, you can now track these dependencies
(including version numbers, which I'm betting you can't recite to me
about the current version of your project). In the event you have to
recover to some previous incarnation of a project, you'll know exactly
which versions of which dependencies to look for.
As for the jar file names, you can simply use the <jar>jarname.jar</jar>
element within a <dependency/> specification. This will allow you to
have the following:
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.0</version>
<jar>commons-lang.jar</jar>
</dependency>
and have maven look for <repo>/commons-lang/jars/commons-lang.jar
instead of <repo>/commons-lang/jars/commons-lang-2.0.jar.
This is a pathetically incomplete reasoning for why you should use the
maven approach, and I'm sure you'll get some more detail from others on
the list, but I wanted to provide at least one voice of reason on this
topic. Maven is hard to get at first, but once you do it will change the
way you think about producing software. It may seem strange to do things
in the recommended way, but in the end it will save you time and effort,
and make your codebase much more usable both for producing software and
for reporting on progress, etc.
Hope it helps,
-john
On Fri, 2004-06-11 at 14:32, Bielby, Randy J wrote:
> Hello,
>
> First, I'm a newbie and just getting started. I'm trying to proof out
> an existing build that is currently using Ant, while also making a
> determination of Maven is a good choice for new projects.
>
> I have a situation that I don't believe is unique but I can't seem to
> find all the info I'm looking for. I have several projects with a
> number of dependent jars. The development team is anywhere from 10-30
> developers depending upon the project. We are using WSAD and have as
> one of the projects in our workspace a webapp. This webapp contains all
> the dependent jars within the WEB-INF/lib folder. All the other project
> within the workspace are included as dependent jars in the EAR. I would
> prefer that the compile uses the jars in the lib folder. This is the
> ensure that the deployed runtime code is the same as what the developers
> have developed against. I know this goes against Maven's perferred
> method of retrieving dependencies for the repository. I know that I can
> override this behavior, but I'm struggling with how to go about it.
>
> I guess I could override the local repository to be the WEB-INF/lib, but
> I'm not sure that will work due to the expected folder structure of the
> repo. I could also just not use the dependencies and add the jar to the
> classpath.
>
> Also, due to corporate defined standards, my jar names cannot contain
> the version number (don't ask). So I also need my jar dependencies to
> be something like, log4j.jar instead of log4j-1.2.6.jar. I have tried
> eliminating the version from the dependency but I get, log4j-.jar
> instead.
>
> Randy Bielby
>
--
John Casey
jdcasey@commonjava.org
CommonJava Open Components Project
http://www.commonjava.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar help
Posted by "Julian C. Dunn" <Ju...@cbc.ca>.
On Fri, 2004-06-11 at 14:32, Bielby, Randy J wrote:
> I have a situation that I don't believe is unique but I can't seem to
> find all the info I'm looking for. I have several projects with a
> number of dependent jars. The development team is anywhere from 10-30
> developers depending upon the project. We are using WSAD and have as
> one of the projects in our workspace a webapp. This webapp contains all
> the dependent jars within the WEB-INF/lib folder. All the other project
> within the workspace are included as dependent jars in the EAR. I would
> prefer that the compile uses the jars in the lib folder. This is the
> ensure that the deployed runtime code is the same as what the developers
> have developed against. I know this goes against Maven's perferred
> method of retrieving dependencies for the repository. I know that I can
> override this behavior, but I'm struggling with how to go about it.
Could you override the dependency retrieving by setting
"maven.jar.override=true" in your project.properties and then listing
the path to each of the JARs explicitly? In this case, the "structure"
does not have to respect the regular repo structure since you're not
overriding maven.repo.remote.
> Also, due to corporate defined standards, my jar names cannot contain
> the version number (don't ask). So I also need my jar dependencies to
> be something like, log4j.jar instead of log4j-1.2.6.jar. I have tried
> eliminating the version from the dependency but I get, log4j-.jar
> instead.
If you use the <jar> tag you can specify the filename explicitly.
- Julian
--
Julian C. Dunn, B.A.Sc. <Ju...@cbc.ca>
Software Developer, CBC New Media Operations
Office: 2C310-I * Tel.: (416) 205-3311 x5592
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org