5 ms·

apples and oranges, the name conflict was perfectly disambiguated by the use of the mandatory group identifier. npm design was so bad that you could at the beg

apples and oranges, the name conflict was perfectly disambiguated by the use of the mandatory group identifier. npm design was so bad that you could at the beginning upload over an existing version of your package name and break dependencies retroactively even to people that pinned versions. if you want to try some good old whataboutism, at least try to be in the same ballpark.

littlestymaar 6y ago
Nobody in this thread argues that npm is not bad (it is), the current topic is: “is maven's design[1] better” and there is little evidence on this front. Maven was (yes, I'm using the past on purpose) not a panacea that later system failed to equal: it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. In 2014, last time I did Java for work, the main security feature against supply chain attack was: “we are getting .jar files individually and not using maven because it's a fucking mess” [1]: not implementation, which is what's make npm arguably a pile of shit
- stuff4ben 6y ago
  Maven is ubiquitous in the Java world and the de-facto package/dependency management system out there. Has been since the mid-2000's and as of 2018 when I last did Java development (Scala really), it is still widely in use. Getting jar files manually would have me running from whatever company that was doing that. Let me guess, they wrote all their code in Notepad because IDE's are a "fucking mess" too right?
  - littlestymaar 6y ago
    You vastly underestimate the level of bureaucracy that can exist in the biggest Java users of this planet (namely banks and public administrations): in these organization (at least a few years ago, the Solarwind attack shows it may not be the case anymore) every single dependency you want to use must be justified, and then is audited by a dedicated team, which ends up handing you the validated .jar. It was a common development practice in these entities (I was working as a contractor, for different customers), most of them have been using computer programs at there core long before the internet went mainstream.
    - GrinningFool 6y ago
      That bureaucracy makes sense to me. You're _shipping_ those dependencies. When something misbehaves or allows an exploit it doesn't matter if it happened in a dependency or not -- the dependency isn't the one who's accountable to customers and the regulatory authorities. It sounds like the processes in use to do this may have been pretty crappy in the organizations you've been with, but it also sounds like it would take less time than implementing a dependency's functionality from scratch in most cases you'd want to pull in a dep.
    - the_af 6y ago
      So you worked with customers using some particularly strict vetting protocols. That's a far cry from claiming Maven never reached the popularity in the Java world that NPM has in the Javascript world -- Maven is the dependency manager in the Java world. The entities you worked for are the exception. Another thing that strikes me as odd in your comparison: those customers you worked with wouldn't have used javascript+NPM either, since it has all of the problems of Maven and external deps and then some! So what exactly are we comparing then?
    - jjav 6y ago
      This "bureacucracy" is very necessary if security is at all a concern. Solarwinds is hot to talk about right now but it has always been the case that having a build download code willy-nilly is a recipe for getting attacked. In any security conscious organization the only way to pull dependencies is from a local trusted repository. And the only way they get placed there is through a review process.
- the_af 6y ago
  Maven is/was huge in the Java world. For years it was pretty much the only way to resolve dependencies, until people got fed up with its many idiosyncrasies. > “we are getting .jar files individually and not using maven because it's a fucking mess” That seems odd and a bizarre edge case. Nobody worked like that with Java projects, and I bet nobody does today either.
  - eitland 6y ago
    > until people got fed up with its many idiosyncrasies. Many of us still prefer Maven. Having to deal with other people's artistic Gradle files works wonders when it comes to understanding the goodness of standards.
    - the_af 6y ago
      Yes, of course. Another example: SBT was supposed to be the "savior" in the Scala world and... I still have nightmares about SBT from a couple of years ago. Maybe it's finally become usable and intelligible in recent years.
  - didibus 6y ago
    I think you're confusing the client side build tool Maven with the artifact repository Maven. Gradle for example still uses Maven for its dependency artifact repository. So Maven is still the standard for Java.
    - the_af 6y ago
      I am confusing what now? I'm the one arguing Maven is huge and that the parent post I'm replying to is mistaken. I never mentioned Gradle, that was a sibling comment.
      - didibus 6y ago
        I might have misinterpreted you the first time around. I thought you were saying that people have moved on from Maven, when in fact Maven is still the defacto repository for open source Java projects. Sorry if I did.
- 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 ago
    We 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 ago
        Due 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 ago
        OK, 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?
- eitland 6y ago
  > it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. I thought IRS forms were hard? I have more than a decade of experience collected from work with CDs (Delphi), downloaded libraries (Delphi, Java, PHP), Ant (Java), Maven (Java), PEAR (PHP), Composer (PHP), Nuget (.Net), NPM/Yarn (Javascript/TypeScript) and Gradle (Java/Kotlin). Two of these have been somewhat easy to work with for as long as I used them: Maven and Yarn. I hear NPM us usable now, but it absolutely wasn't good early on. > “we are getting .jar files individually and not using maven because it's a [...] mess” It seems obvious from your writing that you either worked in a place that was really serious about security or had no clue. Both could result in this conclusion, but based on your writing my bet is on the latter, i.e. they were clueless. Edit: Reading your comment here: https://news.ycombinator.com/item?id=26091480 https://news.ycombinator.com/item?id=26091480 I have concluded that it was a mix of those two: the people you worked for were trying really hard to be really serious about security and failing to automate it.

