[MINSTALL-126] localRepositoryPath for install like for install-file

[jira-importer]

Michael Vorburger opened MINSTALL-126 and commented

I believe there are real world use cases where to have a localRepositoryPath available for maven-install-plugin's install goal like it currently is for the install-file goal would be useful.

http://blog2.vorburger.ch/2016/06/maven-install-into-additional.html is a Blog post I wrote with some background about why this would be useful.

---

Issue Links:

• MNG-3655 Allow multiple local repositories

• MNG-4980 Shared local repository

• MNG-6793 Sharing local repo for dependencies and a separate local repo for project

Remote Links:

• GitHub Pull Request #109
  

3 votes, 8 watchers

[jira-importer]

Karl Heinz Marbaise commented

To be honest from the intention of the maven-install-plugin something like what you wish does not make sense. Furthermore if i take a look into Karaf docs there is something:

Only Maven based URLs and Maven SNAPSHOTs will actually be updated automatically.

which means you can use a file url or snapshots...so i don't see the real problem here ?

BTW: Discussion about such issues would be better done on the mailing list than in JIRA...Furthermore it would be better having the information in the JIRA about the use case instead of a link to blog...

[jira-importer]

Jesse Glick commented

Use case from StackOverflow

[jira-importer]

Guillaume Boué commented

In this use case, the OP wants to remove their installed artifacts from the local repo.

I would guess that they use a consistent set of Maven coordinates, so for this, one could use the maven-dependency-plugin:purge-local-repository MOJO and use the manualInclude property with -DmanualInclude=my.groupId. This would remove all artifacts from the local repo under the groupId my.groupId.

[jira-importer]

Michael Vorburger commented

Yes Karaf only updates Maven based URLs and Maven SNAPSHOTs, and that's exactly what this is for; a proposed new option to be able to install artifacts into an additional (!) local Maven repository. I use this regularly (we have it in https://github.com/opendaylight/odlparent/blob/master/odlparent-lite/pom.xml#L273).

Would you like to elaborate in more details on what you mean by "you can use a file url or snapshots" - where? (Using maven-deploy-plugin (with a file:// URL parameter) instead of the maven-install-plugin in this context is no good, because deploy adds a unique time stamp to JAR file names (and its uniqueVersion option appears to be broken; see also issues MDEPLOY-44 and MDEPLOY-211).)

BTW: I like my blog! You don't? Improvement Issues (without Fix Version) are perfectly fine for things like this IMHO. If you are the (sole?) current maintainer of maven-install-plugin, you are free to close issues where people try to contribute possible enhancements, of course. (To subscribe to mailing lists all over the universe to post an occasional suggestion like this, is too much email traffic overhead.)

[jira-importer]

Jesse Glick commented

In my case there is no simple list of coördinates I could purge in that fashion, as I work on numerous projects from time to time, and other people do releases in some of them.

[jira-importer]

Michael Vorburger commented

I've run into this again today in the context of https://bugs.opendaylight.org/show_bug.cgi?id=8050, realizing that the original "workaround" was stupid / limited, and so was motivated to make my first Maven contribution for this. Curious now if this can get merged - and a new maven-install-plugin released, some time? Happy to also back-port this from 3.0.0-SNAPSHOT to an e.g. 2.5.3, if there is engagement.

FTR: I've locally tested that change actually does work properly and allows one to install all artifacts (including attaches) into an alternative local repository using the install goal - just like the install-file goal already supports.

[jira-importer]

Tamas Cservenak commented

Am torn here... this "watch" thing (if am right, it relies on this and especially on Parser and these are "naive" implementations of maven repo.

In other words, while in maven2 times the local and remote repositories were pretty much similar (you could produce non-timestamped versions), this was intentionally changed in Maven3. So, "assuming" you take GAV and turn it into path may not be true anymore, especially as Maven3.9+ and above will introduce "split repository" and other nice things.

So, to me this for sure is not "install" (local repository involved), but you cannot support "deploy" to remote repository (due timestamped snapshot, Parser does not use maven metadata to figure out timestamped version), hence, this (to me) yields more like https://maven.apache.org/plugins/maven-stage-plugin/copy-mojo.html or alike, but here again "remote vs remote" repository is in play. So maybe a 3rd plugin that is dedicated (and uses same layout as Parser supports) is the proper solution, as Parser does not implements "local" nor "remote" repository in Maven3 sense. Is merely a hack.

In short, your own mojo that implements same layout as is supported by Parser is the way to go.