Re: Parametrisizing artifact version numbers
Hi!
I tried the release plugin a few months ago and couldn't get it to work for
such a complex setup. If I remember correctly, when I did the
release:prepare stage with -DdryRun=true it worked fine, but when I did it
for real I got some exception... But still, even if I got that to work, I
would still have to manually replace all snapshot dependency versions that
was not part of the current project. Maybe I'll find the time to experiment
a bit today to find out what the error was...
And Yan, I tried your idea to put the properties in settings.xml (via a
profile), but that didn't work either.
/Anders,
> - Message from "Huang, Yan" <[EMAIL PROTECTED]> on Wed, 12
> Sep 2007 12:10:16 -0700 -
>
> To:
>
> "Maven Users List"
>
> Subject:
>
> RE: Parametrisizing artifact version numbers
>
> It always puzzles me that maven does not resolve the property when
> building in the individual module vs. it's able to do so when building
> from the parent level. The property is defined in the "settings.xml",
> should maven pick up and resolve it when building from inside of
> individual modules?
>
> -Original Message-
> From: Wayne Fay [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 12, 2007 8:59 AM
> To: Maven Users List
> Subject: Re: Parametrisizing artifact version numbers
>
> Have you considered the release plugin?
>
> Wayne
>
> On 9/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Hi!
> > I'm working on a few different maven projects with several modules in
> each.
> > Most of the modules have dependencies to other modules within the same
> > project and also to other projects. Since the development in most of
> these
> > projects go in parallell, most of the dependencies are towards
> snapshot
> > versions.
> >
> > Now, my problem is that when I want to make a release, I have to go
> through
> > 30+ poms and replace snapshot versions with the new versions, check in
> the
> > new poms, tag, and then I have to replace the versions to new snapshot
> > versions... A lot of work, and it's easy to make a mistake.
> >
> > So, I'm trying to put the version numbers in properties instead, so I
> only
> > have to update the properties of the parent pom in each project.
> >
> > Here's a few sample poms of two projects, where "myotherproject"
> depends on
> > "myproject":
> >
> >
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> > 4.0.0.
> > my.project
> > ${my.project.version}
> > myparentpom
> > pom
> >
> > myjar
> >
> >
> > 1.2-SNAPSHOT
> >
> >
> >
> >
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> > 4.0.0.
> > my.project
> > ${my.project.version}
> > myjar
> > jar
> >
> > my.project
> > myparentpom
> > ${my.project.version}
> > >
> > >
> >
> >
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> > 4.0.0.
> > my.other.project
> > ${my.other.project.version}.
> > myotherparentpom
> > pom
> >
> > myotherjar
> >
> >
> > 1.2-SNAPSHOT
> >
> > 1.1-SNAPSHOT
> >
> >
> >
> >
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> > 4.0.0.
> > my.other.project
> > ${my.other.project.version}.
> > myotherjar}
> > jar
> >
> > my.other.project
> > myotherparentpom
> > ${my.other.project.version}
> > >
> > .
> > >.
> > my.project
> > myjar
> > ${my.project.version}
> >
> > .
> >
> >
> >
> > Now, I can succesfully build myproject, but when I build
> myotherproject I
> > get this error:
> >
> > [INFO]
> >
>
> > [ERROR] BUILD ERROR
> > [INFO]
> >
>
> > [INFO] Failed to resolve artifact.
> >
> > GroupId: my.project
> > ArtifactId: myparentpom
> > Version: ${my.project.version}
> >
> > Reason: Unable to download the artifact from any repository
> >
> > my.project:myparentpom:pom:${my.project.version}
> >
> > from the specified remote repositories:
> > central (http://repo1.maven.org/maven2).
> >
> >
> > When I look into my local reposito
Re: Surefire support for 'smoke tests'
Is it possible to perhaps utilize an in-memory db to speed up your database tests? Are you already using one? Or is this not an option for various technical reasons (ie you need certain stored procs in Oracle etc)? Wayne On 9/12/07, Brad from MA <[EMAIL PROTECTED]> wrote: > > Thanks Jim - that looks promising, and I'll definitely give it a try. > > As to our test speed, we're actually doing quite well. Unfortunately, the > tests are for a meta-driven db application, and have lots of time-consuming > db io (create/drop/query/delete) tests to verify our db layer behavior. The > db verification is 90% of the test time; everything else rocks (mostly unit > tests). > > > > Jim Sellers wrote: > > > > Another possible way that I've seen does "integration tests" and "unit > > tests". I'm not actually a fan of this, but it might solve your problem. > > > > In your src/test/java you have to have 2 sets of directories: itest and > > utest. > > > > > > org.apache.maven.plugins > > maven-surefire-plugin > > 2.3-SNAPSHOT > > > > true > > once > > > > > > > > utest > > test > > > > test > > > > > > false > > > > > > **/utest/**/*Test.java > > > > > > > > > > > > itest > > integration-test > > > > test > > > > > > false > > > > > > **/itest/**/*Test.java > > > > > > > > > > > > > > > > However, I'd go with default maven behaviour. Look into what else you can > > do to make your tests faster. > > > > Jim > > > > On 9/12/07, Jason Chaffee <[EMAIL PROTECTED]> wrote: > >> > >> Use TestNG to run your tests in surefire and then you can use TestNG > >> groups. For example, > >> > >> mvn test -Dgroups=smoke-test > >> > >> -Original Message- > >> From: Michael McCallum [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, September 12, 2007 2:20 PM > >> To: Maven Users List > >> Subject: Re: Surefire support for 'smoke tests' > >> > >> refacator your artifacts... > >> > >> why make maven complicated > >> > >> On Thursday 13 September 2007 08:52, Brad from MA wrote: > >> > Hi, > >> > I have surefire working well running a full suite of tests. It is > >> bound > >> > to the test phase of the default lifecycle. The full suite of tests > >> is > >> > taking a long time (say 10 minutes and growing), and is onerous for > >> > developers to run on a frequent basis as part of their rapid > >> development > >> > cycles. > >> > > >> > To remedy this, I'd like to support the ability for a developer to > >> run > >> > a much quicker subset of the tests to provide more immediate feedback > >> > (seconds as opposed to minutes). Yes, it would not be as thorough > >> > (probably catches 95% of test failures), but the automated build > >> machine > >> > will always run the full test suite on every checkin to catch any > >> 'missed' > >> > failures. > >> > > >> > 1. How can I configure surefire to support more than one > >> 'configuration' of > >> > tests to be run? I have no problem as getting surefire to run any > >> desired > >> > subset of tests; the problem is supporting more than one configuration > >> of > >> > tests to be run. > >> > > >> > 2. Ideally developer would be able to type something like: 'mvn > >> smoketest' > >> > or 'mvn test -Dtest.smoke=true' to invoke the quicker subset of tests. > >> Any > >> > ideas on how to configure a pom to support something like this? > >> > > >> > Any help greatly appreciated, > >> > Brad > >> > > >> > p.s. I tried searching the forum for anything related to this, to no > >> avail. > >> > >> -- > >> Michael McCallum > >> Enterprise Engineer > >> mailto:[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] > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Sure
RE: Surefire support for 'smoke tests'
You can still write your tests in JUnit, TestNG will run JUnit tests. -Original Message- From: Brad from MA [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 6:20 PM To: users@maven.apache.org Subject: RE: Surefire support for 'smoke tests' Alas, we're making heavy use of the Spring testing infrastructure (which rocks), which happens to be JUnit-based. At this point, we're sticking w/JUnit... The TestNG groups feature is slick however. thx anyway, Brad tvworks wrote: > > Use TestNG to run your tests in surefire and then you can use TestNG > groups. For example, > > mvn test -Dgroups=smoke-test > > -Original Message- > From: Michael McCallum [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 12, 2007 2:20 PM > To: Maven Users List > Subject: Re: Surefire support for 'smoke tests' > > refacator your artifacts... > > why make maven complicated > > On Thursday 13 September 2007 08:52, Brad from MA wrote: >> Hi, >> I have surefire working well running a full suite of tests. It is > bound >> to the test phase of the default lifecycle. The full suite of tests > is >> taking a long time (say 10 minutes and growing), and is onerous for >> developers to run on a frequent basis as part of their rapid > development >> cycles. >> >> To remedy this, I'd like to support the ability for a developer to > run >> a much quicker subset of the tests to provide more immediate feedback >> (seconds as opposed to minutes). Yes, it would not be as thorough >> (probably catches 95% of test failures), but the automated build > machine >> will always run the full test suite on every checkin to catch any > 'missed' >> failures. >> >> 1. How can I configure surefire to support more than one > 'configuration' of >> tests to be run? I have no problem as getting surefire to run any > desired >> subset of tests; the problem is supporting more than one configuration > of >> tests to be run. >> >> 2. Ideally developer would be able to type something like: 'mvn > smoketest' >> or 'mvn test -Dtest.smoke=true' to invoke the quicker subset of tests. > Any >> ideas on how to configure a pom to support something like this? >> >> Any help greatly appreciated, >> Brad >> >> p.s. I tried searching the forum for anything related to this, to no > avail. > > -- > Michael McCallum > Enterprise Engineer > mailto:[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] > > > -- View this message in context: http://www.nabble.com/Surefire-support-for-%27smoke-tests%27-tf4431949s1 77.html#a12647048 Sent from the Maven - Users mailing list archive at Nabble.com. - 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]
Re: Surefire support for 'smoke tests'
Thanks Jim - that looks promising, and I'll definitely give it a try. As to our test speed, we're actually doing quite well. Unfortunately, the tests are for a meta-driven db application, and have lots of time-consuming db io (create/drop/query/delete) tests to verify our db layer behavior. The db verification is 90% of the test time; everything else rocks (mostly unit tests). Jim Sellers wrote: > > Another possible way that I've seen does "integration tests" and "unit > tests". I'm not actually a fan of this, but it might solve your problem. > > In your src/test/java you have to have 2 sets of directories: itest and > utest. > > > org.apache.maven.plugins > maven-surefire-plugin > 2.3-SNAPSHOT > > true > once > > > > utest > test > > test > > > false > > > **/utest/**/*Test.java > > > > > > itest > integration-test > > test > > > false > > > **/itest/**/*Test.java > > > > > > > > However, I'd go with default maven behaviour. Look into what else you can > do to make your tests faster. > > Jim > > On 9/12/07, Jason Chaffee <[EMAIL PROTECTED]> wrote: >> >> Use TestNG to run your tests in surefire and then you can use TestNG >> groups. For example, >> >> mvn test -Dgroups=smoke-test >> >> -Original Message- >> From: Michael McCallum [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 12, 2007 2:20 PM >> To: Maven Users List >> Subject: Re: Surefire support for 'smoke tests' >> >> refacator your artifacts... >> >> why make maven complicated >> >> On Thursday 13 September 2007 08:52, Brad from MA wrote: >> > Hi, >> > I have surefire working well running a full suite of tests. It is >> bound >> > to the test phase of the default lifecycle. The full suite of tests >> is >> > taking a long time (say 10 minutes and growing), and is onerous for >> > developers to run on a frequent basis as part of their rapid >> development >> > cycles. >> > >> > To remedy this, I'd like to support the ability for a developer to >> run >> > a much quicker subset of the tests to provide more immediate feedback >> > (seconds as opposed to minutes). Yes, it would not be as thorough >> > (probably catches 95% of test failures), but the automated build >> machine >> > will always run the full test suite on every checkin to catch any >> 'missed' >> > failures. >> > >> > 1. How can I configure surefire to support more than one >> 'configuration' of >> > tests to be run? I have no problem as getting surefire to run any >> desired >> > subset of tests; the problem is supporting more than one configuration >> of >> > tests to be run. >> > >> > 2. Ideally developer would be able to type something like: 'mvn >> smoketest' >> > or 'mvn test -Dtest.smoke=true' to invoke the quicker subset of tests. >> Any >> > ideas on how to configure a pom to support something like this? >> > >> > Any help greatly appreciated, >> > Brad >> > >> > p.s. I tried searching the forum for anything related to this, to no >> avail. >> >> -- >> Michael McCallum >> Enterprise Engineer >> mailto:[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] >> >> > > -- View this message in context: http://www.nabble.com/Surefire-support-for-%27smoke-tests%27-tf4431949s177.html#a12647120 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Surefire support for 'smoke tests'
Alas, we're making heavy use of the Spring testing infrastructure (which rocks), which happens to be JUnit-based. At this point, we're sticking w/JUnit... The TestNG groups feature is slick however. thx anyway, Brad tvworks wrote: > > Use TestNG to run your tests in surefire and then you can use TestNG > groups. For example, > > mvn test -Dgroups=smoke-test > > -Original Message- > From: Michael McCallum [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 12, 2007 2:20 PM > To: Maven Users List > Subject: Re: Surefire support for 'smoke tests' > > refacator your artifacts... > > why make maven complicated > > On Thursday 13 September 2007 08:52, Brad from MA wrote: >> Hi, >> I have surefire working well running a full suite of tests. It is > bound >> to the test phase of the default lifecycle. The full suite of tests > is >> taking a long time (say 10 minutes and growing), and is onerous for >> developers to run on a frequent basis as part of their rapid > development >> cycles. >> >> To remedy this, I'd like to support the ability for a developer to > run >> a much quicker subset of the tests to provide more immediate feedback >> (seconds as opposed to minutes). Yes, it would not be as thorough >> (probably catches 95% of test failures), but the automated build > machine >> will always run the full test suite on every checkin to catch any > 'missed' >> failures. >> >> 1. How can I configure surefire to support more than one > 'configuration' of >> tests to be run? I have no problem as getting surefire to run any > desired >> subset of tests; the problem is supporting more than one configuration > of >> tests to be run. >> >> 2. Ideally developer would be able to type something like: 'mvn > smoketest' >> or 'mvn test -Dtest.smoke=true' to invoke the quicker subset of tests. > Any >> ideas on how to configure a pom to support something like this? >> >> Any help greatly appreciated, >> Brad >> >> p.s. I tried searching the forum for anything related to this, to no > avail. > > -- > Michael McCallum > Enterprise Engineer > mailto:[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] > > > -- View this message in context: http://www.nabble.com/Surefire-support-for-%27smoke-tests%27-tf4431949s177.html#a12647048 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven for existing ANT project
Hi Anny, It's the exact thing I'm doing at work, with multiple teams in different countries. Maven Ant Tasks are used to integrate Maven2 dependencies management into the build, and only dependencies management: instead of storing lib/*.jar into CVS, Maven Ant Tasks download them, then the Ant build works as previously. For site generation, "mvn site:site" command is used. Technically, this builds the project (or at least parts of the project) before site generation, but we ignore it: all we need is to avoid compilation to fail, for the site to be generated. When the compilation fails on a project because our Ant scripts do some special work necessary to the sources compilation, we know that we've done the right choice not trying to drop Ant in favor of Maven too fast: we try to understand if this "special work" is really usefull, how we could better handle it in a way Maven can handle. When all our projects will have this first step done, we'll know how many of them are special and will need rework before we can drop Ant and really migrate ot Maven for building our projects. HTH Hervé Le mardi 4 septembre 2007, ANU RADHA a écrit : > Hi All, > > Currently we have existing project which is build using ANT. > > Our vision is to Integrate Maven2 into it. So that Maven can be used for > site generation containing reports etc. > > We donot want to shift the build to Maven. > > Currently we have many context specfic build.xml and a common build.xml. > > We want as soon ANT run it will call maven or Maven side by side generated > site with reports. > > > Please provide some practical example to proceed on this. > > > Thanks in Advance > Anny > > - > Once upon a time there was 1 GB storage in your inbox. Click here for > happy ending. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] assembly filter assignment
I want to add a build.xml to my assembly, but filter it with different
preferences like:
/tools/build-tools/src/main/resources/bpel/build.xml
c2/bpel
build1.xml
true
server1
dos
0554
/tools/build-tools/src/main/resources/bpel/build.xml
c2/bpel
build2.xml
true
server2
dos
0554
Then in the build.xml, just have:
ant deployProcess -Dprocess.name=${process.name} -
Dproject.version=${project.version}
--
Thanks,
Mick Knutson
http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/djmick_dot_com
http://www.myspace.com/sexybeotches
http://www.thumpradio.com
---
Re: Surefire support for 'smoke tests'
Another possible way that I've seen does "integration tests" and "unit tests". I'm not actually a fan of this, but it might solve your problem. In your src/test/java you have to have 2 sets of directories: itest and utest. org.apache.maven.plugins maven-surefire-plugin 2.3-SNAPSHOT true once utest test test false **/utest/**/*Test.java itest integration-test test false **/itest/**/*Test.java However, I'd go with default maven behaviour. Look into what else you can do to make your tests faster. Jim On 9/12/07, Jason Chaffee <[EMAIL PROTECTED]> wrote: > > Use TestNG to run your tests in surefire and then you can use TestNG > groups. For example, > > mvn test -Dgroups=smoke-test > > -Original Message- > From: Michael McCallum [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 12, 2007 2:20 PM > To: Maven Users List > Subject: Re: Surefire support for 'smoke tests' > > refacator your artifacts... > > why make maven complicated > > On Thursday 13 September 2007 08:52, Brad from MA wrote: > > Hi, > > I have surefire working well running a full suite of tests. It is > bound > > to the test phase of the default lifecycle. The full suite of tests > is > > taking a long time (say 10 minutes and growing), and is onerous for > > developers to run on a frequent basis as part of their rapid > development > > cycles. > > > > To remedy this, I'd like to support the ability for a developer to > run > > a much quicker subset of the tests to provide more immediate feedback > > (seconds as opposed to minutes). Yes, it would not be as thorough > > (probably catches 95% of test failures), but the automated build > machine > > will always run the full test suite on every checkin to catch any > 'missed' > > failures. > > > > 1. How can I configure surefire to support more than one > 'configuration' of > > tests to be run? I have no problem as getting surefire to run any > desired > > subset of tests; the problem is supporting more than one configuration > of > > tests to be run. > > > > 2. Ideally developer would be able to type something like: 'mvn > smoketest' > > or 'mvn test -Dtest.smoke=true' to invoke the quicker subset of tests. > Any > > ideas on how to configure a pom to support something like this? > > > > Any help greatly appreciated, > > Brad > > > > p.s. I tried searching the forum for anything related to this, to no > avail. > > -- > Michael McCallum > Enterprise Engineer > mailto:[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] > >
Re: Maven Ant Tasks 2.0.7
Hi Hilco, Profiles are not supported yet in Maven Ant Tasks: if you need to define a repository, it has to be done in build.xml or pom.xml. And FYI, running "ant -v" adds information on which repositories are used. HTH regards, Hervé Le mercredi 5 septembre 2007, Hilco Wijbenga a écrit : > Hi Hervé, > > I've created a set of files that show the problem. I hope I didn't > miss any details below. :-) > > My settings.xml (~/.m2/settings.xml) has the following: > >xmlns="http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/settings-1.0.0.xsd"; > > > true > > MyRepo > file:///home/hwijbenga/maven-test/repository > default > > > > > Furthermore, my "project" is as follows: > > my_project/lib/maven-ant-tasks-2.0.7.jar > my_project/build.xml > my_project/pom.xml > repository/ > my_parent_pom/pom.xml > > The following sequence of commands shows the problems (I haven't > listed the output). > > in my_parent_pom: > mvn deploy > > rm ~/.m2/repository/com/example > (To make sure your local repository if empty.) > > in my_project: > ant > (This will fail.) > > mvn package > (This will download the parent POM and succeed.) > > ant > (This will now succeed.) > > The parent POM contains: > >xmlns="http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"; > > 4.0.0 > com.example > pom > pom > 1.0 > Parent POM > > > myRepo > file:///home/hwijbenga/maven-test/repository > > > > > The project POM: > >xmlns="http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"; > > 4.0.0 > > com.example > pom > 1.0 > > com.example > my_project > jar > 0.1-SNAPSHOT > My Project > > > And, finally, the build.xml: > > > > > uri="urn:maven-artifact-ant" > > > > > > >filesetId="maven-ant-tasks.dependency.fileset" > > >url="file:///home/hwijbenga/maven-test/repository" > /> > > > > > Cheers, > Hilco > > - > 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]
Re: Problem Performing Build - Version 1.0.3
On 9/12/07, Mark_E <[EMAIL PROTECTED]> wrote: > > Hello, >I am new to Continuum so please bear with me. I Installed version 1.0.3 > and I am running into 2 problems. If you're just starting with Continuum, the latest 1.1 beta is a *much* better choice. -- Wendy
RE: Surefire support for 'smoke tests'
Use TestNG to run your tests in surefire and then you can use TestNG groups. For example, mvn test -Dgroups=smoke-test -Original Message- From: Michael McCallum [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 2:20 PM To: Maven Users List Subject: Re: Surefire support for 'smoke tests' refacator your artifacts... why make maven complicated On Thursday 13 September 2007 08:52, Brad from MA wrote: > Hi, > I have surefire working well running a full suite of tests. It is bound > to the test phase of the default lifecycle. The full suite of tests is > taking a long time (say 10 minutes and growing), and is onerous for > developers to run on a frequent basis as part of their rapid development > cycles. > > To remedy this, I'd like to support the ability for a developer to run > a much quicker subset of the tests to provide more immediate feedback > (seconds as opposed to minutes). Yes, it would not be as thorough > (probably catches 95% of test failures), but the automated build machine > will always run the full test suite on every checkin to catch any 'missed' > failures. > > 1. How can I configure surefire to support more than one 'configuration' of > tests to be run? I have no problem as getting surefire to run any desired > subset of tests; the problem is supporting more than one configuration of > tests to be run. > > 2. Ideally developer would be able to type something like: 'mvn smoketest' > or 'mvn test -Dtest.smoke=true' to invoke the quicker subset of tests. Any > ideas on how to configure a pom to support something like this? > > Any help greatly appreciated, > Brad > > p.s. I tried searching the forum for anything related to this, to no avail. -- Michael McCallum Enterprise Engineer mailto:[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]
Re: Surefire support for 'smoke tests'
refacator your artifacts... why make maven complicated On Thursday 13 September 2007 08:52, Brad from MA wrote: > Hi, > I have surefire working well running a full suite of tests. It is bound > to the test phase of the default lifecycle. The full suite of tests is > taking a long time (say 10 minutes and growing), and is onerous for > developers to run on a frequent basis as part of their rapid development > cycles. > > To remedy this, I'd like to support the ability for a developer to run > a much quicker subset of the tests to provide more immediate feedback > (seconds as opposed to minutes). Yes, it would not be as thorough > (probably catches 95% of test failures), but the automated build machine > will always run the full test suite on every checkin to catch any 'missed' > failures. > > 1. How can I configure surefire to support more than one 'configuration' of > tests to be run? I have no problem as getting surefire to run any desired > subset of tests; the problem is supporting more than one configuration of > tests to be run. > > 2. Ideally developer would be able to type something like: 'mvn smoketest' > or 'mvn test -Dtest.smoke=true' to invoke the quicker subset of tests. Any > ideas on how to configure a pom to support something like this? > > Any help greatly appreciated, > Brad > > p.s. I tried searching the forum for anything related to this, to no avail. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Surefire support for 'smoke tests'
Hi, I have surefire working well running a full suite of tests. It is bound to the test phase of the default lifecycle. The full suite of tests is taking a long time (say 10 minutes and growing), and is onerous for developers to run on a frequent basis as part of their rapid development cycles. To remedy this, I'd like to support the ability for a developer to run a much quicker subset of the tests to provide more immediate feedback (seconds as opposed to minutes). Yes, it would not be as thorough (probably catches 95% of test failures), but the automated build machine will always run the full test suite on every checkin to catch any 'missed' failures. 1. How can I configure surefire to support more than one 'configuration' of tests to be run? I have no problem as getting surefire to run any desired subset of tests; the problem is supporting more than one configuration of tests to be run. 2. Ideally developer would be able to type something like: 'mvn smoketest' or 'mvn test -Dtest.smoke=true' to invoke the quicker subset of tests. Any ideas on how to configure a pom to support something like this? Any help greatly appreciated, Brad p.s. I tried searching the forum for anything related to this, to no avail. -- View this message in context: http://www.nabble.com/Surefire-support-for-%27smoke-tests%27-tf4431949s177.html#a12643883 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem Performing Build - Version 1.0.3
I figured it out. Well, I actually got it working by upgrading the velocity-1.4 jars to the velocity-1.5 jars. Now I am able to build. Mark -- View this message in context: http://www.nabble.com/Problem-Performing-Build---Version-1.0.3-tf4430122.html#a12643881 Sent from the Continuum - Users mailing list archive at Nabble.com.
Re: suite in junit and maven 2 - do they work together
Makes sense...thanks man.
Farhan.
On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> correct, i use profiles to configure the excludes/includes values depending
> on which test run i want to do.
>
> On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
> >
> > Sebastian...I assume that you still have to configure surefire to not
> > to run individual tests using the exclude attribute?, since otherwise
> > they would be invoked as well
> > besides the suite which somewhat is being invoked programitically..
> >
> > Farhan.
> >
> > On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> > > My tests are spread across folders and projects. Each project has its
> > own
> > > suite test, with which you must register the individual tests. Then
> > there is
> > > a super suite which registers each project suite.
> > >
> > > To exclude or include the suite tests in the separate phases I am
> > running, i
> > > use maven includes and excludes elements in the surefire plugin.
> > >
> > > On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
> > > >
> > > > interesting but not a good way to go ahead with (as also you
> > > > suggested), more because this way you would have to configure in every
> > > > project's pom the directory where the test-cases reside (so as to
> > > > exclude them) what if the test-cases reside in one more than one
> > > > folder (for a single project) the same would need to be done for all,
> > > > which is sort of cumbersome, it would have been great if there was
> > > > someway we could have configured surefire to run the suites (i.e. if
> > > > found in a project) instead of the individual test-cases, don't know
> > > > if thats too much of an expectation..
> > > >
> > > > Farhan.
> > > >
> > > >
> > > > On 9/12/07, Jim Sellers <[EMAIL PROTECTED]> wrote:
> > > > > You can hack it to run a test suite. I found this on a post
> > somewhere,
> > > > so
> > > > > don't give the credit to me. :-)
> > > > >
> > > > >
> > > > >
> > > > >org.apache.maven.plugins
> > > > >maven-surefire-plugin
> > > > >
> > > > >
> > > > >
> > > > >**/MavenSuite.java
> > > > >
> > > > >
> > > > >**/*Test.java
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > public class MavenSuite extends TestCase {
> > > > >
> > > > >/** The test result. */
> > > > >private TestResult tr;
> > > > >
> > > > >/** */
> > > > >public void testSuite() {
> > > > >TestSuite suite = (TestSuite) AllTests.suite();
> > > > >suite.run(tr);
> > > > >}
> > > > >
> > > > >/**
> > > > > * @see junit.framework.TestCase#run(junit.framework.TestResult)
> > > > > */
> > > > >public void run(TestResult res) {
> > > > >tr = res;
> > > > >testSuite();
> > > > >}
> > > > >
> > > > > }
> > > > >
> > > > > It's not as nice a solution since when surefire runs it looks like
> > it's
> > > > only
> > > > > running *one* test. I recommend not using a suite, but this was a
> > quick
> > > > > solution that I found for another project. I've only tried this
> > with
> > > > junit
> > > > > 3.8, jdk 1.4 (it was an older project)
> > > > >
> > > > > Jim
> > > > >
> > > > >
> > > > > On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > I had the this way working for a while using annotations like so:
> > > > > > @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> > > > > > @RunWith(Suite.class)
> > > > > > Using junit 4.2, but library conflicts and some transitive
> > dependency
> > > > on
> > > > > > junit 3.8 started causing errors.
> > > > > >
> > > > > > So now I have reverted to the old way like so:
> > > > > >
> > > > > >
> > > > > > public static junit.framework.Test suite() {
> > > > > >
> > > > > > TestSuite suite = new TestSuite();
> > > > > > suite.addTestSuite(ServicesSystemTestSuite.class);
> > > > > >
> > > > > > return suite;
> > > > > > }
> > > > > >
> > > > > >
> > > > > > On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > I looked at it at one point and came to the same conclusion that
> > > > there's
> > > > > > > no
> > > > > > > support for running suites. Wouldn't mind be proven wrong
> > though.
> > > > > > >
> > > > > > > Kalle
> > > > > > >
> > > > > > >
> > > > > > > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Hello Folks,
> > > > > > > >
> > > > > > > > Am looking into how having a suite in junit4 (or even earlier
> > > > > > versions)
> > > > > > > > can
> > > > > > > > integrate with the way maven2 runs the junit test-cases, i
> > mean if
> > > > we
> > > > > > > are
> > > > > > > > using maven to run the test-cases, can having a suite make any
> > > > > > > > difference?.
RE: Re: Javadoc in an assembly
Just kidding... -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu Sent: Wednesday, September 12, 2007 3:27 PM To: users@maven.apache.org Subject: Re: Javadoc in an assembly "Brian E. Fox" <[EMAIL PROTECTED]> writes: >>If you dare maven-dependency-plugin. > > Hey what does that mean? j/k > BTW, what does j/k means ? > --Brian -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - 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]
Re: site deploy ignoring server username and password settings
I workaround by putting username into my distribution management url as follows someservername.com scp://[EMAIL PROTECTED] On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote: > > Sorry if this has been asked and answered. > > Despite having set the remote username and password in my settings.xmllike so > > > someservername.com > remoteuser > remotepass > > > and then in my pom configured like so: > > > > someservername.com > someurl > > > > The site deploy goal consistently attempts to login to someservername.comwith > my windows username, and prompts me for my windows password. > > I'm on maven 2.0.6. > > Anyone been able to get this to work? > > -z > -- Sebastian Johnck ~~~ MotionBased, A Division of Garmin International 180 Harbor Dr. Sausalito, CA 94965 www.motionbased.com Coordinates: N37° 51' 33" W 122° 29' 08" ~~~
Re: M2Eclipse Problem: Incorrect project dependencies
Suddenly it got resolved alone... When I run the compile task, it started working... 2007/9/12, Juan Ignacio Garzón <[EMAIL PROTECTED]>: > Hi, sorry for bringing m2eclipse into the maven user list, but maybe > someone can help me. > > I have a multimodule project with this layout: > > project A > --- project A.1 > --- project A.2 > --- project A.3 -> depends on A.2 > > The problem is, that in project A.3 the "Eclipse Project" dependency > added by m2eclipse inside "Maven2 Dependencies" is project A instead > of project A.2. > > Any advices? I deleted the "Maven2 Dependencies" item, but when it is > created again the same thing happens. > > Thanks! > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-changelog-plugin issue?
I'm afraid I donät understand your project hierarchy. Can you try to present a directory tree showing it? Also pom snippets of the relevant plugin configurations (site and changelog) would help. Andre Salvati wrote: Hi, I've tried to generate reports with maven-changelog-plugin 2.1 and got an issue. The problem is that I have two modules with "same" name in subversion repository because I've renamed project Genericxxx to GenericXXX. At Windows environment: When I run "mvn site" , it works fine, but it replaces some Genericxxx files by GenericXXX. (Windows is not case sensitive) At Linux environment: When I run "mvn site", it works in part because it generates all files without substitution (Linux is case sensitive) but I get this error: [INFO] Generate "About" report. [INFO] Generate "Project Summary" report. [INFO] Generate "Source Repository" report. [INFO] Generate "Project Team" report. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Files 'statscm/dir_GenericoEsb_src_main_java_com.xml' clashes with existing '/usr/local/continuum-1.0.3/apps/continuum/work/1/target/generated-site/xdoc/statscm/dir_GenericoESB_src_main_java_com.xml' Is this a bug? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next version of the site plugin? (Was: Why is my site.xml ignored?)
I'm releasing doxia as we speak. I'll get started on releasing the site-plugin after that. Lukas Theussl wrote: According to jira [1] the site plugin is only waiting for a doxia release, which is currently being voted on. So if you find the right person to prod, it could be done soon... ;) -Lukas [1] http://jira.codehaus.org/browse/MSITE?report=com.atlassian.jira.plugin.system.project:roadmap-panel Jochen Wiedmann wrote: Hi, answering my own question: I see, that this is a bug in the current version of the site plugin and that the bug has been fixed in the trunk. Any ideas, why the next version will be released? Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is my site.xml ignored?
Unless you are using a custom velocity template, you shouldn't set the configuration option. Jochen Wiedmann wrote: Hi, I've got a project, which I am currently moving to Maven. Historically, the directory "src" is used for Java sources and this cannot be changed easily. Not now, at least. Obviously, "src/site" would be an unfortunate choice, which is why I am using the directory "site". Therefore, my POM contains the following section: maven-site-plugin site site However, the file site/site.xml is completely ignored. Am I doing something wrong? Or is there something else I need to change? Thanks, Jochen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc in an assembly
"Brian E. Fox" <[EMAIL PROTECTED]> writes: >>If you dare maven-dependency-plugin. > > Hey what does that mean? j/k > BTW, what does j/k means ? > --Brian -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc in an assembly
"Brian E. Fox" <[EMAIL PROTECTED]> writes: >>If you dare maven-dependency-plugin. > > Hey what does that mean? j/k Hmm, nothing wrong about the m-d-p :) And this may not be very english too. Just referring to some example I saw today (about self-contained jars) where this plugin was a bit abused, if I reming correctly, and the solution with assembly was cleaner. I really find the maven-dependency-plugin extremely useful by the way... -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suite in junit and maven 2 - do they work together
correct, i use profiles to configure the excludes/includes values depending
on which test run i want to do.
On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
>
> Sebastian...I assume that you still have to configure surefire to not
> to run individual tests using the exclude attribute?, since otherwise
> they would be invoked as well
> besides the suite which somewhat is being invoked programitically..
>
> Farhan.
>
> On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> > My tests are spread across folders and projects. Each project has its
> own
> > suite test, with which you must register the individual tests. Then
> there is
> > a super suite which registers each project suite.
> >
> > To exclude or include the suite tests in the separate phases I am
> running, i
> > use maven includes and excludes elements in the surefire plugin.
> >
> > On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
> > >
> > > interesting but not a good way to go ahead with (as also you
> > > suggested), more because this way you would have to configure in every
> > > project's pom the directory where the test-cases reside (so as to
> > > exclude them) what if the test-cases reside in one more than one
> > > folder (for a single project) the same would need to be done for all,
> > > which is sort of cumbersome, it would have been great if there was
> > > someway we could have configured surefire to run the suites (i.e. if
> > > found in a project) instead of the individual test-cases, don't know
> > > if thats too much of an expectation..
> > >
> > > Farhan.
> > >
> > >
> > > On 9/12/07, Jim Sellers <[EMAIL PROTECTED]> wrote:
> > > > You can hack it to run a test suite. I found this on a post
> somewhere,
> > > so
> > > > don't give the credit to me. :-)
> > > >
> > > >
> > > >
> > > >org.apache.maven.plugins
> > > >maven-surefire-plugin
> > > >
> > > >
> > > >
> > > >**/MavenSuite.java
> > > >
> > > >
> > > >**/*Test.java
> > > >
> > > >
> > > >
> > > >
> > > > public class MavenSuite extends TestCase {
> > > >
> > > >/** The test result. */
> > > >private TestResult tr;
> > > >
> > > >/** */
> > > >public void testSuite() {
> > > >TestSuite suite = (TestSuite) AllTests.suite();
> > > >suite.run(tr);
> > > >}
> > > >
> > > >/**
> > > > * @see junit.framework.TestCase#run(junit.framework.TestResult)
> > > > */
> > > >public void run(TestResult res) {
> > > >tr = res;
> > > >testSuite();
> > > >}
> > > >
> > > > }
> > > >
> > > > It's not as nice a solution since when surefire runs it looks like
> it's
> > > only
> > > > running *one* test. I recommend not using a suite, but this was a
> quick
> > > > solution that I found for another project. I've only tried this
> with
> > > junit
> > > > 3.8, jdk 1.4 (it was an older project)
> > > >
> > > > Jim
> > > >
> > > >
> > > > On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I had the this way working for a while using annotations like so:
> > > > > @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> > > > > @RunWith(Suite.class)
> > > > > Using junit 4.2, but library conflicts and some transitive
> dependency
> > > on
> > > > > junit 3.8 started causing errors.
> > > > >
> > > > > So now I have reverted to the old way like so:
> > > > >
> > > > >
> > > > > public static junit.framework.Test suite() {
> > > > >
> > > > > TestSuite suite = new TestSuite();
> > > > > suite.addTestSuite(ServicesSystemTestSuite.class);
> > > > >
> > > > > return suite;
> > > > > }
> > > > >
> > > > >
> > > > > On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > I looked at it at one point and came to the same conclusion that
> > > there's
> > > > > > no
> > > > > > support for running suites. Wouldn't mind be proven wrong
> though.
> > > > > >
> > > > > > Kalle
> > > > > >
> > > > > >
> > > > > > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Hello Folks,
> > > > > > >
> > > > > > > Am looking into how having a suite in junit4 (or even earlier
> > > > > versions)
> > > > > > > can
> > > > > > > integrate with the way maven2 runs the junit test-cases, i
> mean if
> > > we
> > > > > > are
> > > > > > > using maven to run the test-cases, can having a suite make any
> > > > > > > difference?...because maven eventually will be running all
> methods
> > > > > which
> > > > > > > have @Test as a prefix (for Junit 4) or otherwise run methods
> with
> > > > > test
> > > > > > as
> > > > > > > prefix (for junit3 and earlier). Does sure-fire plugin has any
> > > support
> > > > > > for
> > > > > > > it ? doesnt seem so ?
> > > > > > >
> > > > > > > Thanks and Reg
RE: Parametrisizing artifact version numbers
It always puzzles me that maven does not resolve the property when
building in the individual module vs. it's able to do so when building
from the parent level. The property is defined in the "settings.xml",
should maven pick up and resolve it when building from inside of
individual modules?
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 8:59 AM
To: Maven Users List
Subject: Re: Parametrisizing artifact version numbers
Have you considered the release plugin?
Wayne
On 9/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hi!
> I'm working on a few different maven projects with several modules in
each.
> Most of the modules have dependencies to other modules within the same
> project and also to other projects. Since the development in most of
these
> projects go in parallell, most of the dependencies are towards
snapshot
> versions.
>
> Now, my problem is that when I want to make a release, I have to go
through
> 30+ poms and replace snapshot versions with the new versions, check in
the
> new poms, tag, and then I have to replace the versions to new snapshot
> versions... A lot of work, and it's easy to make a mistake.
>
> So, I'm trying to put the version numbers in properties instead, so I
only
> have to update the properties of the parent pom in each project.
>
> Here's a few sample poms of two projects, where "myotherproject"
depends on
> "myproject":
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0.
> my.project
> ${my.project.version}
> myparentpom
> pom
>
> myjar
>
>
> 1.2-SNAPSHOT
>
>
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0.
> my.project
> ${my.project.version}
> myjar
> jar
>
> my.project
> myparentpom
> ${my.project.version}
> >
> >
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0.
> my.other.project
> ${my.other.project.version}.
> myotherparentpom
> pom
>
> myotherjar
>
>
> 1.2-SNAPSHOT
>
> 1.1-SNAPSHOT
>
>
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0.
> my.other.project
> ${my.other.project.version}.
> myotherjar}
> jar
>
> my.other.project
> myotherparentpom
> ${my.other.project.version}
> >
> .
> >.
> my.project
> myjar
> ${my.project.version}
>
> .
>
>
>
> Now, I can succesfully build myproject, but when I build
myotherproject I
> get this error:
>
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
>
> GroupId: my.project
> ArtifactId: myparentpom
> Version: ${my.project.version}
>
> Reason: Unable to download the artifact from any repository
>
> my.project:myparentpom:pom:${my.project.version}
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2).
>
>
> When I look into my local repository I can see that the files and
> directories of myproject correctly has the 1.2-SNAPSHOT version. But
when I
> look inside the saved poms in the repo I can see that they still
contain
> the ${my.project.version} variable, and it seems that maven is unable
to
> dereference that variable when resolving the dependency.
>
> So, am I missing something here? Do you have any other suggestions on
how
> to parametrisize the version numbers?
>
> Thanx in advance,
> /Anders
>
>
> -
> 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]
RE: Custom mojo/lifecycle questions
Thank you! I feared as much, but good to have my suspicions confirmed! In my view, this is a severe flaw with Maven, which could have become an invaluable tool for all types of projects rather than just for (Java) development projects. I remember from the thread where you and Jason discussed this, that others also voiced similar opinions, so maybe with time the consensus can shift towards a more generic lifecycle model. Cordialement :) - Anders. > -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu > Sent: 12. september 2007 20:21 > To: users@maven.apache.org > Subject: Re: Custom mojo/lifecycle questions > > Hello Anders, > I was the one who triggered the mail from Jason as I and lot > of other people had the same kind of questions than yours :) > The net conclusion I came up to is that if you want to do > something with custom lifecyles, you jsut have to live with > the three lifecycles that exists right now: default, clean and site. > > Apart from the name problem, this is not really an issue: > just pretend that compile = install, install = overlay, ... > and everything will be ok. Also, there may some confusion > between phases naming and mojo > naming: It would have been better to name the phases 'phase1' 'phase2' > ... You can think in terms of "programs" and "functions": a > mojo is a function, a phase and a lifecycle are programs. > > You have more than enough phases to create complex > lifecycles. Actually, from a a theoretical point of view, as > a plugin can trigger a lifecycle, I think you just need 2 > phases to create a complex build tree ! > > As usual, I am not aware of your particular problem but what > I would do would be to just stick to the default lifecycle, > bind your mojos to it and don't care to fork lifecycles > within the mojo themselves (it is always possible to do the > binding in the pom) and use your custom packaging as the > example you gave us. > > HTH > -- > OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. > \web> http://www.oqube.com > > > - > 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]
RE: Re: Javadoc in an assembly
>If you dare maven-dependency-plugin. Hey what does that mean? j/k --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: two test directories
Hello, You could use http://mojo.codehaus.org/build-helper-maven-plugin/ to add a test source directory. -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
M2Eclipse Problem: Incorrect project dependencies
Hi, sorry for bringing m2eclipse into the maven user list, but maybe someone can help me. I have a multimodule project with this layout: project A --- project A.1 --- project A.2 --- project A.3 -> depends on A.2 The problem is, that in project A.3 the "Eclipse Project" dependency added by m2eclipse inside "Maven2 Dependencies" is project A instead of project A.2. Any advices? I deleted the "Maven2 Dependencies" item, but when it is created again the same thing happens. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc in an assembly
Hello, I posted recently a example of javadoc jarring and inclusion in a third(party project. Addition to assembly follows immediately using dependencySet or if you dare maven-dependency-plugin. -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom mojo/lifecycle questions
Hello Anders, I was the one who triggered the mail from Jason as I and lot of other people had the same kind of questions than yours :) The net conclusion I came up to is that if you want to do something with custom lifecyles, you jsut have to live with the three lifecycles that exists right now: default, clean and site. Apart from the name problem, this is not really an issue: just pretend that compile = install, install = overlay, ... and everything will be ok. Also, there may some confusion between phases naming and mojo naming: It would have been better to name the phases 'phase1' 'phase2' ... You can think in terms of "programs" and "functions": a mojo is a function, a phase and a lifecycle are programs. You have more than enough phases to create complex lifecycles. Actually, from a a theoretical point of view, as a plugin can trigger a lifecycle, I think you just need 2 phases to create a complex build tree ! As usual, I am not aware of your particular problem but what I would do would be to just stick to the default lifecycle, bind your mojos to it and don't care to fork lifecycles within the mojo themselves (it is always possible to do the binding in the pom) and use your custom packaging as the example you gave us. HTH -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] making a section linkable in site?
I want to make and actual link, but still have it be a tag as I have many subsections. How can I do this? -- Thanks, Mick Knutson http://www.baselogic.com http://www.blincmagazine.com http://www.djmick.com http://www.myspace.com/mickknutson http://www.myspace.com/djmick_dot_com http://www.myspace.com/sexybeotches http://www.thumpradio.com ---
Re: suite in junit and maven 2 - do they work together
Sebastian...I assume that you still have to configure surefire to not
to run individual tests using the exclude attribute?, since otherwise
they would be invoked as well
besides the suite which somewhat is being invoked programitically..
Farhan.
On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> My tests are spread across folders and projects. Each project has its own
> suite test, with which you must register the individual tests. Then there is
> a super suite which registers each project suite.
>
> To exclude or include the suite tests in the separate phases I am running, i
> use maven includes and excludes elements in the surefire plugin.
>
> On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
> >
> > interesting but not a good way to go ahead with (as also you
> > suggested), more because this way you would have to configure in every
> > project's pom the directory where the test-cases reside (so as to
> > exclude them) what if the test-cases reside in one more than one
> > folder (for a single project) the same would need to be done for all,
> > which is sort of cumbersome, it would have been great if there was
> > someway we could have configured surefire to run the suites (i.e. if
> > found in a project) instead of the individual test-cases, don't know
> > if thats too much of an expectation..
> >
> > Farhan.
> >
> >
> > On 9/12/07, Jim Sellers <[EMAIL PROTECTED]> wrote:
> > > You can hack it to run a test suite. I found this on a post somewhere,
> > so
> > > don't give the credit to me. :-)
> > >
> > >
> > >
> > >org.apache.maven.plugins
> > >maven-surefire-plugin
> > >
> > >
> > >
> > >**/MavenSuite.java
> > >
> > >
> > >**/*Test.java
> > >
> > >
> > >
> > >
> > > public class MavenSuite extends TestCase {
> > >
> > >/** The test result. */
> > >private TestResult tr;
> > >
> > >/** */
> > >public void testSuite() {
> > >TestSuite suite = (TestSuite) AllTests.suite();
> > >suite.run(tr);
> > >}
> > >
> > >/**
> > > * @see junit.framework.TestCase#run(junit.framework.TestResult)
> > > */
> > >public void run(TestResult res) {
> > >tr = res;
> > >testSuite();
> > >}
> > >
> > > }
> > >
> > > It's not as nice a solution since when surefire runs it looks like it's
> > only
> > > running *one* test. I recommend not using a suite, but this was a quick
> > > solution that I found for another project. I've only tried this with
> > junit
> > > 3.8, jdk 1.4 (it was an older project)
> > >
> > > Jim
> > >
> > >
> > > On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I had the this way working for a while using annotations like so:
> > > > @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> > > > @RunWith(Suite.class)
> > > > Using junit 4.2, but library conflicts and some transitive dependency
> > on
> > > > junit 3.8 started causing errors.
> > > >
> > > > So now I have reverted to the old way like so:
> > > >
> > > >
> > > > public static junit.framework.Test suite() {
> > > >
> > > > TestSuite suite = new TestSuite();
> > > > suite.addTestSuite(ServicesSystemTestSuite.class);
> > > >
> > > > return suite;
> > > > }
> > > >
> > > >
> > > > On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I looked at it at one point and came to the same conclusion that
> > there's
> > > > > no
> > > > > support for running suites. Wouldn't mind be proven wrong though.
> > > > >
> > > > > Kalle
> > > > >
> > > > >
> > > > > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >
> > > > > > Hello Folks,
> > > > > >
> > > > > > Am looking into how having a suite in junit4 (or even earlier
> > > > versions)
> > > > > > can
> > > > > > integrate with the way maven2 runs the junit test-cases, i mean if
> > we
> > > > > are
> > > > > > using maven to run the test-cases, can having a suite make any
> > > > > > difference?...because maven eventually will be running all methods
> > > > which
> > > > > > have @Test as a prefix (for Junit 4) or otherwise run methods with
> > > > test
> > > > > as
> > > > > > prefix (for junit3 and earlier). Does sure-fire plugin has any
> > support
> > > > > for
> > > > > > it ? doesnt seem so ?
> > > > > >
> > > > > > Thanks and Regards,
> > > > > >
> > > > > > Farhan.
> > > > > > --
> > > > > > View this message in context:
> > > > > >
> > > > >
> > > >
> > http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433
> > > > > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > > > > >
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: [EM
Re: 2 Classpath Questions - how to included generated classes in classpath so dependent Testcases compile.
Sorry i mean to say
"I'm using ant-plugin to do some source generation"
On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
>
> I'm not familiar with the xml-beans plugin, but it may be failing to add
> generated-sources as a source dir.
>
> I'm using to do some source generation, and I must manually add the
> generated-srouces as a source dir.
>
> Here's what I use
>
> org.codehaus.mojo
> build-helper-maven-plugin
> 1.0
>
>
> add-source
> generate-sources
>
> add-source
>
>
>
> ${project.build.directory
> }/generated-sources/java
>
>
>
>
>
>
> On 9/12/07, bkbonner <[EMAIL PROTECTED] > wrote:
> >
> >
> > I have a project setup that includes xml schemas from 3rd parties that I
> > want
> > to create jar files for using XMLBeans. This works fine.
> >
> > The xmlbeans plugin generates:
> >
> > generated-sources
> > generated-classes
> >
> > I would also like to include test cases in the project to verify that
> > the
> > sample xml files in fact are validated and parsed properly.
> >
> > Unfortunately, mvn is failing to compile the test cases since it can't
> > find
> > the generated classes from the xmlbeans plugin.
> >
> > Does anyone have suggestions as to how I can use the resulting classes
> > from
> > the xmlbeans plugin in my test cases. And also, how if possible to
> > include
> > the generated-sources and generated-classes on the classpath so that mvn
> > eclipse:eclipse includes them in an eclipse project?
> >
> > Thanks.
> >
> > Brian
> > --
> > View this message in context:
> > http://www.nabble.com/2-Classpath-Questions---how-to-included-generated-classes-in-classpath-so-dependent-Testcases-compile.-tf4429139s177.html#a12634948
> >
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Sebastian Johnck
>
> ~~~
> MotionBased, A Division of Garmin International
> 180 Harbor Dr.
> Sausalito, CA 94965
> www.motionbased.com
> Coordinates:
> N37° 51' 33"
> W 122° 29' 08"
> ~~~
--
Sebastian Johnck
~~~
MotionBased, A Division of Garmin International
180 Harbor Dr.
Sausalito, CA 94965
www.motionbased.com
Coordinates:
N37° 51' 33"
W 122° 29' 08"
~~~
Re: 2 Classpath Questions - how to included generated classes in classpath so dependent Testcases compile.
I'm not familiar with the xml-beans plugin, but it may be failing to add
generated-sources as a source dir.
I'm using to do some source generation, and I must manually add the
generated-srouces as a source dir.
Here's what I use
org.codehaus.mojo
build-helper-maven-plugin
1.0
add-source
generate-sources
add-source
${project.build.directory
}/generated-sources/java
On 9/12/07, bkbonner <[EMAIL PROTECTED]> wrote:
>
>
> I have a project setup that includes xml schemas from 3rd parties that I
> want
> to create jar files for using XMLBeans. This works fine.
>
> The xmlbeans plugin generates:
>
> generated-sources
> generated-classes
>
> I would also like to include test cases in the project to verify that the
> sample xml files in fact are validated and parsed properly.
>
> Unfortunately, mvn is failing to compile the test cases since it can't
> find
> the generated classes from the xmlbeans plugin.
>
> Does anyone have suggestions as to how I can use the resulting classes
> from
> the xmlbeans plugin in my test cases. And also, how if possible to
> include
> the generated-sources and generated-classes on the classpath so that mvn
> eclipse:eclipse includes them in an eclipse project?
>
> Thanks.
>
> Brian
> --
> View this message in context:
> http://www.nabble.com/2-Classpath-Questions---how-to-included-generated-classes-in-classpath-so-dependent-Testcases-compile.-tf4429139s177.html#a12634948
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Sebastian Johnck
~~~
MotionBased, A Division of Garmin International
180 Harbor Dr.
Sausalito, CA 94965
www.motionbased.com
Coordinates:
N37° 51' 33"
W 122° 29' 08"
~~~
Re: two test directories
For the surefire plugin there is only one source directory http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#testSourceDirectory I believe you would need two test phases run separately with different configurations to accomplish this. On 9/12/07, Sergey Kabashnyuk <[EMAIL PROTECTED]> wrote: > > HI ALL > > I have a question. > Is it possible to configure two test directories? > One for example for TCK tests, second for internal tests. > > Sergey Kabashnyuk > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sebastian Johnck ~~~ MotionBased, A Division of Garmin International 180 Harbor Dr. Sausalito, CA 94965 www.motionbased.com Coordinates: N37° 51' 33" W 122° 29' 08" ~~~
Javadoc in an assembly
I am able to generate Javadoc as part of the website generation for my multiple module project with no problems, but when I try to include Javadoc in my assembly I run into problems. When I type "mvn javadoc:jar" Maven will say "No goals needed for project - skipping" for each of my modules. Any ideas how to get this to work? Once I manage to get the Javadoc generated, how do I tell Maven to include the Javadoc for each of the modules in my assembly? Bruce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suite in junit and maven 2 - do they work together
My tests are spread across folders and projects. Each project has its own
suite test, with which you must register the individual tests. Then there is
a super suite which registers each project suite.
To exclude or include the suite tests in the separate phases I am running, i
use maven includes and excludes elements in the surefire plugin.
On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
>
> interesting but not a good way to go ahead with (as also you
> suggested), more because this way you would have to configure in every
> project's pom the directory where the test-cases reside (so as to
> exclude them) what if the test-cases reside in one more than one
> folder (for a single project) the same would need to be done for all,
> which is sort of cumbersome, it would have been great if there was
> someway we could have configured surefire to run the suites (i.e. if
> found in a project) instead of the individual test-cases, don't know
> if thats too much of an expectation..
>
> Farhan.
>
>
> On 9/12/07, Jim Sellers <[EMAIL PROTECTED]> wrote:
> > You can hack it to run a test suite. I found this on a post somewhere,
> so
> > don't give the credit to me. :-)
> >
> >
> >
> >org.apache.maven.plugins
> >maven-surefire-plugin
> >
> >
> >
> >**/MavenSuite.java
> >
> >
> >**/*Test.java
> >
> >
> >
> >
> > public class MavenSuite extends TestCase {
> >
> >/** The test result. */
> >private TestResult tr;
> >
> >/** */
> >public void testSuite() {
> >TestSuite suite = (TestSuite) AllTests.suite();
> >suite.run(tr);
> >}
> >
> >/**
> > * @see junit.framework.TestCase#run(junit.framework.TestResult)
> > */
> >public void run(TestResult res) {
> >tr = res;
> >testSuite();
> >}
> >
> > }
> >
> > It's not as nice a solution since when surefire runs it looks like it's
> only
> > running *one* test. I recommend not using a suite, but this was a quick
> > solution that I found for another project. I've only tried this with
> junit
> > 3.8, jdk 1.4 (it was an older project)
> >
> > Jim
> >
> >
> > On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> > >
> > > I had the this way working for a while using annotations like so:
> > > @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> > > @RunWith(Suite.class)
> > > Using junit 4.2, but library conflicts and some transitive dependency
> on
> > > junit 3.8 started causing errors.
> > >
> > > So now I have reverted to the old way like so:
> > >
> > >
> > > public static junit.framework.Test suite() {
> > >
> > > TestSuite suite = new TestSuite();
> > > suite.addTestSuite(ServicesSystemTestSuite.class);
> > >
> > > return suite;
> > > }
> > >
> > >
> > > On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I looked at it at one point and came to the same conclusion that
> there's
> > > > no
> > > > support for running suites. Wouldn't mind be proven wrong though.
> > > >
> > > > Kalle
> > > >
> > > >
> > > > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > > Hello Folks,
> > > > >
> > > > > Am looking into how having a suite in junit4 (or even earlier
> > > versions)
> > > > > can
> > > > > integrate with the way maven2 runs the junit test-cases, i mean if
> we
> > > > are
> > > > > using maven to run the test-cases, can having a suite make any
> > > > > difference?...because maven eventually will be running all methods
> > > which
> > > > > have @Test as a prefix (for Junit 4) or otherwise run methods with
> > > test
> > > > as
> > > > > prefix (for junit3 and earlier). Does sure-fire plugin has any
> support
> > > > for
> > > > > it ? doesnt seem so ?
> > > > >
> > > > > Thanks and Regards,
> > > > >
> > > > > Farhan.
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433
> > > > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sebastian Johnck
> > > (415) 425 - 8361
> > >
> > > ~~~
> > > MotionBased Technologies
> > > 180 Harbor Dr.
> > > Sausalito, CA 94965
> > > www.motionbased.com
> > > Coordinates:
> > > N37° 51' 33"
> > > W 122° 29' 08"
> > > ~~~
> > >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: suite in junit and maven 2 - do they work together
interesting but not a good way to go ahead with (as also you
suggested), more because this way you would have to configure in every
project's pom the directory where the test-cases reside (so as to
exclude them) what if the test-cases reside in one more than one
folder (for a single project) the same would need to be done for all,
which is sort of cumbersome, it would have been great if there was
someway we could have configured surefire to run the suites (i.e. if
found in a project) instead of the individual test-cases, don't know
if thats too much of an expectation..
Farhan.
On 9/12/07, Jim Sellers <[EMAIL PROTECTED]> wrote:
> You can hack it to run a test suite. I found this on a post somewhere, so
> don't give the credit to me. :-)
>
>
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
>
>
>**/MavenSuite.java
>
>
>**/*Test.java
>
>
>
>
> public class MavenSuite extends TestCase {
>
>/** The test result. */
>private TestResult tr;
>
>/** */
>public void testSuite() {
>TestSuite suite = (TestSuite) AllTests.suite();
>suite.run(tr);
>}
>
>/**
> * @see junit.framework.TestCase#run(junit.framework.TestResult)
> */
>public void run(TestResult res) {
>tr = res;
>testSuite();
>}
>
> }
>
> It's not as nice a solution since when surefire runs it looks like it's only
> running *one* test. I recommend not using a suite, but this was a quick
> solution that I found for another project. I've only tried this with junit
> 3.8, jdk 1.4 (it was an older project)
>
> Jim
>
>
> On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> >
> > I had the this way working for a while using annotations like so:
> > @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> > @RunWith(Suite.class)
> > Using junit 4.2, but library conflicts and some transitive dependency on
> > junit 3.8 started causing errors.
> >
> > So now I have reverted to the old way like so:
> >
> >
> > public static junit.framework.Test suite() {
> >
> > TestSuite suite = new TestSuite();
> > suite.addTestSuite(ServicesSystemTestSuite.class);
> >
> > return suite;
> > }
> >
> >
> > On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> > >
> > > I looked at it at one point and came to the same conclusion that there's
> > > no
> > > support for running suites. Wouldn't mind be proven wrong though.
> > >
> > > Kalle
> > >
> > >
> > > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > Hello Folks,
> > > >
> > > > Am looking into how having a suite in junit4 (or even earlier
> > versions)
> > > > can
> > > > integrate with the way maven2 runs the junit test-cases, i mean if we
> > > are
> > > > using maven to run the test-cases, can having a suite make any
> > > > difference?...because maven eventually will be running all methods
> > which
> > > > have @Test as a prefix (for Junit 4) or otherwise run methods with
> > test
> > > as
> > > > prefix (for junit3 and earlier). Does sure-fire plugin has any support
> > > for
> > > > it ? doesnt seem so ?
> > > >
> > > > Thanks and Regards,
> > > >
> > > > Farhan.
> > > > --
> > > > View this message in context:
> > > >
> > >
> > http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433
> > > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sebastian Johnck
> > (415) 425 - 8361
> >
> > ~~~
> > MotionBased Technologies
> > 180 Harbor Dr.
> > Sausalito, CA 94965
> > www.motionbased.com
> > Coordinates:
> > N37° 51' 33"
> > W 122° 29' 08"
> > ~~~
> >
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: suite in junit and maven 2 - do they work together
Sorry I forgot to include this, you need to have a test method in your suite
class that calls the suite and runs it. Like So.
@Test
public void testMe() {
System.out.println("Running Suite AllTests");
TestResult t = junit.textui.TestRunner.run(suite());
if (t.failureCount() > 0) {
fail("All Test suit Failed with " + t.failureCount() + "
failures, please investigate SureFireReports");
}
if (t.errorCount() > 0) {
fail("There were errors in the AllTests suite count:" +
t.errorCount());
}
}
Personally i run my suites on a separate run in order to not get mixed with
the rest of the tests and invoke the suite manually like so
mvn test -Dtest=SomeNameTest
On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
>
> but does maven invoke these suites for you during its build-cycle? as
> thats what i want
>
> On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> > I had the this way working for a while using annotations like so:
> > @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> > @RunWith(Suite.class)
> > Using junit 4.2, but library conflicts and some transitive dependency on
> > junit 3.8 started causing errors.
> >
> > So now I have reverted to the old way like so:
> >
> >
> > public static junit.framework.Test suite() {
> >
> >TestSuite suite = new TestSuite();
> >suite.addTestSuite(ServicesSystemTestSuite.class);
> >
> >return suite;
> >}
> >
> >
> > On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> > >
> > > I looked at it at one point and came to the same conclusion that
> there's
> > > no
> > > support for running suites. Wouldn't mind be proven wrong though.
> > >
> > > Kalle
> > >
> > >
> > > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > Hello Folks,
> > > >
> > > > Am looking into how having a suite in junit4 (or even earlier
> versions)
> > > > can
> > > > integrate with the way maven2 runs the junit test-cases, i mean if
> we
> > > are
> > > > using maven to run the test-cases, can having a suite make any
> > > > difference?...because maven eventually will be running all methods
> which
> > > > have @Test as a prefix (for Junit 4) or otherwise run methods with
> test
> > > as
> > > > prefix (for junit3 and earlier). Does sure-fire plugin has any
> support
> > > for
> > > > it ? doesnt seem so ?
> > > >
> > > > Thanks and Regards,
> > > >
> > > > Farhan.
> > > > --
> > > > View this message in context:
> > > >
> > >
> http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433
> > > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > > >
> > > >
> > > >
> -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sebastian Johnck
> > (415) 425 - 8361
> >
> > ~~~
> > MotionBased Technologies
> > 180 Harbor Dr.
> > Sausalito, CA 94965
> > www.motionbased.com
> > Coordinates:
> > N37° 51' 33"
> > W 122° 29' 08"
> > ~~~
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Sebastian Johnck
(415) 425 - 8361
~~~
MotionBased Technologies
180 Harbor Dr.
Sausalito, CA 94965
www.motionbased.com
Coordinates:
N37° 51' 33"
W 122° 29' 08"
~~~
Re: suite in junit and maven 2 - do they work together
If you use the plugin configuration he provided, then yes, Maven will
automatically invoke the suites in the test phase.
Wayne
On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
> but does maven invoke these suites for you during its build-cycle? as
> thats what i want
>
> On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> > I had the this way working for a while using annotations like so:
> > @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> > @RunWith(Suite.class)
> > Using junit 4.2, but library conflicts and some transitive dependency on
> > junit 3.8 started causing errors.
> >
> > So now I have reverted to the old way like so:
> >
> >
> > public static junit.framework.Test suite() {
> >
> >TestSuite suite = new TestSuite();
> >suite.addTestSuite(ServicesSystemTestSuite.class);
> >
> >return suite;
> >}
> >
> >
> > On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> > >
> > > I looked at it at one point and came to the same conclusion that there's
> > > no
> > > support for running suites. Wouldn't mind be proven wrong though.
> > >
> > > Kalle
> > >
> > >
> > > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > Hello Folks,
> > > >
> > > > Am looking into how having a suite in junit4 (or even earlier
> versions)
> > > > can
> > > > integrate with the way maven2 runs the junit test-cases, i mean if we
> > > are
> > > > using maven to run the test-cases, can having a suite make any
> > > > difference?...because maven eventually will be running all methods
> which
> > > > have @Test as a prefix (for Junit 4) or otherwise run methods with
> test
> > > as
> > > > prefix (for junit3 and earlier). Does sure-fire plugin has any support
> > > for
> > > > it ? doesnt seem so ?
> > > >
> > > > Thanks and Regards,
> > > >
> > > > Farhan.
> > > > --
> > > > View this message in context:
> > > >
> > >
> http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433
> > > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sebastian Johnck
> > (415) 425 - 8361
> >
> > ~~~
> > MotionBased Technologies
> > 180 Harbor Dr.
> > Sausalito, CA 94965
> > www.motionbased.com
> > Coordinates:
> > N37° 51' 33"
> > W 122° 29' 08"
> > ~~~
> >
>
> -
> 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]
Re: suite in junit and maven 2 - do they work together
but does maven invoke these suites for you during its build-cycle? as
thats what i want
On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
> I had the this way working for a while using annotations like so:
> @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> @RunWith(Suite.class)
> Using junit 4.2, but library conflicts and some transitive dependency on
> junit 3.8 started causing errors.
>
> So now I have reverted to the old way like so:
>
>
> public static junit.framework.Test suite() {
>
>TestSuite suite = new TestSuite();
>suite.addTestSuite(ServicesSystemTestSuite.class);
>
>return suite;
>}
>
>
> On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> >
> > I looked at it at one point and came to the same conclusion that there's
> > no
> > support for running suites. Wouldn't mind be proven wrong though.
> >
> > Kalle
> >
> >
> > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Hello Folks,
> > >
> > > Am looking into how having a suite in junit4 (or even earlier versions)
> > > can
> > > integrate with the way maven2 runs the junit test-cases, i mean if we
> > are
> > > using maven to run the test-cases, can having a suite make any
> > > difference?...because maven eventually will be running all methods which
> > > have @Test as a prefix (for Junit 4) or otherwise run methods with test
> > as
> > > prefix (for junit3 and earlier). Does sure-fire plugin has any support
> > for
> > > it ? doesnt seem so ?
> > >
> > > Thanks and Regards,
> > >
> > > Farhan.
> > > --
> > > View this message in context:
> > >
> > http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433
> > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
>
> --
> Sebastian Johnck
> (415) 425 - 8361
>
> ~~~
> MotionBased Technologies
> 180 Harbor Dr.
> Sausalito, CA 94965
> www.motionbased.com
> Coordinates:
> N37° 51' 33"
> W 122° 29' 08"
> ~~~
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: suite in junit and maven 2 - do they work together
You can hack it to run a test suite. I found this on a post somewhere, so
don't give the credit to me. :-)
org.apache.maven.plugins
maven-surefire-plugin
**/MavenSuite.java
**/*Test.java
public class MavenSuite extends TestCase {
/** The test result. */
private TestResult tr;
/** */
public void testSuite() {
TestSuite suite = (TestSuite) AllTests.suite();
suite.run(tr);
}
/**
* @see junit.framework.TestCase#run(junit.framework.TestResult)
*/
public void run(TestResult res) {
tr = res;
testSuite();
}
}
It's not as nice a solution since when surefire runs it looks like it's only
running *one* test. I recommend not using a suite, but this was a quick
solution that I found for another project. I've only tried this with junit
3.8, jdk 1.4 (it was an older project)
Jim
On 9/12/07, Sebastian Johnck <[EMAIL PROTECTED]> wrote:
>
> I had the this way working for a while using annotations like so:
> @Suite.SuiteClasses( { ServicesSystemTestSuite.class })
> @RunWith(Suite.class)
> Using junit 4.2, but library conflicts and some transitive dependency on
> junit 3.8 started causing errors.
>
> So now I have reverted to the old way like so:
>
>
> public static junit.framework.Test suite() {
>
> TestSuite suite = new TestSuite();
> suite.addTestSuite(ServicesSystemTestSuite.class);
>
> return suite;
> }
>
>
> On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> >
> > I looked at it at one point and came to the same conclusion that there's
> > no
> > support for running suites. Wouldn't mind be proven wrong though.
> >
> > Kalle
> >
> >
> > On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Hello Folks,
> > >
> > > Am looking into how having a suite in junit4 (or even earlier
> versions)
> > > can
> > > integrate with the way maven2 runs the junit test-cases, i mean if we
> > are
> > > using maven to run the test-cases, can having a suite make any
> > > difference?...because maven eventually will be running all methods
> which
> > > have @Test as a prefix (for Junit 4) or otherwise run methods with
> test
> > as
> > > prefix (for junit3 and earlier). Does sure-fire plugin has any support
> > for
> > > it ? doesnt seem so ?
> > >
> > > Thanks and Regards,
> > >
> > > Farhan.
> > > --
> > > View this message in context:
> > >
> >
> http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433
> > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
>
> --
> Sebastian Johnck
> (415) 425 - 8361
>
> ~~~
> MotionBased Technologies
> 180 Harbor Dr.
> Sausalito, CA 94965
> www.motionbased.com
> Coordinates:
> N37° 51' 33"
> W 122° 29' 08"
> ~~~
>
site deploy ignoring server username and password settings
Sorry if this has been asked and answered. Despite having set the remote username and password in my settings.xml like so someservername.com remoteuser remotepass and then in my pom configured like so: someservername.com someurl The site deploy goal consistently attempts to login to someservername.comwith my windows username, and prompts me for my windows password. I'm on maven 2.0.6. Anyone been able to get this to work? -z
Re: adding struts-config.xml file to WEB-INF folder during WAR build
On projects that I've worked on I've kept the struts-config file under
src/main/resources/config. In the web.xml where you specify the struts
servlet you specify it as /WEB-INF/classes/config/struts-config.xml
I'm not sure if that'll help, but we found that it worked best so we could
run builds in eclipse, maven and use StrutsTestCase.
Jim
On 9/12/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
>
> If you're doing all that work, you might as well migrate to SVN before
> the transition, too. CVS does not handle moves well at all.
>
> Wayne
>
> On 9/12/07, Farhan Sarwar < [EMAIL PROTECTED]> wrote:
> > A one time thing but certainly worth the effort in my opinion,
> > eventually the goal should be to have a similar structure
> > enterprise-wide so as to speed up the time it takes for the new
> > members to adapt to a different project in the company.
> >
> > Farhan.
> >
> > On 9/12/07, Syed Shabir <[EMAIL PROTECTED]> wrote:
> > > Well, I did think about that, but I was hoping that someone could have
> a
> > > simpler solution before the long haul of moving stuff around in CVS
> > > etc...
> > >
> > > -Original Message-
> > > From: Wayne Fay [mailto: [EMAIL PROTECTED]
> > > Sent: 12 September 2007 17:06
> > > To: Maven Users List
> > > Subject: Re: adding struts-config.xml file to WEB-INF folder during
> WAR
> > > build
> > >
> > > Assuming you're using the standard Maven directory structure, simply
> > > put the struts-config.xml file in the following place:
> > > {root}/src/main/webapp/WEB-INF/
> > >
> > > Then Maven should include it automatically in WEB-INF in your WAR.
> > >
> > > It looks like you're using a non-standard layout, so that makes it
> > > more difficult. Can you not restructure your project to use the
> > > "normal" Maven layout?
> > >
> > > Wayne
> > >
> > > On 9/12/07, Syed Shabir <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >
> > > >
> > > >
> > > > Could anyone tell me how to copy the struts xml files to the WEB-INF
> > > > folder during a WAR build.
> > > >
> > > >
> > > >
> > > > I'm using the 'maven-war-plugin' to do the build as below
> > > >
> > > >
> > > >
> > > > .
> > > >
> > > >
> > > >
> > > > ..
> > > >
> > > >
> > > >
> > > >
> > > > org.apache.maven.plugins
> > > >
> > > >
> > > > maven-war-plugin
> > > >
> > > > 2.0
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ${basedir}\web
> > > >
> > > >
>
> > > >
> > > >
> > > > *.html
> > > >
> > > >
> > > > **/*.html
> > > >
> > > >
> > > > **/*.gif
> > > >
> > > >
> > > > **/*.js
> > > >
> > > >
> > > > **/*.css
> > > >
> > > >
> > > > **/*.jsp
> > > >
> > > >
> > > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ${basedir}\WEB-INF
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > **/*.xml
> > > >
> > > >
> > > > *.tld
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > WEB-INF
> > > >
> > > >
> > > > false
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> ${basedir}\WEB-INF\web.xml
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > .
> > > >
> > > >
> > > >
> > > > .
> > > >
> > > >
> > > >
> > > > This copies the XML files to the root of the WAR file
> > > >
> > > >
> > > >
> > > > Much appreciated!!
> > > >
> > > >
> > >
> > > -
> > > 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]
>
>
Re: suite in junit and maven 2 - do they work together
I had the this way working for a while using annotations like so:
@Suite.SuiteClasses( { ServicesSystemTestSuite.class })
@RunWith(Suite.class)
Using junit 4.2, but library conflicts and some transitive dependency on
junit 3.8 started causing errors.
So now I have reverted to the old way like so:
public static junit.framework.Test suite() {
TestSuite suite = new TestSuite();
suite.addTestSuite(ServicesSystemTestSuite.class);
return suite;
}
On 9/12/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
>
> I looked at it at one point and came to the same conclusion that there's
> no
> support for running suites. Wouldn't mind be proven wrong though.
>
> Kalle
>
>
> On 9/12/07, mfs <[EMAIL PROTECTED]> wrote:
> >
> >
> > Hello Folks,
> >
> > Am looking into how having a suite in junit4 (or even earlier versions)
> > can
> > integrate with the way maven2 runs the junit test-cases, i mean if we
> are
> > using maven to run the test-cases, can having a suite make any
> > difference?...because maven eventually will be running all methods which
> > have @Test as a prefix (for Junit 4) or otherwise run methods with test
> as
> > prefix (for junit3 and earlier). Does sure-fire plugin has any support
> for
> > it ? doesnt seem so ?
> >
> > Thanks and Regards,
> >
> > Farhan.
> > --
> > View this message in context:
> >
> http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
--
Sebastian Johnck
(415) 425 - 8361
~~~
MotionBased Technologies
180 Harbor Dr.
Sausalito, CA 94965
www.motionbased.com
Coordinates:
N37° 51' 33"
W 122° 29' 08"
~~~
Re: adding struts-config.xml file to WEB-INF folder during WAR build
If you're doing all that work, you might as well migrate to SVN before
the transition, too. CVS does not handle moves well at all.
Wayne
On 9/12/07, Farhan Sarwar <[EMAIL PROTECTED]> wrote:
> A one time thing but certainly worth the effort in my opinion,
> eventually the goal should be to have a similar structure
> enterprise-wide so as to speed up the time it takes for the new
> members to adapt to a different project in the company.
>
> Farhan.
>
> On 9/12/07, Syed Shabir <[EMAIL PROTECTED]> wrote:
> > Well, I did think about that, but I was hoping that someone could have a
> > simpler solution before the long haul of moving stuff around in CVS
> > etc...
> >
> > -Original Message-
> > From: Wayne Fay [mailto:[EMAIL PROTECTED]
> > Sent: 12 September 2007 17:06
> > To: Maven Users List
> > Subject: Re: adding struts-config.xml file to WEB-INF folder during WAR
> > build
> >
> > Assuming you're using the standard Maven directory structure, simply
> > put the struts-config.xml file in the following place:
> > {root}/src/main/webapp/WEB-INF/
> >
> > Then Maven should include it automatically in WEB-INF in your WAR.
> >
> > It looks like you're using a non-standard layout, so that makes it
> > more difficult. Can you not restructure your project to use the
> > "normal" Maven layout?
> >
> > Wayne
> >
> > On 9/12/07, Syed Shabir <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > >
> > >
> > > Could anyone tell me how to copy the struts xml files to the WEB-INF
> > > folder during a WAR build.
> > >
> > >
> > >
> > > I'm using the 'maven-war-plugin' to do the build as below
> > >
> > >
> > >
> > > .
> > >
> > >
> > >
> > > ..
> > >
> > >
> > >
> > >
> > > org.apache.maven.plugins
> > >
> > >
> > > maven-war-plugin
> > >
> > > 2.0
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ${basedir}\web
> > >
> > >
> > >
> > >
> > > *.html
> > >
> > >
> > > **/*.html
> > >
> > >
> > > **/*.gif
> > >
> > >
> > > **/*.js
> > >
> > >
> > > **/*.css
> > >
> > >
> > > **/*.jsp
> > >
> > >
> > >
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ${basedir}\WEB-INF
> > >
> > >
> > >
> > >
> > >
> > > **/*.xml
> > >
> > >
> > > *.tld
> > >
> > >
> > >
> > >
> > >
> > > WEB-INF
> > >
> > >
> > > false
> > >
> > >
> > >
> > >
> > >
> > >
> > > ${basedir}\WEB-INF\web.xml
> > >
> > >
> > >
> > >
> > >
> > >
> > > .
> > >
> > >
> > >
> > > .
> > >
> > >
> > >
> > > This copies the XML files to the root of the WAR file
> > >
> > >
> > >
> > > Much appreciated!!
> > >
> > >
> >
> > -
> > 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]
Re: adding struts-config.xml file to WEB-INF folder during WAR build
A one time thing but certainly worth the effort in my opinion,
eventually the goal should be to have a similar structure
enterprise-wide so as to speed up the time it takes for the new
members to adapt to a different project in the company.
Farhan.
On 9/12/07, Syed Shabir <[EMAIL PROTECTED]> wrote:
> Well, I did think about that, but I was hoping that someone could have a
> simpler solution before the long haul of moving stuff around in CVS
> etc...
>
> -Original Message-
> From: Wayne Fay [mailto:[EMAIL PROTECTED]
> Sent: 12 September 2007 17:06
> To: Maven Users List
> Subject: Re: adding struts-config.xml file to WEB-INF folder during WAR
> build
>
> Assuming you're using the standard Maven directory structure, simply
> put the struts-config.xml file in the following place:
> {root}/src/main/webapp/WEB-INF/
>
> Then Maven should include it automatically in WEB-INF in your WAR.
>
> It looks like you're using a non-standard layout, so that makes it
> more difficult. Can you not restructure your project to use the
> "normal" Maven layout?
>
> Wayne
>
> On 9/12/07, Syed Shabir <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >
> >
> > Could anyone tell me how to copy the struts xml files to the WEB-INF
> > folder during a WAR build.
> >
> >
> >
> > I'm using the 'maven-war-plugin' to do the build as below
> >
> >
> >
> > .
> >
> >
> >
> > ..
> >
> >
> >
> >
> > org.apache.maven.plugins
> >
> >
> > maven-war-plugin
> >
> > 2.0
> >
> >
> >
> >
> >
> >
> >
> >
> > ${basedir}\web
> >
> >
> >
> >
> > *.html
> >
> >
> > **/*.html
> >
> >
> > **/*.gif
> >
> >
> > **/*.js
> >
> >
> > **/*.css
> >
> >
> > **/*.jsp
> >
> >
> >
>
> >
> >
> >
> >
> >
> >
> > ${basedir}\WEB-INF
> >
> >
> >
> >
> >
> > **/*.xml
> >
> >
> > *.tld
> >
> >
> >
> >
> >
> > WEB-INF
> >
> >
> > false
> >
> >
> >
> >
> >
> >
> > ${basedir}\WEB-INF\web.xml
> >
> >
> >
> >
> >
> >
> > .
> >
> >
> >
> > .
> >
> >
> >
> > This copies the XML files to the root of the WAR file
> >
> >
> >
> > Much appreciated!!
> >
> >
>
> -
> 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]
RE: Re: properties in settings.xml
Will the "deploy" phase actually resolve this version property? Or I have to go
through maven release plug-in?
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu
Sent: Wednesday, September 12, 2007 12:13 AM
To: users@maven.apache.org
Subject: Re: properties in settings.xml
"Huang, Yan" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I noticed that the "install" phase does not resolve the properties that
> are defined in settings.xml. For example, I use a property in my
> settings.xml to define the release version:
>
>
> DefaultProfile
>
> true
>
>
> 1.1.1.1
>
>
>
>
> Now, I have a pom that access that property:
>
> myexample.myexample
> foo1
> ${myversion}
>
> When I run "mvn install", it does creat and install foo1-1.1.1.1.jar in
> my local repo in ~/.m2/repository/myexample/ However, when I look at
> the foo1-1.1.1.1.pom file, the "version" tag is not resolved and instead
> it still refers to ${myversion}. Is it a problem?
AFAIK this is perfectly normal: The deployed .pom file is the actual
pom of the project without any modification. You can find the
effective pom (ie. the one used to build the artifact) inside the
META-INF/ directory of the jar.
The rationale behind this (speaking within control of more knowledgeable
maven developers) is that the deployed pom can be used as a dependency
to construct another pom withing another process, where the variables
would need to be instantiated to other values according to
settings/profiles/whatever.
HTH
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
-
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]
RE: adding struts-config.xml file to WEB-INF folder during WAR build
Well, I did think about that, but I was hoping that someone could have a
simpler solution before the long haul of moving stuff around in CVS
etc...
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: 12 September 2007 17:06
To: Maven Users List
Subject: Re: adding struts-config.xml file to WEB-INF folder during WAR
build
Assuming you're using the standard Maven directory structure, simply
put the struts-config.xml file in the following place:
{root}/src/main/webapp/WEB-INF/
Then Maven should include it automatically in WEB-INF in your WAR.
It looks like you're using a non-standard layout, so that makes it
more difficult. Can you not restructure your project to use the
"normal" Maven layout?
Wayne
On 9/12/07, Syed Shabir <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> Could anyone tell me how to copy the struts xml files to the WEB-INF
> folder during a WAR build.
>
>
>
> I'm using the 'maven-war-plugin' to do the build as below
>
>
>
> .
>
>
>
> ..
>
>
>
>
> org.apache.maven.plugins
>
>
> maven-war-plugin
>
> 2.0
>
>
>
>
>
>
>
>
> ${basedir}\web
>
>
>
>
> *.html
>
>
> **/*.html
>
>
> **/*.gif
>
>
> **/*.js
>
>
> **/*.css
>
>
> **/*.jsp
>
>
>
>
>
>
>
>
>
> ${basedir}\WEB-INF
>
>
>
>
>
> **/*.xml
>
>
> *.tld
>
>
>
>
>
> WEB-INF
>
>
> false
>
>
>
>
>
>
> ${basedir}\WEB-INF\web.xml
>
>
>
>
>
>
> .
>
>
>
> .
>
>
>
> This copies the XML files to the root of the WAR file
>
>
>
> Much appreciated!!
>
>
-
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]
RE: Custom mojo/lifecycle questions
Thanks, this makes sense, if I invoke 'mvn install' instead, it works a lot better. In fact, if I invoke the default lifecycle phase 'compile' (which maps to esp:install), it works just fine (apart from the unwanted warning message), identical to how it behaves if I invoke 'install'. My understanding then of what happens is that a default lifecycle phase is invoked and that mvn (as intended) invokes all default lifecycle phases up to and including the invoked phase, but if and only of they are mapped to goals in components.xml. Is my understanding correct? The problem with this is that our lifecycle is *not* the default lifecycle. 'install' is the second to last phase in the default lifecycle, whereas it is only the second phase in our solution deployment lifecycle (which is: validate > install > patch > overlay > load > test > report). If I try to invoke a phase that is *not* in the default lifecycle (e.g. 'overlay'), I get the following error: [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'overlay': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal This also makes good sense. However, if I invoke the goal 'esp:overlay' instead, I'm back to executing single goals twice or even more often. Unless it is possible to invoke plugin:goal and still have mvn invoke goals only once and in order, it would seem that the only way out of this dead end would be to create a truly customised lifecycle, am I right? If so, can this be done by creating a custom LifecycleMapping implementation? I have looked at the DefaultLifecycleMapping class in an attempt to flesh out what needs to be done, but I didn't even manage to figure out how the private member variable 'lifecycles' ever gets assigned a value... :-| I remember seeing a posting from someone about a month ago that all that's required to build a truly customised lifecycle is present in the current code base and that some examples would be provided shortly. I have yet to see the examples, though, so I am a bit uncertain as to whether this is really possible, particularly based on other postings stating that custom lifecycles are not and will not be supported in M2 due to their messing up inter-mojo dependencies and what not. Insights and recommendations highly appreciated! Thanks, - Anders. > -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu > Sent: 12. september 2007 14:53 > To: users@maven.apache.org > Subject: Re: Custom mojo/lifecycle questions > > Hello, > In your mvn command, you are invoing esp:install which means: > - execute the mojo install in the plugin esp > > In your mojo's configuration you may have forked a lifecycle which > would explain maven's behavior: > - validate is executed twice, one for the mojo and once for the >lifecycle the pom is packaged two > - install is executed once to prevent recursive invocation > > HTH > -- > OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. > \web> http://www.oqube.com > > > - > 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]
Re: adding struts-config.xml file to WEB-INF folder during WAR build
Assuming you're using the standard Maven directory structure, simply
put the struts-config.xml file in the following place:
{root}/src/main/webapp/WEB-INF/
Then Maven should include it automatically in WEB-INF in your WAR.
It looks like you're using a non-standard layout, so that makes it
more difficult. Can you not restructure your project to use the
"normal" Maven layout?
Wayne
On 9/12/07, Syed Shabir <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> Could anyone tell me how to copy the struts xml files to the WEB-INF
> folder during a WAR build.
>
>
>
> I'm using the 'maven-war-plugin' to do the build as below
>
>
>
> .
>
>
>
> ..
>
>
>
>
> org.apache.maven.plugins
>
>
> maven-war-plugin
>
> 2.0
>
>
>
>
>
>
>
>
> ${basedir}\web
>
>
>
>
> *.html
>
>
> **/*.html
>
>
> **/*.gif
>
>
> **/*.js
>
>
> **/*.css
>
>
> **/*.jsp
>
>
>
>
>
>
>
>
>
> ${basedir}\WEB-INF
>
>
>
>
>
> **/*.xml
>
>
> *.tld
>
>
>
>
>
> WEB-INF
>
>
> false
>
>
>
>
>
>
> ${basedir}\WEB-INF\web.xml
>
>
>
>
>
>
> .
>
>
>
> .
>
>
>
> This copies the XML files to the root of the WAR file
>
>
>
> Much appreciated!!
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: suite in junit and maven 2 - do they work together
I looked at it at one point and came to the same conclusion that there's no support for running suites. Wouldn't mind be proven wrong though. Kalle On 9/12/07, mfs <[EMAIL PROTECTED]> wrote: > > > Hello Folks, > > Am looking into how having a suite in junit4 (or even earlier versions) > can > integrate with the way maven2 runs the junit test-cases, i mean if we are > using maven to run the test-cases, can having a suite make any > difference?...because maven eventually will be running all methods which > have @Test as a prefix (for Junit 4) or otherwise run methods with test as > prefix (for junit3 and earlier). Does sure-fire plugin has any support for > it ? doesnt seem so ? > > Thanks and Regards, > > Farhan. > -- > View this message in context: > http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433 > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Parametrisizing artifact version numbers
Have you considered the release plugin?
Wayne
On 9/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hi!
> I'm working on a few different maven projects with several modules in each.
> Most of the modules have dependencies to other modules within the same
> project and also to other projects. Since the development in most of these
> projects go in parallell, most of the dependencies are towards snapshot
> versions.
>
> Now, my problem is that when I want to make a release, I have to go through
> 30+ poms and replace snapshot versions with the new versions, check in the
> new poms, tag, and then I have to replace the versions to new snapshot
> versions... A lot of work, and it's easy to make a mistake.
>
> So, I'm trying to put the version numbers in properties instead, so I only
> have to update the properties of the parent pom in each project.
>
> Here's a few sample poms of two projects, where "myotherproject" depends on
> "myproject":
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0.
> my.project
> ${my.project.version}
> myparentpom
> pom
>
> myjar
>
>
> 1.2-SNAPSHOT
>
>
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0.
> my.project
> ${my.project.version}
> myjar
> jar
>
> my.project
> myparentpom
> ${my.project.version}
> >
> >
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0.
> my.other.project
> ${my.other.project.version}.
> myotherparentpom
> pom
>
> myotherjar
>
>
> 1.2-SNAPSHOT
>
> 1.1-SNAPSHOT
>
>
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0.
> my.other.project
> ${my.other.project.version}.
> myotherjar}
> jar
>
> my.other.project
> myotherparentpom
> ${my.other.project.version}
> >
> .
> >.
> my.project
> myjar
> ${my.project.version}
>
> .
>
>
>
> Now, I can succesfully build myproject, but when I build myotherproject I
> get this error:
>
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
>
> GroupId: my.project
> ArtifactId: myparentpom
> Version: ${my.project.version}
>
> Reason: Unable to download the artifact from any repository
>
> my.project:myparentpom:pom:${my.project.version}
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2).
>
>
> When I look into my local repository I can see that the files and
> directories of myproject correctly has the 1.2-SNAPSHOT version. But when I
> look inside the saved poms in the repo I can see that they still contain
> the ${my.project.version} variable, and it seems that maven is unable to
> dereference that variable when resolving the dependency.
>
> So, am I missing something here? Do you have any other suggestions on how
> to parametrisize the version numbers?
>
> Thanx in advance,
> /Anders
>
>
> -
> 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]
adding struts-config.xml file to WEB-INF folder during WAR build
Hi,
Could anyone tell me how to copy the struts xml files to the WEB-INF
folder during a WAR build.
I'm using the 'maven-war-plugin' to do the build as below
.
..
org.apache.maven.plugins
maven-war-plugin
2.0
${basedir}\web
*.html
**/*.html
**/*.gif
**/*.js
**/*.css
**/*.jsp
${basedir}\WEB-INF
**/*.xml
*.tld
WEB-INF
false
${basedir}\WEB-INF\web.xml
.
.
This copies the XML files to the root of the WAR file
Much appreciated!!
suite in junit and maven 2 - do they work together
Hello Folks, Am looking into how having a suite in junit4 (or even earlier versions) can integrate with the way maven2 runs the junit test-cases, i mean if we are using maven to run the test-cases, can having a suite make any difference?...because maven eventually will be running all methods which have @Test as a prefix (for Junit 4) or otherwise run methods with test as prefix (for junit3 and earlier). Does sure-fire plugin has any support for it ? doesnt seem so ? Thanks and Regards, Farhan. -- View this message in context: http://www.nabble.com/suite-in-junit-and-maven-2---do-they-work-together-tf4430242s177.html#a12638433 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Parametrisizing artifact version numbers
Hi!
I'm working on a few different maven projects with several modules in each.
Most of the modules have dependencies to other modules within the same
project and also to other projects. Since the development in most of these
projects go in parallell, most of the dependencies are towards snapshot
versions.
Now, my problem is that when I want to make a release, I have to go through
30+ poms and replace snapshot versions with the new versions, check in the
new poms, tag, and then I have to replace the versions to new snapshot
versions... A lot of work, and it's easy to make a mistake.
So, I'm trying to put the version numbers in properties instead, so I only
have to update the properties of the parent pom in each project.
Here's a few sample poms of two projects, where "myotherproject" depends on
"myproject":
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0.
my.project
${my.project.version}
myparentpom
pom
myjar
1.2-SNAPSHOT
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0.
my.project
${my.project.version}
myjar
jar
my.project
myparentpom
${my.project.version}
>
>
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0.
my.other.project
${my.other.project.version}.
myotherparentpom
pom
myotherjar
1.2-SNAPSHOT
1.1-SNAPSHOT
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0.
my.other.project
${my.other.project.version}.
myotherjar}
jar
my.other.project
myotherparentpom
${my.other.project.version}
>
.
>.
my.project
myjar
${my.project.version}
.
Now, I can succesfully build myproject, but when I build myotherproject I
get this error:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: my.project
ArtifactId: myparentpom
Version: ${my.project.version}
Reason: Unable to download the artifact from any repository
my.project:myparentpom:pom:${my.project.version}
from the specified remote repositories:
central (http://repo1.maven.org/maven2).
When I look into my local repository I can see that the files and
directories of myproject correctly has the 1.2-SNAPSHOT version. But when I
look inside the saved poms in the repo I can see that they still contain
the ${my.project.version} variable, and it seems that maven is unable to
dereference that variable when resolving the dependency.
So, am I missing something here? Do you have any other suggestions on how
to parametrisize the version numbers?
Thanx in advance,
/Anders
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
two test directories
HI ALL I have a question. Is it possible to configure two test directories? One for example for TCK tests, second for internal tests. Sergey Kabashnyuk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Assembly Plugin Error : appXML attribute required
I think that is it because EAR assembling is not implemented so far? Regards, Nishant Sonar -Original Message- From: Sonar, Nishant Sent: Wednesday, September 12, 2007 10:49 AM To: Maven Users List Subject: Assembly Plugin Error : appXML attribute required Hi Can anyone help me? I am receiving following error with assembly plug-in Failed to create assembly: Error creating assembly archive: appxml attribute is required Here's my descriptor file dist ear . target\generated-resources\ear target\generated-resources\war\SimpleWebService.war *.xml And plug-in in POM maven-assembly-plugin generate-test-sources assembly assembly-descriptor.xml What is the appXml attribute? I didn't find any in side my descriptor file. Regards, Nishant Sonar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly Plugin Error : appXML attribute required
Hi Can anyone help me? I am receiving following error with assembly plug-in Failed to create assembly: Error creating assembly archive: appxml attribute is required Here's my descriptor file dist ear . target\generated-resources\ear target\generated-resources\war\SimpleWebService.war *.xml And plug-in in POM maven-assembly-plugin generate-test-sources assembly assembly-descriptor.xml What is the appXml attribute? I didn't find any in side my descriptor file. Regards, Nishant Sonar
Re: location of pom.xml
Do you have you rpom.xml in your cvs? under /cvs-repository. Emmanuel CyTG a écrit : My first post to the mailing I must have some level of a beginners problem here, but i really cant figure it out! Say i have this project C:\test\ConversionWebAdmin\src C:\test\ConversionWebAdmin\target C:\test\ConversionWebAdmin\logs C:\test\ConversionWebAdmin\pom.xml i go here C:\test\ConversionWebAdmin\src and run "mvn clean install" and it runs fine (ok tests fail, but's partially what this is all about) Now i add the pom in continuum as a file; file:///C:/test/ConversionWebAdmin/pom.xml and output from the console is as follows INFO Continuum:default - Created 1 projects. INFO Continuum:default - Created 1 project groups. INFO Continuum:default - 0 errors. (ed. fine) INFO ContinuumScm:default - Checking out project: 'Conversion Web Administration', id: '23' to 'C:\continuum\continuum-1.1-beta-2\23'. INFO ScmManager:default - Executing: cmd.exe /X /C '"cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/cvs-repository -q checkout -d 23 Conversion"' INFO ScmManager:default - Working directory: C:\continuum\continuum-1.1-beta-2 INFO ContinuumScm:default - Checked out 619 files. - and this is where trouble begins, i'll point it out loud. "...to 'C:\continuum\continuum-1.1-beta-2\23'" So it checks out the project to homedirectory (set under config) and appends "\23", then sets working directory to "C:\continuum\continuum-1.1-beta-2" - Alright, i'll try to build this sucker and i press "Build Now", and get .. INFO BuildController:default- Initializing build INFO BuildController:default- Starting build of Conversion Web Administration INFO BuildController:default- Updating working dir INFO BuildController:default- Performing action check-working-directory INFO BuildController:default- Performing action update-working-directory-from-scm INFO ContinuumScm:default - Updating project: id: '23', name 'Conversion Web Administration'. INFO ScmManager:default - Executing: cmd.exe /X /C '"cvs -z3 -f -q update-d"' INFO ScmManager:default - Working directory: C:\continuum\continuum-1.1-beta-2\23 INFO BuildController:default- Merging SCM results INFO BuildController:default- Changes found, building INFO BuildController:default- Performing action update-project-from-working-directory INFO Action:update-project-from-working-directory - Updating project 'Conversion Web Administration' from checkout. ERROR BuildController:default- Error executing action update-project-from-working-directory ' org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'update-project-from-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction (DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build( DefaultBuildController.java:137) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask (BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run (ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run( FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. and inspecting the log from within continuum ; [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [clean, install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Wed Sep 12 15:30:55 CEST 2007 [INFO] Final Memory: 1M/2M [INFO] SO .. it seems like it cant find
maven-changelog-plugin issue?
Hi, I've tried to generate reports with maven-changelog-plugin 2.1 and got an issue. The problem is that I have two modules with "same" name in subversion repository because I've renamed project Genericxxx to GenericXXX. At Windows environment: When I run "mvn site" , it works fine, but it replaces some Genericxxx files by GenericXXX. (Windows is not case sensitive) At Linux environment: When I run "mvn site", it works in part because it generates all files without substitution (Linux is case sensitive) but I get this error: [INFO] Generate "About" report. [INFO] Generate "Project Summary" report. [INFO] Generate "Source Repository" report. [INFO] Generate "Project Team" report. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Files 'statscm/dir_GenericoEsb_src_main_java_com.xml' clashes with existing '/usr/local/continuum-1.0.3/apps/continuum/work/1/target/generated-site/xdoc/statscm/dir_GenericoESB_src_main_java_com.xml' Is this a bug? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
location of pom.xml
My first post to the mailing I must have some level of a beginners problem here, but i really cant figure it out! Say i have this project C:\test\ConversionWebAdmin\src C:\test\ConversionWebAdmin\target C:\test\ConversionWebAdmin\logs C:\test\ConversionWebAdmin\pom.xml i go here C:\test\ConversionWebAdmin\src and run "mvn clean install" and it runs fine (ok tests fail, but's partially what this is all about) Now i add the pom in continuum as a file; file:///C:/test/ConversionWebAdmin/pom.xml and output from the console is as follows INFO Continuum:default - Created 1 projects. INFO Continuum:default - Created 1 project groups. INFO Continuum:default - 0 errors. (ed. fine) INFO ContinuumScm:default - Checking out project: 'Conversion Web Administration', id: '23' to 'C:\continuum\continuum-1.1-beta-2\23'. INFO ScmManager:default - Executing: cmd.exe /X /C '"cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/cvs-repository -q checkout -d 23 Conversion"' INFO ScmManager:default - Working directory: C:\continuum\continuum-1.1-beta-2 INFO ContinuumScm:default - Checked out 619 files. - and this is where trouble begins, i'll point it out loud. "...to 'C:\continuum\continuum-1.1-beta-2\23'" So it checks out the project to homedirectory (set under config) and appends "\23", then sets working directory to "C:\continuum\continuum-1.1-beta-2" - Alright, i'll try to build this sucker and i press "Build Now", and get .. INFO BuildController:default- Initializing build INFO BuildController:default- Starting build of Conversion Web Administration INFO BuildController:default- Updating working dir INFO BuildController:default- Performing action check-working-directory INFO BuildController:default- Performing action update-working-directory-from-scm INFO ContinuumScm:default - Updating project: id: '23', name 'Conversion Web Administration'. INFO ScmManager:default - Executing: cmd.exe /X /C '"cvs -z3 -f -q update-d"' INFO ScmManager:default - Working directory: C:\continuum\continuum-1.1-beta-2\23 INFO BuildController:default- Merging SCM results INFO BuildController:default- Changes found, building INFO BuildController:default- Performing action update-project-from-working-directory INFO Action:update-project-from-working-directory - Updating project 'Conversion Web Administration' from checkout. ERROR BuildController:default- Error executing action update-project-from-working-directory ' org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'update-project-from-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction (DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build( DefaultBuildController.java:137) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask (BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run (ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run( FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could not find Maven project descriptor. and inspecting the log from within continuum ; [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [clean, install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Wed Sep 12 15:30:55 CEST 2007 [INFO] Final Memory: 1M/2M [INFO] SO .. it seems like it cant find the pom.xml ? .. the very same pom.xml it used to check out the source with! Wonder what
RE: Custom mojo/lifecycle questions
Thanks, this makes sense, if I invoke 'mvn install' instead, it works a lot better. In fact, if I invoke the default lifecycle phase 'compile' (which maps to esp:install), it works just fine (apart from the unwanted warning message), identical to how it behaves if I invoke 'install'. My understanding then of what happens is that a default lifecycle phase is invoked and that mvn (as intended) invokes all default lifecycle phases up to and including the invoked phase, but if and only of they are mapped to goals in components.xml. Is my understanding correct? The problem with this is that our lifecycle is *not* the default lifecycle. 'install' is the second to last phase in the default lifecycle, whereas it is only the second phase in our solution deployment lifecycle (which is: validate > install > patch > overlay > load > test > report). If I try to invoke a phase that is *not* in the default lifecycle (e.g. 'overlay'), I get the following error: [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'overlay': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal This also makes good sense. However, if I invoke the goal 'esp:overlay' instead, I'm back to executing single goals twice or even more often. Unless it is possible to invoke plugin:goal and still have mvn invoke goals only once and in order, it would seem that the only way out of this dead end would be to create a truly customised lifecycle, am I right? If so, can this be done by creating a custom LifecycleMapping implementation? I have looked at the DefaultLifecycleMapping class in an attempt to flesh out what needs to be done, but I didn't even manage to figure out how the private member variable 'lifecycles' ever gets assigned a value... :-| I remember seeing a posting from Jason van Zyl from about a month ago that all that's required to build a truly customised lifecycle is present in the current code base and that he was going to provide some examples shortly. I have yet to see the examples, though, so I am a bit uncertain as to whether this is really possible, particularly based on other postings stating that custom lifecycles are not and will not be supported in M2 due to their messing up inter-mojo dependencies and what not. Insights and recommendations highly appreciated! Thanks, - Anders. > -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu > Sent: 12. september 2007 14:53 > To: users@maven.apache.org > Subject: Re: Custom mojo/lifecycle questions > > Hello, > In your mvn command, you are invoing esp:install which means: > - execute the mojo install in the plugin esp > > In your mojo's configuration you may have forked a lifecycle > which would explain maven's behavior: > - validate is executed twice, one for the mojo and once for the >lifecycle the pom is packaged two > - install is executed once to prevent recursive invocation > > HTH > -- > OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. > \web> http://www.oqube.com > > > - > 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]
2 Classpath Questions - how to included generated classes in classpath so dependent Testcases compile.
I have a project setup that includes xml schemas from 3rd parties that I want to create jar files for using XMLBeans. This works fine. The xmlbeans plugin generates: generated-sources generated-classes I would also like to include test cases in the project to verify that the sample xml files in fact are validated and parsed properly. Unfortunately, mvn is failing to compile the test cases since it can't find the generated classes from the xmlbeans plugin. Does anyone have suggestions as to how I can use the resulting classes from the xmlbeans plugin in my test cases. And also, how if possible to include the generated-sources and generated-classes on the classpath so that mvn eclipse:eclipse includes them in an eclipse project? Thanks. Brian -- View this message in context: http://www.nabble.com/2-Classpath-Questions---how-to-included-generated-classes-in-classpath-so-dependent-Testcases-compile.-tf4429139s177.html#a12634948 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom mojo/lifecycle questions
Hello, In your mvn command, you are invoing esp:install which means: - execute the mojo install in the plugin esp In your mojo's configuration you may have forked a lifecycle which would explain maven's behavior: - validate is executed twice, one for the mojo and once for the lifecycle the pom is packaged two - install is executed once to prevent recursive invocation HTH -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Acessing command line properties from JUnit tests
that wont work, please take a look at maven-surefire-plugin's doco on how to
configure your pom.xml to passin system property into your test
-D
On 9/12/07, carl.whalley <[EMAIL PROTECTED]> wrote:
>
> If I use "mvn -Dfoo=bar integration-test" I was expecting
> System.getProperty("foo") to return "bar" in the invoked tests. It isn't -
> have I misunderstood this please? Thanks.
> --
> View this message in context:
> http://www.nabble.com/-M2--Acessing-command-line-properties-from-JUnit-tests-tf4427748s177.html#a12630944
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> -
> 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]
Re: How to use common:jelly regexp:match tag in maven 1.0.1
You need oro-2.0.8.jar on your classpath, not jakarta-oro (or maybe both). HTH, -Lukas Lasith Chandrasekara wrote: I have a pugin.jelly file and where I want to use regexp:match tag for some string processing function. So I have added the xmlns:r="jelly: org.apache.commons.jelly.tags.regexp.RegexpTagLibrary" at the beginning of my pugin.jelly file to resolve commons.jelly.tags.regexp jar for Maven1.0.1. After that when I running the appropriate goal it will give following exception trace. java.lang.NoClassDefFoundError: org/apache/oro/text/regex/Perl5Matcher at org.apache.commons.jelly.tags.regexp.RegexpTag.( RegexpTag.java:34) at org.apache.commons.jelly.tags.regexp.MatchTag.( MatchTag.java:24) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance( NativeConstructorAccessorImpl.java:80) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance( DelegatingConstructorAccessorImpl.java(Compile d Code)) at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code)) at java.lang.Class.newInstance3(Class.java(Compiled Code)) at java.lang.Class.newInstance(Class.java(Compiled Code)) at org.apache.commons.jelly.impl.DefaultTagFactory.createTag( DefaultTagFactory.java:91) at org.apache.commons.jelly.impl.TagScript.createTag(TagScript.java(Inlined Compiled Code)) at org.apache.commons.jelly.impl.TagScript.getTag(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag( MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag( MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java :233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java :233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag( MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag( MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java :233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag( MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag( MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java :233) at org.apache.commons.jelly.tags.core.ForEachTag.doTag( ForEachTag.java:145) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag( MavenGoalTag.java:79) at o
How to use common:jelly regexp:match tag in maven 1.0.1
I have a pugin.jelly file and where I want to use regexp:match tag for some string processing function. So I have added the xmlns:r="jelly: org.apache.commons.jelly.tags.regexp.RegexpTagLibrary" at the beginning of my pugin.jelly file to resolve commons.jelly.tags.regexp jar for Maven1.0.1. After that when I running the appropriate goal it will give following exception trace. java.lang.NoClassDefFoundError: org/apache/oro/text/regex/Perl5Matcher at org.apache.commons.jelly.tags.regexp.RegexpTag.( RegexpTag.java:34) at org.apache.commons.jelly.tags.regexp.MatchTag.( MatchTag.java:24) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance( NativeConstructorAccessorImpl.java:80) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance( DelegatingConstructorAccessorImpl.java(Compile d Code)) at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code)) at java.lang.Class.newInstance3(Class.java(Compiled Code)) at java.lang.Class.newInstance(Class.java(Compiled Code)) at org.apache.commons.jelly.impl.DefaultTagFactory.createTag( DefaultTagFactory.java:91) at org.apache.commons.jelly.impl.TagScript.createTag(TagScript.java(Inlined Compiled Code)) at org.apache.commons.jelly.impl.TagScript.getTag(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag( MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag( MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java :233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java :233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag( MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag( MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java :233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag( MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag( MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java :233) at org.apache.commons.jelly.tags.core.ForEachTag.doTag( ForEachTag.java:145) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java :135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag( MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werke
Re: Next version of the site plugin? (Was: Why is my site.xml ignored?)
According to jira [1] the site plugin is only waiting for a doxia release, which is currently being voted on. So if you find the right person to prod, it could be done soon... ;) -Lukas [1] http://jira.codehaus.org/browse/MSITE?report=com.atlassian.jira.plugin.system.project:roadmap-panel Jochen Wiedmann wrote: Hi, answering my own question: I see, that this is a bug in the current version of the site plugin and that the bug has been fixed in the trunk. Any ideas, why the next version will be released? Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum 1.1.0-beta-2 UI performance
Damien Lecan a écrit : Hello, for http://maven.zones.apache.org/continuum/projectGroupSummary.action?projectGroupId=9 we have 30 modules printed in 7,5s and the page size is 101ko We use the standalone version installed in a vm. Standalone version is as slow as embedded version in Tomcat :-( :( My server is not powerful, but other applications running on it are very fast compared to Continuum (Jira, Spring MVC/Struts home-made Java applications, Proximity, ...) Are 7,5s to load a single page an acceptable value for a such product ? We'll improve performance in 1.2, but I don't think 7,5s is a problem for a such product Emmanuel
Re: Re: Maven Antrun Plugin - specific target call
You are right the difference is not too big.
The members of my project team used ant for many years so they are used to say
ant which target to call.
And the pom would be much bigger to set up with profiles (only for the
ant-plugin) for every different build.
Martin
> Ritz, Martin schrieb:
> > Indeed, Dave is right.
> > I use the ant plugin only to perform tasks maven could'nt fulfill.
> > Main works is done by maven but some things I couldn't find
> ways to perform with maven.
> >
> > In my project I have integrated the izpack plugin with ant.
> > I don't want to execute this task in every build.
> > The next would be a deploy to the SAP Web Application
> Server for which I found only a way with ant.
> > So this tasks should be executed for different builds and I
> don't want to execute this both togetheter in one build.
> > Profiles would be an option but it's not a really smart way...
> > (because I have some profiles yet - i dont want to confuse
> my users to
> > much)
> >
> > The best way in my opinion would by (like Dave posted) "mvn
> install -DantTarget=targetToCall" or something similar.
> > So it would be self explanatory and good to remind.
>
> Why would this be more self explanatory than 'mvn
> -Pgenerate_izpack install' for example?
>
> -Tim
>
> >
> > On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
> >> I would just move those targets out to a build.xml file so you
> >> can call them directly with Ant. Then set Maven up so it calls
> >> the targets in the build.xml file rather than
> embedding the Ant stuff in your pom.
> >
> > I use already this way like this:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Here i define different targets in the buildscript but I'm
> not able to call a specific one so if i run the ant-plugin i
> have to perform all targets which i declared.
> >
> >
> > Martin (OP)
> >
> >
> >
> >> Until the OP responds, we'll never know the answer. We're
> both making
> >> assumptions here.
> >>
> >> Wayne
> >>
> >> On 9/11/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote:
> >>> Because ant can inherit the classpaths/dependencies.
> Presumably he
> >>> *is* utilizing the lifecycle, and attaching this ant config
> >> to one of
> >>> the phases, but has a need to call specific ant tasks only
> >> sometimes.
> >>> Was there something I missed that made you think he was
> >> calling maven
> >>> only to call ant, and that he had no interest in utlizing the
> >>> lifecycle? I assumed this was a somewhat special case
> and that it
> >>> wasn't just using Maven to wrap an ant build process - that
> >> I agree would be silly.
> >>>
> >>> On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
> That just sounds more complicated than it needs to be.
> >> Calling Maven
> just so it will call Ant for me is too indirect when I
> >> can just call
> Ant directly, right? What's the advantage when it works
> fine with
> "ant " and I have no interest in utilizing the Maven
> lifecycle for this particular Ant target/call?
>
> Wayne
>
> On 9/11/07, Dave Feltenberger
> <[EMAIL PROTECTED]> wrote:
> > Can't you just pass in a -D argument and execute the argument
> > that's
> passed
> > in?
> >
> > e.g.
> > mvn install -DantTarget=targetToCall
> >
> > then in the antrun execution:
> > > antfile="src/main/ant-builds/buildJnlps.xml"
> > target="${antTarget}" />
> >
> >
> > On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
> >> I would just move those targets out to a build.xml
> >> file so you
> >> can call them directly with Ant. Then set Maven up so
> >> it calls
> >> the targets in the build.xml file rather than
> >> embedding the Ant stuff in your pom.
> >> Wayne
> >>
> >> On 9/11/07, Ritz, Martin <[EMAIL PROTECTED]> wrote:
> >>> I have already two profiles...
> >>> I dont want to blow up my pom too much!
> >>> Is there no other easier way to call specific targets?
> >>>
> >>> Martin
> >>>
> >>>
> Profiles will solve your problem.
>
> Wayne
>
> On 9/11/07, Ritz, Martin <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I have some ant targets integrated in my pom.xml.
> > I declared an ant build script which is therefor called from
> maven.
> > Now I dont want to perform every ant target on
> >> every build.
> > Is there a way to call only specific
> >> ant-targets from the
> command line (maybe by calling the target or the id)?
> > ---
> > kind regards
> > Martin Ritz
> >
> >> BTC AG - Unit Software Engineering
> > mailto:[EMAIL PROTECTED]
> >
> >
>
> >>
>
> -
> To unsubscribe,
Custom mojo/lifecycle issues
List, I'm investigating the use of Maven as a project lifecycle management tool for solution deployment projects that we do at my company. I have so far defined 2 goals in my mojo, validate and install, which correspond to the 2 initial phases of our specific lifecycle (validate > install > patch > overlay > load > test > report). As far as my current understanding goes, it is not (yet?) possible to define an entirely custom lifecycle in Maven, only to map mojo goals to phases in one of the existing lifecycles, the default lifecycle being, as it were, the default. My components.xml and lifecycle.xml files are as follows: org.apache.maven.lifecycle.mapping.LifecycleMapping fast-gs-project org.apache.maven.lifecycle.mapping.DefaultLifecycleMappi ng com.fastsearch.gs.mojo:maven-esp-plugin:validate com.fastsearch.gs.mojo:maven-esp-plugin:install fast-gs-project validate validate compile install (Note that I have mapped the 'install' goal to the 'compile' phase in the default lifecycle.) However, when I run Maven on a sample project, its behaviour i somewhat strange: C:\cygwin\home\blehra\eclipsework\default\sampleproj>mvn esp:install [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'esp'. [INFO] [INFO] Building Sample Project [INFO]task-segment: [esp:install] [INFO] [INFO] Preparing esp:install [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [INFO] Preparing esp:validate [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [WARNING] Removing: validate from forked lifecycle, to prevent recursive invocation. [INFO] No goals needed for project - skipping [INFO] [esp:validate] [INFO] Project is valid [INFO] Preparing esp:validate [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [WARNING] Removing: validate from forked lifecycle, to prevent recursive invocation. [INFO] No goals needed for project - skipping [INFO] [esp:validate] [INFO] Project is valid [INFO] [esp:install] [INFO] [INFO] FAST Maven Installer starting up... [INFO] Customer:customer [INFO] Project: project [INFO] Target env: test [INFO] Local host: ablehr.laptop.net [INFO] Local base dir: C:\cygwin\home\blehra\eclipsework\default\sampleproj [INFO] Install profile: \custom\resources\test\InstallProfile.xml [INFO] [INFO] Reading install profile and connecting to hosts... [INFO] ESP version: 5.1.3 [INFO] Platform:Linux [INFO] Remote command: SSH2 [INFO] Target hosts: [INFO] - test48.oslo.fast.no [INFO] - test66.oslo.fast.no [INFO] - test117.oslo.fast.no (admin) [INFO] - test123.oslo.fast.no [INFO] [INFO] Checking if ESP 5.1.3 is installed on hosts in configuration... [INFO] -> test48.oslo.fast.no: Running OK [INFO] -> test66.oslo.fast.no: Running OK [INFO] -> test117.oslo.fast.no: Running OK [INFO] -> test123.oslo.fast.no: Running OK [INFO] ESP 5.1.3 is installed on all hosts in configuration, nothing to do. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Wed Sep 12 13:05:53 CEST 2007 [INFO] Final Memory: 2M/5M [INFO] C:\cygwin\home\blehra\eclipsework\default\sampleproj> My questions: 1. The 'validate' goal is invoked twice in a row; why and how to avoid? 2. I'm getting the message 'No goals needed for project - skipping', which according to a posting here from Brett Porter on 17 Nov 2005 means that 'the module has a packaging of POM or something else that doesn't define any goals for the lifecycle step you are running'. Should I be worried? 3. I'm getting warnings that has been 'removed from lifecycle, to prevent recursive invocation'. Should I be worried (guess not), and if not, is it possible to disable this message (without hacking the Maven sources, I mean)? The POM for my sample project is the following: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/ma
Next version of the site plugin? (Was: Why is my site.xml ignored?)
Hi, answering my own question: I see, that this is a bug in the current version of the site plugin and that the bug has been fixed in the trunk. Any ideas, why the next version will be released? Thanks, Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Custom mojo/lifecycle questions
List, I'm investigating the use of Maven as a project lifecycle management tool for solution deployment projects that we do at my company. I have so far defined 2 goals in my mojo, validate and install, which correspond to the 2 initial phases of our specific lifecycle (validate > install > patch > overlay > load > test > report). As far as my current understanding goes, it is not (yet?) possible to define an entirely custom lifecycle in Maven, only to map mojo goals to phases in one of the existing lifecycles, the default lifecycle being, as it were, the default. My components.xml and lifecycle.xml files are as follows: org.apache.maven.lifecycle.mapping.LifecycleMapping fast-gs-project org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping com.fastsearch.gs.mojo:maven-esp-plugin:validate com.fastsearch.gs.mojo:maven-esp-plugin:install fast-gs-project validate validate compile install (Note that I have mapped the 'install' goal to the 'compile' phase in the default lifecycle.) However, when I run Maven on a sample project, its behaviour i somewhat strange: C:\cygwin\home\blehra\eclipsework\default\sampleproj>mvn esp:install [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'esp'. [INFO] [INFO] Building Sample Project [INFO]task-segment: [esp:install] [INFO] [INFO] Preparing esp:install [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [INFO] Preparing esp:validate [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [WARNING] Removing: validate from forked lifecycle, to prevent recursive invocation. [INFO] No goals needed for project - skipping [INFO] [esp:validate] [INFO] Project is valid [INFO] Preparing esp:validate [WARNING] Removing: install from forked lifecycle, to prevent recursive invocation. [WARNING] Removing: validate from forked lifecycle, to prevent recursive invocation. [INFO] No goals needed for project - skipping [INFO] [esp:validate] [INFO] Project is valid [INFO] [esp:install] [INFO] [INFO] FAST Maven Installer starting up... [INFO] Customer:customer [INFO] Project: project [INFO] Target env: test [INFO] Local host: ablehr.laptop.net [INFO] Local base dir: C:\cygwin\home\blehra\eclipsework\default\sampleproj [INFO] Install profile: \custom\resources\test\InstallProfile.xml [INFO] [INFO] Reading install profile and connecting to hosts... [INFO] ESP version: 5.1.3 [INFO] Platform:Linux [INFO] Remote command: SSH2 [INFO] Target hosts: [INFO] - test48.oslo.fast.no [INFO] - test66.oslo.fast.no [INFO] - test117.oslo.fast.no (admin) [INFO] - test123.oslo.fast.no [INFO] [INFO] Checking if ESP 5.1.3 is installed on hosts in configuration... [INFO] -> test48.oslo.fast.no: Running OK [INFO] -> test66.oslo.fast.no: Running OK [INFO] -> test117.oslo.fast.no: Running OK [INFO] -> test123.oslo.fast.no: Running OK [INFO] ESP 5.1.3 is installed on all hosts in configuration, nothing to do. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Wed Sep 12 13:05:53 CEST 2007 [INFO] Final Memory: 2M/5M [INFO] C:\cygwin\home\blehra\eclipsework\default\sampleproj> My questions: 1. The 'validate' goal is invoked twice in a row; why and how to avoid? 2. I'm getting the message 'No goals needed for project - skipping', which according to a posting here from Brett Porter on 17 Nov 2005 means that 'the module has a packaging of POM or something else that doesn't define any goals for the lifecycle step you are running'. Should I be worried? 3. I'm getting warnings that has been 'removed from lifecycle, to prevent recursive invocation'. Should I be worried (guess not), and if not, is it possible to disable this message (without hacking the Maven sources, I mean)? The POM for my sample project is the following: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/
Re: Maven Antrun Plugin - specific target call
Ritz, Martin schrieb: Indeed, Dave is right. I use the ant plugin only to perform tasks maven could'nt fulfill. Main works is done by maven but some things I couldn't find ways to perform with maven. In my project I have integrated the izpack plugin with ant. I don't want to execute this task in every build. The next would be a deploy to the SAP Web Application Server for which I found only a way with ant. So this tasks should be executed for different builds and I don't want to execute this both togetheter in one build. Profiles would be an option but it's not a really smart way... (because I have some profiles yet - i dont want to confuse my users to much) The best way in my opinion would by (like Dave posted) "mvn install -DantTarget=targetToCall" or something similar. So it would be self explanatory and good to remind. Why would this be more self explanatory than 'mvn -Pgenerate_izpack install' for example? -Tim On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote: I would just move those targets out to a build.xml file so you can call them directly with Ant. Then set Maven up so it calls the targets in the build.xml file rather than embedding the Ant stuff in your pom. I use already this way like this: Here i define different targets in the buildscript but I'm not able to call a specific one so if i run the ant-plugin i have to perform all targets which i declared. Martin (OP) Until the OP responds, we'll never know the answer. We're both making assumptions here. Wayne On 9/11/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: Because ant can inherit the classpaths/dependencies. Presumably he *is* utilizing the lifecycle, and attaching this ant config to one of the phases, but has a need to call specific ant tasks only sometimes. Was there something I missed that made you think he was calling maven only to call ant, and that he had no interest in utlizing the lifecycle? I assumed this was a somewhat special case and that it wasn't just using Maven to wrap an ant build process - that I agree would be silly. On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote: That just sounds more complicated than it needs to be. Calling Maven just so it will call Ant for me is too indirect when I can just call Ant directly, right? What's the advantage when it works fine with "ant " and I have no interest in utilizing the Maven lifecycle for this particular Ant target/call? Wayne On 9/11/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: Can't you just pass in a -D argument and execute the argument that's passed in? e.g. mvn install -DantTarget=targetToCall then in the antrun execution: On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote: I would just move those targets out to a build.xml file so you can call them directly with Ant. Then set Maven up so it calls the targets in the build.xml file rather than embedding the Ant stuff in your pom. Wayne On 9/11/07, Ritz, Martin <[EMAIL PROTECTED]> wrote: I have already two profiles... I dont want to blow up my pom too much! Is there no other easier way to call specific targets? Martin Profiles will solve your problem. Wayne On 9/11/07, Ritz, Martin <[EMAIL PROTECTED]> wrote: Hi, I have some ant targets integrated in my pom.xml. I declared an ant build script which is therefor called from maven. Now I dont want to perform every ant target on every build. Is there a way to call only specific ant-targets from the command line (maybe by calling the target or the id)? --- kind regards Martin Ritz BTC AG - Unit Software Engineering mailto:[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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why is my site.xml ignored?
Hi, I've got a project, which I am currently moving to Maven. Historically, the directory "src" is used for Java sources and this cannot be changed easily. Not now, at least. Obviously, "src/site" would be an unfortunate choice, which is why I am using the directory "site". Therefore, my POM contains the following section: maven-site-plugin site site However, the file site/site.xml is completely ignored. Am I doing something wrong? Or is there something else I need to change? Thanks, Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Maven Antrun Plugin - specific target call
Indeed, Dave is right.
I use the ant plugin only to perform tasks maven could'nt fulfill.
Main works is done by maven but some things I couldn't find ways to perform
with maven.
In my project I have integrated the izpack plugin with ant.
I don't want to execute this task in every build.
The next would be a deploy to the SAP Web Application Server for which I found
only a way with ant.
So this tasks should be executed for different builds and I don't want to
execute this both togetheter in one build.
Profiles would be an option but it's not a really smart way... (because I have
some profiles yet - i dont want to confuse my users to much)
The best way in my opinion would by (like Dave posted) "mvn install
-DantTarget=targetToCall" or something similar.
So it would be self explanatory and good to remind.
On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
> > > > > I would just move those targets out to a build.xml file so you
> > > > > can call them directly with Ant. Then set Maven up so it calls
> > > > > the targets in the build.xml file rather than embedding the Ant stuff
> > > > > in your pom.
I use already this way like this:
Here i define different targets in the buildscript but I'm not able to call a
specific one so if i run the ant-plugin i have to perform all targets which i
declared.
Martin (OP)
>
> Until the OP responds, we'll never know the answer. We're
> both making assumptions here.
>
> Wayne
>
> On 9/11/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote:
> > Because ant can inherit the classpaths/dependencies. Presumably he
> > *is* utilizing the lifecycle, and attaching this ant config
> to one of
> > the phases, but has a need to call specific ant tasks only
> sometimes.
> > Was there something I missed that made you think he was
> calling maven
> > only to call ant, and that he had no interest in utlizing the
> > lifecycle? I assumed this was a somewhat special case and that it
> > wasn't just using Maven to wrap an ant build process - that
> I agree would be silly.
> >
> >
> > On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
> > >
> > > That just sounds more complicated than it needs to be.
> Calling Maven
> > > just so it will call Ant for me is too indirect when I
> can just call
> > > Ant directly, right? What's the advantage when it works fine with
> > > "ant " and I have no interest in utilizing the Maven
> > > lifecycle for this particular Ant target/call?
> > >
> > > Wayne
> > >
> > > On 9/11/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote:
> > > > Can't you just pass in a -D argument and execute the argument
> > > > that's
> > > passed
> > > > in?
> > > >
> > > > e.g.
> > > > mvn install -DantTarget=targetToCall
> > > >
> > > > then in the antrun execution:
> > > > > > > antfile="src/main/ant-builds/buildJnlps.xml"
> > > > target="${antTarget}" />
> > > >
> > > >
> > > > On 9/11/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I would just move those targets out to a build.xml
> file so you
> > > > > can call them directly with Ant. Then set Maven up so
> it calls
> > > > > the targets in the build.xml file rather than
> embedding the Ant stuff in your pom.
> > > > >
> > > > > Wayne
> > > > >
> > > > > On 9/11/07, Ritz, Martin <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > I have already two profiles...
> > > > > > I dont want to blow up my pom too much!
> > > > > > Is there no other easier way to call specific targets?
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > >
> > > > > > > Profiles will solve your problem.
> > > > > > >
> > > > > > > Wayne
> > > > > > >
> > > > > > > On 9/11/07, Ritz, Martin <[EMAIL PROTECTED]> wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I have some ant targets integrated in my pom.xml.
> > > > > > > > I declared an ant build script which is therefor called
> > > > > > > > from
> > > maven.
> > > > > > > > Now I dont want to perform every ant target on
> every build.
> > > > > > > > Is there a way to call only specific
> ant-targets from the
> > > > > > > command line (maybe by calling the target or the id)?
> > > > > > > >
> > > > > > > > ---
> > > > > > > > kind regards
> > > > > > > > Martin Ritz
> > > > > > > >
> > > > > > > > > BTC AG - Unit Software Engineering
> > > > > > > > mailto:[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]
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---
Re: Surefire 2.4 release and TestNG
Thanks Brett, I'll have a read through and see if there is anything I can help with. - Original message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Users List" Date: Wed, 12 Sep 2007 20:39:48 +1000 Subject: Re: Surefire 2.4 release and TestNG IT's still moving along slowly: http://docs.codehaus.org/display/MAVEN/Surefire+TestNG+refactoring On 12/09/2007, Martin Gilday <[EMAIL PROTECTED]> wrote: > Is a release of Surefire 2.4 about due? 2.3 was released in March with > the note: > Note: a 2.4 release is being worked on immediately to resolve some > issues with TestNG. This release is being made available to users > having the above problems before that work begins. > > The previous advice for anyone wanting to use TestNG with Maven is to > use the 2.4-SNAPSHOT from people.apache.org. This seems to > intermittently cease working. Currently the error being: > java.lang.IllegalArgumentException: Unknown parameter type: > java.util.Properties > at > > org.apache.maven.surefire.booter.SurefireBooter.constructParamObjects(SurefireBooter.java: > 800) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java: > 855) > > The current advice seems to be to use the snapshot found here: > http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-surefire-plugin/2.4-collab-SNAPSHOT/ > This works well for me. But what is the collab version? > > The uncertainty of the pairing of TestNG and Maven is currently a major > blocker in ours, and I assume many peoples, uptake of TestNG. > Is it possible to have a 2.4 release made of the Surefire which works > with TestNG to some degree (such as the collab version) so users do not > have to rely on the state of the SNAPSHOT all the time? > > Thanks, > Martin. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - 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]
Re: Surefire 2.4 release and TestNG
IT's still moving along slowly: http://docs.codehaus.org/display/MAVEN/Surefire+TestNG+refactoring On 12/09/2007, Martin Gilday <[EMAIL PROTECTED]> wrote: > Is a release of Surefire 2.4 about due? 2.3 was released in March with > the note: > Note: a 2.4 release is being worked on immediately to resolve some > issues with TestNG. This release is being made available to users > having the above problems before that work begins. > > The previous advice for anyone wanting to use TestNG with Maven is to > use the 2.4-SNAPSHOT from people.apache.org. This seems to > intermittently cease working. Currently the error being: > java.lang.IllegalArgumentException: Unknown parameter type: > java.util.Properties > at > > org.apache.maven.surefire.booter.SurefireBooter.constructParamObjects(SurefireBooter.java: > 800) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java: > 855) > > The current advice seems to be to use the snapshot found here: > http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-surefire-plugin/2.4-collab-SNAPSHOT/ > This works well for me. But what is the collab version? > > The uncertainty of the pairing of TestNG and Maven is currently a major > blocker in ours, and I assume many peoples, uptake of TestNG. > Is it possible to have a 2.4 release made of the Surefire which works > with TestNG to some degree (such as the collab version) so users do not > have to rely on the state of the SNAPSHOT all the time? > > Thanks, > Martin. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Surefire 2.4 release and TestNG
Is a release of Surefire 2.4 about due? 2.3 was released in March with the note: Note: a 2.4 release is being worked on immediately to resolve some issues with TestNG. This release is being made available to users having the above problems before that work begins. The previous advice for anyone wanting to use TestNG with Maven is to use the 2.4-SNAPSHOT from people.apache.org. This seems to intermittently cease working. Currently the error being: java.lang.IllegalArgumentException: Unknown parameter type: java.util.Properties at org.apache.maven.surefire.booter.SurefireBooter.constructParamObjects(SurefireBooter.java: 800) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java: 855) The current advice seems to be to use the snapshot found here: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-surefire-plugin/2.4-collab-SNAPSHOT/ This works well for me. But what is the collab version? The uncertainty of the pairing of TestNG and Maven is currently a major blocker in ours, and I assume many peoples, uptake of TestNG. Is it possible to have a 2.4 release made of the Surefire which works with TestNG to some degree (such as the collab version) so users do not have to rely on the state of the SNAPSHOT all the time? Thanks, Martin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: properties in settings.xml
why would you specify your version outside of source control... you will no
consistency acros difference machines/developers?
On Wednesday 12 September 2007 19:04, Huang, Yan wrote:
> Hi,
>
> I noticed that the "install" phase does not resolve the properties that
> are defined in settings.xml. For example, I use a property in my
> settings.xml to define the release version:
>
>
> DefaultProfile
>
> 1.1.1.1
>
>
>
>
> Now, I have a pom that access that property:
>
> myexample.myexample
> foo1
> ${myversion}
>
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
eclipse:eclipse and aspectj
Hi all, I am trying to generate my eclipse project metadata (.project/.classpath) with mvn eclipse:eclispe, while also using aspectj. The .project that gets created DOES contain the ajnature and ajbuilder, so that's looking good. However, the classpath attributes indicating that aspects from a jar should be woven into my project are NOT generated, i.e., instead of: I just get: The relevant configuration in the the aspectj plugin is in my pom.xml is: 1.5 org.contract4j5 contract4j5 I was wondering if there was any way to get this working. Am I doing something wrong or do I need to do some extra configuration? Or is this functionality missing from the relevant plugin (eclispe or aspectj)? Many thanks! Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Plugin Binding
Hi, is there a way to bind a plugin execution to a other plugin mojo call? I want to bind the webstart plugin execution to the assembly:single mojo. So everytime i execute the assembly plugin the webstart would be also started and I can pack the webstart artifacts in an zip file. I don't want to bind both to a phase because i don't want to execute the assembly in every build. Martin
[M2] Acessing command line properties from JUnit tests
If I use "mvn -Dfoo=bar integration-test" I was expecting
System.getProperty("foo") to return "bar" in the invoked tests. It isn't -
have I misunderstood this please? Thanks.
--
View this message in context:
http://www.nabble.com/-M2--Acessing-command-line-properties-from-JUnit-tests-tf4427748s177.html#a12630944
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 : Jar with included Jar dependencies
Not really difficult :
maven-assembly-plugin
jar-with-dependencies
sample.soapwithattachments.client.SWAClient
make-assembly
package
attached
Arnaud
On 12/09/2007, Annies, Sebastian <[EMAIL PROTECTED]> wrote:
>
> We do this by hand since the assembly plugin is too hard to use. You may
> give it a try:
>
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
>
> copy-dependencies
> package
>
> copy-dependencies
>
>
> ${project.build.directory}/release-${
> project.version}/lib
> runtime
> true
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> packageApp
> package
>
>
>
>
>prefix="isoviewer" includes="**/*" />
>
>
>
>
> run
>
>
>
>
>
>
>
> org.codehaus.mojo
> build-helper-maven-plugin
>
>
> attach-artifacts
> package
>
> attach-artifact
>
>
>
>
> ${project.build.directory}/isoviewer-${
> project.version}.zip
> zip
> bin
>
>
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> iso.gui.Main
> true
> lib
>
>
>
>
>
>
>
>
>
> -Ursprüngliche Nachricht-
> Von: zm [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 11. September 2007 22:24
> An: users@maven.apache.org
> Betreff: Maven 2 : Jar with included Jar dependencies
>
>
> Hi,
>
> I'm trying to create a jar using Maven 2, but I'm not getting what I whant
> to ...
>
> I have a jar project (main.jar) that depends on another jar (common.jar).
> My
> poms are working correctly, but I need to create a self dependant main.jar
> .
> That is, I need main.jar to include the common.jar, and access it without
> any other external classpath info. I just want to execute "java -jar
> main.jar" and voila ... executes nicelly.
>
> Googling around I found no solution for the base jar "feature", but I
> heard
> about plugins for Maven ... UberJar and JavaApp. Both should work fine
> with
> Maven 1.x.
>
> I'm using Maven 2.0.7, and I've read somewhere around my googling that
> this
> "jar included dependencies" are already available in the base Maven 2
> framework.
>
> Now I just need some help to put it to works, as googling around is
> bringing
> me many results that does not interest me, and maybe you know how to do
> it,
> or point me to some link that helps ...
>
> I'm new to Maven, and I really want to learn how to use it properly ...
> the
> fact is that I also find it very difficult sometimes to find info about
> pluggins, how to use them, their settings/usage ...
>
> Anyway, any help regarding jars inside jars :) would be greatly
> appreciated.
>
> Thanks.
> --
> View this message in context:
> http://www.nabble.com/Maven-2-%3A-Jar-with-included-Jar-dependencies-tf4425083s177.html#a12622970
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> -
> 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]
>
>
--
..
Arnaud HERITIER
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...
Re: Maven2 properties file as in Ant
Perhaps filtering [1] will help you out?
Andy
[1] http://maven.apache.org/guides/getting-started/
index.html#How_do_I_filter_resource_files
On 7 Sep 2007, at 21:38, Juan Ignacio Garzón wrote:
Hi!
I have read the Settings Reverence [1], and in the section
"Properties" there is a paragraph saying:
"x : Set within a element or an **external files**, the
value may be used as ${someVar} ."
Is there a way to define properties in an external file, in the same
way as Ant? I would like to have all my passwords (for example, for
database connections) stored in only one place and isolated from the
rest of my properties. I prefer having them outside settings.xml and
pom.xml.
Thanks in advance!!
[1] http://maven.apache.org/settings.html#Profiles
-
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]
AW: Maven 2 : Jar with included Jar dependencies
We do this by hand since the assembly plugin is too hard to use. You may give
it a try:
org.apache.maven.plugins
maven-dependency-plugin
copy-dependencies
package
copy-dependencies
${project.build.directory}/release-${project.version}/lib
runtime
true
org.apache.maven.plugins
maven-antrun-plugin
packageApp
package
run
org.codehaus.mojo
build-helper-maven-plugin
attach-artifacts
package
attach-artifact
${project.build.directory}/isoviewer-${project.version}.zip
zip
bin
org.apache.maven.plugins
maven-jar-plugin
iso.gui.Main
true
lib
-Ursprüngliche Nachricht-
Von: zm [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 11. September 2007 22:24
An: users@maven.apache.org
Betreff: Maven 2 : Jar with included Jar dependencies
Hi,
I'm trying to create a jar using Maven 2, but I'm not getting what I whant
to ...
I have a jar project (main.jar) that depends on another jar (common.jar). My
poms are working correctly, but I need to create a self dependant main.jar.
That is, I need main.jar to include the common.jar, and access it without
any other external classpath info. I just want to execute "java -jar
main.jar" and voila ... executes nicelly.
Googling around I found no solution for the base jar "feature", but I heard
about plugins for Maven ... UberJar and JavaApp. Both should work fine with
Maven 1.x.
I'm using Maven 2.0.7, and I've read somewhere around my googling that this
"jar included dependencies" are already available in the base Maven 2
framework.
Now I just need some help to put it to works, as googling around is bringing
me many results that does not interest me, and maybe you know how to do it,
or point me to some link that helps ...
I'm new to Maven, and I really want to learn how to use it properly ... the
fact is that I also find it very difficult sometimes to find info about
pluggins, how to use them, their settings/usage ...
Anyway, any help regarding jars inside jars :) would be greatly appreciated.
Thanks.
--
View this message in context:
http://www.nabble.com/Maven-2-%3A-Jar-with-included-Jar-dependencies-tf4425083s177.html#a12622970
Sent from the Maven - Users mailing list archive at Nabble.com.
-
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]
RE: NoClassDeFoundError running unit test
My dependent class is a test class, that is, in my unit test I do a new of a class located in project A, it is a class which contains only static methods, and so, my unit tests in project B want to use those static methods to test the classes in project B. I believe is quite normal what I'm doing... In eclipse, I've compiled the pom of both the project by hand, then I've also isntalled the m2plugin per eclipse, but I wrote the dependencies without using other tools. However I haven't ever used mvn eclipse:eclipse Any other hints? However my projects are only very simple projects created only with the aim of learning and using MAVEN because in my company we would like to employ maven. But as you can see I immediately found a big block in my evaluetion. Thanks to all, any other hints? Raffaele -Original Message- From: Iker Almandoz [mailto:[EMAIL PROTECTED] Sent: martedì 11 settembre 2007 17.52 To: 'Maven Users List' Subject: RE: NoClassDeFoundError running unit test Is your dependent class a 'test' class in project A or a 'main' class in project A ? In eclipse, are you importing project A or you have used 'mvn eclipse:eclipse' to generate your dependencies? Eclipse does not distinguish between test classpath and compile classpath so that could be part of the issue... -Original Message- From: GAMBELLI Raffaele [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 11, 2007 7:26 AM To: users@maven.apache.org Subject: NoClassDeFoundError running unit test I'm using Maven 2.0.7 I have two project, let's call them A and B. A has only external dependencies. B has external dependencies, but is also dependent on project A. Project B uses a class from Project A in a unit test. Running either "mvn test" or "mvn package" from the project B level results in a java.lang.NoClassDefFoundError (it can't found the class defined in project A) during the unit test of project B. But, if I run directly unit test of project B from Eclipse, the unit test completes successfully. Why? Thanks in advance, regards. Raffaele - 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]
RE: NoClassDeFoundError running unit test
The class in project A is in src/java (I'm not using the default maven tree, but I have override those properties in my pom don't worry) I tried with either test scope either compile scope in the dependency from project B to project A. The default scope is compile, is that true? I've also tried mvn install but the error remains and it is practically the same as mvn test, that is project B cannot see a class of project A. Thanks. Raffaele -Original Message- From: Jim Sellers [mailto:[EMAIL PROTECTED] Sent: martedì 11 settembre 2007 17.27 To: Maven Users List Subject: Re: NoClassDeFoundError running unit test "Project B uses a class from Project A in a unit test." Where is this class in Project A? Is it in src/main/java or src/test/java? If it's in src/test/java you'll have to create a test jar: http://maven.apache.org/guides/mini/guide-attached-tests.html What is the scope of the dependency from Project B to Project A? Have you tried mvn install on Project A first? With maven, code in src/test can only "see" the code in src/main, but not the other way around. With eclipse your code in src/main/java can see src/test/java. HTH Jim On 9/11/07, GAMBELLI Raffaele <[EMAIL PROTECTED]> wrote: > > I'm using Maven 2.0.7 > I have two project, let's call them A and B. > A has only external dependencies. > B has external dependencies, but is also dependent on project A. > > Project B uses a class from Project A in a unit test. > > Running either "mvn test" or "mvn package" from the project B level > results in a > java.lang.NoClassDefFoundError (it can't found the class defined in > project A) during the unit test of project B. > > But, if I run directly unit test of project B from Eclipse, the unit test > completes successfully. Why? > > Thanks in advance, regards. > Raffaele > > > > - > 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]
Re: properties in settings.xml
"Huang, Yan" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I noticed that the "install" phase does not resolve the properties that
> are defined in settings.xml. For example, I use a property in my
> settings.xml to define the release version:
>
>
> DefaultProfile
>
> true
>
>
> 1.1.1.1
>
>
>
>
> Now, I have a pom that access that property:
>
> myexample.myexample
> foo1
> ${myversion}
>
> When I run "mvn install", it does creat and install foo1-1.1.1.1.jar in
> my local repo in ~/.m2/repository/myexample/ However, when I look at
> the foo1-1.1.1.1.pom file, the "version" tag is not resolved and instead
> it still refers to ${myversion}. Is it a problem?
AFAIK this is perfectly normal: The deployed .pom file is the actual
pom of the project without any modification. You can find the
effective pom (ie. the one used to build the artifact) inside the
META-INF/ directory of the jar.
The rationale behind this (speaking within control of more knowledgeable
maven developers) is that the deployed pom can be used as a dependency
to construct another pom withing another process, where the variables
would need to be instantiated to other values according to
settings/profiles/whatever.
HTH
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
properties in settings.xml
Hi,
I noticed that the "install" phase does not resolve the properties that
are defined in settings.xml. For example, I use a property in my
settings.xml to define the release version:
DefaultProfile
true
1.1.1.1
Now, I have a pom that access that property:
myexample.myexample
foo1
${myversion}
When I run "mvn install", it does creat and install foo1-1.1.1.1.jar in
my local repo in ~/.m2/repository/myexample/ However, when I look at
the foo1-1.1.1.1.pom file, the "version" tag is not resolved and instead
it still refers to ${myversion}. Is it a problem?
Thanks
Yan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
