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.
Enjoy,
Steve Amerige
Principal Software Developer, Fraud and Compliance Solutions Development
SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617
