It should always be generated on install and deploy.
It has a different name of maven-metadata-REPOSITORY_ID.xml in the
local repository.
In the final release, the extra flag is not needed.
- Brett
On 10/14/05, Yann Le Du [EMAIL PROTECTED] wrote:
Solved the problem by copying
On install, a maven-metadata-local.xml was indeed generated. Then, the plugin
was correctly accessed from... local :)
However, I need my plugin be available from remote users. Apparently, the only
way to achieve that in m2b3 is to provide a maven-metadata.xml (without -local
suffix).
In the
On 10/14/05, Yann Le Du [EMAIL PROTECTED] wrote:
However, I need my plugin be available from remote users. Apparently, the only
way to achieve that in m2b3 is to provide a maven-metadata.xml (without -local
suffix).
m2 deploy (in combination with the distributionManagement section)
will share
Yes, I did that. More exactly, I used this in the plugin POM :
~ plugin
~artifactIdmaven-install-plugin/artifactId
~configuration
~ updateReleaseInfotrue/updateReleaseInfo
~/configuration
~ /plugin
...so that my corp repo
Got it. But is the behaviour that I described normal ? If not, I can file in
JIRA. If yes, then I got a problem because I tried a dozen confs to no avail.
At the moment, I'm dealing with :
pom.xml :
~ pluginRepositories
~pluginRepository
~ releases
~enabledtrue/enabled
~
Have you done m2 -DupdateReleaseInfo=true [install|deploy] to ensure
the release gets published with the new information?
- Brett
On 10/11/05, Yann Le Du [EMAIL PROTECTED] wrote:
Got it. But is the behaviour that I described normal ? If not, I can file in
JIRA. If yes, then I got a problem
