4 ms·
Sounds like you had some poor experiences with people who didn't know what they were doing. The proper way to audit your dependencies is to run an in-house Mav
by oauea 6y ago
Sounds like you had some poor experiences with people who didn't know what they were doing.
The proper way to audit your dependencies is to run an in-house Maven repository server. Just like you would for npm, or any package repository really.
So you just spin up Sonatype Nexus, proxy the repositories you trust and disallow releases from being overwritten. That way you're certain the jar you're using today, is the exact same as the one you'll be using years from now.
Alternatively, if you have a vendor who ships their jars manually, you can just vet them, then upload them to your in-house Maven repository and have your developers pull them in as usual.
- withinboredom 6y agoWe do this. I had to work on a greenfield project and it used a ton of libs that weren’t in our repo. It was so annoying to have a list of repos to add to the in-house list, then discover things didn’t work, so now we need these. It literally added weeks of man-hours to the project, per day.
- eitland 6y ago> It literally added weeks of man-hours to the project, per day. Can you explain what exactly you mean here, because the way I read it realistic time estimates for the projects grew by weeks pr day which probably means - I misread - you wrote something you didn't mean Anyways it sounds like something was way off and I have worked on some projects with Maven and other systems.
- withinboredom 6y agoDue to the amount of bureaucracy and vetting required, each package needed four people to touch the task, it took about an hour each person (four man-hours). Then you throw in their dependencies and it grew to about 50 man-hours per top-level dependency.
- eitland 6y agoOK, so again not Mavens fault but an utterly insane bureaucracy? Because otherwise the workload should shrink fast after one has vetted the dependecies for a couple of packages?
- avereveard 6y agoI agree on "not maven fault" but I don't find that much bureaucracy insane, for one changing dependencies on a mature java project doesn't happen that often, and for another knowing licensing, possible patent violation and a scan against a known vulnerabilities database is not a bad thing to do and it's normal for it to take some time as it passes hand between different people, after all you don't want devs working on licensing and you don't want to waste legals just to run a package trough vuln scans software. beside, companies that care usually also have a database of previously cleared packages, so one can reduce one own work/delays by picking from the approved deps list.
- eitland 6y ago50 hours pr top level dependency not once or twice or ten times but every time does however sound like something "cache-like" is missing on the human level?
- avereveard 6y agotrue I was reasoning more on the 4 hour per package, which is in line. but you're right for sure the unique dependency graph can't be averaging that high
- oauea 6y agoYes, vetting everything takes a LOT of time. Regardless of the language, package manager, etc. We (small shop) don't vet the code of all of our dependencies, since we simply don't have the manpower. But we do run nexus to have the guarantee of version pinning. So something that is fine today will be fine in 5 years.