Hacker News Reader

Comment by lern_too_spel | Hacker News Reader

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

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.

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.

Reply on news.ycombinator.com