groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Amerige <>
Subject Re: Remove Version from File Names in Distributions; Add Manifest
Date Wed, 29 Jul 2015 11:52:26 GMT
On 7/29/2015 1:41 AM, Jochen Theodorou wrote:
> But Steve, I do have a question...
> Normally the things you describe are part of the installation process 
> as well as making a package for the system installation. That means 
> normally you want a system package. Installing software packages 
> manually in a system with a packaging manager is usually a bad idea.
> GVM was mentioned, but GVM is not for a system-wide installation like 
> Steve wants it. And it is (currently) not a way to provide libraries 
> for usage by applications outside of a GVM package.

Some issues that large enterprises typically face include that dynamic 
tools that resolve dependencies are not permitted.  There are many 
reasons for this: everything from legal (third-party jars, including 
version changes, must be approved), to having centralized control of 
which jars engineers have access to for their particular product and for 
their particular intended release event.  And, developers tend to use 
either Eclipse or IntelliJ IDEs, while some few do everything command 
line with environment variables or scripts helping compilation to find 
jars.  Developer environments need to include the specific 
network-accessible jars they need. These jars are organized into groups 
that are approved and are consistent for a particular release event.  
Having release numbers on the jars themselves would cause problems in 
which developer environments would need to be reconfigured when jar 
updates are mandated.  What seems reasonable for small to medium 
projects sometimes isn't appropriate for very large scale projects 
involving thousands of developers.

Fortunately, we have excellent build and release engineers who take 
third-party jars and fit them into our system so that all concerns are 
addressed.  Since it doesn't seem that our needs are shared by others, 
it's just fine to leave it at that.

Steve Amerige
Principal Software Developer, Fraud and Compliance Solutions Development
SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617

View raw message