maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bielby, Randy J" <>
Subject RE: Jar help
Date Mon, 14 Jun 2004 17:43:06 GMT

>-----Original Message-----
>From: Maczka Michal [] 
>Sent: Monday, June 14, 2004 10:31 AM
>To: 'Maven Users List'
>Subject: RE: Jar help
>> -----Original Message-----
>> From: Bielby, Randy J []
>> Sent: Monday, June 14, 2004 5:17 PM
>> To: Maven Users List
>> Subject: RE: Jar help
>> 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 
>> 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?  
>It makes much more sense in coorpoarte env. then in case of small open
>source project
>as in cooroprate evn, you need much more often to share and distiribute
>software artifacts
>in a standard way.
>>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. 
>Not really. Maven repository is competly different beast then 
>SCM repository
>and provides different features.

Is it?  Or is it just a difference of access protocol, http vs pserver?
Yes, I know that versioning etc is not part of the repo, but from a very
basic view of a jar containment mechanism, they could be used
interchangably.  I'm not that familiar with the plugins, but I would
guess that I could implement a repostory plugin that access a cvs
repository rather than a Maven one. By basically creating a module in
cvs that had contents very similar to a Maven repo, I could in theory
accomplish the same thing.

>> 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.
>Jars and other generated artifacts are not "sources" and SCM system are
>really useless for them.
>Are you going to keep javadocs in cvs as well?

No they are not sources, but the ARE components that contribute to the
overall completion of the resulting artifact.  There fore they should be
under some kind of version control mechanism.  In Maven case, that
mechanism is the Maven repository.  And instead of the version
attributes of a given file being a relationship to the file, it is part
of the name of the file.  From and auditing standpoint, I have to be
able to recreate an EAR from a single repository.  Plus I'm not sure we
would pass an internal audit if some of our distributed binary was not
maintained internally.  And then to top it all off, we have an
additional deployment tool (Harvest/AllFusion) for deploying to all
tiers above our development tier.  

>> 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
>Don't get me wrong either:
>With maven we are trying to realize certain philosophy of 
>build system. We
>are not looking for very flexible
>build system which is able to build any java project with 
>radom structure
>like ant does. 
>If somebody does not share our vision he might happier with other build

And I think that is what I am trying to figure out here.  I like the
philosophy of Maven very much.  I am just learning about and
unfortunately I don't have control of all the aspects of the build

>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message