Hacker News Reader

Comment by dkopi | Hacker News Reader

Maven: <dependency> <groupId>org.sakaiproject.edu-services.course-management</groupId> <artifactId>course-management</artifactId> <version>10.2</version> </dependency>

Gradle: compile 'org.sakaiproject.edu-services.course-management:course-management:10.2'

It's worth the transition.

View on HN

You're working in Intellij, it's the same number of keystrokes (the entire block is generated on <dep+tab). Making a decision about a build tool based on a few characters of boilerplate is insane.

If you like Gradle fine, but this is a really stupid thing to make that choice over.

Back in the day the standard project layout for Android was using either Ant or whatever magic Eclipse itself was doing. So developers wanting to import dependencies were copying JAR files in the "libs" folder. I don't remember Maven being in the picture at all.

> It's worth the transition

Or maybe it's worth formatting a Maven syntax sample in your comment just like an IDE would:

    <dependency>
      <groupId>org.sakaiproject.edu-services.course-management</groupId>
      <artifactId>course-management</artifactId>
      <version>10.2</version>
    </dependency>

Gradle still looks far more efficient to me.

The word I would use is "vague".

That's still awful...

...ly good

I'm interested in how you would do it better. This syntax seems fantastic to me, both terse and readable.

I don't know enough about the ecosystem to suggest a better alternative, but given the obvious redundancy, I'm not sure how it could be described as 'terse'.

Since you don't know about the ecosystem...there is no redundancy in his examples.

One could argue the conventions are poor though. groupId isn't really necessary. Most artifactIds are unique, and Maven Central could be the authority for (rare) naming conflicts. Works fine for ruby gems, apt repos, etc.

"com.google.guava:guava:18.0" could have been "guava:18.0".

Not really. You should have seen the discussion about the new Rust package manager. Putting everything top level means that good package names are taken forever by what is possibly abandonware. With namespacing everything is equal, first comers don't take over everything. Especially with the Maven/Java "use your reversed domain name" as groupId/package. Maybe it's a bit too verbose, but I'd still keep a group layer above the actual package name.

With namespacing, the namespaces end up being taken forever. A top level name of 'google/guava' isn't a big difference compared to namespace:google, artifact:guava.

If everyone followed the reversed-domain-name naming scheme, then namespaces taken up by abandonwares will get flushed out of the system after a few years.

That's a pretty huge "if" though.

I suppose you're talking about the "course-management" bit. That's just the way they named things. You could just as well have the following:

  <dependency>
    <groupId>net.java.dev</groupId>
    <artifactId>jvyaml</artifactId>
    <version>0.2.1</version>
  </dependency>

The artifactId is the name of the jar file.

You appear to have forgotten the HN rules:

For all statements X If X contains "Java" Emit comment Y where disparaging(Y) is true.

Maven's HTML/XML-style syntax in dkopi's example...

    <dependency>
      <groupId>org.sakaiproject.edu-services.course-management</groupId>
      <artifactId>course-management</artifactId>
      <version>10.2</version>
    </dependency>

...is equivalent to the Gradle/CSS-style ...

    dependency{
      groupID: "org.sakaiproject.edu-services.course-management"
      artifactId: "course-management"
      version: "10.2"
    }

...via simple syntactic transformations. Of course, IDE's go a step further and automatically generate and parse the whole shebang so the issue of syntax readability is moot if you use an IDE.

I'm absolutely nitpicking here, but Gradle's style is closer to json.

If at least they had used a JSON parser instead of a full blown (slow) language!

Using Groovy to parse their build scripts instead of an industry standard like JSON is what's holding Gradle back. But I suspect they'll open their build process up as an API now that Java provides lambdas.

Reply on news.ycombinator.com