Re: Cleanup Script
Below is a modded version of the quick and dirty 'mvn-clear-snapshots'
script I have for clearing out SNAPSHOT artifacts for the project I'm
currently working on. I typically run it prior to performing my first
build of the day (the version I actually use decends only into the
directory structure for the project I'm working on).
This isn't as smart as the hypothetical one that Wayne suggests (mine
doesn't keep the latest version around). But if you know that someone (or
something) can be counted on to deploy a snapshot build before too long,
anyway, maybe it will work good enough for you.
-Al
--8---
#!/bin/sh
set -x
M2_REPO_PATH=${HOME}/.m2/repository
if ( find ${M2_REPO_PATH} -type d -name '*SNAPSHOT*' /dev/null 21 ); then
find ${M2_REPO_PATH} -type d -name '*SNAPSHOT*' -print0 | \
xargs --null -I '{}' rm -vfr {}
fi
--8---
On Thu, Oct 18, 2007 at 12:48:47PM -0500, Wayne Fay spake thus:
Not that I've seen, but when you write it later today, maybe you won't
mind contributing it back via this list and/or the Wiki for the
benefit of future users? ;-)
It should be a simple script -- for all directories, if this is a
snapshot version, find latest and delete (or move) the rest. Then run
it via cron.
Wayne
On 10/18/07, Thomas Jackson [EMAIL PROTECTED] wrote:
We have an internal repository and are constantly deploying snapshots
throughout the day. We want to clean these nightly(to preserve space)
and I was wondering if anyone had a shell script already written that
will cleanup snapshots nightly?
Thanks
Thomas Jackson
-
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]
--
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
Alan D. Salewski
Software Developer
Health Market Science, Inc.
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleanup Script
On Thu, Oct 18, 2007 at 02:57:56PM -0400, Alan D. Salewski spake thus:
Below is a modded version of the quick and dirty 'mvn-clear-snapshots'
script I have for clearing out SNAPSHOT artifacts for the project I'm
currently working on. I typically run it prior to performing my first
build of the day (the version I actually use decends only into the
directory structure for the project I'm working on).
This isn't as smart as the hypothetical one that Wayne suggests (mine
doesn't keep the latest version around). But if you know that someone (or
something) can be counted on to deploy a snapshot build before too long,
anyway, maybe it will work good enough for you.
-Al
--8---
#!/bin/sh
set -x
M2_REPO_PATH=${HOME}/.m2/repository
if ( find ${M2_REPO_PATH} -type d -name '*SNAPSHOT*' /dev/null 21 );
then
find ${M2_REPO_PATH} -type d -name '*SNAPSHOT*' -print0 | \
xargs --null -I '{}' rm -vfr {}
fi
--8---
Upon reflection, it seems that the version I've been using is more
complicated (and slower) than necessary. Don't know why it was written
that way; probably settled that way after removing other excessive
functionality.
Anyway, here's a simpler version:
--8---
#!/bin/sh
set -x
M2_REPO_PATH=${HOME}/.m2/repository
find ${M2_REPO_PATH} -type d -name '*SNAPSHOT*' -print0 | \
xargs --null -I '{}' rm -vfr '{}'
--8---
--
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
Alan D. Salewski
Software Developer
Health Market Science, Inc.
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving Maven Site Docs
On Thu, Sep 27, 2007 at 10:23:28AM -0500, Lee Meador spake thus: [...]Can anyone claim that a makefile's syntax is any easier to understand? [...] -- Lee *dons flame retardant suit* Frankly, yes. A Makefile is transparent in way that maven and maven plugins are not. An individual Makefile target can be understood piecemeal by inspection and by invoking pieces of it directly in the shell. However, I wouldn't recommend maintaining Makefiles by hand for large projects; the GNU autotools[0] are much better suited for that, and suffer from a lot of the same documentation mishmash issues that people have been citing here. -Al [0] http://en.wikipedia.org/wiki/GNU_build_system -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Detecting build failures in linux
On Thu, Sep 27, 2007 at 01:16:25PM -0300, Martin Alejandro Villalobos spake
thus:
Hello, I have a question.
I want write a little script in linux that detect when maven is
returning build failure?
Somebody knows how I can do it?
Thaks to all and cheers.
Martin.
-8--
#!/bin/sh
PROG='whatever'
trap 'printf $PROG (WARN): HUP signal caught; bailing out\n 12; exit 1' HUP
trap 'printf $PROG (WARN): INT signal caught; bailing out\n 12; exit 1' INT
trap 'printf $PROG (WARN): QUIT signal caught; bailing out\n 12; exit 1'
QUIT
trap 'printf $PROG (WARN): TERM signal caught; bailing out\n 12; exit 1'
TERM
mvn clean install
if test $? -ne 0; then
printf ${PROG} (ERROR): maven build failed\n 12
exit 1
fi
-8--
Customize to suit...
HTH,
-Al
--
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
Alan D. Salewski
Software Developer
Health Market Science, Inc.
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving Maven Site Docs
On Thu, Sep 27, 2007 at 06:57:17PM +0200, Insitu spake thus:
[...]
2. they have a hard time understanding all the magic behind $ mvn
install when they are used to $ ant all or $ make all. [...]
People with experience using the conventions of other build tools are
likely to be confused by 'mvn install'. In particular, there is a
long-standing convention of providing a 'make install' target in
make-based projects, and that target actually installs the software on
the system for use by end-users (and typically requires root privileges
to succeed when building with defaults).
A user with this experience will be apprehensive about invoking:
$ mvn install
because his intuition is telling him that the action will attempt to
perform some action other than put the artifact in the local m2 repo
where it can be accessed by other subprojects, etc.
In my opinion, 'mvn all' or 'mvn available' would have been better
choices. 'all' is ambiguous, but in a familiar way. 'available'
introduces new terminology, but is okay because it maps to a new concept
('make' and 'ant' do not have the concept of a local repository).
I'm not suggesting that the maven 2.x 'install' build life cycle phase
be renamed at this point because maven is well-enough established that
doing so would be needlessly disruptive. But, thinking back to my
pre-maven-lobotomy days, it would have been nice if it did not violate
the principle of least surprise on this point. To the extent possible,
new approaches and new tools should leverage users' existing experience
as much as possible.
-Al
--
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
Alan D. Salewski
Software Developer
Health Market Science, Inc.
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
my lobotomy [was: Improving Maven Site Docs]
On 9/27/07, Lally Singh [EMAIL PROTECTED] spake thus: On 9/27/07, Alan D. Salewski [EMAIL PROTECTED] wrote: I'm not suggesting that the maven 2.x 'install' build life cycle phase be renamed at this point because maven is well-enough established that doing so would be needlessly disruptive. But, thinking back to my pre-maven-lobotomy days, it would have been nice if it did not violate the principle of least surprise on this point. To the extent possible, new approaches and new tools should leverage users' existing experience as much as possible. Some aliases could be useful. Just have an alias called 'available' that maven translates to 'install'. Similarly, a command line option -t which translates to -Dmaven.test.skip=true :-) Oh, I've got boatloads of aliases and wrapper scripts for maven (and most other tools that have non-trivial invocation variations that I use frequently, for that matter). I was just using the overloaded meaning of 'install' as an example of something that causes a needless impedence mismatch for new maven users that are familiar with other widely used tools. -Al P.S. Since I couldn't, in good conscience, keep contributing to marginally topical branches of this thread without actually contributing real content, I've added a new Maven for Make and GNU Autotools users section to the Getting Started with Maven wiki page: http://docs.codehaus.org/display/MAVENUSER/Getting+Started+with+Maven#GettingStartedwithMaven-MavenforMakeandGNUAutotoolsusers -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTP plugin for deploying a directory, _not_ an artifact
On Wed, Sep 26, 2007 at 01:23:40AM -0400, Brian E. Fox spake thus:
To my knowledge, only the scp wagon supports directory copying (hence
the inability to deploy sites any other way besides file). It would seem
that the ftp wagon would need to support this first and then a plugin
could leverage it.
--Brian
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 8:00 AM
To: Maven Users List
Subject: FTP plugin for deploying a directory, _not_ an artifact
Hi,
I need to be able to deploy an entire directory to an ftp server.
Is anyone working on such a plugin?
The only solutions I have googled so far use ant run, and include som
creativity to include a dependency which ant needs. This seems very
ugly.
Either that or they use maven1
I can understand why it isn't included in the default maven stuff, as it
is not a conventional build thing. It shouldn't be too easy, or
people
will ignore the (great) maven conventions, which is a real risk.
best regards, and thanks in advance,
Michael
This doesn't directly address your request, but perhaps it will be
useful. If you have scp access to the remote host, you can use the
'wagon-maven-plugin' from the Apache MyFaces project to deploy an entire
directory:
plugin
groupIdorg.apache.myfaces.maven/groupId
artifactIdwagon-maven-plugin/artifactId
executions
execution
phasedeploy/phase
iddeploy-non-maven-artifacts/id
goals
goaldeploy/goal
/goals
configuration
urlscpexe://somehost.com/path/to/some/directory//url
inputDirectory${project.build.directory}/whatever/inputDirectory
/configuration
/execution
/executions
/plugin
Note that I've not tried to use the plugin to deploy a directory with
subdirs. I'd be interested to hear whether or not that works.
HTH,
-Al
--
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
Alan D. Salewski
Software Developer
Health Market Science, Inc.
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building JBoss EAR archives with SAR included
On Thu, Aug 30, 2007 at 04:52:05PM -0500, Wayne Fay spake thus: On 8/30/07, Alan D. Salewski [EMAIL PROTECTED] wrote: Hope that cookbook is helpful to someone, This is a great contribution. I don't suppose I could get you to post it in the Maven User Wiki? http://docs.codehaus.org/display/MAVENUSER/Home Wayne Sure thing: http://docs.codehaus.org/display/MAVENUSER/Creating+JBoss+SAR+%28Service+ARchive%29+Artifacts I also created a link to it from the Mini Guides wiki page: http://docs.codehaus.org/display/MAVENUSER/Mini+Guides -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building JBoss EAR archives with SAR included
On Fri, Aug 17, 2007 at 10:35:19AM -0400, Alan D. Salewski spake thus:
On Fri, Aug 17, 2007 at 09:19:12AM -0500, Wayne Fay spake thus:
I don't use the SAR plugin but I think I understand the error
message... It looks like your dependencies define the sar as
packagingjboss-sar without a classifier... and then your EAR
configuration says classifierjboss-sar without a packaging.
I'd assume one of those is wrong. My guess would be to change
classifier to packaging.
Wayne
[...]
My recent experience with the jboss-packaging-maven-plugin confirms
Wayne's suspicion. In my particular case, simply omitting the
'classfier' element from the EJB SarModule solved the problem.
On 8/16/07, Steve Dobson [EMAIL PROTECTED] wrote:
[...]
However it builds just fine if I remove the SAR information. What am I
doing wrong?
[...]
dependency
groupIduk.org.syscall.pugwash/groupId
artifactIdpugwash-sar/artifactId
version2.0/version
typejboss-sar/type
/dependency
[...]
That's fine as is.
sarModule
groupIduk.org.syscall.pugwash/groupId
artifactIdpugwash-sar/artifactId
classifierjboss-sar/classifier
/sarModule
Try this, instead:
sarModule
groupIduk.org.syscall.pugwash/groupId
artifactIdpugwash-sar/artifactId
/sarModule
HTH,
-Al
[ Since I found myself again working with SAR files, and my earlier post
turned out to be antihelp to myself (and I hope not too many others), I
think it's only appropriate that I reply to my own busted post to set
the record straight... ]
First, for the untainted, there are currently several different
maven-2.x plugins that purport to produce SAR files (JBoss-specific
Service ARchives). My comments below below pertain only to use of the
'jboss-packaging-maven-plugin' plugin, currently available in the
codehaus.org snapshots repository:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/jboss-packaging-maven-plugin/
To configure use of the plugin, I added the following snippets to my
top-level pom.xml file:
project
modules
modulemyproj-sar/module
modulemyproj-ear/module
...
/modules
...
dependencyManagement
...
dependency
groupId${project.groupId}/groupId
artifactIdmyproj-sar/artifactId
version${project.version}/version
typesar/type
/dependency
...
/dependencyManagement
...
build
...
pluginManagement
plugins
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.3.1/version
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjboss-packaging-maven-plugin/artifactId
version2.0-SNAPSHOT/version
/plugin
...
/plugins
/pluginManagement
plugins
...
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjboss-packaging-maven-plugin/artifactId
!-- Enable 'jboss-sar', etc., as a recoginized maven packaging type
--
extensionstrue/extensions
/plugin
...
/plugins
...
/build
...
/project
In the pom.xml of the subproject that produces the SAR file, I declared
the packaging type as 'jboss-sar':
project
...
artifactIdmyproj-sar/artifactId
packagingjboss-sar/packaging
...
/project
Note that the dependencyManagement entry for the SAR subproject in the
top-level pom.xml indicates type 'sar', but the packaging type declared
by the SAR subproject itself is 'jboss-sar'. During the 'install' build
phase, the SAR subproject will install the artifact with a '.sar'
extension in the local maven repository.
In the pom.xml of the subproject that produces the EAR file, I have the
following relevant snippets:
project
...
dependencies
...
dependency
groupId${project.groupId}/groupId
artifactIdmyproj-sar/artifactId
typesar/type
/dependency
...
/dependencies
build
plugins
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
!-- The version of the application.xml file to generate. Valid --
!-- values include '1.3', '1.4', and '5'. --
version5/version
...
modules
!-- JBoss specific stuff --
SarModule
groupId${project.groupId}/groupId
artifactIdmyproj-sar/artifactId
/SarModule
...
/modules
...
/configuration
executions
execution
phasepackage
Re: (Simple) POM in YAML
On Mon, Aug 20, 2007 at 09:21:01PM -0400, John Casey spake thus: Hey Eric, Looks interesting, but it does make my eyes hurt just a little to read. :) -john The Ruby? The YAML? Oh, you must mean the XML! ;-) -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Simple) POM in YAML
On Tue, Aug 21, 2007 at 10:07:59AM +0200, [EMAIL PROTECTED] spake thus: Hi Eric and others :-) I have some remarks considering YAML. - IMHO YAML editor support is less than XML support. I imagine that is true. However, there is a YAML mode for emacs here: http://yaml-mode.clouder.jp/ (For Debian users, the 'yaml-mode' package is currently in the 'testing' distribution.) According to [0], the Radrails Eclipse plugin[1] understands YAML syntax. Looking at [2], it looks like NetBeans has support for YAML, also in a Ruby/Rails plugin. For jEdit, vim, and SciTE, check the links at [3] (vim supports YAML out of the box). After that, I got tired of following google links, but it looks like editor support for YAML is pretty widespread. Sure, that doesn't cover /all/ editors, but even just emacs, eclipse, and netbeans covers a lot of bases. - How does YAML work with the maven release plugin? AFAIK the release plugin modifies the pom file. When using YAML it modifies the intermediate pom.xml file, not the pom.yml file. Regards, Minto 'misl' van der Sluis That's a good point. However, it probably wouldn't be much work to create a reverse transform prog. One of the things I like about RelaxNG[4] is that it supports both an XML syntax and a compact syntax. As Eric has demonstrated, YAML could provide a similar feature for Maven pom.xml files. -Al [0] http://www.mail-archive.com/[EMAIL PROTECTED]/msg01291.html [1] http://www.aptana.com/download_rails_rdt.php [2] http://wiki.netbeans.org/wiki/view/NB6VisiblePlugins [3] http://www.digitalhobbit.com/archives/2005/09/15/yaml-editor-support/ [4] http://relaxng.org/ -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building JBoss EAR archives with SAR included
On Fri, Aug 17, 2007 at 09:19:12AM -0500, Wayne Fay spake thus: I don't use the SAR plugin but I think I understand the error message... It looks like your dependencies define the sar as packagingjboss-sar without a classifier... and then your EAR configuration says classifierjboss-sar without a packaging. I'd assume one of those is wrong. My guess would be to change classifier to packaging. Wayne [...] My recent experience with the jboss-packaging-maven-plugin confirms Wayne's suspicion. In my particular case, simply omitting the 'classfier' element from the EJB SarModule solved the problem. On 8/16/07, Steve Dobson [EMAIL PROTECTED] wrote: [...] However it builds just fine if I remove the SAR information. What am I doing wrong? [...] dependency groupIduk.org.syscall.pugwash/groupId artifactIdpugwash-sar/artifactId version2.0/version typejboss-sar/type /dependency [...] That's fine as is. sarModule groupIduk.org.syscall.pugwash/groupId artifactIdpugwash-sar/artifactId classifierjboss-sar/classifier /sarModule Try this, instead: sarModule groupIduk.org.syscall.pugwash/groupId artifactIdpugwash-sar/artifactId /sarModule HTH, -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building MDB's with Maven
On Thu, Aug 16, 2007 at 03:05:56PM -0400, Mark Eramo spake thus: Hello, I have a question. A few of the jars I currently build with Any also produce mdb's (message driven beans). I did not see a plugin for this but was wondering if anyone has accomplished this with Maven.[...] We use the maven-ejb-plugin for this. Here's an example snippet for an MDB subproject's pom.xml: ... build ... plugins ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ejb-plugin/artifactId configuration ejbVersion2.1/ejbVersion generateClientfalse/generateClient archive manifest addClasspathtrue/addClasspath classpathPrefixlib//classpathPrefix /manifest /archive /configuration /plugin ... /plugins /build ... For more info, check out the site for the maven-ejb-plugin: http://maven.apache.org/plugins/maven-ejb-plugin/ HTH, -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Wagon
On Wed, Aug 01, 2007 at 10:10:13PM -0400, Timothy Reilly spake thus: Is there additional information on Wagon besides http://maven.apache.org/wagon ? I have been working with wagon for the last couple of days. The best I've personally have found is to read the code: http://svn.apache.org/viewvc/maven/wagon/trunk/ *snip* There is also an 'org.apache.myfaces.maven:wagon-maven-plugin': http://myfaces.apache.org/wagon-maven-plugin/ Though it was developed for the Apache MyFaces project, it's functionality is of general use by other projects. We have several projects using it for deployment of non-maven-build artifacts. -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release:perform - How do I suppress the version prompts
On Tue, Jul 17, 2007 at 02:42:22PM -0700, Max Stepanenko spake thus: I would like to wrap my release:prepare and release:perform in some sort of a script (ant??), so that there is this magical button that someone can press to prepare and release our software. That said, release:perform, requires some user input (versions). Is there anyway to avoid/streamline this? You could probably do this using expect(1), which is tailor-made for automating program interaction. Check out: http://expect.nist.gov/ The 'autoexpect' program (linked to from the page at the above URL) could generate the code to get you most of the way there. What is the common approach to problem, is writing an ant script that will call release:prepare and release:perform w the arguments of my choice a good approach? Regards, Max I don't know how common it is, but I have all kinds of scripts that invoke maven in various ways. Others may suggest you try to do this from within maven... -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release:perform - How do I suppress the version prompts
On Tue, Jul 17, 2007 at 04:57:58PM -0700, Dan Tran spake thus:
mvn release:prepare -B
Thanks for that, Dan. I didn't realize that batch mode implied that
release:prepare would do The Right Thing.
I was playing around with this a bit (I just happen to be performing a
release tonight), and ended up with the following Bourne shell script
that works for our environment. Maybe this illustration will serve as
documentation to help others, as well.
-Al
---8-
#! /bin/sh
# mvn-release-prepare: Invoke 'mvn release:prepare' in such a way that it will
# not prompt you for version numbers and SCM tags.
#
# Assumes:
# * You are working with CVS (so you must specify the SCM release tag to be
# something CVS accepts as a tag; the default guessed by the maven
# release plugin is not valid for CVS)
#
# * You want the release version number to be the same as the value
# specified in xpath:/project/version in the paremt pom.xml (minus the
# -SNAPSHOT suffix, of course)
#
# * You want to auto-version subprojects with the same version as the
# parent pom.xml
#
# * You want the default successive *-SNAPSHOT version number
#
# Usage:
# $ mvn-release-prepare CVS-TAG [ mvn-args ... ]
PROG=$(basename $0)
if test $# -lt 1; then
printf Usage: ${PROG} CVS-TAG\n 12
exit 1
fi
SCM_TAG=$1
shift
set -x
mvn --batch-mode -Dtag=${SCM_TAG} -DautoVersionSubmodules $@ release:prepare
---8-
--
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
Alan D. Salewski
Software Developer
Health Market Science, Inc.
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can Maven do this?
On Wed, Jul 11, 2007 at 08:35:02AM -0400, Russell Gold spake thus: Alan D. Salewski wrote: Sure, maven can do this. In fact, any project that contains multiple subprojects (which would include any project that produces more than a single artifact) is probably organized to take advantage of the feature. Basically, you declare your common dependencies (specifying version numbers, etc) in the 'dependencyManagement' section of a pom.xml file that your subproject builds reference as their parent (and override settings as necessary). The subproject builds declare their dependencies in the 'dependencies' section of their pom.xml files, and get the version specified in the parent pom.xml. Google for 'dependencyManagement', and you should find everything you need to get this going. Sounds very promising. But this does not appear to be implemented by the 'ant tasks for maven' which is what I am using at present (conversion of all of our ant scripts to maven is likely to take a long time). Any clues on how I would go about adding the support? Sorry, but I have not used the 'ant tasks for maven', and am not familiar with it. The website[0] looks like it may have the answer; this is a quote from the Using the Antlib section of the site: The main purpose of the antlib is to utilise Maven's dependency management features. If you do not find what you need there, maybe ask on this list in a new thread with a more specific subject and someone else will be able to help. -Al [0] http://maven.apache.org/ant-tasks.html -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can Maven do this?
On Tue, Jul 10, 2007 at 03:41:23PM -0400, Russell Gold spake thus: I have a complex of projects that I want to manage. Essentially, it consists of a number of master projects, each of which in turn consists of a number of builds. A rule that I need to follow is that if any two builds refer to the same artifact, they must use the same version - even if they do not depend on each other, or are in separate master projects. If master project A picks up a new version of master project B, and one of the latter's builds has move to a new version of one of its dependencies, the next time I build master project A, any of its builds that uses that dependency must also move to the new version. Now, I know of a way to do this using custom ant tasks and a new form of configuration file for the master project - but I would prefer not to re-invent the wheel if Maven already has a solution (or if not, is it a capability that Maven users would like...?) Sure, maven can do this. In fact, any project that contains multiple subprojects (which would include any project that produces more than a single artifact) is probably organized to take advantage of the feature. Basically, you declare your common dependencies (specifying version numbers, etc) in the 'dependencyManagement' section of a pom.xml file that your subproject builds reference as their parent (and override settings as necessary). The subproject builds declare their dependencies in the 'dependencies' section of their pom.xml files, and get the version specified in the parent pom.xml. Google for 'dependencyManagement', and you should find everything you need to get this going. HTH, -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preflight check for 2.0.7
On Tue, Jun 05, 2007 at 08:31:51PM -0400, Jason van Zyl spake thus: I have uploaded another version here: http://people.apache.org/~jvanzyl/ *snip* It works for me. I've tested this version (05-Jun-2007 17:29) against a 32-subproject application (where some of the subprojects have more subprojects) that builds several plain JARs, a WAR, lots of EJBs[0], several EARs, and some other stuff. The app builds fine, and deploys fine. -Al [0] Including use of 'ejb-client' artifact deps, as fixed in MNG-2921 -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.6 using JDK 1.3
I think the fact maven-2.x is written in Java should be treated just as an implementation detail, not as something to be relied upon. Hypothetically, someone could re-implement maven in something else, and no Java version would be available from which to infer the version. So I don't think the java compiler source level should be inferred at build time. Also, not specifying the version needed hides information that may be necessary to have a reproducible build. OTOH, I would be in favor of such a default being inferred by an archetype. At archetype:create time, the compiler source level configuration would be inserted into the created pom.xml. This could work regardless of the maven implementation language by using the first found version of Java found by some search alorithm (i.e., $JAVA_HOME, then $PATH, then /usr/bin, then default to 1.3) -Al On Fri, May 04, 2007 at 08:52:07AM -0700, Dan Tran spake thus: I totally agree with Paul here, any one else? On 5/4/07, Paul Gier [EMAIL PROTECTED] wrote: It seems like a better default behavior for the compiler plugin would be to use the current jvm version. If I'm running maven with jdk1.5 I would expect the compiler plugin to default to source level 1.5. Is there a reason that it can't work like that? *snip* -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.6 source release
On Mon, Apr 30, 2007 at 12:12:02PM +0100, Thomas Leonard spake thus: Is the source code for maven 2.0.6 available? The download sites only seem to go up to 2.0.5: http://mirrors.dedipower.com/ftp.apache.org/maven/source/ You can grab the code directly from the Subversion repository like this: $ svn export https://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6 HTH -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On Wed, Apr 11, 2007 at 01:27:42PM -0500, Michael Dick spake thus: *snip* It seems that the finalName *could* be added in an xml file in the repository. Whether it *should* be added is another issue. FTR I'm just curious whether this is a possibility, or if anyone else thinks it would be a good idea. I did look through the mailing list archives unfortunately after I posted the question) and I know this issue has come up before. Thanks again, Michael Dick On 4/11/07, Heinrich Nirschl [EMAIL PROTECTED] wrote: On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote: Hi, I've noticed that the finalName configuration option for an assembly is ignored when you install or deploy your project. Is this intended behavior? *snip* -- -Michael Dick There is no way for maven to access an artifact in the repository if it does not follow the standard naming conventions. Henry I have projects that create artifacts with a 'finalName' set, and these artifacts get installed/deployed with the wrong file names (that is, not what I specified in 'finalName'). In all of my cases, these artifacts do not need to be accessible by maven for build purposes, so the fact that the files are installed and deployed with names different from what I specified in 'finalName' is simply an annoyance (because I then have to rename the files on the deployment server by hand). Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On Wed, Apr 11, 2007 at 09:45:17PM +0200, Heinrich Nirschl spake thus: *snip* On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry I'm not insisting on it; in fact, I like your idea much better ;-) Our current practice of deploying all of our artifacts to our internal maven repository came about because the infrastructure was already in place and accessible by everyone who needed access to the artifacts. Now that you mention it, though, it would make sense to have an arbitrary deployment plugin. There is precedence for this with other specialized deployment plugins (cargo, tomcat, probably others). -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Finding where the jar came from...
On Thu, Feb 22, 2007 at 11:00:42AM -0700, Bryan Noll spake thus: Can anyone tell me the quick-n-dirty way to figure out which dependency is responsible for a jar that is being transitively downloaded/included in the project? For instance, I see the servlet-api jar showing up in my assembly, but don't need it. I've already excluded it once from the spring dependency like so: dependency groupIdorg.springframework/groupId artifactIdspring/artifactId version2.0.2/version exclusions exclusion groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId /exclusion /exclusions /dependency I just need to find out if another one of my dependencies depends on the servlet-api. Could it be the case that the assembly plugin doesn't grock that I said to exclude when I specified the spring dependency? You can run $ mvn -o project-info-reports:dependencies to generate the dependency report in target/site/dependencies.html HTH, -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multi project interdependencies
On Wed, Jan 03, 2007 at 07:18:17PM -0500, Trevor Torrez spake thus: Is it the suggested / best practice to have a subproject in a multi project setup to declare it's dependencies on the other subprojects in the dependency section? Yes. This leads to requiring some parts of the multi-project to be installed to the local repository before other parts can be developed (using the eclipse:eclipse goal fails if the dependency / subproject is not installed). [...] That's correct. The reason is that maven-2.x is (by design) repository based; when maven needs a dependency, it looks for it in your local repos (regardless of whether it's another subproject within the project that is building, or something else). That's just how it's supposed to work. -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running Maven 2 reports
On Tue, Nov 14, 2006 at 03:28:31PM -0600, Morgovsky, Alexander (US - Glen Mills) spake thus: Is it possible to run Maven 2 reports, like pmd, for example, outside of the site generation phase? For example, if I want to create a report without associating it with any site, can I do this? If so, how can I do this? Thanks. Sure. I generate just the dependency report all the time with this: $ mvn -o project-info-reports:dependencies (I find that difficult enough to remember that I've created a 'mvn-dep-report' shell alias...) To generate both the 'dependencies' report and the 'license' report, I would do this: $ mvn -o project-info-reports:dependencies project-info-reports:license Check the documentation for a specific plugin for the name of the goal to run to create a specific report. -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Current state of play with maven 2 junit 4.1
On Sun, Nov 12, 2006 at 11:08:21PM +1100, J. Matthew Pryor spake thus: *snip* I am porting from maven 1 to maven 2, and we had begun using junit 4.1 by using the JUnit4TestAdapter like so: *snip* This worked fine for maven 1 and since I didn't know any better, was ported over to maven 2, where it *MOSTLY* works. I say mostly, because there are 2 out of about 80 classes don't get any tests detected in them i.e. *snip* From reading around, it looks like I am between a rock a hard place because http://jira.codehaus.org/browse/MSUREFIRE-131 would imply the approach above shouldn't work (well it doesn't seem to all the time) but http://jira.codehaus.org/browse/MSUREFIRE-84 would imply that native junit 4 support is not baked properly either. I'd rather not go to a temporary solution like http://www.unto.net/wiki/Maven_JUnit4_plugin if I don't have to. Any insights, work-arounds of corrections would be greatly appreciated We've had good results using a slightly modified version of the patches attached to SUREFIRE-31 by Karl M. Davis: http://jira.codehaus.org/browse/SUREFIRE-31#action_76833 We basically made an internal version of the surefire plugin (based on a patched version of the svn code from 2006-10-11) for projects that use JUnit-4.x. As for your 2 out of 80 classes not having their JUnit-4.x tests detected, this may be due to the behavior of the default surefire plugin: it attempts to run as tests anything that looks like a junit-3.x test, a TestNG test, or a non-framework-related unit test (methods named test*()). It may be that your unit tests are not being run by the provider you think they are. A simple way to test this would be to add (to one of your classes where no unit tests are detected) methods that print something recognizable to stderr: * a JUnit-4.x style @Before method * a JUnit-4.x style @Test annotated method named doFoo() [that is, /not/ named testFoo()] * a method named testJunk() I suspect that you'll see the output from testJunk() only. More to the point, using a patched version of the surefire plugin is the only solution I've seen that supports JUnit-4.x completely. In this case, completely means completely for my purposes as I've not tested every JUnit-4.x feature using our patched version, but I have tested these behaviors: * Exceptions in @BeforeClass, @Before, @AfterClass, and @After methods are detected and reported (they fail the tests) * Methods annotated with @Test, and /only/ those methods, are treated as unit test methods (regardless of the method name) HTH, -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
shameless self-promotion not considered harmful (was: WANTED: Suggestions on performing vendor-specific builds)
On Wed, Sep 13, 2006 at 11:21:02AM -0500, Eric Redmond spake thus: Well, as a shameless self-promotion, I did write an article about this recently (mostly about the concept, but it may help... I could only have 2500 words!) http://www.devx.com/Java/Article/32386 Eric I, for one, do not mind, and in fact, appreciate links posted to this list for articles or other new maven-related documentation. So thanks, Eric :-) -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shameless self-promotion not considered harmful (was: WANTED: Suggestions on performing vendor-specific builds)
On Wed, Sep 13, 2006 at 10:14:21AM -0700, Carlos Sanchez spake thus: There's a list here http://maven.apache.org/articles.html Hi Carlos, I'm aware of the list on the maven site, but I only check it when I find myself rummaging around there. On the other hand, I sit in my email client all day, so I'll become aware of maven-related resources announced there more quickly. Thanks for the heads-up, anyway... -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. Visit our new site: www.healthmarketscience.com :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with manifest EJB
On Wed, Aug 16, 2006 at 07:35:21PM +0100, Marco Mistroni spake thus: hi all, i am using maven2, i have 2 ejb projects that have as dependency two external jars maven2 included those 2 jars in my ear, but i need to have a ClassPath reference also in the manifest file of both ejbs... how can i do that? i am using maven-ear plugin.. i know there was some tags to be used , such as addToClasspath but if i remember correctly that was for building jars can anyone help me out? Hi Marco, Check this out: http://www.mail-archive.com/users@maven.apache.org/msg47020.html In short, you can configure the maven-ejb-plugin in the same way as the maven-jar-plugin. HTH, -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin:download Failed
On Thu, Jul 13, 2006 at 07:53:33PM +0200, Christian López Espínola spake thus: Hola a todos, Hi Christian, I'm starting using maven, I'm going to use it with AndroMDA. I downloaded Maven 2.0.4, and when I type mvn plugin:download -DgroupId=andromda -DartifactId=maven-andromdapp-plugin -Dversion=3.2 I obtain the following message: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'plugin'. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Required goal not found: plugin:download Maven comes in two primary flavors: maven-1.x and maven-2.x maven-2.x is not backward compatible with maven-1.x The maven-1.x command line program is called 'maven'. The maven-2.x command line program is called 'mvn' (formerly 'm2'). The command line you posted in your message is a mixture of maven-1.x and maven-2.x, so won't work with either version. Plugins target a specific version of maven; it looks like the plugin you are trying to use is a maven-1.x plugin (I have not used andromda, but the presence of the 'plugin.jelly' in the jar file a a dead giveaway that it's a maven-1.x plugin). It looks like you'll want to use maven-1.x to make use of that plugin, unless there's a maven-2.x equivalent somewhere (I didn't find one when I quickly rummaged around their site a few minutes ago[0]). HTH, -Al [0] http://galaxy.andromda.org/docs/maven-andromda-plugin/download.html -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any news about the update of Maven2 book with corrected errata ?
On Mon, Jun 26, 2006 at 05:10:17PM -0700, natalie burdick spake thus: Sebastien, Are you volunteering as an author or a reviewer? Please let me know and I will contact you directly off the mailing list - and if there are any other volunteers interested in being reviewers, please feel free to respond to this thread. Natalie Hi Natalie, I'm interested in being a reviewer. -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: to install a plugin manually failed
On Thu, Jun 22, 2006 at 06:37:33PM +0200, Usorov, Evgeny (KBV) spake thus: Hallo, I am trying to install a specific plugin (from soap-ui) but I allways get an error. I can't install any plugin manually. What is wrong? The automatically downloading and installing of plugins works fine, but if i have to install manually i can't. thanks in advance for every help. [ C:\Programme\maven-2.0.4\binmvn.bat plugin:install-file -DgroupId=eviware -DartifactId=maven-soapui-plugin -Dversion=1.5 -Dpackaging=plugin -Dfile=maven-soapui-plugin-1.5.jar You want to use 'install:install-file', not 'plugin:install-file': $ mvn install:install-file -DgroupId=eviware -DartifactId=maven-soapui-plugin -Dversion=1.5 -Dpackaging=plugin -Dfile=maven-soapui-plugin-1.5.jar [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'install'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [install:install-file] (aggregator-style) [INFO] [INFO] [install:install-file] [INFO] Installing /tmp/maven-soapui-plugin-1.5.jar to /my/home/.m2/repository/eviware/maven-soapui-plugin/1.5/maven-soapui-plugin-1.5.plugin [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Jun 22 15:11:09 EDT 2006 [INFO] Final Memory: 2M/4M [INFO] -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
