Re: [gradle-dev] Translating Ivy dep version syntax to Maven in POM generation

Just to be clear, you're trying to maintain the dynamic constraint and NOT replace them with the resolved version? I point this out since it's conventional to publish a resolved POM and not the range query. I do see the use-case for publishing with a range, but in general it's not what people what.

Re: [gradle-dev] Parallel Compilation of the Native Extension

On 30 Jun 2014, at 12:21 pm, Daniel Lacasse wrote: > Thanks Adam for your insight. I agree that option #2 would probably be a > really good start. Unfortunately, for someone who is pretty new to the code > base, I would rather start with #1 by exposing n on the compile task, set it > to one b

Re: [gradle-dev] Parallel Compilation of the Native Extension

Thanks Adam for your insight. I agree that option #2 would probably be a really good start. Unfortunately, for someone who is pretty new to the code base, I would rather start with #1 by exposing n on the compile task, set it to one by default and have the logic there to fork compiler tag. I would

Re: [gradle-dev] Translating Ivy dep version syntax to Maven in POM generation

On 30 Jun 2014, at 7:18 am, WonderCsabo wrote: > I think we should specify the feature first. This > is the > syntax for Ivy dependencies, and here >

Re: [gradle-dev] Parallel Compilation of the Native Extension

On 30 Jun 2014, at 1:51 am, Daniel Lacasse wrote: > I have been using the native extension for Gradle inside an actual project > for a couple months. The biggest limitation I'm seeing is the inflexibility > of the compile task when compared to other build tool in the industry. The > --paralle

Re: [gradle-dev] Windows locking issue

On 28 June 2014 at 1:55:24 am, Gary Hale (gary.h...@gradleware.com) wrote: I've made a simple change to capture the file name in the exception when hashing fails so this at least provides a minimum of information when this sort of thing occurs, but it's pretty basic and doesn't really provide

Re: [gradle-dev] Add Args to RunTestExecutable for Native Test

I think option #2 is the best in term of code duplication. I will then extract the required implementation into an abstract class - org.gradle.api.tasks.AbstractExecTask which follow the same idea of the current AbstractCopyTask. I will move forward with this. On Sun, Jun 29, 2014 at 7:41 PM, Ad

Re: [gradle-dev] Add Args to RunTestExecutable for Native Test

On 30 Jun 2014, at 1:46 am, Daniel Lacasse wrote: > Should we have RunTestExecutable implement ExecSpec? > > Following the next story at: > https://github.com/gradle/gradle/blob/master/design-docs/testing-for-native-runtime.md, > I had some thinking about the design. > > We would probably wa

[gradle-dev] Re: Translating Ivy dep version syntax to Maven in POM generation

I think we should specify the feature first. This is the syntax for Ivy dependencies, and here

Re: [gradle-dev] Google Test Support

On the assumption that in 99% of cases the sources for a test component are implemented on top of a single framework, I think it's probably better to use a consistent: "src/MyComponentUnitTestSuite/c" instead of "src/MyComponentUnitTestSuite/cunit" and "src/MyComponentUnitTestSuite/googletest". 1.

Re: [gradle-dev] Translating Ivy dep version syntax to Maven in POM generation

Hi Yes it would be good if Gradle produced POM files that were valid to use in Maven! There are a few current limitations noted in https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#fix-pom-generation-issues, one of which is dynamic versions. It would be ok if any fix onl

[gradle-dev] Translating Ivy dep version syntax to Maven in POM generation

I found out that the gradle maven plugins can generate invalid POMs due to invalid version syntax. This is becuase most gradle users use the Ivy syntax, but that is illegal in the maven POM. Since Gradle supports both Ivy and Maven dependency version syntax, we could translate the version to maven

[gradle-dev] Parallel Compilation of the Native Extension

I have been using the native extension for Gradle inside an actual project for a couple months. The biggest limitation I'm seeing is the inflexibility of the compile task when compared to other build tool in the industry. The --parallel switch works great for concurrent execution of tasks. When it

[gradle-dev] Add Args to RunTestExecutable for Native Test

Should we have RunTestExecutable implement ExecSpec? Following the next story at: https://github.com/gradle/gradle/blob/master/design-docs/testing-for-native-runtime.md, I had some thinking about the design. We would probably want to sync up later with Test from Java with the implementation of th

Re: [gradle-dev] Google Test Support

I can see some confusion there. I was planing to go the same route as CUnit which is: sources { ${componentNameUnderTest}Test { googleTest(CppSourceSet) { srcDir } } } The plugin would automatically create the CppSourceSet name googleTest. I see a couple adv