6 ms·

Gradle is pretty tightly integrated with the IDE now, and in general I find myself rarely having to troubleshoot build problems with Android studio. Adding new

Gradle is pretty tightly integrated with the IDE now, and in general I find myself rarely having to troubleshoot build problems with Android studio. Adding new dependencies is as simple as adding a single line to the build.gradle file, it's great.

dkopi 12y ago
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.
- JshWright 12y ago
  That's still awful...
  - jspaetzel 12y ago
    ...ly good
  - lern_too_spel 12y ago
    I'm interested in how you would do it better. This syntax seems fantastic to me, both terse and readable.
    - JshWright 12y ago
      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'.
      - heartbreak 12y ago
        Since you don't know about the ecosystem...there is no redundancy in his examples.
        dlubarov 12y ago
        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".
        oblio 12y ago
        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.
        ori_b 12y ago
        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.
        desdiv 12y ago
        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.
      - arjie 12y ago
        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.
    - peterashford 12y ago
      You appear to have forgotten the HN rules: For all statements X If X contains "Java" Emit comment Y where disparaging(Y) is true.
    - vorg 12y ago
      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.
      - ajoy39 12y ago
        I'm absolutely nitpicking here, but Gradle's style is closer to json.
        pjmlp 12y ago
        If at least they had used a JSON parser instead of a full blown (slow) language!
        vorg 12y ago
        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.
- bpodgursky 12y ago
  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.
  - bad_user 12y ago
    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.
- vorg 12y ago
  > 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>
  - nailer 12y ago
    Gradle still looks far more efficient to me.
    - ultramancool 12y ago
      The word I would use is "vague".

dkopi 12y ago

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.

JshWright 12y ago
That's still awful...
- jspaetzel 12y ago
  ...ly good
- lern_too_spel 12y ago
  I'm interested in how you would do it better. This syntax seems fantastic to me, both terse and readable.
  - JshWright 12y ago
    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'.
    - heartbreak 12y ago
      Since you don't know about the ecosystem...there is no redundancy in his examples.
      - dlubarov 12y ago
        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".
        oblio 12y ago
        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.
        ori_b 12y ago
        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.
        desdiv 12y ago
        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.
    - arjie 12y ago
      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.
  - peterashford 12y ago
    You appear to have forgotten the HN rules: For all statements X If X contains "Java" Emit comment Y where disparaging(Y) is true.
  - vorg 12y ago
    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.
    - ajoy39 12y ago
      I'm absolutely nitpicking here, but Gradle's style is closer to json.
      - pjmlp 12y ago
        If at least they had used a JSON parser instead of a full blown (slow) language!
        vorg 12y ago
        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.
bpodgursky 12y ago
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.
- bad_user 12y ago
  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.
vorg 12y ago
> 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>
- nailer 12y ago
  Gradle still looks far more efficient to me.
  - ultramancool 12y ago
    The word I would use is "vague".