Hi Brian,
So is the idea would be to use the assembly plugin to create a bundle
which the user can "unpack" over their repository and end up with the
correct files? (sounds a bit dirty no?) or is there a specific repo
goal/descriptor function for this that I've missed?
In the meanwhile I will see if the client is willing to submit the
plugin to the codehaus repository with the appropriate license.
thanks again for your help.
Kaveh.
Brian Fox wrote:
> The assembly plugin can construct a repo and put it in a zip, but I
> would be surprised if this case is covered. then you would have to
> devise a way to unpack the zip to the users local repo.
>
> --Brian (mobile)
>
>
> On Mar 13, 2009, at 4:38 PM, Kaveh Goudarzi <[email protected]> wrote:
>
>> Hi Brian,
>>
>> I will look in to what is involved in publishing the plugin to a
>> repository. But failing that is there a supported way of installing a
>> plugin from a file asset? e.g. a combination of mvn commands such that
>> the repository is set up as if it had been a normal plugin download?
>>
>> thanks,
>>
>> Kaveh.
>>
>> Brian E. Fox wrote:
>>> Ah, I see. The install-file doesn't understand what should be done for
>>> plugins, which is why it's there for you but not someone else. Why not
>>> publish this plugin to a repo that your users can access? It will make
>>> your life easier.
>>>
>>> -----Original Message-----
>>> From: Kaveh Goudarzi [mailto:[email protected]]
>>> Sent: Friday, March 13, 2009 4:18 PM
>>> To: Maven Developers List
>>> Subject: Re: install:install-file & Repository MetaData files
>>> maven-metadata-local.xml
>>>
>>> Hi Brian,
>>>
>>> In both cases the pluginGroup is added to my settings.xml e.g
>>>
>>> ~/.m2/settings.xml
>>> ------------------
>>> <settings>
>>> <pluginGroups>
>>> <pluginGroup>com.my.pacakge</pluginGroup>
>>> </pluginGroups>
>>> </settings>
>>> ------------------
>>>
>>> However it only appears to work if the two
>>> maven-metadata-local.xml
>>> files exist otherwise the short-hand or non-specific-version
>>> invocations fail.
>>>
>>> Any thoughts?
>>>
>>> thanks in advance.
>>>
>>> Kaveh.
>>>
>>> Brian E. Fox wrote:
>>>> In order for maven to look in the right place for the shorthand
>>> lookup,
>>>> you need to add a pluginGroup in your settings. By default, maven only
>>>> uses org.apache.maven.plugins and org.codehaus.mojo.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Kaveh Goudarzi [mailto:[email protected]]
>>>> Sent: Friday, March 13, 2009 11:22 AM
>>>> To: [email protected]
>>>> Subject: install:install-file & Repository MetaData files
>>>> maven-metadata-local.xml
>>>>
>>>> Hi All,
>>>>
>>>> I've implemented a maven plugin which when installed via the "mvn
>>>> install" command as part of the build is installed "correctly" in the
>>>> local repository. By adding the plugin group reference to the
>>>> ~/.m2/settings.xml I'm able to then invoke the plugin using it's short
>>>> hand prefix or without specifying the version. So far so good.
>>>>
>>>> However I find that when I send the users the jar file alone and
>>>> ask them to install the plugin using the following command
>>>>
>>>> mvn install:install-file -Dfile=maven-mytest-plugin-1.1.jar \
>>>> -DgroupId=com.my.package \
>>>> -DartifactId=maven-mytest-plugin \
>>>> -Dpackaging=maven-plugin \
>>>> -Dversion=1.1 \
>>>> -DupdateReleaseInfo=true \
>>>> -DcreateChecksum=true \
>>>> -DgeneratePom=true
>>>>
>>>>
>>>> The users always have to supply the full plugin
>>>> group:artifact-id:version:goal and are not able to use the short-hand
>>>> or the default latest version of the plugin.
>>>>
>>>> Comparing the maven repository files I see that when I install
>>>> the
>>>> plugin on my dev machine using the mvn install command two crucial
>>>> files are created which are absent when the mvn install:install-file
>>>> command is invoked. These are:
>>>>
>>>> ~/.m2/repositories/com/my/package/maven-metadata-local.xml
>>>> ------------------
>>>> <?xml version="1.0" encoding="UTF-8"?><metadata>
>>>> <plugins>
>>>> <plugin>
>>>> <name>maven-mytest-plugin Maven Mojo</name>
>>>> <prefix>mytest</prefix>
>>>> <artifactId>maven-mytest-plugin</artifactId>
>>>> </plugin>
>>>> </plugins>
>>>> </metadata>
>>>>
>>>> and another one at
>>>>
>>>>
>>> ~/.m2/repositories/com/my/package/maven-mytest-plugin/maven-metadata-loc
>>>> al.xml
>>>> ------------------
>>>> <?xml version="1.0" encoding="UTF-8"?><metadata>
>>>> <groupId>com.my.package</groupId>
>>>> <artifactId>maven-mytest-plugin</artifactId>
>>>> <version>1.1</version>
>>>> <versioning>
>>>> <latest>1.1</latest>
>>>> <versions>
>>>> <version>1.1</version>
>>>> </versions>
>>>> <lastUpdated>20090312204457</lastUpdated>
>>>> </versioning>
>>>> </metadata>
>>>>
>>>> These two files appear to be crucial in allowing me to invoke
>>>> the
>>>> plugin using the long-hand but not specifying the version and for it
>>>> to default to the latest version and also to allow the short hand
>>>> prefix invocation.
>>>>
>>>> So my questions is what is the correct way of installing such a
>>>> plugin? ... am I missing some crucial step? I found this link but
>>>> couldn't understand if it applies
>>>> http://docs.codehaus.org/display/MAVEN/Repository+Metadata
>>>>
>>>> I'm using 2.0.9 writing plugins in java
>>>>
>>>> mvn -version
>>>> Maven version: 2.0.9
>>>> Java version: 1.5.0_16
>>>> OS name: "mac os x" version: "10.5.6" arch: "i386" Family: "unix"
>>>>
>>>> thanks in advance for you help + kind regards,
>>>>
>>>> Kaveh.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
