commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 10814] - Build environment configuration: Mavenize the build process
Date Mon, 22 Jul 2002 17:27:53 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10814>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10814

Build environment configuration: Mavenize the build process

jsdever@sympatico.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Build environment           |Build environment
                   |configuration               |configuration: Mavenize the
                   |                            |build process



------- Additional Comments From jsdever@sympatico.ca  2002-07-22 17:27 -------
> And there is the real problem, which is the reason I don't like JAR 
files
> checked into CVS either.  (Disk space isn't expensive enough to be a
> deterrent any more :-)
> 
> Let's assume that I want to build a single app that uses two different
> commons packages (A and B) that both depend on a third one (S).  In the
> runtime environment of my app, all three are going to be in the same 
class
> loader, so there can obviously only be one copy of S.
> 
> The challenge comes when A and B each depend on different versions of S.
> I don't find out about problems (say, incompatible method signatures due
> to changes between S1 and S2) until I'm doing integration testing (and
> only then if my test suite happens to include coverage for the 
combination
> in question).
> 
> I'd really like the compiler to help me catch things like this, by 
forcing
> *my* compilations of A and B to use a specific copy of S, no matter what
> the A and B project documentation declares to be the required versions.
> 
> In non-Mavenized builds like BeanUtils and Digester, I manage this 
through
> a shared "${user.home}/build.properties" file that declares which 
version
> of S's jar files should be used.  (This relies on using the same 
property
> name in each build script, which is generally true for Commons projects
> but not always true elsewhere.)
> 
> Fortunately, Jason just added similar functionality to Maven, so 
Mavenized
> apps will be able to do the same sort of "local override" configuration.
> So, there is now even less reason for projects to continue to check JAR
> files into CVS.
> 
> Craig
>

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message