Did the install task move from the maven plugin?

Old Forum
1

I seem to need the ‘java’ plugin to get the install task, but that brings a bunch of stuff I don’t want, like creating a default jar. I just want to archive some files and have the abiliity to install them to the local maven cache or deploy them to our main maven repo.

The docs I found indicate that the maven plugin adds the ‘install’ task, but that doesn’t appear to be the case.

I’m also getting a deprecation warning that I don’t know how to get rid of: “Relying on packaging to define the extension of the main artifact has been deprecated and is scheduled to be removed in Gradle 2.0”

2

While the ‘maven’ plugin does provide the ‘install’ task, it only adds the task in the presence of the ‘java’ plugin. This hasn’t changed recently.

If you want to publish/install maven artifacts without the java plugin, you might want to consider the new maven-publish plugin. The ‘publish’ task will publish to a remote repository, while the ‘publishToMavenLocal’ task will ‘install’ to your maven local repository.

3

Thanks for the reply. I am interested in the maven-publish approach as well, but I was going to let it incubate for a bit more as I don’t want to have to make all our devs update their Gradle install just yet. (I may like working on the bleeding edge, but not everyone else is as comfortable with that.)

Since I’m disabling the JAR artifact (based on Luke’s post here http://gradle.1045684.n5.nabble.com/Maven-install-dist-not-jar-td4726649.html) and I have a classifier on the artifact I am producing (e.g. “windows-x86”) it seems that I trigger the deprecation warning mentioned above. Do you know how I can eliminate that warning while staying with the older ‘java’ and ‘maven’ plugins?

4

I tried the maven-publish plugin and it worked well, but I still get the deprecation warning “Relying on packaging to define the extension of the main artifact has been deprecated and is scheduled to be removed in Gradle 2.0”

Also, the version of the artifact in the file is no longer stored as 1.2.3-SNAPSHOT, but is now 1.2.3-{date}.{time}

In my local maven cache I don’t want to accumulate tons of different snapshots - just the latest snapshot for any given version is fine. How do I make it do that?

Thanks,

Scott

5

The deprecation warning is problematic, as there are many cases where you can’t do anything about it. You’ll just need to ignore it until we come up with either: 1. A proper solution to this problem 2. A way to ‘acknowledge’ a deprecation warning so that it stops displaying.

Regarding the snapshot versions generated by the ‘maven-publish’ plugin, there is no way to make Gradle use a non-unique snapshot for the ‘PublishToMavenLocal’ task. This could be a bug: what happens when you “install” a snapshot artifact using Maven 3?

6

Good point… I think Maven 3 is doing the same thing… though it seems to also have a version with just the -SNAPSHOT instead of the timestamp.

7

It would be great if Gradle added a “discussion forum”-thingy on every documentation page, like e.g. PHP have. Then the fact “While the maven plugin does provide the install task, it only adds the task in the presence of the java plugin. This hasn’t changed recently.” could have been put there by some ordinary user (since the documentation is blatantly MISSING this).