Problem occured Checking out Maven projects
Hi all, I recently installed Maven by following the steps given in this link: http://docs.codehaus.org/display/M2ECLIPSE/Demo+Script I got an error after, I had to modify the eclipse.ini by adding the -vm argument. Now my eclipse is running on JDK, so no problem there. When I try File- New - Other - Checkout Maven Projects from SVN I get an error: Problem Occurred: Checking out Maven projects (time of error: 1 April 2008 11:23:09 BST) Reason: Check the details The details say: Checkout error, so no help here... I am using Eclipse Europa, Windows XP, JDK 5.0, latest versions of subclipse, mylyn and maven. Thanks in advance, Oana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Third Party Jar
Hi, Thanks for the suggestion. I have tried this and it seems to lack some features that I really need in my plugin. So appearently I will need to write my own plugin. However, I analyzed some of the code in this plugin and it doesn't seem to do a lot more different stuff that I am doing, since the standard transformation API is used. The only difference seems to be that the xml-maven-plugin is run at build time, while mine is run at report time (in the reporting section). Could this be a cause why the transformer is not loaded? Thanks On Fri, Mar 28, 2008 at 5:29 PM, Wayne Fay [EMAIL PROTECTED] wrote: There is already an XML plugin in Codehaus which has XSLT functionality. Why don't you just take a look at it before moving too far down this path of possibly re-implementing an existing solution? http://mojo.codehaus.org/xml-maven-plugin/ Wayne On 3/28/08, Cosmin Marginean [EMAIL PROTECTED] wrote: It seems that this goes deeper. What I actually need to do is create a Maven plugin that performs an XSL transformation using Saxon 9. I unpacked the Saxon 9 jar and added the classes to my plugin jar to make sure the transformer is loaded. However, it seems that the transformer won't get loaded, even when I run Maven with - Djava.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl Some people seem to have worked around this by specifying the Saxon dependency in the client pom.xml but this doesn't seem to work if I make the transformation call from the plugin Jar. I even set the property manually in the plugin: TransformerFactory factory = TransformerFactory.newInstance(); But without any luck. The transformer will not be found Thanks in advance On Fri, Mar 28, 2008 at 9:04 AM, Cosmin Marginean [EMAIL PROTECTED] wrote: Hello guys, Sorry to bother you with such issues, but I've googling my brains out with this without any relevant results. I have a question regarding bundling a 3rd party jar in a Maven Plugin. I am a bit new to Maven and Maven plugins. I tried bundling it in the plugin jar and adding it to the Class-Path attribute of MANIFEST.MF, but it seems to be ignored when using the plugin. Another question would be: assuming that somehow this 3rd party jar will make it into a public repository, what is the proper way to configure the dependency to make sure that the client (plugin user) will download and load this jar correctly without having to configure 3rd third party dependency in the pom.xml? Many thanks in advance -- Cosmin Marginean -- Cosmin Marginean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cosmin Marginean
HELP war:inplace eats up all my files' content! :-(
Hi, I've got the following problem: when I call mvn war:inplace, the goal fails: [INFO] [war:inplace] [INFO] Generating webapp in source directory[MY_war_source_directory] [INFO] Assembling webapp[webclient] in [MY_war_source_directory] [INFO] Processing war project [INFO] Copy webapp webResources[MYSOURCE_DIRECTORY/src/conf] to[MY_war_source_directory] [INFO] Copy webapp webResources[MYSOURCE_DIRECTORY/src/conf] to[MY_war_source_directory] [INFO] Copy webapp webResources[MY_war_source_directory] to[MY_war_source_directory] [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] The specified web.xml file 'MYSOURCE_DIRECTORY\target\jspweb.xml' does not exist And after this ALL files in my war folder still exist, but with zero content - all has been erased. Really weird behavior - do you have any idea how to prevent this from happening? I don't really would need the goal, I just don't want any developer to call it and to empty all files that might not have been checked in before hand... Thanks in advance, Stefanie -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exclude module from deploy phase
You could set an altDeploymentRepository for this specific project, and let it point to a dummy local location. On Mon, Mar 31, 2008 at 9:18 PM, Andrew Uhm [EMAIL PROTECTED] wrote: Hello, Is it possible to configure a module to be excluded from the mvn deploy phase? For instance, in a single project I have 3 modules: Domain Repository Web My domain and repository modules are dependencies to other projects, but the web module is not. The web module tends to be rather large (80-90M) as it contains all dependent jars and a grip of images, and so my site maven repository is growing at an alarming rate. My project parent pom file: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; xs i:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent groupIdcom.mycomp.commons/groupId artifactIdComp-commons-parent/artifactId version1.6.0-SNAPSHOT/version /parent properties commons.parent.version1.6.0-SNAPSHOT/commons.parent.version search.version1.10.0-SNAPSHOT/search.version combine.version1.12.0-SNAPSHOT/combine.version /properties groupIdcom.mycomp.site/groupId artifactIdComp-site-parent/artifactId version1.13.0-SNAPSHOT/version packagingpom/packaging nameSite Parent Project Model/name scm connectionscm:svn: http://testtools02.la3.mycomp.com/svn/repos/site/trunk/connection developerConnectionscm:svn: http://testtools02.la3.mycomp.com/svn/repos/site/trunk/developerConnection urlhttp://testtools02.la3.mycomp.com/fisheye/browse/site/url /scm modules moduleComp-site-domain/module moduleComp-site-repository/module moduleComp-site-web/module moduleComp-site-integration-tests/module moduleComp-site-acceptance-tests/module /modules . /project I appreciate your help, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: release : Unable to check for local modifications
What's the output of svn --non-interactive status when you do it manually? I once had a problem because of the internationalization of the messages. In my case, the svn messages were displayed in french. The calling code (was maven-buidnumber-plugin now that I think of it) was trying to parse the svn output. But as the code was written only for english output, it didn't work. The way I did: I deleted the i18n properties files from the local svn installation, then it worked fine. Cheers. -Message d'origine- De : Oscar Picasso [mailto:[EMAIL PROTECTED] Envoyé : lundi 31 mars 2008 21:19 À : Maven Users List Objet : release : Unable to check for local modifications Hi, When I do a release:prepare I get an Unable to check for local modifications (see below). From the logs it seems the problem come when maven tries to execute svn --non-interactive status. However if I execute svn --non-interactive status, it works fine. Any idea ? Thanks == === [INFO] [release:prepare] [INFO] Resuming release from phase 'scm-check-modifications' [INFO] Verifying that there are no local modifications... [INFO] Executing: svn --non-interactive status [INFO] Working directory: C:\mycomp\workspace\my-app [INFO] -- -- [ERROR] BUILD FAILURE [INFO] -- -- [INFO] Unable to check for local modifications Provider message: The svn command failed. Command output: [INFO] -- -- [INFO] Trace org.apache.maven.BuildFailureException: Unable to check for local modifications Provider message: The svn command failed. Command output: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:560) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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.MojoFailureException: Unable to check for loc al modifications Provider message: The svn command failed. Command output: at org.apache.maven.plugins.release.PrepareReleaseMojo.execute (PrepareRe leaseMojo.java:144) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:539) ... 16 more [INFO] -- -- [INFO] Total time: 23 seconds [INFO] Finished at: Mon Mar 31 13:31:51 EDT 2008 [INFO] Final Memory: 31M/57M [INFO] - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
how to include Sun JAXWS2.1.1 in Maven?
Hi, I need to include the jars provided by Sun's JAXWS2.1.1( https://jax-ws.dev.java.net/servlets/ProjectDocumentList?expandFolder=5468folderID=6020 ) What´s recommended to do this instead of deploying the jars with a selfmade groupId, artifactId and version? (See http://mohanrajk.wordpress.com/2006/12/03/maven-2-jax-ws-ri-and-tomcat-deploy-part-i/ ) How can I avoid having the same jar in my classpath, with different group- and artifact/version Id´s, if I have other dependencies? For example, the jaxb-api.jar is also provided by Suns JAXB2 bundle Is there an official Sun Repo out there? What are the recommended group/artifact/version Ids for the jars contained in the bundle? Thanx, Torsten
Problems settings up
I'm having some problems getting Archiva to work and just wondered if I'm missing anything. I'm using 1.0.1 standalone. I followed the install guide but I think there is an error when it says to move the conf and data directories. I had to move the conf directory back otherwise it wasn't being picked up even with PLEXUS_BASE being set. Now that the UI is running I can see that the data, logs and temp directories are all being used so PLEXUS_BASE seems to be working for that. I've now changed the Maven setting.xml as suggested to proxy all requests and Maven is using the new mirror setting but Archiva show no traffic in the logs and nothing is downloaded. I've searched the mail lists and found some threads which suggest that the mirror id needs proxy in it but that no effect and the thread was old. I've found another thread that says to change the guest account to be an observer which I've done but it had no effect and also no entries in the log. Archiva is obviously working for lots of users so I must be missing something. It's as if there is a big chunk of documentation missing. Any ideas? Eric.
RE: Class files not generated when compiler argument sourcepath is used
Hi Simon,
Thanks for the input, I was afraid someone was going to say
something along those lines. Over the past few weeks I've realized how
flexible ant is compared to maven and how much my predecessors took
advantage of those flexibilities, which makes my job harder. Everyone
here really wants to switch over to maven though so I'll have to figure
out a way to restructure the code, which is probably the best option.
Thanks for the advice,
Jarod
-Original Message-
From: simon [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2008 5:32 PM
To: Maven Users List
Subject: Re: Class files not generated when compiler argument sourcepath
isused
Hi Jarod,
I can't offer any specific advice on the -sourcepath issue. However you
should be aware of something about Maven: Maven is NOT as flexible as
ant. And that is deliberate.
Ant is pretty much a Turing-complete programming language that can do
anything. But the disadvantage is that because it can do anything,
people make it do some very weird and unmaintainable things. Your
current setup sounds like it might well fall into that category.
It is precisely because Maven does *not* support every weird setup that
its builds remain more maintainable and comprehensible.
So if you are moving to Maven, you might find that you are forced to
clean up your project structures before Maven will work for you. Maven
is somewhat tweakable but if you don't want to follow its approach at
all, then it is better to stay with Ant (maybe using the maven ant tasks
for dependency resolution, or using ant+ivy).
This thing about compiling other module's code for them sounds really
un-mavenish. How on earth are you going to properly define the module's
dependencies when that is going on?
Regards,
Simon
On Mon, 2008-03-31 at 17:19 -0400, Jarod Rose wrote:
Hello,
I'm in the middle of a project to convert a bunch of ant build scripts
over to maven 2. The section that I'm working with right now is
fairly large (approx. 2600 java files) and the ant scripts take these
files and generates multiple jars from the files. Unfortunately,
these jars are so dependent on each other that the ant scripts use the
-sourcepath parameter for javac to compile each jar's classes
correctly. From what I can tell there is no built in way to do this
in maven, besides specifying sourcepath in the compilerArguments for
the maven-compiler-plugin. I've tried that and tried adding the
sourcepath argument and it seemed to work, as in maven went through
the motions of compiling the files (taking plenty of time doing it).
However, when it finished ../target/classes was empty as well as the
jar file. I created a dummy project to try and simulate my issue with
a smaller file set but everything worked properly and classes were
generated. I also tried to just compile all 2600 files without using
-sourcepath, which also worked. My only guess is that it has to do
with the combination of the large amount of files and the use of
-sourcepath, but I'm not sure.
Any input would be appreciated. Below is the build section of the pom
I'm using, along with the related debug output from maven. (I cut some
out for length's sake.)
Thanks,
Jarod
Maven version: 2.0.8
Java version: 1.6.0_04
OS name: windows xp version: 5.1 arch: x86 Family: windows
---The Pom File---
...
build
defaultGoalinstall/defaultGoal
sourceDirectory../src/com/nwms/emr/client/sourceDirectory
!--testSourceDirectory../unittest/src/testSourceDirectory--
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
compilerArguments
sourcepath../src/sourcepath
/compilerArguments
source1.5/source
target1.5/target
forktrue/fork
excludes
excludegeneric/**/exclude
/excludes
/configuration
/plugin
/plugins
/build
...
---End Pom---
---Maven Output---
...
Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' --
[DEBUG] (f) basedir =
C:\.hudson\jobs\mvnEHR\workspace\trunk\Core\EMR\nwemrClient
[DEBUG] (f) buildDirectory =
C:\.hudson\jobs\mvnEHR\workspace\trunk\Core\EMR\nwemrClient\target
[DEBUG] (f) classpathElements = (lots of classes)
[DEBUG] (f) compileSourceRoots =
[C:\.hudson\jobs\mvnEHR\workspace\trunk\Core\EMR\nwemrClient\..\src\co
m\
nwms\emr\client]
[DEBUG] (f) compilerArguments = {sourcepath=../src}
[DEBUG] (f) compilerId = javac
[DEBUG] (f) debug = true
[DEBUG] (f) excludes = [generic/**]
[DEBUG] (f) failOnError = true
[DEBUG] (f) fork = true
[DEBUG] (f) optimize = false
[DEBUG] (f) outputDirectory =
C:\.hudson\jobs\mvnEHR\workspace\trunk\Core\EMR\nwemrClient\target\cla
ss
es
[DEBUG] (f) outputFileName = nwemr-client-core-6.1-SNAPSHOT
Re: antrun plugin - GWT - add the source directory to the classpath
Hi Nicolas,
We're already using the gwt-maven-plugin (perhaps the issue your talking
about is a classpath too long problem, comming from my colleague ;-)).
But an important improvement for us would be a plugin launching the GWT
compilation only if there are changes in java source code. Is it planed ? Do
I have to make this suggestion somewhere ?
Kind regards,
Bernard
nicolas de loof-3 wrote:
Can I suggest you to test the Mojo-sandbox gwt-maven-plugin ?
I just upgrade it to fix GWTCompiler issue, and it now comes with a DTO
generator from JPA entities.
Some dependencies are not yet available in central, but the MAVENUPLOAD
request is created for them.
Nicolas.
2008/3/31, Bernard Lupin [EMAIL PROTECTED]:
Hi all,
Using the antrun plugin, I'm trying to call an ant task which is
launching
the GWT compiler. This ant task is based on the Joachim work at
http://braindump.dk/tech/gwt-task-for-ant/.
Something specific with GWT is that you must include the java source
directory in your classpath before calling the compiler. Unfortunatelly,
I
can add all the needed jars in my classpath (gwt-user.jar,
gwt-dev-windows.jar, my ant-compile.jar ) using dependencies, but I don't
know how to add my source directory.
I tried to build an ant reference classpath with the
maven.plugin.classpath
reference and the ${project.build.sourceDirectory} variable, but in all
cases my java task tells me Unable to find
'com/company/gwt/MyModule.gwt.xml'.
I also tried to put all my java source files inside a jar and add the
corresponding dependency, in that case the GWT compilation works ! (but
it
can't be a workarround, you agree ?).
So my question is : Does Maven provide a solution to add a directory to
the
maven.plugin.classpath ?
Below is my pom.xml
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
groupIdcom.company.exemple/groupId
artifactIdgwt-maven/artifactId
packagingwar/packaging
nameGWT Maven example/name
version1.0-SNAPSHOT/version
urlhttp://maven.apache.org/url
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdcom.google.gwt/groupId
artifactIdgwt-dev-windows/artifactId
version1.4.61/version
scopecompile/scope
/dependency
dependency
groupIdcom.company.gwt/groupId
artifactIdant-compile/artifactId
version1.0-SNAPSHOT/version
scopecompile/scope
/dependency
/dependencies
executions
execution
phaseprocess-classes/phase
goals
goalrun/goal
/goals
configuration
tasks
property name=maven_source_directory
value=${project.build.sourceDirectory} /
echo message=source
directory: ${maven_source_directory}
/
property name=maven_plugin_classpath
refid=maven.plugin.classpath /
echo message=maven_plugin_classpath:
${maven_plugin_classpath} /
path id=my.classpath
pathelement path=${project.build.sourceDirectory} /
path refid=maven.plugin.classpath /
/path
taskdef name=gwtcompile
classname=com.francetelecom.clara.tool.gwt.GWTCompileTask
classpathref=my.classpath /
gwtcompile destdir=c:/tmp optimize=true
style=obfuscated
fileset dir=${maven_source_directory}
include name=**/*.gwt.xml /
/fileset
/gwtcompile
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
dependencies
!-- GWT Dependencies --
dependency
groupIdcom.google.gwt/groupId
artifactIdgwt-user/artifactId
version1.4.61/version
scopecompile/scope
/dependency
dependency
groupIdcom.google.gwt/groupId
artifactIdgwt-servlet/artifactId
version1.4.61/version
scoperuntime/scope
/dependency
!-- GUI Dependencies --
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.4/version
scopeprovided/scope
/dependency
dependency
groupIdjavax.servlet.jsp/groupId
artifactIdjsp-api/artifactId
version2.1/version
scopeprovided/scope
/dependency
/dependencies
/project
--
View this message in context:
Re: Problem occured Checking out Maven projects
Can you check out regular project from svn? Like File-Import-Check out projects from SVN 1. If you can't, then you might have problem with svn + eclipse. 2. If you can, then after check out, it will ask you to choose an appropriate Project type to create, you can specify Maven at that time. However, I am not big fan of m2eclipse, even when pom.xml exists, it still try to ask and create one for you. Stan On Tue, Apr 1, 2008 at 6:25 AM, Oana Ureche [EMAIL PROTECTED] wrote: Hi all, I recently installed Maven by following the steps given in this link: http://docs.codehaus.org/display/M2ECLIPSE/Demo+Script I got an error after, I had to modify the eclipse.ini by adding the -vm argument. Now my eclipse is running on JDK, so no problem there. When I try File- New - Other - Checkout Maven Projects from SVN I get an error: Problem Occurred: Checking out Maven projects (time of error: 1 April 2008 11:23:09 BST) Reason: Check the details The details say: Checkout error, so no help here... I am using Eclipse Europa, Windows XP, JDK 5.0, latest versions of subclipse, mylyn and maven. Thanks in advance, Oana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to force the check of the latest dependency jars?
Hi all, Assume project A depends on lib1.jar. When I build project A, first time it will go to get the latest lib1.jar. After that, it only tries so if last check was 1 day ago or more. Is there any way to force the build to check out latest lib1.jar? I saw mvn command line has an option --update-snapshots, and tried it. However, on screen, I don't see any hint that Maven try to connect to repository and pull the latest lib1.jar. Your help is highly appreciated! Stan
javax.xml.ws jaxws-api 2.1 in repo1.maven.org - missing dependencies
Hi, looking at https://jax-ws.dev.java.net/faq/index.html#maven Suns recommended repo https://maven-repository.dev.java.net/nonav/repository seems to have the complete dependencies list. The jaxws-api in repo1.maven.org is missing the dependencies dependency groupIdjavax.xml.soap/groupId artifactIdsaaj-api/artifactId version1.3/version /dependency dependency groupIdjavax.annotation/groupId artifactIdjsr250-api/artifactId version1.0/version /dependency dependency groupIdjavax.jws/groupId artifactIdjsr181-api/artifactId version1.0-MR1/version /dependency Will this pom be updated/deleted? Thanx, Torsten
Skip tests for installation phase
Hi,
I want to skip my tests for specific projects which contains integration
tests.. I have read alot on the web/forums/maillists etc and found that this
is sort of a de-fact way of doing this:
[pom.xml: contained in that separate which only contains these tests]=
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
skiptrue/skip
/configuration
executions
execution
idsurefire-it/id
phaseintegration-test/phase
goals
goaltest/goal
/goals
configuration
skipfalse/skip
/configuration
/execution
/executions
/plugin
/plugins
/build
The tests are skipped for most commands (compile, test, package etc) which
is good. But when i run mvn install, the tests are run. It seems as if
install matches my surefire-it executions, which was not my intention...
[INFO] Scanning for projects...
[INFO]
[INFO] Building X JAR
[INFO]task-segment: [integration-test]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] [surefire:test {execution: surefire-it}]
[INFO] Surefire report directory:
c:\myplace\dev\integrationtest\target\surefire-reports
---
T E S T S
---
Running xxx.xxx.AdminIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Tue Apr 01 16:30:10 CEST 2008
[INFO] Final Memory: 5M/11M
[INFO]
I only want it to be run if i run integration-test.. Have any one
encountered this before?
thanks and regards,
-Kristoffer
--
View this message in context:
http://www.nabble.com/Skip-tests-for-installation-phase-tp16418470s177p16418470.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: javax.xml.ws jaxws-api 2.1 in repo1.maven.org - missing dependencies
Umm... Don't use the 2.1 jar from central. It's broken and missing some files that are in the Sun 2.1 jar. Basically, Sun released 2.1 at one point and it was synced to central. Sun then withdrew that and released a new 2.1, but didn't change the version number or anything. However, central won't replace the jar. Instead, use 2.1-1 from central. If you use 2.1, you MAY get the correct version from java.net. OR you might get the broken version from central. If you specify 2.1-1, you'll always get the correct version. Dan On Tuesday 01 April 2008, [EMAIL PROTECTED] wrote: Hi, looking at https://jax-ws.dev.java.net/faq/index.html#maven Suns recommended repo https://maven-repository.dev.java.net/nonav/repository seems to have the complete dependencies list. The jaxws-api in repo1.maven.org is missing the dependencies dependency groupIdjavax.xml.soap/groupId artifactIdsaaj-api/artifactId version1.3/version /dependency dependency groupIdjavax.annotation/groupId artifactIdjsr250-api/artifactId version1.0/version /dependency dependency groupIdjavax.jws/groupId artifactIdjsr181-api/artifactId version1.0-MR1/version /dependency Will this pom be updated/deleted? Thanx, Torsten -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 2.0.9 Release Candidate
Having to do a formal vote and release is not agile enough, we'd be doing RCs for decades. Hopefully the users on the list are interested in quality and forward compatibility of their builds to grab the RC and give it a whirl. As I said, the quality is now a community effort and entirely dependent on the level of user interaction with the RCs. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Benedict Sent: Monday, March 31, 2008 11:58 PM To: Maven Users List Subject: Re: 2.0.9 Release Candidate Brian, I hope the release process can be refined to allow substantial usage of the RC builds by syncing with the central repo. Since Apache requires a release to have binding votes, you could publish them for a week or two and collect feedback rather than rapidly producing RC after RC. Maybe you want to use RC as a patch version or go one level further (2.0.8.1, etc.)? In any event, the downside of not publishing a build is that you can't call it a release and get the widespreader usage than the die-hard Maven watchers. Paul On Mon, Mar 31, 2008 at 4:25 PM, Brian E. Fox [EMAIL PROTECTED] wrote: In an attempt to raise quality and reduce/eliminate regressions in the core releases, we are experimenting with a new release process. The old process had a few informal staged builds followed by one or more official staged builds that where voted on. Clearly this didn't attract enough testing prior to the official release to identify regressions or other major issues. The new process we are using for the 2.0.9 release is to cut actual release candidate (RC-XXX) releases. These are released with the normal release process so it generates a tag, but do not get sync'd to central. We have gone through several RCs[1] as we tested on the dev@ list. The next step is to open it up to the user list for fix validation and regression identification. This is really the first time we've followed such a process so we'll have to see how it pans out. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javax.xml.ws jaxws-api 2.1 in repo1.maven.org - missing dependencies
What is the full URL for the java.net jars for 2.1-1 ? http://download.java.net/maven/2/javax/xml/ Does have 2.1-1 On Tue, Apr 1, 2008 at 7:46 AM, Daniel Kulp [EMAIL PROTECTED] wrote: Umm... Don't use the 2.1 jar from central. It's broken and missing some files that are in the Sun 2.1 jar. Basically, Sun released 2.1 at one point and it was synced to central. Sun then withdrew that and released a new 2.1, but didn't change the version number or anything. However, central won't replace the jar. Instead, use 2.1-1 from central. If you use 2.1, you MAY get the correct version from java.net. OR you might get the broken version from central. If you specify 2.1-1, you'll always get the correct version. Dan On Tuesday 01 April 2008, [EMAIL PROTECTED] wrote: Hi, looking at https://jax-ws.dev.java.net/faq/index.html#maven Suns recommended repo https://maven-repository.dev.java.net/nonav/repository seems to have the complete dependencies list. The jaxws-api in repo1.maven.org is missing the dependencies dependency groupIdjavax.xml.soap/groupId artifactIdsaaj-api/artifactId version1.3/version /dependency dependency groupIdjavax.annotation/groupId artifactIdjsr250-api/artifactId version1.0/version /dependency dependency groupIdjavax.jws/groupId artifactIdjsr181-api/artifactId version1.0-MR1/version /dependency Will this pom be updated/deleted? Thanx, Torsten -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Mick Knutson http://www.baselogic.com http://www.blincmagazine.com http://www.linkedin.com/in/mickknutson http://www.djmick.com http://www.myspace.com/mickknutson http://www.myspace.com/BLiNCMagazine http://tahoe.baselogic.com ---
Classpath for mojo
Can anyone tell me the best way to get the project classpath from with a plug-in including transitive dependencies? I've tried mavenProject.getCompileClasspath() but it doesn't seem to have the transitive deps Some problem with mavenProject.getDependencies() I think I need mavenProject.getArtifacts() but how do I resolve this to paths to the local repository? Am I missing something much simpler like a component or property I can just use?
Re: Third Party Jar
I have no clue without going into the code and looking at it, and I'm not doing that today. If you decide the codehaus plugin is close enough, feel free to modify it and submit your modifications for future incorporation into the plugin. Then everyone benefits from your changes. Wayne On 4/1/08, Cosmin Marginean [EMAIL PROTECTED] wrote: Hi, Thanks for the suggestion. I have tried this and it seems to lack some features that I really need in my plugin. So appearently I will need to write my own plugin. However, I analyzed some of the code in this plugin and it doesn't seem to do a lot more different stuff that I am doing, since the standard transformation API is used. The only difference seems to be that the xml-maven-plugin is run at build time, while mine is run at report time (in the reporting section). Could this be a cause why the transformer is not loaded? Thanks On Fri, Mar 28, 2008 at 5:29 PM, Wayne Fay [EMAIL PROTECTED] wrote: There is already an XML plugin in Codehaus which has XSLT functionality. Why don't you just take a look at it before moving too far down this path of possibly re-implementing an existing solution? http://mojo.codehaus.org/xml-maven-plugin/ Wayne On 3/28/08, Cosmin Marginean [EMAIL PROTECTED] wrote: It seems that this goes deeper. What I actually need to do is create a Maven plugin that performs an XSL transformation using Saxon 9. I unpacked the Saxon 9 jar and added the classes to my plugin jar to make sure the transformer is loaded. However, it seems that the transformer won't get loaded, even when I run Maven with - Djava.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl Some people seem to have worked around this by specifying the Saxon dependency in the client pom.xml but this doesn't seem to work if I make the transformation call from the plugin Jar. I even set the property manually in the plugin: TransformerFactory factory = TransformerFactory.newInstance(); But without any luck. The transformer will not be found Thanks in advance On Fri, Mar 28, 2008 at 9:04 AM, Cosmin Marginean [EMAIL PROTECTED] wrote: Hello guys, Sorry to bother you with such issues, but I've googling my brains out with this without any relevant results. I have a question regarding bundling a 3rd party jar in a Maven Plugin. I am a bit new to Maven and Maven plugins. I tried bundling it in the plugin jar and adding it to the Class-Path attribute of MANIFEST.MF, but it seems to be ignored when using the plugin. Another question would be: assuming that somehow this 3rd party jar will make it into a public repository, what is the proper way to configure the dependency to make sure that the client (plugin user) will download and load this jar correctly without having to configure 3rd third party dependency in the pom.xml? Many thanks in advance -- Cosmin Marginean -- Cosmin Marginean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cosmin Marginean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath for mojo
Take a look at http://svn.codehaus.org/mojo/trunk/sandbox/gwt-maven-plugin/src/main/java/org/codehaus/mojo/gwt/CompileMojo.java The addProjectClasspathElements method creates the set of URL to be used by an URLClassLoader. Nicolas. 2008/4/1, Timothy Reilly [EMAIL PROTECTED]: Can anyone tell me the best way to get the project classpath from with a plug-in including transitive dependencies? I've tried mavenProject.getCompileClasspath() but it doesn't seem to have the transitive deps Some problem with mavenProject.getDependencies() I think I need mavenProject.getArtifacts() but how do I resolve this to paths to the local repository? Am I missing something much simpler like a component or property I can just use?
Re: javax.xml.ws jaxws-api 2.1 in repo1.maven.org - missing dependencies
2.1-1 is at central: http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/ Dan On Tuesday 01 April 2008, Mick Knutson wrote: What is the full URL for the java.net jars for 2.1-1 ? http://download.java.net/maven/2/javax/xml/ Does have 2.1-1 On Tue, Apr 1, 2008 at 7:46 AM, Daniel Kulp [EMAIL PROTECTED] wrote: Umm... Don't use the 2.1 jar from central. It's broken and missing some files that are in the Sun 2.1 jar. Basically, Sun released 2.1 at one point and it was synced to central. Sun then withdrew that and released a new 2.1, but didn't change the version number or anything. However, central won't replace the jar. Instead, use 2.1-1 from central. If you use 2.1, you MAY get the correct version from java.net. OR you might get the broken version from central. If you specify 2.1-1, you'll always get the correct version. Dan On Tuesday 01 April 2008, [EMAIL PROTECTED] wrote: Hi, looking at https://jax-ws.dev.java.net/faq/index.html#maven Suns recommended repo https://maven-repository.dev.java.net/nonav/repository seems to have the complete dependencies list. The jaxws-api in repo1.maven.org is missing the dependencies dependency groupIdjavax.xml.soap/groupId artifactIdsaaj-api/artifactId version1.3/version /dependency dependency groupIdjavax.annotation/groupId artifactIdjsr250-api/artifactId version1.0/version /dependency dependency groupIdjavax.jws/groupId artifactIdjsr181-api/artifactId version1.0-MR1/version /dependency Will this pom be updated/deleted? Thanx, Torsten -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Third Party Jar
I see. However, i don't think the codehaus plugin is close enough nor would be usefull to update it with my needs. This is a very specific plugin and should not be used as a general purpose XSL translator. Anyways, in case you ever get the time to take a look: 1. the plugin's pom.xml: http://testng-xslt.googlecode.com/svn/trunk/pom.xml 2. the actual report Mojo: http://testng-xslt.googlecode.com/svn/trunk/src/main/java/org/testng/xslt/mavenplugin/TestNgXsltMojo.java (You can ignore the boiler plate. The problem is around the commented lines above the TODO - the project that is used to test the plugin fails with javax.xml.transform.TransformerFactoryConfigurationError: Provider net.sf.saxon.TransformerFactoryImpl not found when uncommenting them) 3. the pom.xml of the project that I use to test the plugin: http://testng-xslt.googlecode.com/svn/trunk/test/maven/pom.xml There are workarounds that I could implement. However, i need to know if I am missing something as this seems to be a classloader issue, as far as I can tell. I also tried to manually set the classloader on the current thread with the one of net.sf.saxon.TransformerFactoryImpl and curiously it worked, so my guess is that the search is performed in the plugin's classloader and not in the top-level classloader. Thanks anyways, Cosmin On Tue, Apr 1, 2008 at 6:25 PM, Wayne Fay [EMAIL PROTECTED] wrote: I have no clue without going into the code and looking at it, and I'm not doing that today. If you decide the codehaus plugin is close enough, feel free to modify it and submit your modifications for future incorporation into the plugin. Then everyone benefits from your changes. Wayne On 4/1/08, Cosmin Marginean [EMAIL PROTECTED] wrote: Hi, Thanks for the suggestion. I have tried this and it seems to lack some features that I really need in my plugin. So appearently I will need to write my own plugin. However, I analyzed some of the code in this plugin and it doesn't seem to do a lot more different stuff that I am doing, since the standard transformation API is used. The only difference seems to be that the xml-maven-plugin is run at build time, while mine is run at report time (in the reporting section). Could this be a cause why the transformer is not loaded? Thanks On Fri, Mar 28, 2008 at 5:29 PM, Wayne Fay [EMAIL PROTECTED] wrote: There is already an XML plugin in Codehaus which has XSLT functionality. Why don't you just take a look at it before moving too far down this path of possibly re-implementing an existing solution? http://mojo.codehaus.org/xml-maven-plugin/ Wayne On 3/28/08, Cosmin Marginean [EMAIL PROTECTED] wrote: It seems that this goes deeper. What I actually need to do is create a Maven plugin that performs an XSL transformation using Saxon 9. I unpacked the Saxon 9 jar and added the classes to my plugin jar to make sure the transformer is loaded. However, it seems that the transformer won't get loaded, even when I run Maven with - Djava.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl Some people seem to have worked around this by specifying the Saxon dependency in the client pom.xml but this doesn't seem to work if I make the transformation call from the plugin Jar. I even set the property manually in the plugin: TransformerFactory factory = TransformerFactory.newInstance(); But without any luck. The transformer will not be found Thanks in advance On Fri, Mar 28, 2008 at 9:04 AM, Cosmin Marginean [EMAIL PROTECTED] wrote: Hello guys, Sorry to bother you with such issues, but I've googling my brains out with this without any relevant results. I have a question regarding bundling a 3rd party jar in a Maven Plugin. I am a bit new to Maven and Maven plugins. I tried bundling it in the plugin jar and adding it to the Class-Path attribute of MANIFEST.MF, but it seems to be ignored when using the plugin. Another question would be: assuming that somehow this 3rd party jar will make it into a public repository, what is the proper way to configure the dependency to make sure that the client (plugin user) will download and load this jar correctly without having to configure 3rd third party dependency in the pom.xml? Many thanks in advance -- Cosmin Marginean -- Cosmin Marginean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cosmin Marginean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: javax.xml.ws jaxws-api 2.1 in repo1.maven.org - missing dependencies
Hi, what I´m looking for is JAX-WS-2..1.1, that means com\sun\xml\ws\jaxws-rt\2.1.1\jaxws-rt-2.1.1.jar with all the correct dependencies. Have you fixed that too? I couldn´t find any version at repo1 Thanx, Torsten Daniel Kulp [EMAIL PROTECTED] 01.04.2008 17:21 Bitte antworten an Maven Users List users@maven.apache.org An users@maven.apache.org Kopie Mick Knutson [EMAIL PROTECTED] Thema Re: javax.xml.ws jaxws-api 2.1 in repo1.maven.org - missing dependencies 2.1-1 is at central: http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/ Dan On Tuesday 01 April 2008, Mick Knutson wrote: What is the full URL for the java.net jars for 2.1-1 ? http://download.java.net/maven/2/javax/xml/ Does have 2.1-1 On Tue, Apr 1, 2008 at 7:46 AM, Daniel Kulp [EMAIL PROTECTED] wrote: Umm... Don't use the 2.1 jar from central. It's broken and missing some files that are in the Sun 2.1 jar. Basically, Sun released 2.1 at one point and it was synced to central. Sun then withdrew that and released a new 2.1, but didn't change the version number or anything. However, central won't replace the jar. Instead, use 2.1-1 from central. If you use 2.1, you MAY get the correct version from java.net. OR you might get the broken version from central. If you specify 2.1-1, you'll always get the correct version. Dan On Tuesday 01 April 2008, [EMAIL PROTECTED] wrote: Hi, looking at https://jax-ws.dev.java.net/faq/index.html#maven Suns recommended repo https://maven-repository.dev.java.net/nonav/repository seems to have the complete dependencies list. The jaxws-api in repo1.maven.org is missing the dependencies dependency groupIdjavax.xml.soap/groupId artifactIdsaaj-api/artifactId version1.3/version /dependency dependency groupIdjavax.annotation/groupId artifactIdjsr250-api/artifactId version1.0/version /dependency dependency groupIdjavax.jws/groupId artifactIdjsr181-api/artifactId version1.0-MR1/version /dependency Will this pom be updated/deleted? Thanx, Torsten -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to force the check of the latest dependency jars?
mvn -U forces Maven to check for updates. But lib1.jar is not a snapshot, so Maven will not look for updates to it. Only if the name was lib1-SNAPSHOT.jar. Things that don't have SNAPSHOT in the name are considered final and immutable, thus Maven will never look for updates to those files as they cannot exist (if you are doing things right). Wayne On 4/1/08, Stanley Lee [EMAIL PROTECTED] wrote: Hi all, Assume project A depends on lib1.jar. When I build project A, first time it will go to get the latest lib1.jar. After that, it only tries so if last check was 1 day ago or more. Is there any way to force the build to check out latest lib1.jar? I saw mvn command line has an option --update-snapshots, and tried it. However, on screen, I don't see any hint that Maven try to connect to repository and pull the latest lib1.jar. Your help is highly appreciated! Stan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: Re: javax.xml.ws jaxws-api 2.1 in repo1.maven.org - missing dependencies
No. The runtime jars would just be at java.net. Dan On Tuesday 01 April 2008, [EMAIL PROTECTED] wrote: Hi, what I´m looking for is JAX-WS-2..1.1, that means com\sun\xml\ws\jaxws-rt\2.1.1\jaxws-rt-2.1.1.jar with all the correct dependencies. Have you fixed that too? I couldn´t find any version at repo1 Thanx, Torsten Daniel Kulp [EMAIL PROTECTED] 01.04.2008 17:21 Bitte antworten an Maven Users List users@maven.apache.org An users@maven.apache.org Kopie Mick Knutson [EMAIL PROTECTED] Thema Re: javax.xml.ws jaxws-api 2.1 in repo1.maven.org - missing dependencies 2.1-1 is at central: http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/ Dan On Tuesday 01 April 2008, Mick Knutson wrote: What is the full URL for the java.net jars for 2.1-1 ? http://download.java.net/maven/2/javax/xml/ Does have 2.1-1 On Tue, Apr 1, 2008 at 7:46 AM, Daniel Kulp [EMAIL PROTECTED] wrote: Umm... Don't use the 2.1 jar from central. It's broken and missing some files that are in the Sun 2.1 jar. Basically, Sun released 2.1 at one point and it was synced to central. Sun then withdrew that and released a new 2.1, but didn't change the version number or anything. However, central won't replace the jar. Instead, use 2.1-1 from central. If you use 2.1, you MAY get the correct version from java.net. OR you might get the broken version from central. If you specify 2.1-1, you'll always get the correct version. Dan On Tuesday 01 April 2008, [EMAIL PROTECTED] wrote: Hi, looking at https://jax-ws.dev.java.net/faq/index.html#maven Suns recommended repo https://maven-repository.dev.java.net/nonav/repository seems to have the complete dependencies list. The jaxws-api in repo1.maven.org is missing the dependencies dependency groupIdjavax.xml.soap/groupId artifactIdsaaj-api/artifactId version1.3/version /dependency dependency groupIdjavax.annotation/groupId artifactIdjsr250-api/artifactId version1.0/version /dependency dependency groupIdjavax.jws/groupId artifactIdjsr181-api/artifactId version1.0-MR1/version /dependency Will this pom be updated/deleted? Thanx, Torsten -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
m2eclipse project proposal submitted to Eclipse.org
Hi, This is for those interested in Maven/Eclipse integration. I have just finished going through the process of getting our project proposal submitted to Eclipse. So what this means is that the idea floats around for about a month and then we go through a creation review process. The process is outlined here if anyone is interested: http://www.eclipse.org/projects/dev_process/proposal-phase.php So this is where we are now: 1) We have mentors, which is required to get to the next phase. We have the great fortune to have Ed Merks of the EMF project, and Chris Aniszczyk of the PDE project. 2) We have a relatively diverse committer base, which we will improve upon 3) We have many interested parties from industry and the community You can see the proposal here: http://www.eclipse.org/proposals/m2e/ The newsgroup should be setup within the next 48 hours and we'll begin working toward our Creation Process Review. Woo hoo! Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: war plugin error with cargo
That's not your whole pom. Send the whole thing, or even better, post
it on pastebin.org and send us a link.
Wayne
On 4/1/08, Urooj Khan [EMAIL PROTECTED] wrote:
hi everyone
i get the following error when i try to
mvn cargo:deploy -P
[ERROR] BUILD ERROR
[INFO]
[INFO] Artifact [emailer:emailer:war] is not a dependency of the project.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Artifact
[emailer:emailer:war] is not a dependency of the project.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(
DefaultLifecycleExecutor.java:493)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
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:585)
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: Artifact
[emailer:emailer:war] is not a dependency of the project.
at
org.codehaus.cargo.maven2.configuration.AbstractDependency.findArtifactLocation
(AbstractDependency.java:110)
at
org.codehaus.cargo.maven2.configuration.Deployable.computeLocation(
Deployable.java:208)
at
org.codehaus.cargo.maven2.configuration.Deployable.createDeployable(
Deployable.java:110)
at
org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables
(AbstractDeployerMojo.java:99)
at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(
AbstractDeployerMojo.java:47)
at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(
AbstractCargoMojo.java:243)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:447)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:539)
... 16 more
Here is my pom.xml:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0/version
configuration
warSourceDirectoryweb/warSourceDirectory
/configuration
/plugin
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
executions
execution
phaseinstall/phase
/execution
/executions
configuration
container
containerIdtomcat5x/containerId
typeremote/type
/container
configuration
typeruntime/type
properties
cargo.remote.username${tomcat.username
}/cargo.remote.username
cargo.remote.password${tomcat.password
}/cargo.remote.password
cargo.hostname${host.name}/cargo.hostname
cargo.servlet.port${host.port}/cargo.servlet.port
/properties
/configuration
deployer
typeremote/type
deployables
deployable
groupIdmoney/groupId
artifactIdmoney/artifactId
typewar/type
properties
context${tomcat.context}/context
/properties
/deployable
/deployables
/deployer
/configuration
/plugin
/plugins
sourceDirectory${basedir}/src/java/sourceDirectory
testSourceDirectory${basedir}/src/test/testSourceDirectory
resources
resource
directory${basedir}/conf/directory
includes
include*.properties/include
/includes
/resource
/resources
/build
--
Urooj Khan
Re: How to force the check of the latest dependency jars?
If the artifact that you want to get the latest of *is* a snapshot, then how often maven checks depends on your repository definition. When a repo is defined (in a pom or settings.xml) there is an optional element that says how often it is checked for updated snapshots. This defaults to 1 day, but can also be set to every time. If you have a setup where you have some developers deploying snapshots to an internal company repo frequently, then adjusting the default value is useful. But if a new snapshot is only every few days, it is probably easier for an email to be sent out telling people to run mvn -U on their next build to get the latest snapshot. And setting every time for the settings referencing the apache snapshot repo will not be terribly popular...if everyone did that, the load on the server would be much much higher. See the pom reference documentation on the maven site for details on the schema for settings.xml or pom.xml files. Regards, Simon On Tue, 2008-04-01 at 11:34 -0500, Wayne Fay wrote: mvn -U forces Maven to check for updates. But lib1.jar is not a snapshot, so Maven will not look for updates to it. Only if the name was lib1-SNAPSHOT.jar. Things that don't have SNAPSHOT in the name are considered final and immutable, thus Maven will never look for updates to those files as they cannot exist (if you are doing things right). Wayne On 4/1/08, Stanley Lee [EMAIL PROTECTED] wrote: Hi all, Assume project A depends on lib1.jar. When I build project A, first time it will go to get the latest lib1.jar. After that, it only tries so if last check was 1 day ago or more. Is there any way to force the build to check out latest lib1.jar? I saw mvn command line has an option --update-snapshots, and tried it. However, on screen, I don't see any hint that Maven try to connect to repository and pull the latest lib1.jar. Your help is highly appreciated! Stan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2eclipse project proposal submitted to Eclipse.org
For those interested, at the end there's going to be 2 proposals, the one that Jason mentions and the previously submitted Eclipse IAM http://www.eclipse.org/proposals/iam based on the Q4E work http://code.google.com/p/q4e/ Both are independent and both can be approved for inclusion in the Eclipse Foundation. On Tue, Apr 1, 2008 at 12:02 PM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, This is for those interested in Maven/Eclipse integration. I have just finished going through the process of getting our project proposal submitted to Eclipse. So what this means is that the idea floats around for about a month and then we go through a creation review process. The process is outlined here if anyone is interested: http://www.eclipse.org/projects/dev_process/proposal-phase.php So this is where we are now: 1) We have mentors, which is required to get to the next phase. We have the great fortune to have Ed Merks of the EMF project, and Chris Aniszczyk of the PDE project. 2) We have a relatively diverse committer base, which we will improve upon 3) We have many interested parties from industry and the community You can see the proposal here: http://www.eclipse.org/proposals/m2e/ The newsgroup should be setup within the next 48 hours and we'll begin working toward our Creation Process Review. Woo hoo! Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
changelog vs scm:update
How can I have scm:update work, but changelog:changelog fail with this
message:
Embedded error: cvs repository connection string doesn't contain six tokens
BTW, my cvs repository connection string is
scm:cvs:pserver:${cvs.user):${cvs.password}@
cipe801.sldc.sbc.com:12310:/appl/pkg1/cvs/reps/theteam/cvs:cans
--
Esse Quam Videre
To Be, rather than to Seem
Finding source
Does anyone have a good way of finding the source for a Maven class? I've been looking for org.apache.maven.util.RepositoryUtils for about half an hour and I can't find it. -- Esse Quam Videre To Be, rather than to Seem
Relative link in xdoc file results in anchor
I used xdoc for my Maven site, and in one XML file I have the following link: a href=upgrade-guide-4.1.docUpgrade Guide/a When the site is generated locally the link is correct - it remains as above. However, when the site is deployed, the link becomes: a href=#upgrade-guide-4.1.docUpgrade Guide/a I have tried prepending the href with ./, but that didn't help. How can I put a relative path in the link which will not become an anchor? I could not find any info in the site docs. :( -- Daniel Siegmann FJA-US, Inc. 512 Seventh Ave., New York, NY 10018 (212) 840-2618 ext. 139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-war-plugin filtering problem
Hi,
Have you tried with last snapshot version ?
Because we have changed resources handling (webResources).
Thanks,
--
Olivier
2008/4/1, Chris Barran [EMAIL PROTECTED]:
Dear maven users,
I cannot get the maven-war-plugin filtering to work as expected.
I'm trying to configure my context.xml thus.
Context path=/${pom.artifactId}-${pom.version} docBase=$
{pom.artifactId}-${pom.version}
ResourceLink name=${jndi.name} global=${jndi.name}/
/Context
${jndi.name} can configured in a properties file or in a profile or
an the command line.
I can get the jndi.name property to replace for plugin version 2.0
I can get the pom.* properties to work for version 2.0.1+ but not
both what is going on?
I can't find the answer in the docs or mail archive.
Others seem to report the problem and get no answer
Others claim it's fixed.
This seems to have come up repeatedly for 2 to 3 years. Other folks
must be using some work around.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[2.0.9 RC6] Release Candidate testing
I didn't get much response yesterday and we respun a new RC (RC6) so I'm resending the original mail. If nothing turns up within 3 days, then we will restage and vote for a release. Thanks, Brian --- In an attempt to raise quality and reduce/eliminate regressions in the core releases, we are experimenting with a new release process. The old process had a few informal staged builds followed by one or more official staged builds that where voted on. Clearly this didn't attract enough testing prior to the official release to identify regressions or other major issues. The new process we are using for the 2.0.9 release is to cut actual release candidate (RCx) releases. These are released with the normal release process so it generates a tag, but do not get sync'd to central. We have gone through several RCs[1] as we tested on the dev@ list. The next step is to open it up to the user list for fix validation and regression identification. This is really the first time we've followed such a process so we'll have to see how it pans out. Here are the operating parameters for this test: * The goal of the RCs are to stabilize the release and any changes at this point naturally risks further regressions. Therefore, the list of fixes for 2.0.9 is locked. We will not be including any more fixes at this point unless it meets the requirements laid out below. This means please don't reply with could you just include xyz. * The issues we are looking to identify and fix are those where it can be shown to work with 2.0.8, but not with 2.0.9-RCxxx. These issues we will almost certainly fix. Our goal is to fix ALL regressions identified between 2.0.8 and 2.0.9, but naturally we need to weigh the severity of the issue along with the exposure against the complexity and risk of further regressions by fixing it. * If any of the issues that are marked as fixed for 2.0.9 are found to not be fixed, then we are interested in this as well, but more likely than not the fix will be rolled back and rescheduled for 2.0.10. Naturally the importance of the issue has bearing in how this will be handled. * If we can receive a sample project or IT[2] showing the issue, then it increases the likelihood of a quick fix and turnaround of the RC exponentially, both for regressions and for not fixed issues in 2.0.9 * Please report any regressions found between earlier versions of 2.0.x and 2.0.9 as they will be prioritized for 2.0.10 along with anything rolled back / not fixed from 2.0.9 * We will continue to iterate through this process until we feel that the release is ready to go. User list input will have a large factor in making this decision. That said, the quality of the 2.0.9 release will depend on the level of involvement from the entire community to test, reproduce and report issues identified. * Please file a Jira[3] for anything you find, and then reply to the RC thread with the details and issue number so that others may see and reduce duplicate reports. We will be watching Jira closely for reports with 2.0.9 in the affected version. * Once a release is ready, we will rebuild and restage the code from the most recent RC for a formal vote. This will produce the official 2.0.9 release. The list of issues fixed for this release can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13801styleName =HtmlprojectId=10500Create=Create Some notable changes are: * Plugin versions are locked in the superpom. (MNG-3395) You can see the locked versions here: http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/ma ven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml * In most cases they are locked to the currently available plugin to avoid suddenly downgrading users that haven't locked their own versions (still the best practice). * Webdav is included in the core, meaning you can deploy:deploy-file without a pom to include the extension (if you use webdav obviously) (MNG-2664) * New syntax for mirror definitions. Details here: MNG-3461 * Introduction of Import scope: (MNG-3220) http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html#Importing_Dependencies The binaries for this RC can be found here: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/ (naturally take the highest RC number deployed as it will change when we iterate) [1] Previous RC threads: http://www.nabble.com/-Pre-Vote--release-maven-2.0.9-td16124759s177.html http://www.nabble.com/-pre-vote-take-3--2.0.9-RC3-td16314473s177.html http://www.nabble.com/-2.0.9-RC4--td16344067s177.html http://www.nabble.com/-2.0.9-RC5--td16365465s177.html#a16365465 [2] Creating a Core IT: http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test [3] http://jira.codehaus.org/browse/MNG
Re: Skip tests for installation phase
You should put the integration test stuff in a profile, and activate
it when you want to run the integration tests. Then it won't happen
unless you want it, no matter what phase you execute.
Wayne
On 4/1/08, kristoffer [EMAIL PROTECTED] wrote:
Hi,
I want to skip my tests for specific projects which contains integration
tests.. I have read alot on the web/forums/maillists etc and found that this
is sort of a de-fact way of doing this:
[pom.xml: contained in that separate which only contains these tests]=
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
skiptrue/skip
/configuration
executions
execution
idsurefire-it/id
phaseintegration-test/phase
goals
goaltest/goal
/goals
configuration
skipfalse/skip
/configuration
/execution
/executions
/plugin
/plugins
/build
The tests are skipped for most commands (compile, test, package etc) which
is good. But when i run mvn install, the tests are run. It seems as if
install matches my surefire-it executions, which was not my intention...
[INFO] Scanning for projects...
[INFO]
[INFO] Building X JAR
[INFO]task-segment: [integration-test]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] [surefire:test {execution: surefire-it}]
[INFO] Surefire report directory:
c:\myplace\dev\integrationtest\target\surefire-reports
---
T E S T S
---
Running xxx.xxx.AdminIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Tue Apr 01 16:30:10 CEST 2008
[INFO] Final Memory: 5M/11M
[INFO]
I only want it to be run if i run integration-test.. Have any one
encountered this before?
thanks and regards,
-Kristoffer
--
View this message in context:
http://www.nabble.com/Skip-tests-for-installation-phase-tp16418470s177p16418470.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to manage Maven 1 artifacts of type zip
IvanPopov a écrit : Hi, it seems as if Archiva do not manage them. If I install it on my repository such as groupId/ [type = zips]/ artefactId-version.[type=zip] Archiva is not able to download it. I think there is a problem relative to maven 2 as zips seems to be considered as distribution. This is a major issue for me, so if someone has an idea, you are welcome. Regards. What does happende when the path is groupId/jars/artefactId-version.zip I used the war type with maven1, they where installed in jars/ folder along with jar file, so maybe archiva expects everything there.
During compile, use the related jar instead of the target/classes directory
HI, for a very very very complex project, I need a hack in order to build my projects. I have a parent pom, and 170 modules. One of this module, is in fact a fake, means that i dont want maven to build the associate jar because he cant (we have circular dependencies between this project and 40 of the others modules). So this fake module is build under eclipse, a jar is generated and deploy into archiva, so the others modules could use this faxe project as a dependency. You will tell me why declared this project as a maven project if i m using eclipse to build it. Because it holds many properties files, and i m using assembly to build an archive file of all properties files of all projects (this is a customer requirement...). I declared this fake project as a pom packaging project, so when it will be build, it will deploy a pom artifact to archiva, and not a jar (otherwise it will be replace the real jar build into eclipse). The problem is during the mvn compile launch from the parent pom, the others projects who have a dependency to this fake project, use as a classpath the target/classes directory, which is empty of course, because it s a pom packaging. My question is: could i tell some projects to always use the jar deployed in archiva instead of using target/classes? NB: when i launched the mvn compile from a project with a dependency to this fake project, the buils is successful of course, cause he used the jar in order to compile. Thks for listening :)
Re: changelog vs scm:update
After cvs.user there is a closing parethesis ) instead of a brace
}. Hope this helps,
Henry
On 4/1/08, Jon Strayer [EMAIL PROTECTED] wrote:
How can I have scm:update work, but changelog:changelog fail with this
message:
Embedded error: cvs repository connection string doesn't contain six tokens
BTW, my cvs repository connection string is
scm:cvs:pserver:${cvs.user):${cvs.password}@
cipe801.sldc.sbc.com:12310:/appl/pkg1/cvs/reps/theteam/cvs:cans
--
Esse Quam Videre
To Be, rather than to Seem
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
