opened
sanderson-sfdc
username_0
I'd love to be able to do something like this:

`repositories {
    mavenCentral()
}

plugins {
    id 'com.github.username_1.dita-ot-gradle' version '0.5.0'
}

dependencies {
    compile 'com.github.dita-ot:dita-ot-minimal:1.8.2'
}`

rather than have to do a prior install.  This works well with the other enhancement about running an install task.  For an automated continuous integration system I could then start from a clean VM and run a build with all my extensions.
Use dita-ot-minimal gradle package instead of requiring an installed version
issue
created
eerohele
username_1
That *would* be nice. To be honest, I hadn't realized that was an option.

Although I suppose it'd be better to use `org.dita-ot:dost:3.0` instead, since it seems like the artifact at `com.github.dita-ot` hasn't been updated in quite a while.

I'll have to look into whether I can make that work. I'm not sure how you'd call DITA-OT in this scenario.
comment
created
sanderson-sfdc
username_0
Are you sure you're using a valid DITA-OT directory?

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED'

What plugin file is it looking for?
comment
created
sanderson-sfdc
username_0
I'm pretty sure dost is just the jar, not the entire OT package.  If we can get this working, I'm sure we can get some more recent OT packages made available.
comment
created
eerohele
username_1
It's looking for either `config/plugins.xml` or `resources/plugins.xml` in the DITA-OT directory. I might be wrong, but I think that file didn't yet exist in DITA-OT 1.8.

It might also be that that approach doesn't work because the DITA-OT Gradle Plugin is looking for the file before the `extractOt` task is executed. I'll need to investigate to be sure.

An alternative solution to defining a Maven dependency would be to use the [Gradle Download Task](https://github.com/michel-kraemer/gradle-download-task) to download the [DITA-OT distribution package](https://github.com/dita-ot/dita-ot/releases/download/3.0/dita-ot-3.0.zip), extract it, and point the DITA-OT Gradle Plugin to use that installation. I think I might actually prefer that option.

I'll see if I have the time to look into this over the weekend.
comment
created
fviolette
username_2
I favor the second approach mentioned too: for one particular project, authors always build locally first . It's extremely helpful to rely on DITA-OT Gradle with the Wrapper and couple of other helper plugins – like grgit, gradle-download-task and saxon-gradle :+1:

Defining `ditaOt.dir` with a closure within the `dita` task does the job:

```
plugins {
    id "de.undercouch.download" version '3.4.2'
    id 'com.github.username_1.dita-ot-gradle' version '0.5.0'
    id 'com.github.username_1.saxon-gradle' version '0.3.0'
}

def ditaOtVersion = '2.5.1'

task downloadZipFile(type: Download) {
    src "https://github.com/dita-ot/dita-ot/releases/download/${ditaOtVersion}/dita-ot-${ditaOtVersion}.zip"
    dest new File(buildDir, "dita-ot-${ditaOtVersion}.zip")
    overwrite false
}

task downloadAndUnzipFile(dependsOn: downloadZipFile, type: Copy) {
    from zipTree(downloadZipFile.dest)
    into buildDir
}

dita {
    doFirst {
        ditaOt.dir "${buildDir}/dita-ot-${ditaOtVersion}"
    }
    input 'guidelines.ditamap'
    output outputDir
    transtype 'html5'
}

defaultTasks 'downloadAndUnzipFile', 'dita'
```
comment
created
sanderson-sfdc
username_0
Great solution @username_2.  You mention you'd prefer this way than the dependency, because it would allow people to build locally.

I think the way to resolve that would be to have two Maven/gradle packages; one that's a "full" DITA-OT install, with all the scripts you mention, and another, a "core" DITA-OT that is aimed at gradle-only usage.
comment
created
eerohele
username_1
Sorry about the delayed response.

@username_2: Using `doFirst` inside `dita` is a nice trick! That hadn't occurred to me.

It might actually be better if the plugin didn't require DITA-OT to be present in the configuration phase at all so that you would't need to use `doFirst`, but I'm not sure I can make that change in a backwards-compatible way.
comment
created
fviolette
username_2
@username_1 @username_3 Would `plugins` fit in this closure? Last time I checked it didn't but I don't recall to be honest.

Generally speaking, fully support the last remark :+1:
comment
created
lionelmoi
username_3
I actually don't use the 'plugin' mechanism... I use I use an 'exec' task to call the 'dita --install' command after copying my plugins in the 'plugins' folder.

@username_1 
"It might actually be better if the plugin didn't require DITA-OT to be present in the Gradle configuration phase"

That would be great indeed!
comment
created
eerohele
username_1
This doesn't seem too difficult. I modified the plugin so that this works:

```groovy
plugins {
    id "de.undercouch.download" version '3.4.2'
    id 'com.github.username_1.dita-ot-gradle' version '0.6.0-SNAPSHOT'
}

def ditaOtVersion = '3.0.4'

task downloadZipFile(type: Download) {
    src "https://github.com/dita-ot/dita-ot/releases/download/${ditaOtVersion}/dita-ot-${ditaOtVersion}.zip"
    dest new File(buildDir, "dita-ot-${ditaOtVersion}.zip")
    overwrite false
}

task downloadAndUnzipFile(dependsOn: downloadZipFile, type: Copy) {
    from zipTree(downloadZipFile.dest)
    into buildDir
}

defaultTasks 'dita'

dita {
    dependsOn downloadAndUnzipFile
    ditaOt "${buildDir}/dita-ot-${ditaOtVersion}"
    input 'dita/root.ditamap'
    transtype 'html5', 'pdf'
}
```

I'll just need to clean up the code and write some tests before I can release a new version of the plugin.

Then again, it might be convenient if you could just define something like `ditaOtVersion`. The plugin would then download that DITA-OT version from GitHub, install any plugins you've specified in `plugins`, then run your build.

That's a bigger effort, though, and I'm not sure I'll have the time to get to that any time soon, I'm afraid.
comment
created
lionelmoi
username_3
You rock!
comment
created
eerohele
username_1
I looked into modifying the plugin so that you'd just have to specify a DITA-OT version, and the plugin would then download and install it so that you could just start publishing.

The downloading bit isn't too difficult, but I haven't yet found a way to specify the DITA-OT version so that it works.

Also, adding support for installing plugins isn't very easy, because there's no super-straightforward and reliable way of checking whether a plugin is installed. The current implementation doesn't seem to take this into account.

Furthermore, doing that while retaining backwards compatibility is quite tricky.

At the moment, my thinking is that I'll add support for making it easier to use the plugin in conjunction with the Download plugin and leave it up to the user to make things work.
comment
created
eerohele
username_1
I'm quite swamped at the moment, but I'll try to do it as soon as I can.
comment
created
eerohele
username_1
Note, though, that the API is subject to change at this point.
comment
created
fviolette
username_2
Initial tests work OK on my end (no plugins).
comment
created
lionelmoi
username_3
Defining the ditaOt.dir during execution phase seems to work for me too. 

I can't make plugins work yet but I may not be using it right.
comment
created
eerohele
username_1
Plugins aren't supported yet. It's a bit complicated. See #19.

Let's continue the discussion there.
comment
created
eerohele
username_1
0.6.0 is out with support for downloading DITA-OT and installing plugins from the plugin registry prior to publishing things.

See the buildfile [`download`](https://github.com/username_1/dita-ot-gradle/blob/master/examples/download/build.gradle) example for details.
comment
closed
eerohele
username_1
issue