[forge-dev] Checking in on Gradle Addon

[Lincoln Baxter, III]

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 at 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 at 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 at 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:
>>>
>>> http://www.gradle.org/docs/current/userguide/eclipse_plugin.html
>>>
>>> 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130904/c36eeb5d/attachment.html