maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bielby, Randy J" <RBIE...@amfam.com>
Subject RE: Jar help
Date Mon, 14 Jun 2004 15:17:28 GMT
First let me say that I really appreciate the responses I have recieved
on this issue.  They have been very helpful in at least giving me a
start as to how to resolve this challange.  I have been on other list
servs of this type where responses are critical, arrogant and basically
useless.  Not the case here... many thanks.

As far as John's response, I can see the need for this structure and
methodolgy.  But I struggle with this for a couple of reasons.

1 - My development staff is used to keeping their workspace in sync with
CVS and doing so thru the WSAD interface (ie Eclipse CVS perspective).
I'm not that concerned with "bloating" out the CVS respository.  Those
jars in the WEB-INF/lib typically do not change that often, if ever.
But they are duplicated on other projects, which I have no control over.
So, if I were to switch to the Maven approach, as right as it might
seem, I would then have to require developers to use two tools, CVS and
Maven, to keep their workspaces current.  I guess you could argue that I
could eliminate the direct access of CVS and do that via Maven, but I'm
not sure I want to go that route.  I'm in a large IT shop and swimming
upstream like this is not something I enjoy.  Due to the internal
corporate economy and corporate politics, our development structure is
very fragmented into smaller development teams all working on the same
code base.   The current build mechanism for developers is WSAD and CVS,
introducing Maven may be more then I want to bite off.  And in reality
more then the staff here could handle  I'm not saying I don't agree with
John, as I do.  It's just that the reality in large corporate
environments like mine, sometimes do not lend themselves to change.  I
am also swimming upstream with standards that are being mandated outside
of my area that do not fit with a tool like Maven.  In fact I'm
struggling to keep Ant and CVS as my build tools.

2 - While the idea of the Maven repository is nice, does it really make
sense in the context of corporate development?  There are many pieces of
an application that get assembled to create the end result, the artifact
if you will.  By introducing the Maven repo, we have now introduced an
additional repository as input for the build and development process.  I
would rather have a single source for all of the components of my
artifact.  In this case CVS.  While I think that the repo works very
well for some fo the open source projects etc, I think it introduces an
additional point of potential inconsitencies, at least in my
environment.  If the repo had an interface to CVS it then might become
more "sellable" in a corporate environment.  That way all components of
an application are contained with a single source control mechanism.
And if I could convince others outside of my immidiate team of the need
for a centralize repository for components/jars, this might be an
interesting endeavor.

Don't get me wrong, I do agree with most of what Maven is about.  I am
just having to pick and choose my battles based upon corporate culture
and desicions that are being made outside of my control.  

I'd be interested in hearing how others are maintaining an updated
workspace for developers while the build process is utilizing Maven.

Randy Bielby
x32258
 
 


-----Original Message-----
From: John Casey [mailto:jdcasey@commonjava.org] 
Sent: Friday, June 11, 2004 8:58 PM
To: Maven Users List
Subject: Re: Jar help


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


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


Mime
View raw message