littlestymaar 6y ago

Nobody in this thread argues that npm is not bad (it is), the current topic is: “is maven's design[1] better” and there is little evidence on this front. Maven was (yes, I'm using the past on purpose) not a panacea that later system failed to equal: it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. In 2014, last time I did Java for work, the main security feature against supply chain attack was: “we are getting .jar files individually and not using maven because it's a fucking mess” [1]: not implementation, which is what's make npm arguably a pile of shit

stuff4ben 6y ago
Maven is ubiquitous in the Java world and the de-facto package/dependency management system out there. Has been since the mid-2000's and as of 2018 when I last did Java development (Scala really), it is still widely in use. Getting jar files manually would have me running from whatever company that was doing that. Let me guess, they wrote all their code in Notepad because IDE's are a "fucking mess" too right?
- littlestymaar 6y ago
  You vastly underestimate the level of bureaucracy that can exist in the biggest Java users of this planet (namely banks and public administrations): in these organization (at least a few years ago, the Solarwind attack shows it may not be the case anymore) every single dependency you want to use must be justified, and then is audited by a dedicated team, which ends up handing you the validated .jar. It was a common development practice in these entities (I was working as a contractor, for different customers), most of them have been using computer programs at there core long before the internet went mainstream.
  - GrinningFool 6y ago
    That bureaucracy makes sense to me. You're _shipping_ those dependencies. When something misbehaves or allows an exploit it doesn't matter if it happened in a dependency or not -- the dependency isn't the one who's accountable to customers and the regulatory authorities. It sounds like the processes in use to do this may have been pretty crappy in the organizations you've been with, but it also sounds like it would take less time than implementing a dependency's functionality from scratch in most cases you'd want to pull in a dep.
  - the_af 6y ago
    So you worked with customers using some particularly strict vetting protocols. That's a far cry from claiming Maven never reached the popularity in the Java world that NPM has in the Javascript world -- Maven is the dependency manager in the Java world. The entities you worked for are the exception. Another thing that strikes me as odd in your comparison: those customers you worked with wouldn't have used javascript+NPM either, since it has all of the problems of Maven and external deps and then some! So what exactly are we comparing then?
  - jjav 6y ago
    This "bureacucracy" is very necessary if security is at all a concern. Solarwinds is hot to talk about right now but it has always been the case that having a build download code willy-nilly is a recipe for getting attacked. In any security conscious organization the only way to pull dependencies is from a local trusted repository. And the only way they get placed there is through a review process.
the_af 6y ago
Maven is/was huge in the Java world. For years it was pretty much the only way to resolve dependencies, until people got fed up with its many idiosyncrasies. > “we are getting .jar files individually and not using maven because it's a fucking mess” That seems odd and a bizarre edge case. Nobody worked like that with Java projects, and I bet nobody does today either.
- eitland 6y ago
  > until people got fed up with its many idiosyncrasies. Many of us still prefer Maven. Having to deal with other people's artistic Gradle files works wonders when it comes to understanding the goodness of standards.
  - the_af 6y ago
    Yes, of course. Another example: SBT was supposed to be the "savior" in the Scala world and... I still have nightmares about SBT from a couple of years ago. Maybe it's finally become usable and intelligible in recent years.
- didibus 6y ago
  I think you're confusing the client side build tool Maven with the artifact repository Maven. Gradle for example still uses Maven for its dependency artifact repository. So Maven is still the standard for Java.
  - the_af 6y ago
    I am confusing what now? I'm the one arguing Maven is huge and that the parent post I'm replying to is mistaken. I never mentioned Gradle, that was a sibling comment.
    - didibus 6y ago
      I might have misinterpreted you the first time around. I thought you were saying that people have moved on from Maven, when in fact Maven is still the defacto repository for open source Java projects. Sorry if I did.
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 ago
  We 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 ago
      Due 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 ago
        OK, 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?
eitland 6y ago
> it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. I thought IRS forms were hard? I have more than a decade of experience collected from work with CDs (Delphi), downloaded libraries (Delphi, Java, PHP), Ant (Java), Maven (Java), PEAR (PHP), Composer (PHP), Nuget (.Net), NPM/Yarn (Javascript/TypeScript) and Gradle (Java/Kotlin). Two of these have been somewhat easy to work with for as long as I used them: Maven and Yarn. I hear NPM us usable now, but it absolutely wasn't good early on. > “we are getting .jar files individually and not using maven because it's a [...] mess” It seems obvious from your writing that you either worked in a place that was really serious about security or had no clue. Both could result in this conclusion, but based on your writing my bet is on the latter, i.e. they were clueless. Edit: Reading your comment here: https://news.ycombinator.com/item?id=26091480 https://news.ycombinator.com/item?id=26091480 I have concluded that it was a mix of those two: the people you worked for were trying really hard to be really serious about security and failing to automate it.