plugin development without release use case

the latter may be necessary anyway, for a use case of library development when using unbounded versions when dependency mediation is in play. Perhaps the best thing to do is to update on local install, if the local version is > the current release version.

Added LATEST artifact metadata for plugins ONLY, which is installed/deployed each time the plugin is. This is more correct than simply updating RELEASE when there is no release. I'm not sure what other issues there are relating to the dependency version ranges, however, so I'm assigning this to Brett for him to resolve. If my change has fixed the issue, this won't be hard to resolve.

doesn't actually fix it. the plugin resolver tries to resolve RELEASE still (as it should), and doesn't know to try LATEST. IT could possibly try LATEST if RELEASE was not resolvable... but that only helps when starting out.

Should now be fixed. I updated the CLI code to fix disabling of the plugin registry, and forced resolution of LATEST metadata during the version resolution process.

NOTE: LATEST metadata resolution isn't enabled unless you use '--check-plugin-latest' or put in <usePluginLatest/> in settings.xml.

this is really annoying. we need to make it such that any invocation of "m2 install" makes that plugin the default

note also that -cpl doesn't appear to be working.

need to write a new mojo for the plugin-plugin to update the version in the plugin registry when a plugin is installed...also, need to workup an IT to specifically test -cpl AND --check-plugin-latest.

added the updateRegistry mojo to the install phase for updating the plugin-registry.xml iff it's enabled.

the -cpl issue was actually caused by another issue (the one with RELEASE landing in the resolved version after failing to find a release version of the plugin).

sorry, that issue was MNG-832.

sorry to whine again....

"this is really annoying. we need to make it such that any invocation of "m2 install" makes that plugin the default"

sorry, I didn't mean to fix -cpl. To be honest, I'd rather remove it, or perhaps make it the default? Will that unnecessarily query the remote repo?

I don't understand. I just tested this, and after installing maven-projecthelp-plugin - with the plugin registry enabled - the new projecthelp entry was in fact recorded.

As for -cpl, it should be working again. Without it, there's no way it0013 and it0020 will work as-is...they will require some sort of hackery with <defaultGoal/> and a multi-module build in order to make this feature testable from the it0000 series.

What exactly is it you want me to do here? Checking LATEST will result in normal users potentially getting snapshot plugin versions (ie. unstable), so I don't think that's a great way to go. On the other hand, some people (namely plugin devs) will want to be able to use the snapshot versions of plugins, so sticking with RELEASE doesn't really work either. I'm not sure what would happen if we allowed a locally installed -SNAPSHOT version to persist (ie. will it resolve the snapshot updates on the remote repo?), but one thing is sure about that: the developer would have to run an install on that plugin at least once, in order to get the entry into the plugin registry (or hand-edit).

All of the above seems pretty nuanced and more than a little unintuitive to me. I think, since -cpl is currently working and NOT the default, we should just leave it alone. We have bigger fish to fry when it comes to plugin usage, IMO.

For example, executing a plugin within the same build in which it was installed/built (esp. when that build is a reactored build, which it is likely to be).

but our plugin snapshot repos are separate, so users won't get them unless they configure it, so I don't see any harm in switching to -cpl, as long as that doesn't cause more frequent update checks.

or perhaps setting the release metadata on plugin installation, since it is only local? risky for deploy though, only want that if they are actually releasing.

removed -cpl and -npl (no plugin latest?) and made plugin version resolution primarily based on LATEST metadata, with RELEASE used as a backup.