maven snapshot dependencies and recompilation
Hi, My question is similar to this one: http://mail-archives.apache.org/mod_mbox/maven-users/200512.mbox/browser but for maven 2.0.9 - 2.2.1. I have two projects A and B. B is dependent upon A. A produces A-1.0-SNAPSHOT.jar. When a change is introduced into A and the new snapshot is installed into the local repository, B is not fully recompiled unless clean is specified when building B. This means that if an interface is changed in A, B will not be recompiled against the changed interface. Is there something wrong with my configuration? If not, what is accepted practice? Manually doing a clean whenever a change in snapshot is detected seems inefficient and error-prone. Thanks, Daniel.
Calling a custom maven plugin
I'm currently working with the book Better Builds with Maven and doing some custom maven plugin development. I have a plugin I've created with the following POM info. groupIdcom.exist.mvnbook.plugins/groupId artifactIdmaven-buildinfo-plugin/artifactId packagingmaven-plugin/packaging You know how you can just type mvn pluginName:mojoName for many mojos? My mojo has to run like this: mvn com.exist.mvnbook.plugins:maven-buildinfo-plugin:extract where extract is the mojo name. From the error I get when I try to run it like this 'mvn buildinfo:extract it looks like I could get it to run that way if I changed the groupId of my mojo to org.apache.maven.plugins. It seems rather inappropriate to use this groupId myself? Is there another way to get my mojo to run without having to be so verbose? Thanks very much.
Re: maven snapshot dependencies and recompilation
2009/9/25 Daniel Bell daniel.b...@nec.com.au Hi, My question is similar to this one: http://mail-archives.apache.org/mod_mbox/maven-users/200512.mbox/browser but for maven 2.0.9 - 2.2.1. I have two projects A and B. B is dependent upon A. A produces A-1.0-SNAPSHOT.jar. When a change is introduced into A and the new snapshot is installed into the local repository, B is not fully recompiled unless clean is specified when building B. This means that if an interface is changed in A, B will not be recompiled against the changed interface. Is there something wrong with my configuration? If not, what is accepted practice? Manually doing a clean whenever a change in snapshot is detected seems inefficient and error-prone. mvn clean compile -- maven will do clean operaion before the comile Thanks, Daniel.
Re: Calling a custom maven plugin
The way I know of is through the pluginGroups element of settings.xml. /Anders On Fri, Sep 25, 2009 at 03:12, Tristan Rouse tjcro...@gmail.com wrote: I'm currently working with the book Better Builds with Maven and doing some custom maven plugin development. I have a plugin I've created with the following POM info. groupIdcom.exist.mvnbook.plugins/groupId artifactIdmaven-buildinfo-plugin/artifactId packagingmaven-plugin/packaging You know how you can just type mvn pluginName:mojoName for many mojos? My mojo has to run like this: mvn com.exist.mvnbook.plugins:maven-buildinfo-plugin:extract where extract is the mojo name. From the error I get when I try to run it like this 'mvn buildinfo:extract it looks like I could get it to run that way if I changed the groupId of my mojo to org.apache.maven.plugins. It seems rather inappropriate to use this groupId myself? Is there another way to get my mojo to run without having to be so verbose? Thanks very much.
Re: DOAP Plugin issues
On Fri, 25 Sep 2009 11:37:40 +1000 Brett Porter br...@apache.org wrote: Would you mind submitting these to JIRA? http://jira.codehaus.org/browse/MDOAP If you can attach patches to correct them they can be applied and released relatively easily. - Brett Hey, I did not find any guidelines on how to properly produces patches so the ones I've created may need to be reworked (trivial since they change almost nothing). Anyway the issues are at: http://jira.codehaus.org/browse/MDOAP-22 and http://jira.codehaus.org/browse/MDOAP-23 Greets - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: copy file from dependent jar
Hi Brett,
Yes, Resource1.xsd is part of Proj1. And there is a dependency between Proj3
and Proj1.
Maybe i should explain it differently:
I need to run wsdl2java (i use the cxf plugin for that) which needs the
Resource1.xsd to be able to run correctly. Additionally some namespaces have to
be adapted.
So i need to extract one file from a dependent artifact, place it in a project
specific directory and do some replacements.
The build script (in ant) looks like this:
target name=copyXSDs description=Copy XSDs to
src/conf/xml-resources/
copy file=${cms.root}/Common/afbCommon/xsd/xxxGlobal.xsd
todir=${xsd.dest}/
/target
The ant script has in my opinion a bad side effect. The structure is not
allowed to change, so i would prefer to use dependencies so structure changes
would have no side effects.
Currently i use the maven-dependency-plugin that copies the file to a defined
position and wrote a plugin that handles the extraction and the replacement.
regards,
Harald
-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:br...@porterclan.net] Im Auftrag von Brett Porter
Gesendet: Freitag, 25. September 2009 03:55
An: Maven Users List
Betreff: Re: copy file from dependent jar
I'm a bit lost. Is Resource1 already included in Proj1 and is Proj1 a
dependency of Proj3?
- Brett
On 24/09/2009, at 8:01 PM, Entner Harald wrote:
Hello,
i face the following problem. Currently i'm refactoring a project so
that i can move from ant to maven. It works rather well (i have done
this in my old company as well), but some special cases occur. Most of
them i could fix, but one causes me a headache.
This is the simple view of the project layout:
Proj1
Resource1.xsd
Proj2
Proj3
The thing is, that Proj3 (actually all Webservices) needs Resource1
(besides it should do some replacements on the content of
Resource1.xd).
So far ant copies the file using relative paths. I would really like
to
avoid that (it would be easy with relative paths), because it adds a
lot
of dependencies. (the project structure is much bigger and has a lot
of
subprojects, the file is needed in many places).
So one solution would be to use the maven-resource-plugin and let it
copy the resource (additionally it could do the replacement).
Unfortunately, it only works with paths, but not with dependent
projects. Or am i missing something?
The solution i am thinking about is to use the dependency plugin and
copy the resource first (it can handle dependent jars) and place it
in a
predefined-(project)-place (i think i can put it into the parent pom,
and hopefully this will work under all circumstances). Then i could
use
the resource-plugin to do the rest and so i only have the resource
plugin inside the project poms.
The bad thing is that i need a second parent. Because Proj1 should not
execute dependency:copy (as it is depends on itself). I could leave
the
phase undefined, but then i would have to add the plugin in every
project pom, which i would like to avoid. I think i could live with
this
solution, but i m wondering if nobody had the same problem and maybe
there is a better solution.
Every input is appreciated.
regards, Harald
-
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
[ANN] Maven Invoker 2.0.11 Released
The Maven team is pleased to announce the release of the Maven Invoker, version 2.0.11. This component allows to programmatically invoke Maven. See the component's site for more details: http://maven.apache.org/shared/maven-invoker/ To use this component in your projects, add the following to the dependency section of your POM: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-invoker/artifactId version2.0.11/version /dependency Release Notes - Maven Invoker 2.0.11 ** Improvement * [MSHARED-123] - Add support for show version option ( -V,--show-version) Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Remove CVS credentials from pom.xml
Hi, I am using the release plugin with CVS. Is there a way to remove the CVS user name and password from the pom.xml? I am setting up a maven project for 20+ developers and it would be bad if every one of them needs to keep a modified pom.xml in their machine with their user name. I tried the maven-properties-plugin but the problem I does not run when I do release:prepare. I can't discover the proper lifecycle phase where to hook the properties plugin so it runs both on normal build and on release. Cheers, Todor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Invoker Plugin 1.4 Released
The Maven team is pleased to announce the release of the Maven Invoker Plugin, version 1.4. This plugin allows to run Maven on a collection of projects and is especially useful for integration testing of other Maven plugins. See the plugin's site for more details: http://maven.apache.org/plugins/maven-invoker-plugin/ To use the updated plugin in your projects, you need to add the the following snippet to the plugins or plugin management section of your POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-invoker-plugin/artifactId version1.4/version /plugin Release Notes - Maven 2.x Invoker Plugin - Version 1.4 ** Bug * [MINVOKER-69] - Filter token basedir no longer interpolated * [MINVOKER-70] - invoker:install does not properly handle versioned dependencies * [MINVOKER-71] - Usage of setupIncludes can result in duplicate project invocation * [MINVOKER-78] - Throwing subclasses of java.lang.Error from hook script aborts main build with FATAL ERROR * [MINVOKER-84] - Staging of snapshot dependencies is incomplete * [MINVOKER-88] - Staging of existing artifacts from the local repository triggers transformations on them * [MINVOKER-93] - Filtering all POMs that are relevant to the forked build needs to consider child modules added by profiles ** Improvement * [MINVOKER-68] - Enable accessibility for non-public members from BeanShell scripts * [MINVOKER-73] - Support filter token @baseurl@ * [MINVOKER-75] - Trigger further builds upon any indexed invoker property * [MINVOKER-76] - Have invoker:run generate report files to allow reporting on the results of running invoker * [MINVOKER-92] - Add support for show version option ( -V,--show-version) ** New Feature * [MINVOKER-72] - Allow to configure network mode for sub builds * [MINVOKER-74] - Allow to specify alternative POMs during multi-module builds * [MINVOKER-77] - Add a invoker report mojo which display invoker its result * [MINVOKER-79] - Allow to easily pass data from the pre-build hook script to the post-build hook script * [MINVOKER-81] - provide a flag to skip the execution of all invoker steps * [MINVOKER-83] - Allow to configure different system properties for multi-invocation builds * [MINVOKER-91] - Decouple test execution from build failure * [MINVOKER-94] - Allow to skip projects based on JRE version or OS family ** Wish * [MINVOKER-85] - Don't treat null return value from hook scripts as error Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Remove CVS credentials from pom.xml
That was my first idea. And I couldn't find a way to do it. All I find are discussions on how people want not to have this in their settings.xml but in an external properties file. How to put arbitrary properties in the settings.xml remains a mistery to me. Anders Hammar wrote: Why not have two pre-define properties for this, which everyone needs to set up in their settings.xml? /Anders On Fri, Sep 25, 2009 at 10:48, Todor Boev t.b...@prosyst.bg wrote: Hi, I am using the release plugin with CVS. Is there a way to remove the CVS user name and password from the pom.xml? I am setting up a maven project for 20+ developers and it would be bad if every one of them needs to keep a modified pom.xml in their machine with their user name. I tried the maven-properties-plugin but the problem I does not run when I do release:prepare. I can't discover the proper lifecycle phase where to hook the properties plugin so it runs both on normal build and on release. Cheers, Todor - 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: Remove CVS credentials from pom.xml
Hmm, I pretty sure I've seen an example of this somewhere. I'll have a look /A On Fri, Sep 25, 2009 at 11:06, Todor Boev t.b...@prosyst.bg wrote: That was my first idea. And I couldn't find a way to do it. All I find are discussions on how people want not to have this in their settings.xml but in an external properties file. How to put arbitrary properties in the settings.xml remains a mistery to me. Anders Hammar wrote: Why not have two pre-define properties for this, which everyone needs to set up in their settings.xml? /Anders On Fri, Sep 25, 2009 at 10:48, Todor Boev t.b...@prosyst.bg wrote: Hi, I am using the release plugin with CVS. Is there a way to remove the CVS user name and password from the pom.xml? I am setting up a maven project for 20+ developers and it would be bad if every one of them needs to keep a modified pom.xml in their machine with their user name. I tried the maven-properties-plugin but the problem I does not run when I do release:prepare. I can't discover the proper lifecycle phase where to hook the properties plugin so it runs both on normal build and on release. Cheers, Todor - 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: Remove CVS credentials from pom.xml
Ok. I think I found the example, and it uses environment properties. Should work. Or, define a profile in your settings.xml that defines these properties. The benefit of this approach is that they can easily be defined (or overridden) through the command line as well. /Anders On Fri, Sep 25, 2009 at 11:07, Anders Hammar and...@hammar.net wrote: Hmm, I pretty sure I've seen an example of this somewhere. I'll have a look /A On Fri, Sep 25, 2009 at 11:06, Todor Boev t.b...@prosyst.bg wrote: That was my first idea. And I couldn't find a way to do it. All I find are discussions on how people want not to have this in their settings.xml but in an external properties file. How to put arbitrary properties in the settings.xml remains a mistery to me. Anders Hammar wrote: Why not have two pre-define properties for this, which everyone needs to set up in their settings.xml? /Anders On Fri, Sep 25, 2009 at 10:48, Todor Boev t.b...@prosyst.bg wrote: Hi, I am using the release plugin with CVS. Is there a way to remove the CVS user name and password from the pom.xml? I am setting up a maven project for 20+ developers and it would be bad if every one of them needs to keep a modified pom.xml in their machine with their user name. I tried the maven-properties-plugin but the problem I does not run when I do release:prepare. I can't discover the proper lifecycle phase where to hook the properties plugin so it runs both on normal build and on release. Cheers, Todor - 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
part the classes are not compiled
THis is my project structure: parent client server src main java cn wps 01.java 02.java resources cn wps xml01 xml02 io webapp The parent contains serveral modules,under the module named server,the package is cn.wps in the java directory there are the sources, and under the resources there are some xml files. When I run mvn install under the parent directory, it build successfully,but I found the server/target/classes/cn.wps, there are only the xml files,the 01.class 02.class do not exist... Then I trun to the server module directory run mvn install the suitation is same as before,Then I try to run mvn clean install ,things like before I want to know if this is my mistake?
Re: Remove CVS credentials from pom.xml
Why not have two pre-define properties for this, which everyone needs to set up in their settings.xml? /Anders On Fri, Sep 25, 2009 at 10:48, Todor Boev t.b...@prosyst.bg wrote: Hi, I am using the release plugin with CVS. Is there a way to remove the CVS user name and password from the pom.xml? I am setting up a maven project for 20+ developers and it would be bad if every one of them needs to keep a modified pom.xml in their machine with their user name. I tried the maven-properties-plugin but the problem I does not run when I do release:prepare. I can't discover the proper lifecycle phase where to hook the properties plugin so it runs both on normal build and on release. Cheers, Todor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Invoker Plugin 1.4 Released
The Maven team is pleased to announce the release of the Maven Invoker Plugin, version 1.4. This plugin allows to run Maven on a collection of projects and is especially useful for integration testing of other Maven plugins. See the plugin's site for more details: http://maven.apache.org/plugins/maven-invoker-plugin/ To use the updated plugin in your projects, you need to add the the following snippet to the plugins or plugin management section of your POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-invoker-plugin/artifactId version1.4/version /plugin Release Notes - Maven 2.x Invoker Plugin - Version 1.4 ** Bug * [MINVOKER-69] - Filter token basedir no longer interpolated * [MINVOKER-70] - invoker:install does not properly handle versioned dependencies * [MINVOKER-71] - Usage of setupIncludes can result in duplicate project invocation * [MINVOKER-78] - Throwing subclasses of java.lang.Error from hook script aborts main build with FATAL ERROR * [MINVOKER-84] - Staging of snapshot dependencies is incomplete * [MINVOKER-88] - Staging of existing artifacts from the local repository triggers transformations on them * [MINVOKER-93] - Filtering all POMs that are relevant to the forked build needs to consider child modules added by profiles ** Improvement * [MINVOKER-68] - Enable accessibility for non-public members from BeanShell scripts * [MINVOKER-73] - Support filter token @baseurl@ * [MINVOKER-75] - Trigger further builds upon any indexed invoker property * [MINVOKER-76] - Have invoker:run generate report files to allow reporting on the results of running invoker * [MINVOKER-92] - Add support for show version option ( -V,--show-version) ** New Feature * [MINVOKER-72] - Allow to configure network mode for sub builds * [MINVOKER-74] - Allow to specify alternative POMs during multi-module builds * [MINVOKER-77] - Add a invoker report mojo which display invoker its result * [MINVOKER-79] - Allow to easily pass data from the pre-build hook script to the post-build hook script * [MINVOKER-81] - provide a flag to skip the execution of all invoker steps * [MINVOKER-83] - Allow to configure different system properties for multi-invocation builds * [MINVOKER-91] - Decouple test execution from build failure * [MINVOKER-94] - Allow to skip projects based on JRE version or OS family ** Wish * [MINVOKER-85] - Don't treat null return value from hook scripts as error Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Remove CVS credentials from pom.xml
Yup. This worked. Thanks :) Anders Hammar wrote: Ok. I think I found the example, and it uses environment properties. Should work. Or, define a profile in your settings.xml that defines these properties. The benefit of this approach is that they can easily be defined (or overridden) through the command line as well. /Anders On Fri, Sep 25, 2009 at 11:07, Anders Hammar and...@hammar.net wrote: Hmm, I pretty sure I've seen an example of this somewhere. I'll have a look /A On Fri, Sep 25, 2009 at 11:06, Todor Boev t.b...@prosyst.bg wrote: That was my first idea. And I couldn't find a way to do it. All I find are discussions on how people want not to have this in their settings.xml but in an external properties file. How to put arbitrary properties in the settings.xml remains a mistery to me. Anders Hammar wrote: Why not have two pre-define properties for this, which everyone needs to set up in their settings.xml? /Anders On Fri, Sep 25, 2009 at 10:48, Todor Boev t.b...@prosyst.bg wrote: Hi, I am using the release plugin with CVS. Is there a way to remove the CVS user name and password from the pom.xml? I am setting up a maven project for 20+ developers and it would be bad if every one of them needs to keep a modified pom.xml in their machine with their user name. I tried the maven-properties-plugin but the problem I does not run when I do release:prepare. I can't discover the proper lifecycle phase where to hook the properties plugin so it runs both on normal build and on release. Cheers, Todor - 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 using DAV with digest-auth
I tried using Mvn 2.2.1 and got the same error from the wagon plugin:
[INFO] [site:deploy {execution: default-deploy}]
WAGON_VERSION: 1.0-beta-2
http://ci1.xxx/test - Session: Opened
Uploading: ./css/maven-base.css to http://ci1.xxx/test
# Transfer error: org.apache.commons.httpclient.HttpException: Unbuffered
entity enclosing request can not be repeated.
http://ci1.xxx/test - Session: Disconnecting
http://ci1.xxx/test - Session: Disconnected
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error uploading site
Embedded error: PUT request for: ./css/maven-base.css to maven-base.css
failed
Unbuffered entity enclosing request can not be repeated.
I also tried using -X but got no more output to indicate the root cause.
brettporter wrote:
This is probably related to the authentication re-submissions that
John worked on. Is it any better in Maven 2.2.1?
- Brett
On 23/09/2009, at 10:19 PM, Marc Lustig wrote:
Hi,
we have configured our httpd to use digest-authentication for dav
write-operations.
In the pom, we have configured the site distribution
site
idmaven-site/id
urldav:http://server/test/url
/site
In settings, we have configured the credentials as a server-tag
server
idmaven-site/id
usernameusername/username
passwordpw/password
/server
When we run maven 2.1 site-deploy, we get the following error:
[INFO] [site:deploy]
http://ci1.muc.allianz/test - Session: Opened
Uploading: ./css/maven-base.css to http://ci1.muc.allianz/test
# Transfer error: org.apache.commons.httpclient.HttpException:
Unbuffered
entity enclosing request can not be repeated.
http://ci1.muc.allianz/test - Session: Disconnecting
http://ci1.muc.allianz/test - Session: Disconnected
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error uploading site
Embedded error: PUT request for: ./css/maven-base.css to maven-
base.css
failed
Unbuffered entity enclosing request can not be repeated.
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error
uploading site
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLifecycleExecutor.java:583)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle
(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments
(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:
336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error
uploading
site
at
org.apache.maven.plugins.site.SiteDeployMojo.execute
(SiteDeployMojo.java:200)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLifecycleExecutor.java:558)
... 16 more
Caused by: org.apache.maven.wagon.TransferFailedException: PUT
request for:
./css/maven-base.css to maven-base.css failed
at
org.apache.maven.wagon.providers.webdav.WebDavWagon.put
(WebDavWagon.java:326)
at
org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory
(WebDavWagon.java:555)
at
org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory
(WebDavWagon.java:549)
at
org.apache.maven.plugins.site.SiteDeployMojo.execute
(SiteDeployMojo.java:184)
... 18 more
Caused by:
Re: why does site-deploy rebuild so often?
2009/9/25 David Hoffer dhoff...@gmail.com:
Hum,
Can you restate/finish the last point 'better still is to switch reporting
plugins to report, and not to do, and use the build lifecycle for doing'?
At the moment, reporting plugins do stuff rather than just generate a
report of stuff that has already been done.
For example,
the javadoc reporting plugin generates the javadocs... better would be
to just integrate the already generated javadocs into the site.
the cobertura reporting plugin measures the test coverage... better
would be to just report the test coverage that was previously measured
and integrate that report into the site.
Thus reporting plugins would do just that: report
This would keep the reporting lifecycle free from having to fork the
build lifecycle in order to ensure that the latest results were
available.
An example of how this works is the maven-invoker-plugin version 1.4,
where we added a report of the integration tests that have been run.
That report never forks the build, it just reports on the previous
results.
With this strategy, you do the work in the build lifecycle... you
report on the work previously done in the site lifecycle.
I'm not sure what you are referring to here.
Is there a way to know if a reporting plugin is a good or bad one? What
about the ones I'm using? I'd say the most important are cobertura,
javadocs, findbugs (not shown here).
cobertura forks a build lifecycle
javadocs forks a build lifecycle
not sure about findbugs... but it probably forks a build lifecycle in
order to ensure that all the source code folders are attached to the
project model and that any generated source code is generated.
See below for other comments/questions.
-Dave
On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
because each of the reporting plugins have no concept of how far up the
lifecycle the build has gone
in maven there are three (3) lifecycles:
1. the clean lifecycle: pre-clean, clean and post-clean phases
2: the site lifecycle: pre-site, site and site-deploy
3. the build lifecycle: validate, ... deploy
mojos have no way to find out which lifecycle they are running, what phase
they are executing in, and what phases have already executed
thus if you want to report the results of unit tests, you can either: scan
the filesystem for the results and hope that these results are current; or
you can fork a build up as far as test and then pull the results from the
filesystem
[dh] Are you saying that since during reporting surefire has no way to know
if you previously did an install and thus ran the test goal, it will fork a
new build and run the build lifecycle upto test?
yes
then if you want code coverage...
if you want to generate javadocs, you need to fork a build up as far as
process-sources in order to ensure that the source code has been generated
before generating the javadocs
if you are a good reporting plugin, you will fork the build
non-recursive... bad plugins are aggregator plugins that fork a build
(everything is hunky-dory until you have two forking aggregator plugins in
the same build, as they will recursively fork each other until you get to a
leaf project)
3.x might help solve some of these issues... better still is to switch
reporting plugins to report, and not to do, and use the build lifecycle for
doing
[dh] ??
Sent from my [rhymes with tryPod] ;-)
On 24 Sep 2009, at 22:18, David Hoffer dhoff...@gmail.com wrote:
We keep having problems with our site-deploy build either hanging or
running
out of memory. I just noticed that it rebuilds everything about 11 times!
Why?
(This top level pom has 3 modules where those 3 modules each have a few
modules. This is the only pom with a reporting section.)
Here is our top level reporting section.
reporting
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjavancss-maven-plugin/artifactId
version2.0-beta-2/version
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version${cobertura-maven-plugin.version}/version
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdsurefire-report-maven-plugin/artifactId
version2.0-beta-1/version
/plugin
plugin
!--Provides creating jar of source--
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-source-plugin/artifactId
version${maven-source-plugin.version}/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version${maven-javadoc-plugin.version}/version
configuration
Re: Calling a custom maven plugin
Also if you have the plugin configured in your pom (even in pluginManagement) and the goalPrefix (http://maven.apache.org/plugins/maven-plugin-plugin/descriptor-mojo.html#goalPrefix) was correctly configured or auto-detected for your plugin, then you can just use goalPrefix:goal when running maven against that pom.xml 2009/9/25 Anders Hammar and...@hammar.net: The way I know of is through the pluginGroups element of settings.xml. /Anders On Fri, Sep 25, 2009 at 03:12, Tristan Rouse tjcro...@gmail.com wrote: I'm currently working with the book Better Builds with Maven and doing some custom maven plugin development. I have a plugin I've created with the following POM info. groupIdcom.exist.mvnbook.plugins/groupId artifactIdmaven-buildinfo-plugin/artifactId packagingmaven-plugin/packaging You know how you can just type mvn pluginName:mojoName for many mojos? My mojo has to run like this: mvn com.exist.mvnbook.plugins:maven-buildinfo-plugin:extract where extract is the mojo name. From the error I get when I try to run it like this 'mvn buildinfo:extract it looks like I could get it to run that way if I changed the groupId of my mojo to org.apache.maven.plugins. It seems rather inappropriate to use this groupId myself? Is there another way to get my mojo to run without having to be so verbose? Thanks very much. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Eclipse as a dependency
Hi, I have created a small Maven plugin which uses the Eclipse code formatter to format my code. I would like to release it but the available librairies of Eclipse are quite old and I don't want my users to have Eclipse installed (that's the whole point of the plugin). Is there a repository with Eclipse jars somewhere ? I think that m2eclipse/tycho should be using them but I can't seem to find the jars. What's the policy concerning these jars ? Thans, Emmanuel
Re: part the classes are not compiled
Can you post the output of mvn help:effective-pom at parent level? With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 11:25 AM, maven apache apachemav...@gmail.com wrote: THis is my project structure: parent client server src main java cn wps 01.java 02.java resources cn wps xml01 xml02 io webapp The parent contains serveral modules,under the module named server,the package is cn.wps in the java directory there are the sources, and under the resources there are some xml files. When I run mvn install under the parent directory, it build successfully,but I found the server/target/classes/cn.wps, there are only the xml files,the 01.class 02.class do not exist... Then I trun to the server module directory run mvn install the suitation is same as before,Then I try to run mvn clean install ,things like before I want to know if this is my mistake? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site
Yes I did and I am still getting the same error. Any ideas what I could do? Anders Hammar wrote: Did you have a look at the doc link I provided? /Anders On Sat, Sep 19, 2009 at 23:31, nnocerino nicandro.nocer...@cigna.comwrote: Anders I tried v2.1.2 and after downloading all the dependencies found that I still get the same error. So now on to option 2. How do i add that dependency to the plugin's dependencies? Can you help by providing the example? Thanks, Nick Anders Hammar wrote: Seems as there is a missing dependency to commons-lang in maven-project-info-reports-plugin v2.1. You can fix that yourself by adding that dependency to the plugin's dependencies section in your pom. See http://maven.apache.org/pom.html#Plugins You should also try v2.1.2 to see if that bug has been fixed. /Anders On Fri, Sep 18, 2009 at 15:57, Nocerino, Nicandro W4LAB nicandro.nocer...@cigna.com wrote: I am trying to use the mvn site command and every time I run it I get the following error: [INFO] Error getting reports from the plugin 'org.apache.maven.plugins:maven-pro ject-info-reports-plugin:2.1': Unable to load the mojo 'org.apache.maven.plugins :maven-project-info-reports-plugin:2.1:plugin-management' in the plugin 'org.apa che.maven.plugins:maven-project-info-reports-plugin'. A required class is missin g: org/apache/commons/lang/StringUtils org.apache.commons.lang.StringUtils I am new to maven so there maybe something I am missing, hope someone can help. Nick Nocerino Clinical IT Phone: (860) 226-2131 nicandro.nocer...@cigna.com Confidential, unpublished property of CIGNA Do not duplicate or distribute Use and distribution limited solely to authorized personnel (C) Copyright 2009 by CIGNA -- CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown. This email transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2009 CIGNA == -- View this message in context: http://www.nabble.com/Maven-Site-tp25509471p25525594.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 -- View this message in context: http://www.nabble.com/Maven-Site-tp25509471p25611127.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 Site
Paste your pom snippet here would allow us to check it. /A On Fri, Sep 25, 2009 at 14:18, nnocerino nicandro.nocer...@cigna.comwrote: Yes I did and I am still getting the same error. Any ideas what I could do? Anders Hammar wrote: Did you have a look at the doc link I provided? /Anders On Sat, Sep 19, 2009 at 23:31, nnocerino nicandro.nocer...@cigna.comwrote: Anders I tried v2.1.2 and after downloading all the dependencies found that I still get the same error. So now on to option 2. How do i add that dependency to the plugin's dependencies? Can you help by providing the example? Thanks, Nick Anders Hammar wrote: Seems as there is a missing dependency to commons-lang in maven-project-info-reports-plugin v2.1. You can fix that yourself by adding that dependency to the plugin's dependencies section in your pom. See http://maven.apache.org/pom.html#Plugins You should also try v2.1.2 to see if that bug has been fixed. /Anders On Fri, Sep 18, 2009 at 15:57, Nocerino, Nicandro W4LAB nicandro.nocer...@cigna.com wrote: I am trying to use the mvn site command and every time I run it I get the following error: [INFO] Error getting reports from the plugin 'org.apache.maven.plugins:maven-pro ject-info-reports-plugin:2.1': Unable to load the mojo 'org.apache.maven.plugins :maven-project-info-reports-plugin:2.1:plugin-management' in the plugin 'org.apa che.maven.plugins:maven-project-info-reports-plugin'. A required class is missin g: org/apache/commons/lang/StringUtils org.apache.commons.lang.StringUtils I am new to maven so there maybe something I am missing, hope someone can help. Nick Nocerino Clinical IT Phone: (860) 226-2131 nicandro.nocer...@cigna.com Confidential, unpublished property of CIGNA Do not duplicate or distribute Use and distribution limited solely to authorized personnel (C) Copyright 2009 by CIGNA -- CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown. This email transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2009 CIGNA == -- View this message in context: http://www.nabble.com/Maven-Site-tp25509471p25525594.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 -- View this message in context: http://www.nabble.com/Maven-Site-tp25509471p25611127.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: why does site-deploy rebuild so often?
Thanks for the explanation that makes sense. I'm surprised maven reporting is designed so poorly, I agree your approach in the invoker makes more sense. BTW, when you say 'fork a build', is this done in the current VM? Is there a way to force all these in separate VMs? The problem we have is that as our build gets bigger (they never seem to get smaller) we are finding that site-deploy is not reliable. Somewhere in the build it will fail, usually because its out of memory. We have raised the max heap to about 2GB, max perm gen to about 350k, etc but some piece will still fail. Most often it fails using the exec plugin where we need to call into some Java code. Sometimes the Flex compiler will fail. Etc. If we could run each of the reports in a separate VM that would solve the problem, it seems. What's the best approach for current users of maven to handle this? I suppose we could generate lots of smaller reports each on a section of the build, etc, but I'd like to investigate other approaches first. (BTW, our CI build is on Linux.) -Dave On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/9/25 David Hoffer dhoff...@gmail.com: Hum, Can you restate/finish the last point 'better still is to switch reporting plugins to report, and not to do, and use the build lifecycle for doing'? At the moment, reporting plugins do stuff rather than just generate a report of stuff that has already been done. For example, the javadoc reporting plugin generates the javadocs... better would be to just integrate the already generated javadocs into the site. the cobertura reporting plugin measures the test coverage... better would be to just report the test coverage that was previously measured and integrate that report into the site. Thus reporting plugins would do just that: report This would keep the reporting lifecycle free from having to fork the build lifecycle in order to ensure that the latest results were available. An example of how this works is the maven-invoker-plugin version 1.4, where we added a report of the integration tests that have been run. That report never forks the build, it just reports on the previous results. With this strategy, you do the work in the build lifecycle... you report on the work previously done in the site lifecycle. I'm not sure what you are referring to here. Is there a way to know if a reporting plugin is a good or bad one? What about the ones I'm using? I'd say the most important are cobertura, javadocs, findbugs (not shown here). cobertura forks a build lifecycle javadocs forks a build lifecycle not sure about findbugs... but it probably forks a build lifecycle in order to ensure that all the source code folders are attached to the project model and that any generated source code is generated. See below for other comments/questions. -Dave On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: because each of the reporting plugins have no concept of how far up the lifecycle the build has gone in maven there are three (3) lifecycles: 1. the clean lifecycle: pre-clean, clean and post-clean phases 2: the site lifecycle: pre-site, site and site-deploy 3. the build lifecycle: validate, ... deploy mojos have no way to find out which lifecycle they are running, what phase they are executing in, and what phases have already executed thus if you want to report the results of unit tests, you can either: scan the filesystem for the results and hope that these results are current; or you can fork a build up as far as test and then pull the results from the filesystem [dh] Are you saying that since during reporting surefire has no way to know if you previously did an install and thus ran the test goal, it will fork a new build and run the build lifecycle upto test? yes then if you want code coverage... if you want to generate javadocs, you need to fork a build up as far as process-sources in order to ensure that the source code has been generated before generating the javadocs if you are a good reporting plugin, you will fork the build non-recursive... bad plugins are aggregator plugins that fork a build (everything is hunky-dory until you have two forking aggregator plugins in the same build, as they will recursively fork each other until you get to a leaf project) 3.x might help solve some of these issues... better still is to switch reporting plugins to report, and not to do, and use the build lifecycle for doing [dh] ?? Sent from my [rhymes with tryPod] ;-) On 24 Sep 2009, at 22:18, David Hoffer dhoff...@gmail.com wrote: We keep having problems with our site-deploy build either hanging or running out of memory. I just noticed that it rebuilds everything about 11 times! Why? (This top level pom has 3
Can not use the plexus component org.sonatype.plexus.components.sec.dispatcher.SecDispatcher since maven 2.2.0
Hi,
Since maven 2.1.0, I use in a mojo the
org.sonatype.plexus.components.sec.dispatcher.SecDispatcher
from the artifact org.sonatype.plexus:plexus-sec-dispatcher:1.3.1
to decrypt password in my settings.xml
I recently change to maven 2.2.1, but my mojo does not anylonger works fine
(same result with 2.2.0) :
Caused by: org.codehaus.plexus.component.composition.CompositionException:
Composition failed of field sec in object of type
org.nuiton.mail.plugin.SendEmailMojo because the requirement
ComponentRequirement{role='org.sonatype.plexus.components.sec.dispatcher.SecDispatcher',
roleHint='default', fieldName='sec'} was missing
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:154)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29)
... 26 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Unable to lookup component
'org.sonatype.plexus.components.sec.dispatcher.SecDispatcherdefault', it could
not be started
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:339)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129)
... 30 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLifecycleException:
Error starting component
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:109)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331)
... 31 more
Caused by:
org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionException:
Error composing component
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105)
... 34 more
Caused by: org.codehaus.plexus.component.composition.CompositionException:
Composition failed for the field _cipher in object of type
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:144)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29)
... 36 more
Caused by: java.lang.IllegalArgumentException: Can not set
org.sonatype.plexus.components.cipher.PlexusCipher field
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher._cipher to
org.sonatype.plexus.components.cipher.DefaultPlexusCipher
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
at java.lang.reflect.Field.set(Field.java:657)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:137)
... 40 more
I read in the release note of maven 2.2.0 that something has changed for these
plexus component, but can't find what ?
What is the catch ? Does I miss something when upgrading to maven 2.2.X ?
Thanks for your replies.
--
Tony Chemit
tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com
-
To unsubscribe, e-mail:
Re: Maven Central Repository - Cleanup Efforts
We just need a high-quality POM, correct metadata, javadocs, sources, and signatures. It is debatable is what you mean on high quality. For me (totally a Maven fan!) what makes the POM high quality? Its ability to build the project! I don't really care if it is full of maven-antrun-plugin, but build it by running mvn ... For some developers high quality really just means that the metadata is correct. Because of this opposition having two separate OSS repos (serving different needs?) makes sense. What is the right thing to do going forward? One question is whether to care about build ability or not! On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl jvan...@sonatype.com wrote: On 2009-09-24, at 7:52 PM, Albert Kurucz wrote: Jason and Brian, thanks for the explanations. Understood, the policy of not removing anything from Maven Central serves a purpose. I wish there would be another publicly Maven repository, which is maintained with rules enforced. This repo could even have a rule (additional to the old and unenforced rules) that only Maven built projects can enter, maybe even more restriction: only the designated Continuous Integration server can upload to it. What matters is a plan to improve the metadata and this can be done over time. There can never be a big bang here, there is just too much content, and too many people relying on the content that's there. Projects that are deploying against oss.sonatype.org are subject to the procurement rules which are stringent. The artifacts are placed in a staging repository, rules are applied and if they all pass they get promoted otherwise they have to be corrected. No promotion unless all the rules pass. Only allowing Maven built projects doesn't make sense. All we need it the correct information. We honestly don't care if people build with Maven or not. We just need a high-quality POM, correct metadata, javadocs, sources, and signatures. This pure Maven repo would not be able to compete with Maven Central regarding size or the number of artifacts, but some OSS developers might prefer to use from and supply to this one instead of the big and ugly. This isn't really going to change or help anything. The existing content cannot change, the content going forward needs to be improved and that's what matters. Over time as the content improves the poorer quality submissions will just fall into disuse. Nexus can now help any project that wants to deploy high quality artifacts via oss.sonatype.org. The next step for us is allowing bundle submissions that are normally pushed into JIRA to be also submitted into a staging repository and run through the same set of rules. This will be available in Nexus 1.4. The last gap to fill will be repositories that directly sync and we'll provide a mechanism for that in Nexus as well. Ultimately we will build up these rules and if you don't pass them, by whatever gate you pass through, then your artifacts get rejected. We'll provide this in an easy to use form with Nexus but ultimately it doesn't matter how these rules are enforced as long as they are enforced. This is the only strategy that will work long-term. What's done has been done. What matters now helping projects do the right thing going forward. On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox bri...@infinity.nu wrote: On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz albert.kur...@gmail.com wrote: Requirements for the POMs are defined as: http://maven.apache.org/guides/mini/guide-central-repository-upload.html I call the artifact corrupt (regarding Maven Central Compliance) if the POM of the artifact does not fulfills the above requirements. There are corrupt ones have made it to the Central, because the guard was sleeping. Correct, but changing them is not an option because it will destabilize builds. This is a long standing rule that we do not remove or change the contents of central. - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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 Site
As I was pasting the snippet of code, I noticed where the issue was, I had placed the dependency under the wrong plugin. Problem when you multitask! Well thanks for all your help and support, I am sure I will be asking other questions. Nick Anders Hammar wrote: Paste your pom snippet here would allow us to check it. /A On Fri, Sep 25, 2009 at 14:18, nnocerino nicandro.nocer...@cigna.comwrote: Yes I did and I am still getting the same error. Any ideas what I could do? Anders Hammar wrote: Did you have a look at the doc link I provided? /Anders On Sat, Sep 19, 2009 at 23:31, nnocerino nicandro.nocer...@cigna.comwrote: Anders I tried v2.1.2 and after downloading all the dependencies found that I still get the same error. So now on to option 2. How do i add that dependency to the plugin's dependencies? Can you help by providing the example? Thanks, Nick Anders Hammar wrote: Seems as there is a missing dependency to commons-lang in maven-project-info-reports-plugin v2.1. You can fix that yourself by adding that dependency to the plugin's dependencies section in your pom. See http://maven.apache.org/pom.html#Plugins You should also try v2.1.2 to see if that bug has been fixed. /Anders On Fri, Sep 18, 2009 at 15:57, Nocerino, Nicandro W4LAB nicandro.nocer...@cigna.com wrote: I am trying to use the mvn site command and every time I run it I get the following error: [INFO] Error getting reports from the plugin 'org.apache.maven.plugins:maven-pro ject-info-reports-plugin:2.1': Unable to load the mojo 'org.apache.maven.plugins :maven-project-info-reports-plugin:2.1:plugin-management' in the plugin 'org.apa che.maven.plugins:maven-project-info-reports-plugin'. A required class is missin g: org/apache/commons/lang/StringUtils org.apache.commons.lang.StringUtils I am new to maven so there maybe something I am missing, hope someone can help. Nick Nocerino Clinical IT Phone: (860) 226-2131 nicandro.nocer...@cigna.com Confidential, unpublished property of CIGNA Do not duplicate or distribute Use and distribution limited solely to authorized personnel (C) Copyright 2009 by CIGNA -- CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown. This email transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2009 CIGNA == -- View this message in context: http://www.nabble.com/Maven-Site-tp25509471p25525594.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 -- View this message in context: http://www.nabble.com/Maven-Site-tp25509471p25611127.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 -- View this message in context: http://www.nabble.com/Maven-Site-tp25509471p25612306.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: part the classes are not compiled
It looks like your server pom file configures the compiler plugin: plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration includes includeorg/n52/wps/server/**/include includeorg/n52/wps/util/**/include /includes excludes excludeorg/n52/wps/server/algorithm/smooth/**/exclude /excludes source1.6/source target1.6/target encodingISO-8859-1/encoding /configuration /plugin Your package cn.wps is not included. Why did you specify the includes? Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 1:53 PM, maven apache apachemav...@gmail.com wrote: The output is too long , so I redirect them to a file in the attach. 2009/9/25 Nick Stolwijk nick.stolw...@gmail.com Can you post the output of mvn help:effective-pom at parent level? With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 11:25 AM, maven apache apachemav...@gmail.com wrote: THis is my project structure: parent client server src main java cn wps 01.java 02.java resources cn wps xml01 xml02 io webapp The parent contains serveral modules,under the module named server,the package is cn.wps in the java directory there are the sources, and under the resources there are some xml files. When I run mvn install under the parent directory, it build successfully,but I found the server/target/classes/cn.wps, there are only the xml files,the 01.class 02.class do not exist... Then I trun to the server module directory run mvn install the suitation is same as before,Then I try to run mvn clean install ,things like before I want to know if this is my mistake? - 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: part the classes are not compiled
2009/9/25 Nick Stolwijk nick.stolw...@gmail.com It looks like your server pom file configures the compiler plugin: plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration includes includeorg/n52/wps/server/**/include includeorg/n52/wps/util/**/include /includes excludes excludeorg/n52/wps/server/algorithm/smooth/**/exclude /excludes source1.6/source target1.6/target encodingISO-8859-1/encoding /configuration /plugin Your package cn.wps is not included. Why did you specify the includes? I just encounter this problem twice, yesterday and today. The mvn install works for other times. I forget how to solove it yesterday. That's so say,even the cn.wps not included in the pom.xml ,it can also be compiled. Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 1:53 PM, maven apache apachemav...@gmail.com wrote: The output is too long , so I redirect them to a file in the attach. 2009/9/25 Nick Stolwijk nick.stolw...@gmail.com Can you post the output of mvn help:effective-pom at parent level? With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 11:25 AM, maven apache apachemav...@gmail.com wrote: THis is my project structure: parent client server src main java cn wps 01.java 02.java resources cn wps xml01 xml02 io webapp The parent contains serveral modules,under the module named server,the package is cn.wps in the java directory there are the sources, and under the resources there are some xml files. When I run mvn install under the parent directory, it build successfully,but I found the server/target/classes/cn.wps, there are only the xml files,the 01.class 02.class do not exist... Then I trun to the server module directory run mvn install the suitation is same as before,Then I try to run mvn clean install ,things like before I want to know if this is my mistake? - 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: part the classes are not compiled
2009/9/25 maven apache apachemav...@gmail.com 2009/9/25 Nick Stolwijk nick.stolw...@gmail.com It looks like your server pom file configures the compiler plugin: plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration includes includeorg/n52/wps/server/**/include includeorg/n52/wps/util/**/include /includes excludes excludeorg/n52/wps/server/algorithm/smooth/**/exclude /excludes source1.6/source target1.6/target encodingISO-8859-1/encoding /configuration /plugin Your package cn.wps is not included. Why did you specify the includes? I just encounter this problem twice, yesterday and today. The mvn install works for other times. I forget how to solove it yesterday. That's so say,even the cn.wps not included in the pom.xml ,it can also be compiled. However , I just do it, add the cn.wps in the pom.xml, and the classes are compiled. But I am surprised why. Since I use maven as build tool for this project for more than five month,I did not add the cn.wps to the pom.xml, the classes were also compiled and installed, I just encountered the problem mentioned in this post yesterday the first time,so I think if there is something else involved in this problem. Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 1:53 PM, maven apache apachemav...@gmail.com wrote: The output is too long , so I redirect them to a file in the attach. 2009/9/25 Nick Stolwijk nick.stolw...@gmail.com Can you post the output of mvn help:effective-pom at parent level? With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 11:25 AM, maven apache apachemav...@gmail.com wrote: THis is my project structure: parent client server src main java cn wps 01.java 02.java resources cn wps xml01 xml02 io webapp The parent contains serveral modules,under the module named server,the package is cn.wps in the java directory there are the sources, and under the resources there are some xml files. When I run mvn install under the parent directory, it build successfully,but I found the server/target/classes/cn.wps, there are only the xml files,the 01.class 02.class do not exist... Then I trun to the server module directory run mvn install the suitation is same as before,Then I try to run mvn clean install ,things like before I want to know if this is my mistake? - 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
Question about maven profiles activation
Dear all, I have been browsing the Maven Book online recently (available on http://www.sonatype.com/books/maven-book/reference/public-book.html), and I have found something interesting about the profiles used in Maven in one example: http://www.sonatype.com/books/maven-book/reference/profiles-sect-tips-tricks.html Basically, this example does the following: - in settings.xml, we define a profile, active by default, that set an environment variable; - in a module pom.xml, we activate another profile based on the presence of the previous environment variable. This is a functionality that looked very interesting at first, with the only drawback that I was not able to make it work. The only solution to activate the profile defined in the pom.xml file was to explicitly set the environment variable on the command-line, which is not what I want to do. I have tested this with versions 2.0.10 and 2.2.1, and both do not work. Does anyone know if what is presented in this example should work ? Or does anyone of you know a similar way of achieving such functionality ? Thanks in advance for your help, Reynald Borer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: part the classes are not compiled
Could it be that you IDE already put those classes in target/classes? The jar packaging just takes everything under target/classes and put that into a jar file. And why did you configure the compiler plugin with includes. Normally you would just want to compile everything under src/main/java. Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 3:54 PM, maven apache apachemav...@gmail.com wrote: 2009/9/25 maven apache apachemav...@gmail.com 2009/9/25 Nick Stolwijk nick.stolw...@gmail.com It looks like your server pom file configures the compiler plugin: plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration includes includeorg/n52/wps/server/**/include includeorg/n52/wps/util/**/include /includes excludes excludeorg/n52/wps/server/algorithm/smooth/**/exclude /excludes source1.6/source target1.6/target encodingISO-8859-1/encoding /configuration /plugin Your package cn.wps is not included. Why did you specify the includes? I just encounter this problem twice, yesterday and today. The mvn install works for other times. I forget how to solove it yesterday. That's so say,even the cn.wps not included in the pom.xml ,it can also be compiled. However , I just do it, add the cn.wps in the pom.xml, and the classes are compiled. But I am surprised why. Since I use maven as build tool for this project for more than five month,I did not add the cn.wps to the pom.xml, the classes were also compiled and installed, I just encountered the problem mentioned in this post yesterday the first time,so I think if there is something else involved in this problem. Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 1:53 PM, maven apache apachemav...@gmail.com wrote: The output is too long , so I redirect them to a file in the attach. 2009/9/25 Nick Stolwijk nick.stolw...@gmail.com Can you post the output of mvn help:effective-pom at parent level? With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 11:25 AM, maven apache apachemav...@gmail.com wrote: THis is my project structure: parent client server src main java cn wps 01.java 02.java resources cn wps xml01 xml02 io webapp The parent contains serveral modules,under the module named server,the package is cn.wps in the java directory there are the sources, and under the resources there are some xml files. When I run mvn install under the parent directory, it build successfully,but I found the server/target/classes/cn.wps, there are only the xml files,the 01.class 02.class do not exist... Then I trun to the server module directory run mvn install the suitation is same as before,Then I try to run mvn clean install ,things like before I want to know if this is my mistake? - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: why does site-deploy rebuild so often?
Just a couple more ideas/questions. Currently we specify our reports at the top level only. Is there a way to exclude some reports on child modules? Or should we be specifying our reports at each child module level where we need the report and not at the top level? I.e. what's the best way to just run the minimum number of reports, so we use less memory? -Dave On Fri, Sep 25, 2009 at 7:06 AM, David Hoffer dhoff...@gmail.com wrote: Thanks for the explanation that makes sense. I'm surprised maven reporting is designed so poorly, I agree your approach in the invoker makes more sense. BTW, when you say 'fork a build', is this done in the current VM? Is there a way to force all these in separate VMs? The problem we have is that as our build gets bigger (they never seem to get smaller) we are finding that site-deploy is not reliable. Somewhere in the build it will fail, usually because its out of memory. We have raised the max heap to about 2GB, max perm gen to about 350k, etc but some piece will still fail. Most often it fails using the exec plugin where we need to call into some Java code. Sometimes the Flex compiler will fail. Etc. If we could run each of the reports in a separate VM that would solve the problem, it seems. What's the best approach for current users of maven to handle this? I suppose we could generate lots of smaller reports each on a section of the build, etc, but I'd like to investigate other approaches first. (BTW, our CI build is on Linux.) -Dave On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/9/25 David Hoffer dhoff...@gmail.com: Hum, Can you restate/finish the last point 'better still is to switch reporting plugins to report, and not to do, and use the build lifecycle for doing'? At the moment, reporting plugins do stuff rather than just generate a report of stuff that has already been done. For example, the javadoc reporting plugin generates the javadocs... better would be to just integrate the already generated javadocs into the site. the cobertura reporting plugin measures the test coverage... better would be to just report the test coverage that was previously measured and integrate that report into the site. Thus reporting plugins would do just that: report This would keep the reporting lifecycle free from having to fork the build lifecycle in order to ensure that the latest results were available. An example of how this works is the maven-invoker-plugin version 1.4, where we added a report of the integration tests that have been run. That report never forks the build, it just reports on the previous results. With this strategy, you do the work in the build lifecycle... you report on the work previously done in the site lifecycle. I'm not sure what you are referring to here. Is there a way to know if a reporting plugin is a good or bad one? What about the ones I'm using? I'd say the most important are cobertura, javadocs, findbugs (not shown here). cobertura forks a build lifecycle javadocs forks a build lifecycle not sure about findbugs... but it probably forks a build lifecycle in order to ensure that all the source code folders are attached to the project model and that any generated source code is generated. See below for other comments/questions. -Dave On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: because each of the reporting plugins have no concept of how far up the lifecycle the build has gone in maven there are three (3) lifecycles: 1. the clean lifecycle: pre-clean, clean and post-clean phases 2: the site lifecycle: pre-site, site and site-deploy 3. the build lifecycle: validate, ... deploy mojos have no way to find out which lifecycle they are running, what phase they are executing in, and what phases have already executed thus if you want to report the results of unit tests, you can either: scan the filesystem for the results and hope that these results are current; or you can fork a build up as far as test and then pull the results from the filesystem [dh] Are you saying that since during reporting surefire has no way to know if you previously did an install and thus ran the test goal, it will fork a new build and run the build lifecycle upto test? yes then if you want code coverage... if you want to generate javadocs, you need to fork a build up as far as process-sources in order to ensure that the source code has been generated before generating the javadocs if you are a good reporting plugin, you will fork the build non-recursive... bad plugins are aggregator plugins that fork a build (everything is hunky-dory until you have two forking aggregator plugins in the same build, as they will recursively fork each other until you get to a leaf project) 3.x might help solve
Re: part the classes are not compiled
2009/9/25 Nick Stolwijk nick.stolw...@gmail.com Could it be that you IDE already put those classes in target/classes? The jar packaging just takes everything under target/classes and put that into a jar file. Maybe. And why did you configure the compiler plugin with includes. Normally you would just want to compile everything under src/main/java. This is a opensouce project. I just use it for study. Anyway, thank you! ^_^ Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 3:54 PM, maven apache apachemav...@gmail.com wrote: 2009/9/25 maven apache apachemav...@gmail.com 2009/9/25 Nick Stolwijk nick.stolw...@gmail.com It looks like your server pom file configures the compiler plugin: plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration includes includeorg/n52/wps/server/**/include includeorg/n52/wps/util/**/include /includes excludes excludeorg/n52/wps/server/algorithm/smooth/**/exclude /excludes source1.6/source target1.6/target encodingISO-8859-1/encoding /configuration /plugin Your package cn.wps is not included. Why did you specify the includes? I just encounter this problem twice, yesterday and today. The mvn install works for other times. I forget how to solove it yesterday. That's so say,even the cn.wps not included in the pom.xml ,it can also be compiled. However , I just do it, add the cn.wps in the pom.xml, and the classes are compiled. But I am surprised why. Since I use maven as build tool for this project for more than five month,I did not add the cn.wps to the pom.xml, the classes were also compiled and installed, I just encountered the problem mentioned in this post yesterday the first time,so I think if there is something else involved in this problem. Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 1:53 PM, maven apache apachemav...@gmail.com wrote: The output is too long , so I redirect them to a file in the attach. 2009/9/25 Nick Stolwijk nick.stolw...@gmail.com Can you post the output of mvn help:effective-pom at parent level? With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Sep 25, 2009 at 11:25 AM, maven apache apachemav...@gmail.com wrote: THis is my project structure: parent client server src main java cn wps 01.java 02.java resources cn wps xml01 xml02 io webapp The parent contains serveral modules,under the module named server,the package is cn.wps in the java directory there are the sources, and under the resources there are some xml files. When I run mvn install under the parent directory, it build successfully,but I found the server/target/classes/cn.wps, there are only the xml files,the 01.class 02.class do not exist... Then I trun to the server module directory run mvn install the suitation is same as before,Then I try to run mvn clean install ,things like before I want to know if this is my mistake? - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Random can't find skin failure
Any suggestions anyone? This is only happening when building via Hudson and multiple executors running at once. -Original Message- From: EJ Ciramella [mailto:ecirame...@upromise.com] Sent: Thursday, September 24, 2009 4:57 PM To: users@maven.apache.org Subject: RE: Random can't find skin failure Another related clue is the following in the logs: [INFO] Parent project loaded from repository. Downloading: http://url/archiva/repository/bertha/parentmodule/1.0-SNAPSHOT/pare ntmodule-1.0-20090330.141907-1-site_en.xml Downloading: http://url/archiva/repository/bertha/parentmodule/1.0-SNAPSHOT/pare ntmodule-1.0-20090330.141907-1-site.xml [INFO] artifact org.apache.maven.skins:maven-default-skin: checking for updates from bertha... What makes maven go look for the site skins there? -Original Message- From: EJ Ciramella [mailto:ecirame...@upromise.com] Sent: Thursday, September 24, 2009 4:47 PM To: users@maven.apache.org Subject: Random can't find skin failure Hello list - I'm struggling a bit with the enclosed error. I see this almost randomly while building in Hudson against our Archiva repository: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] The skin does not exist: Unable to determine the release version Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -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.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.apache.maven.skins:maven-default-skin:jar:RELEASE It only seems to happen if there are a few (unrelated) builds running at the same time - any suggestions? - 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: Question about maven profiles activation
I think this issue is related: https://issues.sonatype.org/browse/MVNDEF-261 On Fri, Sep 25, 2009 at 9:58 PM, Reynald Borer reynald.bo...@elca.chwrote: Dear all, I have been browsing the Maven Book online recently (available on http://www.sonatype.com/books/maven-book/reference/public-book.html), and I have found something interesting about the profiles used in Maven in one example: http://www.sonatype.com/books/maven-book/reference/profiles-sect-tips-tricks.html Basically, this example does the following: - in settings.xml, we define a profile, active by default, that set an environment variable; - in a module pom.xml, we activate another profile based on the presence of the previous environment variable. This is a functionality that looked very interesting at first, with the only drawback that I was not able to make it work. The only solution to activate the profile defined in the pom.xml file was to explicitly set the environment variable on the command-line, which is not what I want to do. I have tested this with versions 2.0.10 and 2.2.1, and both do not work. Does anyone know if what is presented in this example should work ? Or does anyone of you know a similar way of achieving such functionality ? Thanks in advance for your help, Reynald Borer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- - juven
Parent, Modules and version management
Hello, I have a multimodules project (ProjectParent) with each module has a super pom's parent . See the figure: http://www.nabble.com/file/p25614127/Screen03.jpg (red : parent, blue : module) My problem is very simple. I can't manage the version of my modules from my multimodules project. I wish to have the same version in all modules and define this version in the ProjectParent. I look for this in a new plugin called versions (Codehaus), but I didn't find what I need. Has anybody a solution for this? Thank you very much, Emmanuel. -- View this message in context: http://www.nabble.com/Parent%2C-Modules-and-version-management-tp25614127p25614127.html Sent from the Maven - Users mailing list archive at Nabble.com.
Generating a repo from a bunch of jars
I am trying to convert a project to Maven and it is going reasonably well. However the project uses Pellet (http://clarkparsia.com/pellet). And no resent version of Pellet is available in any mvn repository I can find, so I will need to build one my self. I was wondering if there are any tools or scripts out there to convert a bunch of jars into a repo using heuristics. That way I could automatically generate a local repo inside the project to hold the jars that are not available in the public repos. It would be even better if the tool could automatically detect if a jar was already in the public repos and use that version instead of the local one. Thanks a lot. -Arthur
Maven appc plugin
Hi,
i want to use the maven plugin appc to compile my .ear files in our
project. I use Bea Weblogic 10.0 as Webserver and Apache Maven in the
version 2.1.0 as configuration tool. Java is used in version 1.5.0_20.
The pom.xml where the plugin is mapped looks like:
.
.
.
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdweblogic-maven-plugin/artifactId
version2.9.1/version
configuration
explodedfalse/exploded
forceGenerationfalse/forceGeneration
/configuration
executions
execution
phaseverify/phase
goals
goalappc/goal
/goals
/execution
/executions
/plugin
.
.
.
The Problem is now, each time i try to compile my .ear file the following
exception is thrown.
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO]task-segment: [install]
[INFO]
[WARNING] POM for
'com.projects.cdp.libraries:contentintegration_ejb:pom:0.1.2-SNAPSHOT:compile'
is invalid.
Its dependencies (if any) will NOT be available to the current build.
[INFO] [ear:generate-application-xml]
[INFO] Generating application.xml
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] [ear:ear]
[INFO] Copy ear sources to
/home/tboss/workspace/CDP/libraries/contentintegration_ear/target/contentintegration_ear-0.1.2-SNAPSHOT
[INFO] Copy ear resources to
/home/tboss/workspace/CDP/libraries/contentintegration_ear/target/contentintegration_ear-0.1.2-SNAPSHOT
[INFO] Could not find manifest file:
/home/tboss/workspace/CDP/libraries/contentintegration_ear/src/main/application/META-INF/MANIFEST.MF
- Generating one
[INFO] Building jar:
/home/tboss/workspace/CDP/libraries/contentintegration_ear/target/contentintegration_ear-0.1.2-SNAPSHOT.ear
[INFO] [weblogic:appc {execution: default}]
[INFO] Setting weblogic.home = /opt/bea/wlserver_10.0
[INFO] Weblogic APPC processing beginning for artifact
/home/tboss/workspace/CDP/libraries/contentintegration_ear/target/contentintegration_ear-0.1.2-SNAPSHOT.ear
[INFO] Detailed Appc settings information AppcMojo[
basicClientJar = false
forceGeneration = false
keepGenerated = true
lineNumbers = false
inputArtifactPath =
/home/tboss/workspace/CDP/libraries/contentintegration_ear/target/contentintegration_ear-0.1.2-SNAPSHOT.ear
outputArtifactPath = null
artifacts =
[com.projects.cdp.libraries:contentintegration_ejb:ejb:0.1.2-SNAPSHOT:compile,
com.bmw.plattforms.b2v:b2vlogging:jar:1.5:compile,
com.frameworks.ehl:ehl:jar:2:compile,
com.thirdparty.javaee:javaee-api:jar:5.0:provided,
javax.servlet:servlet-api:jar:2.4:provided,
weblogic:wls-api:jar:${weblogic.version}:system,
weblogic:weblogic:jar:${weblogic.version}:system]
project Packaging = ear
verbose = true]
[INFO] Using Classpath
Profile activation based on JDK, how it works?
Hi All, I was just wondering about the following situation I'm using maven 2.2.1 which requires jdk 1.5 to run, but my modules will compile only with 1.4, so i used the 1.4 executable in my compiler plugin. In this case if i create profile with the activation rule for jdk1.4/jdk when this profile will get activated? Any one had this situation
Re: why does site-deploy rebuild so often?
If you don't need the report on every module I would only specify the report on the modules that require it. In this respect the reporting section is badly let down by the lack of a pluginManagement section... but that would require a schema change... and I am not sure I see that happening any time soon... but you could always ask Jason! ;-) -Stephen 2009/9/25 David Hoffer dhoff...@gmail.com: Just a couple more ideas/questions. Currently we specify our reports at the top level only. Is there a way to exclude some reports on child modules? Or should we be specifying our reports at each child module level where we need the report and not at the top level? I.e. what's the best way to just run the minimum number of reports, so we use less memory? -Dave On Fri, Sep 25, 2009 at 7:06 AM, David Hoffer dhoff...@gmail.com wrote: Thanks for the explanation that makes sense. I'm surprised maven reporting is designed so poorly, I agree your approach in the invoker makes more sense. BTW, when you say 'fork a build', is this done in the current VM? Is there a way to force all these in separate VMs? The problem we have is that as our build gets bigger (they never seem to get smaller) we are finding that site-deploy is not reliable. Somewhere in the build it will fail, usually because its out of memory. We have raised the max heap to about 2GB, max perm gen to about 350k, etc but some piece will still fail. Most often it fails using the exec plugin where we need to call into some Java code. Sometimes the Flex compiler will fail. Etc. If we could run each of the reports in a separate VM that would solve the problem, it seems. What's the best approach for current users of maven to handle this? I suppose we could generate lots of smaller reports each on a section of the build, etc, but I'd like to investigate other approaches first. (BTW, our CI build is on Linux.) -Dave On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/9/25 David Hoffer dhoff...@gmail.com: Hum, Can you restate/finish the last point 'better still is to switch reporting plugins to report, and not to do, and use the build lifecycle for doing'? At the moment, reporting plugins do stuff rather than just generate a report of stuff that has already been done. For example, the javadoc reporting plugin generates the javadocs... better would be to just integrate the already generated javadocs into the site. the cobertura reporting plugin measures the test coverage... better would be to just report the test coverage that was previously measured and integrate that report into the site. Thus reporting plugins would do just that: report This would keep the reporting lifecycle free from having to fork the build lifecycle in order to ensure that the latest results were available. An example of how this works is the maven-invoker-plugin version 1.4, where we added a report of the integration tests that have been run. That report never forks the build, it just reports on the previous results. With this strategy, you do the work in the build lifecycle... you report on the work previously done in the site lifecycle. I'm not sure what you are referring to here. Is there a way to know if a reporting plugin is a good or bad one? What about the ones I'm using? I'd say the most important are cobertura, javadocs, findbugs (not shown here). cobertura forks a build lifecycle javadocs forks a build lifecycle not sure about findbugs... but it probably forks a build lifecycle in order to ensure that all the source code folders are attached to the project model and that any generated source code is generated. See below for other comments/questions. -Dave On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: because each of the reporting plugins have no concept of how far up the lifecycle the build has gone in maven there are three (3) lifecycles: 1. the clean lifecycle: pre-clean, clean and post-clean phases 2: the site lifecycle: pre-site, site and site-deploy 3. the build lifecycle: validate, ... deploy mojos have no way to find out which lifecycle they are running, what phase they are executing in, and what phases have already executed thus if you want to report the results of unit tests, you can either: scan the filesystem for the results and hope that these results are current; or you can fork a build up as far as test and then pull the results from the filesystem [dh] Are you saying that since during reporting surefire has no way to know if you previously did an install and thus ran the test goal, it will fork a new build and run the build lifecycle upto test? yes then if you want code coverage... if you want to generate javadocs, you need to fork a build up as far as process-sources in order to ensure that
Re: Maven Central Repository - Cleanup Efforts
For me, High quality is that: /project/(?parent/)(groupId|artifactId|version) are valid and do not reference properties /project/dependencies is valid and if there are any properties defined they are defined within the pom or it's parents /project/name /project/description /project/url Bonus high quality is when it has /project/scm /project/issueTracking /project/developers /project/contributors and if it is a project that builds using Maven 2 -Stephen 2009/9/25 Albert Kurucz albert.kur...@gmail.com: We just need a high-quality POM, correct metadata, javadocs, sources, and signatures. It is debatable is what you mean on high quality. For me (totally a Maven fan!) what makes the POM high quality? Its ability to build the project! I don't really care if it is full of maven-antrun-plugin, but build it by running mvn ... For some developers high quality really just means that the metadata is correct. Because of this opposition having two separate OSS repos (serving different needs?) makes sense. What is the right thing to do going forward? One question is whether to care about build ability or not! On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl jvan...@sonatype.com wrote: On 2009-09-24, at 7:52 PM, Albert Kurucz wrote: Jason and Brian, thanks for the explanations. Understood, the policy of not removing anything from Maven Central serves a purpose. I wish there would be another publicly Maven repository, which is maintained with rules enforced. This repo could even have a rule (additional to the old and unenforced rules) that only Maven built projects can enter, maybe even more restriction: only the designated Continuous Integration server can upload to it. What matters is a plan to improve the metadata and this can be done over time. There can never be a big bang here, there is just too much content, and too many people relying on the content that's there. Projects that are deploying against oss.sonatype.org are subject to the procurement rules which are stringent. The artifacts are placed in a staging repository, rules are applied and if they all pass they get promoted otherwise they have to be corrected. No promotion unless all the rules pass. Only allowing Maven built projects doesn't make sense. All we need it the correct information. We honestly don't care if people build with Maven or not. We just need a high-quality POM, correct metadata, javadocs, sources, and signatures. This pure Maven repo would not be able to compete with Maven Central regarding size or the number of artifacts, but some OSS developers might prefer to use from and supply to this one instead of the big and ugly. This isn't really going to change or help anything. The existing content cannot change, the content going forward needs to be improved and that's what matters. Over time as the content improves the poorer quality submissions will just fall into disuse. Nexus can now help any project that wants to deploy high quality artifacts via oss.sonatype.org. The next step for us is allowing bundle submissions that are normally pushed into JIRA to be also submitted into a staging repository and run through the same set of rules. This will be available in Nexus 1.4. The last gap to fill will be repositories that directly sync and we'll provide a mechanism for that in Nexus as well. Ultimately we will build up these rules and if you don't pass them, by whatever gate you pass through, then your artifacts get rejected. We'll provide this in an easy to use form with Nexus but ultimately it doesn't matter how these rules are enforced as long as they are enforced. This is the only strategy that will work long-term. What's done has been done. What matters now helping projects do the right thing going forward. On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox bri...@infinity.nu wrote: On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz albert.kur...@gmail.com wrote: Requirements for the POMs are defined as: http://maven.apache.org/guides/mini/guide-central-repository-upload.html I call the artifact corrupt (regarding Maven Central Compliance) if the POM of the artifact does not fulfills the above requirements. There are corrupt ones have made it to the Central, because the guard was sleeping. Correct, but changing them is not an option because it will destabilize builds. This is a long standing rule that we do not remove or change the contents of central. - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven
Re: Maven Central Repository - Cleanup Efforts
The pure Maven repo should say: We honestly don't care which Maven plugin the people build with, as long as that plugin is already checked into here. And why people would prefer to use libraries from the pure Maven repo? Quality. Being build-able has always been the target of OSS developments. Finally this could be achieved. (OK it won't come to Maven Central) Anyone care about having Maven Pure? On Fri, Sep 25, 2009 at 8:36 AM, Albert Kurucz albert.kur...@gmail.com wrote: We just need a high-quality POM, correct metadata, javadocs, sources, and signatures. It is debatable is what you mean on high quality. For me (totally a Maven fan!) what makes the POM high quality? Its ability to build the project! I don't really care if it is full of maven-antrun-plugin, but build it by running mvn ... For some developers high quality really just means that the metadata is correct. Because of this opposition having two separate OSS repos (serving different needs?) makes sense. What is the right thing to do going forward? One question is whether to care about build ability or not! On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl jvan...@sonatype.com wrote: On 2009-09-24, at 7:52 PM, Albert Kurucz wrote: Jason and Brian, thanks for the explanations. Understood, the policy of not removing anything from Maven Central serves a purpose. I wish there would be another publicly Maven repository, which is maintained with rules enforced. This repo could even have a rule (additional to the old and unenforced rules) that only Maven built projects can enter, maybe even more restriction: only the designated Continuous Integration server can upload to it. What matters is a plan to improve the metadata and this can be done over time. There can never be a big bang here, there is just too much content, and too many people relying on the content that's there. Projects that are deploying against oss.sonatype.org are subject to the procurement rules which are stringent. The artifacts are placed in a staging repository, rules are applied and if they all pass they get promoted otherwise they have to be corrected. No promotion unless all the rules pass. Only allowing Maven built projects doesn't make sense. All we need it the correct information. We honestly don't care if people build with Maven or not. We just need a high-quality POM, correct metadata, javadocs, sources, and signatures. This pure Maven repo would not be able to compete with Maven Central regarding size or the number of artifacts, but some OSS developers might prefer to use from and supply to this one instead of the big and ugly. This isn't really going to change or help anything. The existing content cannot change, the content going forward needs to be improved and that's what matters. Over time as the content improves the poorer quality submissions will just fall into disuse. Nexus can now help any project that wants to deploy high quality artifacts via oss.sonatype.org. The next step for us is allowing bundle submissions that are normally pushed into JIRA to be also submitted into a staging repository and run through the same set of rules. This will be available in Nexus 1.4. The last gap to fill will be repositories that directly sync and we'll provide a mechanism for that in Nexus as well. Ultimately we will build up these rules and if you don't pass them, by whatever gate you pass through, then your artifacts get rejected. We'll provide this in an easy to use form with Nexus but ultimately it doesn't matter how these rules are enforced as long as they are enforced. This is the only strategy that will work long-term. What's done has been done. What matters now helping projects do the right thing going forward. On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox bri...@infinity.nu wrote: On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz albert.kur...@gmail.com wrote: Requirements for the POMs are defined as: http://maven.apache.org/guides/mini/guide-central-repository-upload.html I call the artifact corrupt (regarding Maven Central Compliance) if the POM of the artifact does not fulfills the above requirements. There are corrupt ones have made it to the Central, because the guard was sleeping. Correct, but changing them is not an option because it will destabilize builds. This is a long standing rule that we do not remove or change the contents of central. - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl
Re: Maven Central Repository - Cleanup Efforts
2009/9/25 Albert Kurucz albert.kur...@gmail.com: The pure Maven repo should say: We honestly don't care which Maven plugin the people build with, as long as that plugin is already checked into here. And why people would prefer to use libraries from the pure Maven repo? Quality. Being build-able has always been the target of OSS developments. Finally this could be achieved. (OK it won't come to Maven Central) Anyone care about having Maven Pure? Not me. Central is good enough if we add deprecation metadata, version comparison metadata, and if we fix a few small issues with the pom xsd. On Fri, Sep 25, 2009 at 8:36 AM, Albert Kurucz albert.kur...@gmail.com wrote: We just need a high-quality POM, correct metadata, javadocs, sources, and signatures. It is debatable is what you mean on high quality. For me (totally a Maven fan!) what makes the POM high quality? Its ability to build the project! I don't really care if it is full of maven-antrun-plugin, but build it by running mvn ... For some developers high quality really just means that the metadata is correct. Because of this opposition having two separate OSS repos (serving different needs?) makes sense. What is the right thing to do going forward? One question is whether to care about build ability or not! On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl jvan...@sonatype.com wrote: On 2009-09-24, at 7:52 PM, Albert Kurucz wrote: Jason and Brian, thanks for the explanations. Understood, the policy of not removing anything from Maven Central serves a purpose. I wish there would be another publicly Maven repository, which is maintained with rules enforced. This repo could even have a rule (additional to the old and unenforced rules) that only Maven built projects can enter, maybe even more restriction: only the designated Continuous Integration server can upload to it. What matters is a plan to improve the metadata and this can be done over time. There can never be a big bang here, there is just too much content, and too many people relying on the content that's there. Projects that are deploying against oss.sonatype.org are subject to the procurement rules which are stringent. The artifacts are placed in a staging repository, rules are applied and if they all pass they get promoted otherwise they have to be corrected. No promotion unless all the rules pass. Only allowing Maven built projects doesn't make sense. All we need it the correct information. We honestly don't care if people build with Maven or not. We just need a high-quality POM, correct metadata, javadocs, sources, and signatures. This pure Maven repo would not be able to compete with Maven Central regarding size or the number of artifacts, but some OSS developers might prefer to use from and supply to this one instead of the big and ugly. This isn't really going to change or help anything. The existing content cannot change, the content going forward needs to be improved and that's what matters. Over time as the content improves the poorer quality submissions will just fall into disuse. Nexus can now help any project that wants to deploy high quality artifacts via oss.sonatype.org. The next step for us is allowing bundle submissions that are normally pushed into JIRA to be also submitted into a staging repository and run through the same set of rules. This will be available in Nexus 1.4. The last gap to fill will be repositories that directly sync and we'll provide a mechanism for that in Nexus as well. Ultimately we will build up these rules and if you don't pass them, by whatever gate you pass through, then your artifacts get rejected. We'll provide this in an easy to use form with Nexus but ultimately it doesn't matter how these rules are enforced as long as they are enforced. This is the only strategy that will work long-term. What's done has been done. What matters now helping projects do the right thing going forward. On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox bri...@infinity.nu wrote: On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz albert.kur...@gmail.com wrote: Requirements for the POMs are defined as: http://maven.apache.org/guides/mini/guide-central-repository-upload.html I call the artifact corrupt (regarding Maven Central Compliance) if the POM of the artifact does not fulfills the above requirements. There are corrupt ones have made it to the Central, because the guard was sleeping. Correct, but changing them is not an option because it will destabilize builds. This is a long standing rule that we do not remove or change the contents of central. - 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
Re: Maven Central Repository - Cleanup Efforts
Le vendredi 25 septembre 2009, Stephen Connolly a écrit : For me, High quality is that: /project/(?parent/)(groupId|artifactId|version) are valid and do not reference properties /project/dependencies is valid and if there are any properties defined they are defined within the pom or it's parents /project/name /project/description /project/url +1 Bonus high quality is when it has /project/scm /project/issueTracking /project/developers /project/contributors +1 and if it is a project that builds using Maven 2 -1 on this one you can build your artifact the way you like, this doesn't change anything on the quality of the artifact itself and of its metadata = what counts for an artifact repository building with Maven, Ant+Maven Ant Tasks, or Ant + Ivy, Buildr, or any other tool doesn't change anything Hervé -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Le vendredi 25 septembre 2009, Stephen Connolly a écrit : 2009/9/25 Albert Kurucz albert.kur...@gmail.com: The pure Maven repo should say: We honestly don't care which Maven plugin the people build with, as long as that plugin is already checked into here. And why people would prefer to use libraries from the pure Maven repo? Quality. Being build-able has always been the target of OSS developments. Finally this could be achieved. (OK it won't come to Maven Central) Anyone care about having Maven Pure? Not me. Central is good enough if we add deprecation metadata, +1 version comparison metadata, -0: need to discuss more on this IMHO (on the dev list probably) and if we fix a few small issues with the pom xsd. need eplanations on this one Hervé - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
On Fri September 25 2009 12:07:09 pm Stephen Connolly wrote: For me, High quality is that: /project/(?parent/)(groupId|artifactId|version) are valid and do not reference properties /project/dependencies is valid and if there are any properties defined they are defined within the pom or it's parents /project/name /project/description /project/url And I would add: /project/licenses as that's very important to know if I can use the artifact or not. Bonus high quality is when it has /project/scm /project/issueTracking /project/developers /project/contributors I would add /project/organization here as well. Dan and if it is a project that builds using Maven 2 -Stephen -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
2009/9/25 Hervé BOUTEMY herve.bout...@free.fr: Le vendredi 25 septembre 2009, Stephen Connolly a écrit : For me, High quality is that: /project/(?parent/)(groupId|artifactId|version) are valid and do not reference properties /project/dependencies is valid and if there are any properties defined they are defined within the pom or it's parents /project/name /project/description /project/url +1 Bonus high quality is when it has /project/scm /project/issueTracking /project/developers /project/contributors +1 and if it is a project that builds using Maven 2 -1 on this one you can build your artifact the way you like, this doesn't change anything on the quality of the artifact itself and of its metadata = what counts for an artifact repository building with Maven, Ant+Maven Ant Tasks, or Ant + Ivy, Buildr, or any other tool doesn't change anything No the tool does not change anything... but it's a bonus if it's built with maven ;-) Hervé -Stephen - 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 Central Repository - Cleanup Efforts
2009/9/25 Hervé BOUTEMY herve.bout...@free.fr: Le vendredi 25 septembre 2009, Stephen Connolly a écrit : 2009/9/25 Albert Kurucz albert.kur...@gmail.com: The pure Maven repo should say: We honestly don't care which Maven plugin the people build with, as long as that plugin is already checked into here. And why people would prefer to use libraries from the pure Maven repo? Quality. Being build-able has always been the target of OSS developments. Finally this could be achieved. (OK it won't come to Maven Central) Anyone care about having Maven Pure? Not me. Central is good enough if we add deprecation metadata, +1 version comparison metadata, -0: need to discuss more on this IMHO (on the dev list probably) +1 to discussing more. I'll start a thread with my thoughts next week and if we fix a few small issues with the pom xsd. need eplanations on this one Hervé - 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: Can not use the plexus component org.sonatype.plexus.components.sec.dispatcher.SecDispatcher since maven 2.2.0
Le Fri, 25 Sep 2009 15:17:04 +0200,
Tony Chemit che...@codelutin.com a écrit :
Hi,
Since maven 2.1.0, I use in a mojo the
org.sonatype.plexus.components.sec.dispatcher.SecDispatcher
from the artifact org.sonatype.plexus:plexus-sec-dispatcher:1.3.1
to decrypt password in my settings.xml
I recently change to maven 2.2.1, but my mojo does not anylonger works fine
(same result with 2.2.0) :
Caused by: org.codehaus.plexus.component.composition.CompositionException:
Composition failed of field sec in object of type
org.nuiton.mail.plugin.SendEmailMojo because the requirement
ComponentRequirement{role='org.sonatype.plexus.components.sec.dispatcher.SecDispatcher',
roleHint='default', fieldName='sec'} was missing at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:154)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29)
...
26 more Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Unable to lookup component
'org.sonatype.plexus.components.sec.dispatcher.SecDispatcherdefault', it
could not be started at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:339)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129)
...
30 more Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLifecycleException:
Error starting component at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:109)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331)
...
31 more Caused by:
org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionException:
Error composing component at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105)
...
34 more Caused by:
org.codehaus.plexus.component.composition.CompositionException: Composition
failed for the field _cipher in object of type
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:144)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29)
...
36 more Caused by: java.lang.IllegalArgumentException: Can not set
org.sonatype.plexus.components.cipher.PlexusCipher field
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher._cipher to
org.sonatype.plexus.components.cipher.DefaultPlexusCipher at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
at java.lang.reflect.Field.set(Field.java:657) at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:137)
...
40 more
I read in the release note of maven 2.2.0 that something has changed for
these plexus component, but can't find what ?
What is the catch ? Does I miss something when upgrading to maven 2.2.X ?
Thanks for your replies.
Juts for try, I forked the two classes in my plugin :
DefaultPlexusCipher
DefaultSecDispatcher
and then it works :)
Is anybody can explain my why ? I really don't understand this behaviour of
plexus...
--
Tony Chemit
tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com
Re: Eclipse as a dependency
there are some jars already there from an attempt long time ago to have eclipse in the repository, under org.eclipse On Fri, Sep 25, 2009 at 2:00 AM, Emmanuel Hugonnet ehsavoi...@gmail.com wrote: Hi, I have created a small Maven plugin which uses the Eclipse code formatter to format my code. I would like to release it but the available librairies of Eclipse are quite old and I don't want my users to have Eclipse installed (that's the whole point of the plugin). Is there a repository with Eclipse jars somewhere ? I think that m2eclipse/tycho should be using them but I can't seem to find the jars. What's the policy concerning these jars ? Thans, Emmanuel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Error during deploy in private repository
Brian Fox-3 wrote: In theory this would be possible, but the paths probably need to be rooted in the same location. I think it can not be a path problem. When I change the url of the distributionManagement to file:///home/thomas/test-repo It all works. The maven-metadata is created. As soon as I switch to sftp://... the deploy stops with the exception, that the maven-metadata.xml can not be received (which is right, as it does not exists, yet). The url is the only path I change, so I rule out a pathing issue. But, why maven skips the missing of the metadata when the deploy url is local but stops when the url is remote? Is there a bug in tssh wagon? I found http://maven.apache.org/wagon/wagon-providers/wagon-ssh/ Getting files from SSH servers is not fully tested. Brian Fox-3 wrote: When Maven goes to deploy, it uses the same channel to retrieve the metadata files that need to be updated. It seems like your system is interfering with this process. It seems that it can skip the missing of the metadata when deploying local but stops, when deploying remote. Thankls for any help. Cheers, Thomas -- View this message in context: http://n2.nabble.com/Error-during-deploy-in-private-repository-tp3687411p3714504.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 Central Repository - Cleanup Efforts
Technically it is possible to manage 3 different OSS Maven repos. 1. The good enough This is the current Maven Central No rules, only recommendations: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Note: it is not a rule what is not enforced! 2. The good This would be the Maven Purgatory. Same rules applied as above, but rules enforced. Mistakes of rule-enforcements corrected by purge. 3. The best Call it the Maven Heaven Same rules, but only for Maven built projects. Good dream, friends! On Fri, Sep 25, 2009 at 12:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/9/25 Hervé BOUTEMY herve.bout...@free.fr: Le vendredi 25 septembre 2009, Stephen Connolly a écrit : 2009/9/25 Albert Kurucz albert.kur...@gmail.com: The pure Maven repo should say: We honestly don't care which Maven plugin the people build with, as long as that plugin is already checked into here. And why people would prefer to use libraries from the pure Maven repo? Quality. Being build-able has always been the target of OSS developments. Finally this could be achieved. (OK it won't come to Maven Central) Anyone care about having Maven Pure? Not me. Central is good enough if we add deprecation metadata, +1 version comparison metadata, -0: need to discuss more on this IMHO (on the dev list probably) +1 to discussing more. I'll start a thread with my thoughts next week and if we fix a few small issues with the pom xsd. need eplanations on this one Hervé - 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: Profile activation based on JDK, how it works?
Hi Jan, Jan wrote: Hi All, I was just wondering about the following situation I'm using maven 2.2.1 which requires jdk 1.5 to run, but my modules will compile only with 1.4, so i used the 1.4 executable in my compiler plugin. In this case if i create profile with the activation rule for jdk1.4/jdk when this profile will get activated? Any one had this situation the profile is activated on the JDK version that is used running Maven. The profile is evaluated at very early stage, since it defines the effective (=resulting) POM that is used for your build. However, you should really know, what you do within this profile. It is e.g. a bad idea to manage a different set of dependencies in profiles based on the JDK version for artifacts although this seems a good example at first glance. Especially in your cases where you try to build using a different compiler version (or even build for a different JDK target), such dependencies might give you a surprise. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Multi-module build/dependency behavior?
When performing [clean] install on multi-module projects, where is maven supposed to look for (child) dependencies? Does it look in target/classes or does it look at the jar previously installed in the local repo? We have two systems where one seems to be looking in the local repo for all dependencies and one looking in target/classes. I thought maven always used the local repo only but is this configurable? How is this supposed to work? -Dave
Re: Maven Central Repository - Cleanup Efforts
On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz albert.kur...@gmail.com wrote: Technically it is possible to manage 3 different OSS Maven repos. 1. The good enough This is the current Maven Central No rules, only recommendations: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Note: it is not a rule what is not enforced! For what purpose? Again this is effectively a dead repo. 2. The good This would be the Maven Purgatory. Same rules applied as above, but rules enforced. Mistakes of rule-enforcements corrected by purge. Or this is the new data in Central. 3. The best Call it the Maven Heaven Same rules, but only for Maven built projects. Pretty much useless. The tool used to build is completely irrelevant. Such a repo would be so barren as to be hardly useful at all. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
For the additional requirement, getting into the pure Maven repo (The best), I really meant: build-able. Me too, I don't really care what tool you use to build it as long as the tool is already checked in and you only use the attached metadata and the attached sources. But a tool like this, in my eyes is just another Maven plugin. Why care about being build-able? Non-buildable source is fine as a gesture of goodwill, but I think if the public source isn't buildable, we're gonna end up with egg on our faces. Quote from: http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002170.html On Fri, Sep 25, 2009 at 4:31 PM, Brian Fox bri...@infinity.nu wrote: On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz albert.kur...@gmail.com wrote: Technically it is possible to manage 3 different OSS Maven repos. 1. The good enough This is the current Maven Central No rules, only recommendations: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Note: it is not a rule what is not enforced! For what purpose? Again this is effectively a dead repo. 2. The good This would be the Maven Purgatory. Same rules applied as above, but rules enforced. Mistakes of rule-enforcements corrected by purge. Or this is the new data in Central. 3. The best Call it the Maven Heaven Same rules, but only for Maven built projects. Pretty much useless. The tool used to build is completely irrelevant. Such a repo would be so barren as to be hardly useful at all. - 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
