Yes it is definately dirty. Using a repo is the cleanest way
--Brian (mobile)
On Mar 15, 2009, at 7:54 AM, Kaveh Goudarzi <ka...@itkaa.com> wrote:
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 <ka...@itkaa.com> 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:ka...@itkaa.com]
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:ka...@itkaa.com]
Sent: Friday, March 13, 2009 11:22 AM
To: dev@maven.apache.org
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---
------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---
------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---
------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---
------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org