RE: Help to use plugin coverage
Standard testing, which uses the surefire plugin and is done at the test lifecycle, use the naming convention like this: * "**/Test*.java" - includes all of its subdirectories and all java filenames that start with "Test". * "**/*Test.java" - includes all of its subdirectories and all java filenames that end with "Test". * "**/*TestCase.java" - includes all of its subdirectories and all java filenames that end with "TestCase". Integration-testing using the maven-failsafe-plugin use the naming convention like this: * "**/IT*.java" - includes all of its subdirectory and all java filenames that start with "IT". * "**/*IT.java" - includes all of its subdirectory and all java filenames that end with "IT". * "**/*ITCase.java" - includes all of its subdirectory and all java filenames that end with "ITCase". So you can put everything in src/test/java and then split them up by name and I suggest package to keep things clean. -Original Message- From: Ewerton Vale Leal [mailto:ewerto...@gmail.com] Sent: Friday, February 18, 2011 6:43 PM To: Maven Users List Subject: Re: Help to use plugin coverage How do I create another directory for integration testing in maven? 2011/2/18 Shay Thompson > > You might also want to look into the maven-failsafe-plugin for your > integration tests. > > -Original Message- > From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com] > Sent: Friday, February 18, 2011 3:34 PM > To: Ewerton Vale Leal > Cc: Maven Users List > Subject: Re: Help to use plugin coverage > > On 18 February 2011 12:45, Ewerton Vale Leal wrote: > > My directory structure is this: > > src/main/java > > src/main/resources > > src/main/webapp > > src/test/java/unitTest > > src/test/java/functionalTest > > This is unusual. I would suggest src/test/java for your unit tests and > something else (src/test/it ?) for your integration/functional tests. > That way at least your unit tests should run. > > You need to check out the Maven Surefire Plugin. For your integration > tests, you'll have to change the testSourceDirectory. > > > I have unit tests and integration tests in the same project. > > FYI, normally, you would put the integration tests in a separate > project that depends on the project it's testing. I would still > recommend that but I don't know how you would get Cobertura working in > that scenario. > > > I running the commands mvn install. > > That's fine. The "verify" phase in the Maven Build Cycle is the one > just before "install". While you're trying things out it's a tiny bit > faster. :-) > > > "Why are you using true? Isn't the whole point to > > run the tests?" > > I do not know right to use maven. I'm new at this. > > In the configuration it has "false " and not true. > > If true, the tests not execute. > > I would remove . > > > To run the tests, I use a test suite, the class "AllTeste.java", > > running the unit tests and integration. > > You mean you're running your unit tests and integration tests all at > the same time? I don't think that's what you want. Also test suites > are not run by Surefire. It uses a pattern to identify tests. See the > Maven Surefire Plugin documentation. > > Run your unit tests first in phase "test" (that should not require any > setup as long as you've named your tests appropriately), then run your > integration tests in phase "integration-test". You should be able to > set up Surefire to run in different phases with a different > testSourceDirectory. > > I think you're pretty close. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Ewerton Leal Vale Bacharelando em Ciência da Computação - UFPI - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Tracking down a dependency mystery
On Sat, Feb 19, 2011 at 2:01 AM, Benson Margulies wrote: > OK, mystery solved. I found the relevant dependencyManagement > statement in a distant parent, leftover from long ago. > Can you see if there is already a bug filed that says we should do more to help the user track these down? If not, can you raise it.
Re: Help to use plugin coverage
How do I create another directory for integration testing in maven? 2011/2/18 Shay Thompson > > You might also want to look into the maven-failsafe-plugin for your > integration tests. > > -Original Message- > From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com] > Sent: Friday, February 18, 2011 3:34 PM > To: Ewerton Vale Leal > Cc: Maven Users List > Subject: Re: Help to use plugin coverage > > On 18 February 2011 12:45, Ewerton Vale Leal wrote: > > My directory structure is this: > > src/main/java > > src/main/resources > > src/main/webapp > > src/test/java/unitTest > > src/test/java/functionalTest > > This is unusual. I would suggest src/test/java for your unit tests and > something else (src/test/it ?) for your integration/functional tests. > That way at least your unit tests should run. > > You need to check out the Maven Surefire Plugin. For your integration > tests, you'll have to change the testSourceDirectory. > > > I have unit tests and integration tests in the same project. > > FYI, normally, you would put the integration tests in a separate > project that depends on the project it's testing. I would still > recommend that but I don't know how you would get Cobertura working in > that scenario. > > > I running the commands mvn install. > > That's fine. The "verify" phase in the Maven Build Cycle is the one > just before "install". While you're trying things out it's a tiny bit > faster. :-) > > > "Why are you using true? Isn't the whole point to > > run the tests?" > > I do not know right to use maven. I'm new at this. > > In the configuration it has "false " and not true. > > If true, the tests not execute. > > I would remove . > > > To run the tests, I use a test suite, the class "AllTeste.java", > > running the unit tests and integration. > > You mean you're running your unit tests and integration tests all at > the same time? I don't think that's what you want. Also test suites > are not run by Surefire. It uses a pattern to identify tests. See the > Maven Surefire Plugin documentation. > > Run your unit tests first in phase "test" (that should not require any > setup as long as you've named your tests appropriately), then run your > integration tests in phase "integration-test". You should be able to > set up Surefire to run in different phases with a different > testSourceDirectory. > > I think you're pretty close. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Ewerton Leal Vale Bacharelando em Ciência da Computação - UFPI
Re: Maven tomcat-maven-plugin doesn't take configuration in the pom.xml in account
Perhaps try adding a default-cli execution as below: > > org.codehaus.mojo > tomcat-maven-plugin default-cli > > tomcat > http://localhost:8081/manager > /freecologic > > This is documented here: http://maven.apache.org/guides/mini/guide-default-execution-ids.html Otherwise, check was "mvn help:effective-pom" tells you about your tomcat-m-p configuration. Maybe a parent is affecting the build config? Also, you should add a version to the plugin node, its a best practice. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven tomcat-maven-plugin doesn't take configuration in the pom.xml in account
I'm trying to set up my maven2 project to deploy to my local tomcat.
In the pom I added:
...
org.codehaus.mojo
tomcat-maven-plugin
tomcat
http://localhost:8081/manager
/freecologic
...
But when I run:
mvn tomcat:deploy
Maven seems to deploy to the default port:
[INFO] Processing war project
[INFO] Copying webapp resources[C:\dev\workspace\appjsf\src\main\webapp]
[INFO] Webapp assembled in[3301 msecs]
[INFO] Building war: C:\dev\workspace\appjsf\targetappjsf-1.0-SNAPSHOT.war
[INFO] [tomcat:deploy {execution: default-cli}]
[INFO] Deploying war to http://localhost:8080/appjsf
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cannot invoke Tomcat manager
Embedded error: Connection refused: connect
[INFO]
Would be that maven isn't taking the configuration in account? I
doubled checked and everything seems to be right.
thanks
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Help to use plugin coverage
You might also want to look into the maven-failsafe-plugin for your integration tests. -Original Message- From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com] Sent: Friday, February 18, 2011 3:34 PM To: Ewerton Vale Leal Cc: Maven Users List Subject: Re: Help to use plugin coverage On 18 February 2011 12:45, Ewerton Vale Leal wrote: > My directory structure is this: > src/main/java > src/main/resources > src/main/webapp > src/test/java/unitTest > src/test/java/functionalTest This is unusual. I would suggest src/test/java for your unit tests and something else (src/test/it ?) for your integration/functional tests. That way at least your unit tests should run. You need to check out the Maven Surefire Plugin. For your integration tests, you'll have to change the testSourceDirectory. > I have unit tests and integration tests in the same project. FYI, normally, you would put the integration tests in a separate project that depends on the project it's testing. I would still recommend that but I don't know how you would get Cobertura working in that scenario. > I running the commands mvn install. That's fine. The "verify" phase in the Maven Build Cycle is the one just before "install". While you're trying things out it's a tiny bit faster. :-) > "Why are you using true? Isn't the whole point to > run the tests?" > I do not know right to use maven. I'm new at this. > In the configuration it has "false " and not true. > If true, the tests not execute. I would remove . > To run the tests, I use a test suite, the class "AllTeste.java", > running the unit tests and integration. You mean you're running your unit tests and integration tests all at the same time? I don't think that's what you want. Also test suites are not run by Surefire. It uses a pattern to identify tests. See the Maven Surefire Plugin documentation. Run your unit tests first in phase "test" (that should not require any setup as long as you've named your tests appropriately), then run your integration tests in phase "integration-test". You should be able to set up Surefire to run in different phases with a different testSourceDirectory. I think you're pretty close. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help to use plugin coverage
On 18 February 2011 12:45, Ewerton Vale Leal wrote: > My directory structure is this: > src/main/java > src/main/resources > src/main/webapp > src/test/java/unitTest > src/test/java/functionalTest This is unusual. I would suggest src/test/java for your unit tests and something else (src/test/it ?) for your integration/functional tests. That way at least your unit tests should run. You need to check out the Maven Surefire Plugin. For your integration tests, you'll have to change the testSourceDirectory. > I have unit tests and integration tests in the same project. FYI, normally, you would put the integration tests in a separate project that depends on the project it's testing. I would still recommend that but I don't know how you would get Cobertura working in that scenario. > I running the commands mvn install. That's fine. The "verify" phase in the Maven Build Cycle is the one just before "install". While you're trying things out it's a tiny bit faster. :-) > "Why are you using true? Isn't the whole point to > run the tests?" > I do not know right to use maven. I'm new at this. > In the configuration it has "false " and not true. > If true, the tests not execute. I would remove . > To run the tests, I use a test suite, the class "AllTeste.java", > running the unit tests and integration. You mean you're running your unit tests and integration tests all at the same time? I don't think that's what you want. Also test suites are not run by Surefire. It uses a pattern to identify tests. See the Maven Surefire Plugin documentation. Run your unit tests first in phase "test" (that should not require any setup as long as you've named your tests appropriately), then run your integration tests in phase "integration-test". You should be able to set up Surefire to run in different phases with a different testSourceDirectory. I think you're pretty close. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: site-deploy always appends ${project.artifactId} in the deploy URL
gotcha, looks like I overlooked that part.
KUDOS for you Lukas! thanks a lot, it worked :)
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Feb 18, 2011 at 9:47 PM, Lukas Theussl wrote:
>
> This is expected and documented [1]: 'If subprojects inherit the site URL
> from a parent POM, they will automatically append their to form
> their effective deployment location'. If you want to overide that, you need
> to declare a site.url in the sub-project.
>
> HTH,
> -Lukas
>
>
> [1] http://maven.apache.org/plugins/maven-site-plugin/usage.html
>
>
> Simone Tripodi wrote:
>>
>> Hi all guys,
>> I'm facing a wired issue, I don't understand if it concerns the
>> maven-site-plugin or the deploy plugin, btw every time I try to deploy
>> the site, the ${project.artifactId} is always appended to the
>> distributionManagement.site.url
>>
>> i.e. if the url is
>>
>> ftp://ftp.acme.org/projects/${project.artifactId}/${project.version}
>>
>> the resulting url will be
>>
>>
>> ftp://ftp.acme.org/projects/${project.artifactId}/${project.version}/${project.artifactId}
>>
>> Any hint/suggestion? My parent pom is public and can be found on
>> github[1], many thanks in advance!
>> Simo
>>
>> [1] https://github.com/99soft/infra
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: site-deploy always appends ${project.artifactId} in the deploy URL
This is expected and documented [1]: 'If subprojects inherit the site
URL from a parent POM, they will automatically append their
to form their effective deployment location'. If you want to overide
that, you need to declare a site.url in the sub-project.
HTH,
-Lukas
[1] http://maven.apache.org/plugins/maven-site-plugin/usage.html
Simone Tripodi wrote:
Hi all guys,
I'm facing a wired issue, I don't understand if it concerns the
maven-site-plugin or the deploy plugin, btw every time I try to deploy
the site, the ${project.artifactId} is always appended to the
distributionManagement.site.url
i.e. if the url is
ftp://ftp.acme.org/projects/${project.artifactId}/${project.version}
the resulting url will be
ftp://ftp.acme.org/projects/${project.artifactId}/${project.version}/${project.artifactId}
Any hint/suggestion? My parent pom is public and can be found on
github[1], many thanks in advance!
Simo
[1] https://github.com/99soft/infra
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Help to use plugin coverage
My directory structure is this:
src/main/java
src/main/resources
src/main/webapp
src/test/java/unitTest
src/test/java/functionalTest
I have unit tests and integration tests in the same project.
I running the commands mvn install.
"Why are you using true? Isn't the whole point to
run the tests?"
I do not know right to use maven. I'm new at this.
In the configuration it has "false " and not true.
If true, the tests not execute.
To run the tests, I use a test suite, the class "AllTeste.java",
running the unit tests and integration.
I running with "verify", and did not coverage. I’m sending in annex.
2011/2/18 Hilco Wijbenga
> On 18 February 2011 11:06, Ewerton Vale Leal wrote:
> > I did what you recommended and did not work.
> > The cargo and selenium plugins must be executed before run the coverage .
> > When I execute the install the coverage does not work and when I execute
> > the coverage, the cargo , selenium and unit tests don’t execute.
> > I’m sending in annex the log of install execution and coverage.
>
> What exactly is your directory structure? Do you have both unit tests
> and integration tests in the same project? What commands are you
> running? Why are you using true? Isn't the whole point to
> run the tests?
>
> I would expect you to run "mvn verify"? And, once that works, "mvn
> install" or "mvn deploy"? In either case, the Cobertura plugin should
> behave the same.
>
--
Ewerton Leal Vale
Bacharelando em Ciência da Computação - UFPI
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Capriovi 1.0
[INFO]
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
capriovi ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 71 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ capriovi ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-antrun-plugin:1.6:run (compile) @ capriovi ---
[INFO] Executing tasks
Generate:
[echo] jHeat: Deleting the previous generated application...
[delete] Deleting directory C:\workspace\Maven\Capriovi\src\main\webapp
[mkdir] Created dir: C:\workspace\Maven\Capriovi\src\main\webapp
[echo] jHeat: Moving all the libraries to the new application
[echo]
folder...
[copy] Copying 533 files to C:\workspace\Maven\Capriovi\src\main\webapp
[echo] jHeat: Generando a aplicação...
[echo] jHeat: Feito. Applicação está pronta.
[INFO] Executed tasks
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @
capriovi ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
capriovi ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.7.1:test (default-test) @ capriovi ---
[INFO] Tests are skipped.
[INFO]
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ capriovi ---
[INFO] Packaging webapp
[INFO] Assembling webapp [capriovi] in
[C:\workspace\Maven\Capriovi\target\capriovi]
[INFO] Processing war project
[INFO] Copying webapp resources [C:\workspace\Maven\Capriovi\src\main\webapp]
[INFO] Webapp assembled in [3232 msecs]
[INFO] Building war: C:\workspace\Maven\Capriovi\target\capriovi.war
[WARNING] Warning: selected war files include a WEB-INF/web.xml which will be
ignored
(webxml attribute is missing from war task, or ignoreWebxml attribute is
specified as 'true')
[INFO]
[INFO] --- selenium-maven-plugin:1.1:start-server (start-server) @ capriovi ---
Launching Selenium Server
Waiting for Selenium Server...
[INFO] Redirecting output to:
C:\workspace\Maven\Capriovi\target\selenium\server.log
[INFO] User extensions:
C:\workspace\Maven\Capriovi\target\selenium\user-extensions.js
Selenium Server started
[INFO]
[INFO] --- cargo-maven2-plugin:1.0.5:start (start-container) @ capriovi ---
[INFO] [stalledLocalDeployer] Deploying
[C:\workspace\Maven\Capriovi\target\capriovi.war] to
[C:\workspace\Maven\Capriovi\target/tomcat6x/webapps]...
[INFO] [talledLocalContainer] Tomcat 6.x starting...
[WARNING] [talledLocalContainer] 18/02/2011 17:33:24
org.apache.tomcat.util.digester.SetPropertiesRule begin
[WARNING] [talledLocalContainer] AVISO: [SetPropertiesRule]{Server} Setting
property 'debug' to '2' did not find a matching property.
[WARNING] [talledLocalContainer] 18/02/2011 17:33:24
org.apache.tomcat.util.digester.SetPropertiesRule begin
[WARNING] [talledLocalContainer] AVISO: [SetPropertiesRule]{Server/Service}
Setting property 'debug' to '2' did not find a matching property.
[WARNING] [talledLocalContainer] 18/02/2011 17:33:24
org.a
site-deploy always appends ${project.artifactId} in the deploy URL
Hi all guys,
I'm facing a wired issue, I don't understand if it concerns the
maven-site-plugin or the deploy plugin, btw every time I try to deploy
the site, the ${project.artifactId} is always appended to the
distributionManagement.site.url
i.e. if the url is
ftp://ftp.acme.org/projects/${project.artifactId}/${project.version}
the resulting url will be
ftp://ftp.acme.org/projects/${project.artifactId}/${project.version}/${project.artifactId}
Any hint/suggestion? My parent pom is public and can be found on
github[1], many thanks in advance!
Simo
[1] https://github.com/99soft/infra
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Help to use plugin coverage
On 18 February 2011 11:06, Ewerton Vale Leal wrote: > I did what you recommended and did not work. > The cargo and selenium plugins must be executed before run the coverage . > When I execute the install the coverage does not work and when I execute > the coverage, the cargo , selenium and unit tests don’t execute. > I’m sending in annex the log of install execution and coverage. What exactly is your directory structure? Do you have both unit tests and integration tests in the same project? What commands are you running? Why are you using true? Isn't the whole point to run the tests? I would expect you to run "mvn verify"? And, once that works, "mvn install" or "mvn deploy"? In either case, the Cobertura plugin should behave the same. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help to use plugin coverage
I did what you recommended and did not work.
The cargo and selenium plugins must be executed before run the coverage .
When I execute the install the coverage does not work and when I execute
the coverage, the cargo , selenium and unit tests don’t execute.
I’m sending in annex the log of install execution and coverage.
2011/2/18 Hilco Wijbenga
> On 18 February 2011 04:06, Ewerton Vale Leal wrote:
> > Hello, I need a help to setting maven. I wanna use the
> > plugin-coverage-maven-plugin to analyse the coverage of functional tests.
> > I use also the cargo plugins, selenium and surefire. Without using these
> > plugins, I can do the coverage of unit tests with no problem.
> > But with functional tests does not work.
> > I also use Hudson for continuous integration.
> > I'm sending in annex my pom.xml
> > Sorry, my english isn't very good.
> > My Pom.xml below and in annex.
>
>
>
> >
> > org.codehaus.mojo
> > cobertura-maven-plugin
> > 2.4
> >
> >
> > instrument
> > site
> >
> > cobertura
> >
> >
> >
> >
>
> I'm guessing this is your problem. The "site" phase seems like the
> wrong place to run Cobertura. I'd try removing the entire
> part.
>
--
Ewerton Leal Vale
Bacharelando em Ciência da Computação - UFPI
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Capriovi 1.0
[INFO]
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
capriovi ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 71 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ capriovi ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-antrun-plugin:1.6:run (compile) @ capriovi ---
[INFO] Executing tasks
Generate:
[echo] jHeat: Deleting the previous generated application...
[delete] Deleting directory C:\workspace\Maven\Capriovi\src\main\webapp
[mkdir] Created dir: C:\workspace\Maven\Capriovi\src\main\webapp
[echo] jHeat: Moving all the libraries to the new application
[echo]
folder...
[copy] Copying 533 files to C:\workspace\Maven\Capriovi\src\main\webapp
[echo] jHeat: Generando a aplicação...
[echo] jHeat: Feito. Applicação está pronta.
[INFO] Executed tasks
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @
capriovi ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
capriovi ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.7.1:test (default-test) @ capriovi ---
[INFO] Tests are skipped.
[INFO]
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ capriovi ---
[INFO] Packaging webapp
[INFO] Assembling webapp [capriovi] in
[C:\workspace\Maven\Capriovi\target\capriovi]
[INFO] Processing war project
[INFO] Copying webapp resources [C:\workspace\Maven\Capriovi\src\main\webapp]
[INFO] Webapp assembled in [4598 msecs]
[INFO] Building war: C:\workspace\Maven\Capriovi\target\capriovi.war
[WARNING] Warning: selected war files include a WEB-INF/web.xml which will be
ignored
(webxml attribute is missing from war task, or ignoreWebxml attribute is
specified as 'true')
[INFO]
[INFO] --- selenium-maven-plugin:1.1:start-server (start-server) @ capriovi ---
Launching Selenium Server
Waiting for Selenium Server...
[INFO] Redirecting output to:
C:\workspace\Maven\Capriovi\target\selenium\server.log
[INFO] User extensions:
C:\workspace\Maven\Capriovi\target\selenium\user-extensions.js
Selenium Server started
[INFO]
[INFO] --- cargo-maven2-plugin:1.0.5:start (start-container) @ capriovi ---
[INFO] [stalledLocalDeployer] Deploying
[C:\workspace\Maven\Capriovi\target\capriovi.war] to
[C:\workspace\Maven\Capriovi\target/tomcat6x/webapps]...
[INFO] [talledLocalContainer] Tomcat 6.x starting...
[WARNING] [talledLocalContainer] 18/02/2011 14:37:29
org.apache.tomcat.util.digester.SetPropertiesRule begin
[WARNING] [talledLocalContainer] AVISO: [SetPropertiesRule]{Server} Setting
property 'debug' to '2' did not find a matching property.
[WARNING] [talledLocalContainer] 18/02/2011 14:37:30
org.apache.tomcat.util.digester.SetPropertiesRule begin
[WARNING] [talledLocalContainer] AVISO: [SetPropertiesRule]{Server/Service}
Setting property 'debug' to '2' did not find a matching property.
[WARNING] [talledLocalContainer] 18/02/2011 14:37:30
org.apache.catalina.core.AprLifecycleListener init
[WARNING] [talledLocalContainer] INFO: The APR based Apache Tomcat Native
library which allows optimal performance in production environments was not
found on the java.library.path: C:\Program
Re: how can we replace properties values in the element .
On Fri, Feb 18, 2011 at 1:39 PM, chandra.c49 wrote:
> My question was -- The build fails to run if we run a maven Component
> build with below element in place. The below element uses
> the element to refer , as it is located at different
> location with name customized . So, how can we pass this ${Comp1.Path} value
> at runtime .
That's still not the right question. Why do you think you need to do
this? What underlying problem are you trying to solve by using (I
assume) different parents for different builds?
If you go to the location of the parent and do "mvn install" then
remove the in your project pom and try to build that,
what happens?
--
Wendy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: how can we replace properties values in the element .
Sorry the question was not about element supporting versionless .
But was good to know , about this .
My question was -- The build fails to run if we run a maven Component
build with below element in place. The below element uses
the element to refer , as it is located at different
location with name customized . So, how can we pass this ${Comp1.Path} value
at runtime .
--> pass the proeprty value from cmd line and it fails .< mvn clean install
-DComp1.path= >
--> pass from settings.xml , profile setting this property value , it will
not pick up and execution fails.
com.xyz.components
component1
5.0
../${Comp1.Path}/pom.xml
pls advise .
Thanks,
Chandra Moahn .
--
View this message in context:
http://maven.40175.n5.nabble.com/how-can-we-replace-properties-values-in-the-parent-element-tp3390613p3391541.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Help to use plugin coverage
On 18 February 2011 04:06, Ewerton Vale Leal wrote: > Hello, I need a help to setting maven. I wanna use the > plugin-coverage-maven-plugin to analyse the coverage of functional tests. > I use also the cargo plugins, selenium and surefire. Without using these > plugins, I can do the coverage of unit tests with no problem. > But with functional tests does not work. > I also use Hudson for continuous integration. > I'm sending in annex my pom.xml > Sorry, my english isn't very good. > My Pom.xml below and in annex. > > org.codehaus.mojo > cobertura-maven-plugin > 2.4 > > > instrument > site > > cobertura > > > > I'm guessing this is your problem. The "site" phase seems like the wrong place to run Cobertura. I'd try removing the entire part. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Tracking down a dependency mystery
OK, mystery solved. I found the relevant dependencyManagement
statement in a distant parent, leftover from long ago.
On Fri, Feb 18, 2011 at 10:27 AM, Benson Margulies
wrote:
> Running with m3, it still fails, and I see
>
> [DEBUG] org.mortbay.jetty:jetty:jar:7.2.0.v20101020:compile
> (version managed from 6.1.21)
>
> in the log. So I need to figure out where this 'management' is coming from.
>
> On Fri, Feb 18, 2011 at 10:25 AM, Benson Margulies
> wrote:
>> I just created a project with an interesting dependency situation: my
>> existing code uses jetty 7, while hector from cassandra-land uses
>> jetty 6.
>>
>> This should be fine; the group IDs are different.
>>
>> However, my build fails as follows below. The actual cassandra-all pom
>> in my local repo, on the other hand, says:
>>
>>
>> org.mortbay.jetty
>> jetty
>> 6.1.21
>>
>>
>>
>> I expected to find a property reference in here and that the problem
>> was that two poms were accidently sharing something like
>> ${jetty.version}. But, no. Cassandra's dep is as above, so I cannot
>> explain how I get the error below.
>>
>> This is with 2.2.0. Anybody got a clue?
>>
>> 1) org.mortbay.jetty:jetty:jar:7.2.0.v20101020
>>
>> Try downloading the file manually from the project website.
>>
>> Then, install it using the command:
>> mvn install:install-file -DgroupId=org.mortbay.jetty
>> -DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
>> -Dfile=/path/to/file
>>
>> Alternatively, if you host your own repository you can deploy the file
>> there:
>> mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
>> -DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
>> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>>
>> Path to dependency:
>> 1) com.basistech.jug:dcs-cassandra-store:jar:4-SNAPSHOT
>> 2) org.apache.cassandra:cassandra-all:jar:0.7.2
>> 3) org.mortbay.jetty:jetty:jar:7.2.0.v20101020
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Tracking down a dependency mystery
Running with m3, it still fails, and I see
[DEBUG] org.mortbay.jetty:jetty:jar:7.2.0.v20101020:compile
(version managed from 6.1.21)
in the log. So I need to figure out where this 'management' is coming from.
On Fri, Feb 18, 2011 at 10:25 AM, Benson Margulies
wrote:
> I just created a project with an interesting dependency situation: my
> existing code uses jetty 7, while hector from cassandra-land uses
> jetty 6.
>
> This should be fine; the group IDs are different.
>
> However, my build fails as follows below. The actual cassandra-all pom
> in my local repo, on the other hand, says:
>
>
> org.mortbay.jetty
> jetty
> 6.1.21
>
>
>
> I expected to find a property reference in here and that the problem
> was that two poms were accidently sharing something like
> ${jetty.version}. But, no. Cassandra's dep is as above, so I cannot
> explain how I get the error below.
>
> This is with 2.2.0. Anybody got a clue?
>
> 1) org.mortbay.jetty:jetty:jar:7.2.0.v20101020
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.mortbay.jetty
> -DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
> -Dfile=/path/to/file
>
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
> -DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>
> Path to dependency:
> 1) com.basistech.jug:dcs-cassandra-store:jar:4-SNAPSHOT
> 2) org.apache.cassandra:cassandra-all:jar:0.7.2
> 3) org.mortbay.jetty:jetty:jar:7.2.0.v20101020
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Tracking down a dependency mystery
I just created a project with an interesting dependency situation: my
existing code uses jetty 7, while hector from cassandra-land uses
jetty 6.
This should be fine; the group IDs are different.
However, my build fails as follows below. The actual cassandra-all pom
in my local repo, on the other hand, says:
org.mortbay.jetty
jetty
6.1.21
I expected to find a property reference in here and that the problem
was that two poms were accidently sharing something like
${jetty.version}. But, no. Cassandra's dep is as above, so I cannot
explain how I get the error below.
This is with 2.2.0. Anybody got a clue?
1) org.mortbay.jetty:jetty:jar:7.2.0.v20101020
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.mortbay.jetty
-DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
-DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) com.basistech.jug:dcs-cassandra-store:jar:4-SNAPSHOT
2) org.apache.cassandra:cassandra-all:jar:0.7.2
3) org.mortbay.jetty:jetty:jar:7.2.0.v20101020
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 does not seem to like version ranges?
Already there by Kristoffer: http://jira.codehaus.org/browse/MNG-5006 > that sounds like a bug. can you please raise a jira > > - Stephen -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-does-not-seem-to-like-version-ranges-tp3389402p3391152.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 does not seem to like version ranges?
that sounds like a bug. can you please raise a jira - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Feb 2011 13:05, "Syvalta" wrote: > > I'm running into this too. I tried to create a test project but unfortunately > the problem didn't reproduce there. > > Some background: > - dependency to artifact with version range [1.0.1, 2.0), matching versions > [1.0.1, 1.0.2, 1.0.3-SNAPSHOT]. > - problems occurs when 1.0.3-SNAPSHOT tries to load it's _released_ parent > pom. > - if parent of 1.0.3-SNAPSHOT is changed to a snapshot the build succeeds. > > Some observations: > - when SNAPSHOT is resolved from local repository it's list of repositories > is empty. Also when it's parent is resolved it's list of repositories is > empty. > - org.apache.maven.model.building.DefaultModelBuilder.readParentExternally > fails because of that (no repositories) > - parent is not found from local repository because the key in repo tracking > properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key > "test-parent-pom-1.0.1.pom>". > > Stack trace from one point of execution: > org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(org.sonatype.aether.RepositorySystemSession, > java.util.Collection org.sonatype.aether.resolution.ArtifactRequest>) line: 237 > org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(org.sonatype.aether.RepositorySystemSession, > org.sonatype.aether.resolution.ArtifactRequest) line: 214 > org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(java.lang.String, > java.lang.String, java.lang.String) line: 115 > org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(org.apache.maven.model.Model, > org.apache.maven.model.building.ModelBuildingRequest, > org.apache.maven.model.building.DefaultModelProblemCollector) line: 819 > org.apache.maven.model.building.DefaultModelBuilder.readParent(org.apache.maven.model.Model, > org.apache.maven.model.building.ModelBuildingRequest, > org.apache.maven.model.building.DefaultModelProblemCollector) line: 670 > org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest, > java.util.Collection) line: 308 > org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest) > line: 232 > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(org.sonatype.aether.RepositorySystemSession, > org.sonatype.aether.resolution.ArtifactDescriptorRequest, > org.sonatype.aether.resolution.ArtifactDescriptorResult) line: 308 > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(org.sonatype.aether.RepositorySystemSession, > org.sonatype.aether.resolution.ArtifactDescriptorRequest) line: 173 > org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(org.sonatype.aether.RepositorySystemSession, > org.sonatype.aether.collection.CollectResult, > java.util.LinkedList, > java.util.List, > java.util.List, > org.sonatype.aether.collection.DependencySelector, > org.sonatype.aether.collection.DependencyManager, > org.sonatype.aether.collection.DependencyTraverser, > org.sonatype.aether.impl.internal.DataPool) line: 419 > org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(org.sonatype.aether.RepositorySystemSession, > org.sonatype.aether.collection.CollectRequest) line: 233 > > > -- > View this message in context: http://maven.40175.n5.nabble.com/Maven-3-does-not-seem-to-like-version-ranges-tp3389402p3391039.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Re: how can we replace properties values in the element .
Perhaps it might be helpful in giving a solution, if we had the root
problem better described.
What are the particular properties of your application that makes it
unlike anything that has ever been built with Maven?
Maven is incredibly flexible and the technical expertise in this forum
is the best available.
However, just because you can make Maven do something (not the case this
time), does not mean that you should.
What are you trying to build and why is this project structure the best
way to do that?
Perhaps there is a simple way to get you a build structure that works well.
Ron
On 18/02/2011 2:21 AM, Anders Hammar wrote:
Neither does Maven 3.0. Possibly future version of Maven will have this
feature.
/Anders
On Fri, Feb 18, 2011 at 06:54, Anurag Kumar Nileshwrote:
Maven 2 doesn't have support for versionless parent pom.
You may use maven 3 instead
https://cwiki.apache.org/MAVEN/maven-3x.html
On 2/18/11 11:18 AM, "chandra.c49" wrote:
Hi ,
I've a maven project in the following structure setup --
Component1
--module1
--module2
--pom.xml
Component2 --> contains a
element referring to
Component3 --> contains a element
referring to
Component4 --> profiles.xml
and each team develops it's own component , hence they have a PROFILE
setup in their settings.xml file . This profile contians some properties
used by the AD team locally .
few questions --
1) Can Component4 profiles.xml properties be used across other components
also. ?
2) The settings.xml file contains a profile with few properties set , and
this overrides all the other properties from all the components. But, it
does NOT for the element . how do we achieve this .?
for ex : Component2 contains a element referring to to
Component2 pom.xml file is below , with
element .
com.xyz.components
component1
../${Comp1.Path}/pom.xml
--
As I try to execute from the Component2 , it first tries to scan the pom
file and fails as it can't find the Component1 pom file , due to not able
to
refer to the ${comp1.Path} property value from "settings.xml" file .
How can we achieve this, with out hardcoding the element
vlaue . Please let me know any other ways .
Thanks,
Chandra
--
View this message in context:
http://maven.40175.n5.nabble.com/how-can-we-replace-properties-values-in-the-parent-element-tp3390613p3390613.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 does not seem to like version ranges?
I'm running into this too. I tried to create a test project but unfortunately the problem didn't reproduce there. Some background: - dependency to artifact with version range [1.0.1, 2.0), matching versions [1.0.1, 1.0.2, 1.0.3-SNAPSHOT]. - problems occurs when 1.0.3-SNAPSHOT tries to load it's _released_ parent pom. - if parent of 1.0.3-SNAPSHOT is changed to a snapshot the build succeeds. Some observations: - when SNAPSHOT is resolved from local repository it's list of repositories is empty. Also when it's parent is resolved it's list of repositories is empty. - org.apache.maven.model.building.DefaultModelBuilder.readParentExternally fails because of that (no repositories) - parent is not found from local repository because the key in repo tracking properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key "test-parent-pom-1.0.1.pom>". Stack trace from one point of execution: org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(org.sonatype.aether.RepositorySystemSession, java.util.Collection) line: 237 org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactRequest) line: 214 org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(java.lang.String, java.lang.String, java.lang.String) line: 115 org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(org.apache.maven.model.Model, org.apache.maven.model.building.ModelBuildingRequest, org.apache.maven.model.building.DefaultModelProblemCollector) line: 819 org.apache.maven.model.building.DefaultModelBuilder.readParent(org.apache.maven.model.Model, org.apache.maven.model.building.ModelBuildingRequest, org.apache.maven.model.building.DefaultModelProblemCollector) line: 670 org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest, java.util.Collection) line: 308 org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest) line: 232 org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactDescriptorRequest, org.sonatype.aether.resolution.ArtifactDescriptorResult) line: 308 org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactDescriptorRequest) line: 173 org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.collection.CollectResult, java.util.LinkedList, java.util.List, java.util.List, org.sonatype.aether.collection.DependencySelector, org.sonatype.aether.collection.DependencyManager, org.sonatype.aether.collection.DependencyTraverser, org.sonatype.aether.impl.internal.DataPool) line: 419 org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.collection.CollectRequest) line: 233 -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-does-not-seem-to-like-version-ranges-tp3389402p3391039.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Help to use plugin coverage
Hello, I need a help to setting maven. I wanna use the
plugin-coverage-maven-plugin to analyse the coverage of functional tests.
I use also the cargo plugins, selenium and surefire. Without using these
plugins, I can do the coverage of unit tests with no problem.
But with functional tests does not work.
I also use Hudson for continuous integration.
I'm sending in annex my pom.xml
Sorry, my english isn't very good.
My Pom.xml below and in annex.
org.codehaus.mojo
selenium-maven-plugin
1.1
start-server
pre-integration-test
start-server
true
true
stop-server
post-integration-test
stop-server
org.codehaus.cargo
cargo-maven2-plugin
1.0.5
start-container
pre-integration-test
start
stop-container
post-integration-test
stop
false
2
tomcat6x
http://www.apache.org/dist/tomcat/tomcat-6/v6.0.32/bin/apache-tomcat-6.0.32.zip
${project.build.directory}/tomcat6x/
8000
http://localhost:8000/capriovi/
/capriovi
org.apache.maven.plugins
maven-surefire-plugin
2.7.1
AllTeste.class
true
once
xml
surefire-it
integration-test
test
false
org.codehaus.mojo
cobertura-maven-plugin
2.4
instrument
site
cobertura
--
Ewerton Leal Vale
Bacharelando em Ciência da Computação - UFPI
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
br.ufpi
capriovi
war
Capriovi
1.0
UTF-8
Sistema de Controle Zootécnico de Rebanhos de Caprinos e Ovinos
http://sistemaseasii.ufpi.br/capriovi
Hudson
http://sistemaseasii.ufpi.br/hudson
UFPI - Universidade Federal do Piauí
http://www.ufpi.br/
${project.artifactId}
org.apache.maven.plugins
maven-compiler-plugin
2.3.2
1.6
1.6
org.apache.maven.plugins
maven-antrun-plugin
1.6
compile
compile
jHeat: Deleting the previous generated application...
jHeat: Moving all the libraries to the new application
folder...
jHeat: Generando a aplicação...
jHeat: Feito. Applicação está pronta.
run
org.codehaus.mojo
selenium-maven-plugin
1.1
start-server
pre-integration-test
start-server
true
true
stop-server
post-integration-test
stop-server
org.codehaus.cargo
cargo-maven2-plugin
1.0.5
start-container
pre-integration-test
start
stop-container
post-integration-test
stop
false
2
tomcat6x
http://www.apache.org/dist/tomcat/tomcat-6/v6.0.32/bin/apache-tomcat-6.0.32.zip
${project.build.directory}/tomcat6x/
8000
http://localhost:8000/capriovi/
/capriovi
org.apache.maven.plugins
maven-surefire-plugin
2.7.1
AllTeste.class
true
once
xml
surefire-it
integration-test
test
false
org.codehaus.mojo
cobertura-maven-plugin
2.4
instrument
site
cobertura
br.com.infowaypi
jheat
1.0.1
jar
compile
jama
jama
1.0.2
jar
compile
junit
junit
4.8.2
jar
test
org.seleniumhq.selenium.client-drivers
selenium-java-client-driver
1.0.2
jar
test
org.codehaus.mojo
cobertura-maven-plugin
2.4
html
xml
org.apache.maven.plugins
maven-pmd-plugin
2.5
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 does not seem to like version ranges?
Kristoffer Peterhaensel wrote: So it is trying to resolve released a dependency on a snapshot repository because the dependency that requires it is a snapshot? And why does that not happen when I lock down the dependency version of coreapi to 1.0.1-SNAPSHOT. Shouldn't that do exactly the same? And when I do it in offline mode, why is it still trying to resolve it remotely? Attaching a self-contained example project to the JIRA ticket that allows to reproduce and analyze the issue in detail increases the likelihood of someone finding answers to your questions. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 does not seem to like version ranges?
On Fri, 18 Feb 2011 10:06:15 + Stephen Connolly wrote: On 18 February 2011 09:27, Kristoffer Peterhaensel < kristof...@codedivision.com> wrote: Hey. Thanks for the reply. We have a couple of snapshot repositories in the settings.xml. But for some reason they do not show up in the output of mvn help:effective-settings. We also specify that our local Nexus installation is a mirror of central (and some other public repos). Running a help:effective-pom on gives the following output. Our own releases should be on our mirror of central. So it should just fetch them there. false true always So always check for updates here fail snapshots SafeCom Snapshots http://webdev01:10080/nexus/content/repositories/snapshots false true always Always check for updates here fail public-snapshots Public Snapshots Proxies http://webdev01:10080/nexus/content/groups/public-snapshots false central Maven Repository Switchboard http://repo1.maven.org/maven2 I don't really think it explains why it looks like maven tries to resolve a released version on a snapshot repository (as can be seen in this trace output: http://jira.codehaus.org/secure/attachment/53605/mvn-verify-range-version.log ) Ranges include -SNAPSHOTs within the range... at least they were originally supposed to for crazy reasons... and then there is some strange strange logic that effectively excludes them under certain circumstances. I would try changing your update policy to daily and see how that affects your build. Benjamin might be able to shed some light for the 3.x behaviour with regards to ranges and SNAPSHOTs but my hunch is that it's because you have repos with update policy of always -Stephen I tried to change our update policy to daily and it does not seem to have any impact on the error. But then if it thinks it has to update it from a snapshot repository (where it is never available). I will never actually get it anyway. So wouldn't have to keep checking? That ranges include snapshots is fine. As it makes it easier to work with modules in parallel and see that they still work. The final released version will be locked down to the released version available at the time anyway. I could see why it would be useful to have the option to only take released versions though. But that's a subject for another time. The thing that worries - and puzzles - me is what I am getting this line: [DEBUG] Verifying availability of C:\Documents and Settings\kpe\.m2\repository\dk\safecom\core\masterproject\1.0.11\masterproject-1.0.11.pom from [safeComSnapshots (http://webdev01:18080/nexus/content/repositories/snapshots, releases=false, snapshots=true, managed=false)] And that then results in: [ERROR] Failed to execute goal on project framework-setup: Could not resolve dependencies for project dk.safecom.products.deviceserver:framework-setup:bundle:0.25.4-SNAPSHOT: Failed to collect dependencies for [org.osgi:org.osgi.core:jar:4.2.0 (provided?), org.osgi:org.osgi.compendium:jar:4.2.0 (provided?), dk.safecom.products.deviceserver:coreapis:jar:[1,2) (compile?), org.bouncycastle:bcprov-jdk15:jar:1.45 (compile)]: Failed to read artifact descriptor for dk.safecom.products.deviceserver:coreapis:jar:1.0.1-SNAPSHOT: Could not find artifact dk.safecom.core:masterproject:pom:1.0.11 -> [Help 1] So it is trying to resolve released a dependency on a snapshot repository because the dependency that requires it is a snapshot? And why does that not happen when I lock down the dependency version of coreapi to 1.0.1-SNAPSHOT. Shouldn't that do exactly the same? And when I do it in offline mode, why is it still trying to resolve it remotely? /Kristoffer Peterhänsel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 does not seem to like version ranges?
On 18 February 2011 09:27, Kristoffer Peterhaensel < kristof...@codedivision.com> wrote: > Hey. > > Thanks for the reply. > > We have a couple of snapshot repositories in the settings.xml. But for some > reason they do not show up in the output of mvn help:effective-settings. We > also specify that our local Nexus installation is a mirror of central (and > some other public repos). > > Running a help:effective-pom on gives the following output. Our own > releases should be on our mirror of central. So it should just fetch them > there. > > > > >false > > >true >always > So always check for updates here >fail > > snapshots > SafeCom Snapshots > http://webdev01:10080/nexus/content/repositories/snapshots > > > >false > > >true >always > Always check for updates here >fail > > public-snapshots > Public Snapshots Proxies > http://webdev01:10080/nexus/content/groups/public-snapshots > > > > >false > > central > Maven Repository Switchboard > http://repo1.maven.org/maven2 > > > > > I don't really think it explains why it looks like maven tries to resolve a > released version on a snapshot repository (as can be seen in this trace > output: > http://jira.codehaus.org/secure/attachment/53605/mvn-verify-range-version.log > ) > > Ranges include -SNAPSHOTs within the range... at least they were originally supposed to for crazy reasons... and then there is some strange strange logic that effectively excludes them under certain circumstances. I would try changing your update policy to daily and see how that affects your build. Benjamin might be able to shed some light for the 3.x behaviour with regards to ranges and SNAPSHOTs but my hunch is that it's because you have repos with update policy of always -Stephen > > what is the updatePolicy in each of the repositories sections? >> >> mvn help:effective-settings >> >> will show the effective settings, then look for the >> >> *updatePolicy*: This element specifies how often updates should attempt to >> occur. Maven will compare the local POM's timestamp (stored in a >> repository's maven-metadata file) to the remote. The choices are: always, >> daily (default), interval:X (where X is an integer in minutes) or never. >> >> as the updatePolicy should also apply to the maven-metadata.xml for each >> repo you have defined. >> >> The Hudson/Jenkins server will be building all the time and so only >> occasionally check for the metadata. Your builds will be less frequent, >> so >> you might seem to "always" update even if it is set to "daily" >> >> -Stephen >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven 3 does not seem to like version ranges?
Hey. Thanks for the reply. We have a couple of snapshot repositories in the settings.xml. But for some reason they do not show up in the output of mvn help:effective-settings. We also specify that our local Nexus installation is a mirror of central (and some other public repos). Running a help:effective-pom on gives the following output. Our own releases should be on our mirror of central. So it should just fetch them there. false true always fail snapshots SafeCom Snapshots http://webdev01:10080/nexus/content/repositories/snapshots false true always fail public-snapshots Public Snapshots Proxies http://webdev01:10080/nexus/content/groups/public-snapshots false central Maven Repository Switchboard http://repo1.maven.org/maven2 I don't really think it explains why it looks like maven tries to resolve a released version on a snapshot repository (as can be seen in this trace output: http://jira.codehaus.org/secure/attachment/53605/mvn-verify-range-version.log) what is the updatePolicy in each of the repositories sections? mvn help:effective-settings will show the effective settings, then look for the *updatePolicy*: This element specifies how often updates should attempt to occur. Maven will compare the local POM's timestamp (stored in a repository's maven-metadata file) to the remote. The choices are: always, daily (default), interval:X (where X is an integer in minutes) or never. as the updatePolicy should also apply to the maven-metadata.xml for each repo you have defined. The Hudson/Jenkins server will be building all the time and so only occasionally check for the metadata. Your builds will be less frequent, so you might seem to "always" update even if it is set to "daily" -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
