So I would recommend using the simplified form when possible, but using the expanded form when extended artifact configuration is required.


On Wed, Sep 4, 2013 at 12:33 PM, Lincoln Baxter, III <lincolnbaxter@gmail.com> wrote:
Please see the gradle DependencyHandler docs for reference. I believe it explains how to resolve this :)

http://www.gradle.org/docs/current/dsl/org.gradle.api.artifacts.dsl.DependencyHandler.html

This states that the mechanism for declaring dependencies follows the form below:

apply plugin: 'java' //so that I can declare 'compile' dependencies

dependencies {
  //configuring dependency to specific configuration of the module
  compile configuration: 'someConf', group: 'org.someOrg', name: 'someModule', version: '1.0'

  //configuring dependency on 'someLib' module
  compile(group: 'org.myorg', name: 'someLib', version:'1.0') {
    //explicitly adding the dependency artifact:
    artifact {
      name = 'someArtifact' //artifact name different than module name
      type = 'jar'
      classifier = 'someClassifier'
    }
  }
}



On Wed, Sep 4, 2013 at 12:30 PM, Lincoln Baxter, III <lincolnbaxter@gmail.com> wrote:
Rather, it omits the packaging type:

               .setPackaging(forgeDep.getCoordinate().getPackaging())



On Wed, Sep 4, 2013 at 12:29 PM, Lincoln Baxter, III <lincolnbaxter@gmail.com> wrote:
The reason the dependency resolution fails is because the Gradle addon is omitting the dependency type from the coordinates, here. It is trying to resolve a JAR but only a POM exists.


   private GradleDependencyBuilder forgeDepToGradleDepBuilder(Dependency forgeDep)

   {

      return GradleDependencyBuilder.create()

               .setConfiguration(GradleDependencyConfiguration

                        .fromMavenScope(forgeDep.getScopeType()).getName())

               .setGroup(forgeDep.getCoordinate().getGroupId())

               .setName(forgeDep.getCoordinate().getArtifactId())

               .setVersion(forgeDep.getCoordinate().getVersion());

   }



On Wed, Sep 4, 2013 at 12:13 PM, Lincoln Baxter, III <lincolnbaxter@gmail.com> wrote:
Hey Adam,

Seems like things have been a bit quiet, but I've been reviewing the Forge Gradle Addon, and it's looking good! I've reproduced the dependency resolution issue you ran in to, but I'm not exactly sure where the error lies. Looking in to it.

You asked what to work on next. And I think that if you have finished all of the core/required functionality, it might be interesting to add a Forge UICommand/UIWizard to set up this eclipse config: 


That should make it easier for people to import Gradle projects into eclipse. Do you think this has value?

Alternatively, have you tested the scenario where a user attempts to use an existing Gradle project with Forge? It does not appear that this is tested yet, so that might be useful to explore. I believe this may raise a few new issues like, "Should we modify the user's gradle.build script in order to support Forge operations?" and "How should we ask them?"

It's possible that you could simply create a temporary build descriptor with the required forge library, execute that, then delete it. Or perhaps a new command in Forge to "Make a gradle project editable by forge."

Thoughts?

--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."



--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."



--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."



--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."



--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."