On 11 May 2010 17:16, Markus Muenkel markus.muen...@fernuni-hagen.dewrote:
I'm releasing a Maven2 multi-module project. One of the modules is a POM
project (assembly project) that uses the maven-assembly-plugin in order to
build an assembly (zip archive). The artifacts to be assembled are
On Wed, May 12, 2010 at 5:57 AM, Prout John - jprout
john.pr...@acxiom.com wrote:
maven1-repository.dev.java.net
(https://maven-repository.dev.java.net/repository/)
Path to dependency:
1) com.acxiomdigital.iws:IWS-Service:war:8.3.0-5-SNAPSHOT
2)
Folks;
in some cases, we're deploying webapps built as .war files manually to
some application server, but in some structure, I'd like to, after
install:install has finished, automatically unpack them to some given
webapps folder for a local jetty installation for the sake of zipping /
add an execution bound to the phase you want and put the configuration of
that execution in the execution.
On 12 May 2010 08:22, Kristian Rink li...@zimmer428.net wrote:
Folks;
in some cases, we're deploying webapps built as .war files manually to some
application server, but in some
Am 12.05.2010 09:53, schrieb Stephen Connolly:
add an execution bound to the phase you want and put the configuration of
that execution in the execution.
Well, that's what I thought too, and I figured out that calling
war:exploded actually does what I need, with one minor annoyance (which
is
Hi!
Jeremy Bopp jer...@psam.bopp.psam.ten
(psam=spam (remove) ; ten=net)
wrote a small patch for mvn.
Using that I don not get the warning any more.
Here it is:
$ diff -u mvn mvnmodified/mvn-modified
--- mvn 2010-05-12 10:34:19.261049000 +0200
+++ mvnmodified/mvn-modified2010-05-12
I'm using Maven 2.2.1 in conjunction with Hudson on Linux (OEL 5.3) and
it seems that if a project pom.xml is more than 4096 bytes, Hudson only
writes up to 4096 bytes when it deploys it to the repository (truncating
it in the process). This means that any projects dependent on this one
won't
Hi Ross,
I saw your http://issues.hudson-ci.org/browse/HUDSON-6370 , and
wondered if you had seen (closed, not reproducible)
http://jira.codehaus.org/browse/MNG-2551 , which seems similar. Might
not help much since it was not resolved.
Brett
On Wed, May 12, 2010 at 7:39 PM, Ross Hedley (AS400)
Thanks for your reply Brett.
Yes I had seen that. I think my next step is upgrade to java 1.6.0_20 on the
build box (it's currently on 1.6.0_16) but I don't think it'll make any
difference. I've upgraded to the latest version of Hudson and the svn client
just in case but these didn't fix it.
Good Afternoon Ross
we could benefit from your experience with a short readme.IBM_OLDXXX.txt text
file which would enumerate pitfalls you encountered such as:
1)configuring the JVM (which version JVM works on your IBM xxx host?)
2)configuring a repository on your machine..any permissions
If you deploy on a local fs the repo must different from your local
repository.
I think there is an issue regarding this in MNG
(http://jira.codehaus.org/browse/MNG-2551).
2010/5/12 Ross Hedley (AS400) ross.hed...@greggs.co.uk:
I'm using Maven 2.2.1 in conjunction with Hudson on Linux (OEL 5.3)
Hi All,
I am using Surefire to run my Junit tests for Eclipse based plug-ins.
I keep getting the following error while running the tests.
java.lang.exception no runnable methods
Where in a have a TestSuite and the TestSuite has a test class.
The test class ends with test and all the methods
I am trying to generate Javadocs for a project that is conceptually an
aggregate of several other projects. I am using the information from
this page as a guide:
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate-dependency-sources.html
That page indicates that you can use
There is something of a best practice of avoiding the aggregation
feature of the javadoc plugin, in favor of:
1) create source artifacts for each dependency
2) use dependency plugin to unpack the source artifacts into 'one big tree'
3) run the javadoc plugin on the result tree to produce
Hello,
I seem to be having a problem with the release:perform plugin.
I need to send a parameter at the commandline such as -Dmy.parameter=my.value.
When I do so with every other phase, it is taken into account and works fine
(even in the release:prepare phase where I use mvn release:prepare
On Wed, 2010-05-12 at 10:07 -0400, Benson Margulies wrote:
There is something of a best practice of avoiding the aggregation
feature of the javadoc plugin, in favor of:
1) create source artifacts for each dependency
2) use dependency plugin to unpack the source artifacts into 'one big tree'
You should provide more information:
- Source code of your test suite
- Can you run the suite from Eclipse?
- etc.
If you asked me to guess, I'd say that for some reason, your tests are run
as JUnit3 tests, but there aren't any methods whose name starts with test
(because you've used
Here's my scenario: I have a large multimodule project whose WARs share
certain dependencies, which are packaged as zips by a few simple assemblies
I wrote.
I am using the maven-dependency-plugin to unpack the contents of these zips
into their destination folders in the webapps.
However, to
First off, release:prepare isn't a phase, it's a goal.
Secondly, my guess is that you're misdiagnosing the problem. Running
release:perform with -X would confirm this. Instead, what I think is
happening is that your command line properties aren't being passed to
the forked Maven instance. Take a
Thank you for your help and sorry about the ultra newbie mistakes.
In my case though, the value I need to receive at the commandline is never the
same...
I'll try release:perform -X to get more info and troubleshoot from there. Thx
-Original Message-
From: Justin Edelson
On 5/12/10 2:04 PM, Compere, Lydie wrote:
Thank you for your help and sorry about the ultra newbie mistakes.
Didn't mean to suggest this was a newbie mistake. The bits of Maven
which do forked execution are always a bit tricky.
And, to make my point, I completely forgot about passing the
Hi Peter,
Thanks for the reply.
(a) Code for the test suite for the eclipse
code
@RunWith(Suite.class)
@SuiteClasses( {ExtensionTest.class,EditorTest.class} )
public class BaseFrameworkTestSuite {
}
/code
(b) The suite runs successfully from the Eclipse.
I think the tests
I am trying to start a process in the background during the
pre-integration-test phase using exec plugin and run some tests against the
process. But unfortunately when I try to start the process, Maven build
hangs up. Is there any way I can start the process in the background?
Thanks
--
View
Do you have classes with 'Test' in the name, but without any @Test
annotations - e.g..test helper classes
Surefire has the (stupid) habit of treating all classes with 'Test' in
the name as test classes.
See
http://jira.codehaus.org/browse/SUREFIRE-482
Christoph
Am 12.05.2010 20:23, schrieb
Thanks for the suggestions!
I've been through all the dependencies referenced through the tree below and
been unable to find any references to maven1-repository.dev.java.net, so no
luck there.
What I've found is that my problems are caused by recent releases of Maven. I
had problems using
On 4/28/2010 11:53 AM, Marshall Schor wrote:
There's a new way to get the build date, documented here:
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html -
search for maven.build.timestamp.
This is nice.
I would like to have multiple versions of this. For instance,
The Maven team is pleased to announce the release of the Maven Reporting API
version 3.0 and Maven Reporting Implementation 2.0.5 + 2.1.
Maven Reporting API version 3.0 is the reporting API version decoupled from
Maven core version: every reporting plugin should update its dependency to
this
The Maven team is pleased to announce the release of the Maven Clean
Plugin, version 2.4.1.
This plugin is used to clean the project output directories. Please see
the plugin's site for more details:
http://maven.apache.org/plugins/maven-clean-plugin/
To use the updated plugin in your
Right, that's another likely cause I've battled with in the past. Now my bet
is on this one. :-)
Christoph Kutzinski wrote:
Do you have classes with 'Test' in the name, but without any @Test
annotations - e.g..test helper classes
--
View this message in context:
Thanks again Peter and Christoph for the replies.
Nope i dont have any helper classes.
I had looked at the surefire bug earlier but of to no avail.
I do have helper methods with no test annotations but i dont think that has
this ability
to create this havoc :).
Peter Niederwieser wrote:
30 matches
Mail list logo
