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 17:51:01 GMT




>-----Original Message-----
>From: John Casey [mailto:jdcasey@commonjava.org] 
>Sent: Monday, June 14, 2004 12:17 PM
>To: Maven Users List
>Subject: RE: Jar help
>
>
>You mention that your company works through a large number of highly
>fragmented teams. Also, I'm sure that the codebase overall consists of
>many reusable libraries (proprietary). So, the question I have for you
>is:
>
>Is your company's inter-team communications so good that you can
>checkout the sources for each dependency project and build 
>them from CVS
>without worrying about pinning a particular dependency down to 
>a version
>so you don't have to develop against a backdrop of moving targets? What
>I mean is, when you compile, are you retrieving a particular SCM tagged
>version for the dependency projects, or simply pulling HEAD? This
>matters, because if you're developing against the HEADs of all of your
>dependency projects, that has to be hell, and it effectively unites all
>of the projects into one release cycle. If you're pulling based on some
>SCM tag (ex. PROJ_2_0_1), then you're essentially doing what 
>maven does,
>except that as soon as you put the artifact into your WEB-INF/lib, you
>lose the version information for your dependencies. Using the 
>repository
>gives you an easy way to pin down your dependencies and not have to
>constantly rebuild them. 
>
>It can therefore: (a) stabilize your development effort in fragmented
>environments if you're developing against one large roiling pool of
>HEADs, and (b) lower the cost of a given build by using prefab jars for
>a given set of dependency/version combinations.
>
>I understand your worries about the one-tool vs. two-tool issue; we're
>experiencing some of that here as well. And believe me, I know what
>corporate inertia can be like. I'm not sure how best to address that
>particular issue (the inertia), but I can say with confidence that once
>you've changed over from ant to maven throughout the company's 
>codebase,
>you'll likely be very glad you did. You get to automatically take
>advantage of these structures with any new maven plugins, etc.
>
>One thing that has made our internal repo very useful where I work is
>the ability to build on the maven process and do things like assemble
>binaries (.tgz, .zip) which are custom-built, coherent 
>applications that
>are tailored for deployment to a particular environment. Since the
>application itself is often a conglomerate of many libraries, this
>process simply involves assembling an archive of all the 
>libraries, plus
>the glue that makes the application coherent (jsps, configs, etc.), and
>applying a set of environment properties to this bundle. This 
>would take
>much longer and probably be much more complex were I to 
>attempt building
>each artifact from SCM. I don't have to, because I already have most of
>my dependencies in the repo (from previous testing iterations, etc.).
>Just food for thought.
>
>Also, I want to throw in a little plug for the future. While 
>it's a long
>way from being ready, and many will likely criticize me for even
>mentioning it, maven2 (next-gen maven) will accommodate the idea of a
>cascading source-build system sort of like what I think you're
>describing below. It's kind of like a ports tree (if you're familiar
>with BSD), except much more dynamic. I only mention this so you know
>that many of us are already thinking about that sort of requirement.
>
>Anyway, I know that maven isn't the right answer for everyone. It takes
>a certain mindset (corporate as well as individual) to use it. 
>It breaks
>many of the traditional codebase management practices. Most 
>importantly,
>it, like Ant or anything, is hard to adopt with a large set of 
>projects.
>You have entrenched practices, and attitudes associated with these
>practices. But it's important to recognize that _any_ change 
>you make in
>codebase management will require the same level of effort. My advice is
>to let maven adoption be viral; let users see the advantages for
>themselves. Maven seems to be pretty good at spreading in this way,
>since the alternative (*cough*Ant) requires a _lot_ of effort 
>to do what
>maven provides in a nearly effortless fashion. So, start small, and
>emphasize the Right Way(tm) on a small scale. This will get you a lot,
>strictly on reporting, etc. convenience. (Show them the jcoverage,
>junit, and checkstyle reports to get them going ;).

I did, that's how I got into this mess ;)  Now I just have to find a way
to get all the goodies that come with Maven and fit it into our current
structure, or bend the current structure a little to fit Maven.  I'm
just not sure if I can bend it enough.  I don't want to have to "crow
bar" Maven into my development process and vice versa.  I have people
twice removed from the development and build process, mandating
standards that make absolutely no sense.  Other then to make someone
else inability to perform a task that meets the development teams
requirements, somehow easier.


>
>Good luck.
>
>HTH
>-john
>
>On Mon, 2004-06-14 at 11:17, Bielby, Randy J wrote:
>> 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