>-----Original Message-----
>From: John Casey [mailto:[EMAIL PROTECTED]
>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:[EMAIL PROTECTED]
>> 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
>[EMAIL PROTECTED]
>CommonJava Open Components Project
>http://www.commonjava.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
