Il 29/07/2015 13:52, Steve Amerige ha scritto:
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.
I don't think any of these reasons prevents the use of a build tool. For instance, having an internal repository server like Nexus or Artifactory would allow to control exactly which dependencies are made available to 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.
What it seems like to me is that these build and release engineers are just reinventing the wheel or probably that the environment they work in predates the modern build tools like Gradle or Maven. In my experience, I saw "big" enterprises manage things in insane ways (like environments where deployments consist of the unpacking a ZIP file - yes, NO way to delete obsolete files unless you contact a support team that MANUALLY performs these kind of operations!!! Another way to say that you can't perform refactoring on classes!!) in the name of "security" or "control". Just because people do crazy things it doesn't mean that they should be supported :-)
We may discuss about the fact that version number of file names might be redundant (once we have manifests), but it's also true that most (if not all) package management system I know of seem to go in this direction. Apart from Maven repositories, OSGi does the same, as well as Linux packages (deb and rpm files have versions in their names).
Just yet another 2 cents by one that doesn't miss the "JAR hell" of some years ago.
Mauro
