[jira] Created: (CONTINUUM-619) shell command line not preserved
shell command line not preserved Key: CONTINUUM-619 URL: http://jira.codehaus.org/browse/CONTINUUM-619 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.2 Reporter: Lee Meador Priority: Minor I have a shell project. The executable is 'mvn.bat' and the argument is the long string: -f 00Build/pom.xml --settings C:\Program Files\Apache Software Foundation\continuum-1.0.2\bin\win32\conf\settings.xml clean install This argument shows up on the info tab for the project correctly. There is only one build for that project. When I click edit to change the argument, the whole argument (as shown above) does not appear in the text box on that web page. It's not that it doesn't fit in the box and I would have to get it to scroll left and right to see the text. It just ends where the first double quote is. I see the first part of the argument and the last word shown is '--settings'. I can work around it by copying the argument on the info tab to my clipboard and then pasting it after I click the 'edit' link. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[continuum build branches/continuum-1.0.x - SUCCESS - update] Mon Mar 6 17:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060306.173001.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060306.173001.txt
[continuum build branches/continuum-1.0.x - FAILED - checkout] Tue Mar 7 02:00:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060307.02.txt
[jira] Updated: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=all ] Eugene Kuleshov updated MNGECLIPSE-85: -- Comment: was deleted MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60197 ] Eugene Kuleshov commented on MNGECLIPSE-85: --- Thorsten, I took a quick look at your changes and it occurs to me that your IMavenLauncher interface is essentially the same as ILaunchShortcut interface. That is one you should be using, as well as platform bindings for launch shortcuts. See org.eclipse.debug.ui.launchShortcuts extension in plugin.xml MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60198 ] Thorsten Kamann commented on MNGECLIPSE-85: --- Yes, the version I've uploaded is the same. The current version has an additional method, so it's not the same anymore. Bye Thorsten MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=all ] Thorsten Kamann updated MNGECLIPSE-85: -- Attachment: launcher.patch MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-74) IsolatedClassloader.getResources returns duplicated results
IsolatedClassloader.getResources returns duplicated results --- Key: MSUREFIRE-74 URL: http://jira.codehaus.org/browse/MSUREFIRE-74 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.2 Reporter: Carlos Sanchez Fix For: 2.2 When calling classLoader.getResources(org/springframework/core/io) every result is twice in the resulting enumeration It doesn't happen in 2.1.3 It may have to do with the fact that classes and test-classes are twice in the classpath output [INFO] [surefire:test] [DEBUG] dummy:dummy:jar:1.0 (selected for null) [DEBUG] org.apache.maven.surefire:surefire-booter:jar:2.0-SNAPSHOT:runtime (selected for runtime) [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.0-SNAPSHOT:runtime (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime (selected for runtime) [DEBUG] surefire-api: using locally installed snapshot [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\csanchez\.m2\repository\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\csanchez\.m2\repository\org\apache\maven\surefire\surefire-booter\2.0-SNAPSHOT\surefire-booter-2.0-SNAPSHOT.jar [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\csanchez\.m2\repository\org\apache\maven\surefire\surefire-api\2.0-SNAPSHOT\surefire-api-2.0-SNAPSHOT.jar [DEBUG] dummy:dummy:jar:1.0 (selected for null) [DEBUG] Skipping disabled repository central [DEBUG] surefire-junit: using locally installed snapshot [DEBUG] Retrieving parent-POM from the repository for project: null:surefire-junit:jar:2.0-SNAPSHOT [DEBUG] Skipping disabled repository central [DEBUG] surefire-providers: using locally installed snapshot [DEBUG] Retrieving parent-POM from the repository for project: null:surefire-providers:pom:null [DEBUG] surefire: using locally installed snapshot [DEBUG] org.apache.maven.surefire:surefire-junit:jar:2.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:compile (selected for compile) [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.0-SNAPSHOT:compile (selected for compile) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:compile (selected for compile) [DEBUG] surefire-junit: using locally installed snapshot [DEBUG] surefire-api: using locally installed snapshot [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\csanchez\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\csanchez\.m2\repository\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\csanchez\.m2\repository\org\apache\maven\surefire\surefire-api\2.0-SNAPSHOT\surefire-api-2.0-SNAPSHOT.jar [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\csanchez\.m2\repository\org\apache\maven\surefire\surefire-junit\2.0-SNAPSHOT\surefire-junit-2.0-SNAPSHOT.jar [DEBUG] Test Classpath : [DEBUG] c:\dev\spring\spring\m2\spring-core\target\test-classes [DEBUG] c:\dev\spring\spring\m2\spring-core\target\classes [DEBUG] c:\dev\spring\spring\m2\spring-core\target\classes [DEBUG] c:\dev\spring\spring\m2\spring-core\target\test-classes [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\commons-collections\commons-collections\3.1\commons-collections-3.1.jar [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\commons-logging\commons-logging\1.0.4\commons-logging-1.0.4.jar [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\javax\servlet\servlet-api\2.4\servlet-api-2.4.jar [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\asm\asm\2.2.1\asm-2.2.1.jar [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\asm\asm-commons\2.2.1\asm-commons-2.2.1.jar [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\easymock\easymock\1.2_Java1.3\easymock-1.2_Java1.3.jar [DEBUG] C:\Documents and Settings\csanchez\.m2\repository\log4j\log4j\1.2.13\log4j-1.2.13.jar [DEBUG] Setting system property [localRepository]=[C:/Documents and Settings/csanchez/.m2/repository] [DEBUG] Setting system property [basedir]=[c:\dev\spring\spring\m2\spring-core] [INFO] Surefire report directory: c:\dev\spring\spring\m2\spring-core\target\surefire-reports Forking command line: java -Djava.awt.headless=true -XX:MaxPermSize=128m -Xmx128m -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -ea -classpath C:\Documents and Settings\csanchez\.m2\repository\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\Documents and
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60201 ] Eugene Kuleshov commented on MNGECLIPSE-85: --- This is kind of thing I am talking about. If your view would use IFile or something adaptable to IFile to represent poms, then existing launch action would be automatically contributed to its popup menu. Unless you are trying to do something else or I am missing something. Can you please describe what exactly you going to implement in that view? Otherwise it could help to see the other part of the code. MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60204 ] Thorsten Kamann commented on MNGECLIPSE-85: --- In the view there aren't pom files. I know only the name of the goal to execute and the IProject the goal belongs to. The ISelection points to the goal and not to the pom file. Therefore i thought the most flexible way were the externalizing of the launcher to allow other views and action to reuse an specialized launcher based on the IMavenLauncher. regards Thorsten MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with JarSignMojo
Brett Porter wrote:
Is this MJAR-32?
Yes it is.
Jerome attached a patch which solved verify problem but it's still far
away from what I would call a complete JarSingMojo.
There is still an issue with making the in-place signing (read my
comments in the MJAR-32) which prevents me from using this Mojo.
Cheers
Pablo
Pablo wrote:
Hello everyone
I tried to use JarSignMojo from maven-jar-plugin trunk but with no success.
Out of the box it's not useable.
1) If I set verify to true the following code is done:
if ( verify )
{
JarSignVerifyMojo verify = new JarSignVerifyMojo();
verify.setWorkingDir( workingDirectory );
verify.setBasedir( basedir );
verify.setJarPath( getJarFile() );
verify.setVerbose( verbose );
verify.execute();
}
I think there is a bug. Since getJarFile() returns unsigned jar
JarSignVerifyMojo:execute() will definitely fail.
There should be verify.setJarPath( *signedjar* ); instead of
verify.setJarPath( *getJarFile()* );
2) There is no way (at least I'm not aware of any) to sign a jar without
specifying signedjar parameter. What if would like to use the signed jar
in a module which depends on this particular project?
There should be a way to overwrite signedjar field with null. If
signedjar is null, jarsigner will not be supplied with -signedjar
parameter and will sign target/${artifactId}.jar jar file instead of
creating target/signed/${artifactId}.jar file. And it will allow me to
use this artifact in other projects which depend on it.
Cheers
Pablo
-
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]
[jira] Created: (MNG-2124) Incorrect resolution of parent POM properties
Incorrect resolution of parent POM properties
-
Key: MNG-2124
URL: http://jira.codehaus.org/browse/MNG-2124
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.2
Environment: Windows XP, JDK 1.4.2_11
Reporter: Kjetil Ødegaard
Attachments: maven-bug.zip
Unzip maven-bug to current dir and cd to maven-bug/artifact.
Now, Maven 2.0.1 handles things correctly (irrelevant output removed):
{code}[echo] Parent: parentartifact, project: artifact{code}
But Maven 2.0.2 has a bug:
{code}[echo] Parent: artifact, project: artifact{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MJAR-31) [webstart] NPE when signing dependencies
[ http://jira.codehaus.org/browse/MJAR-31?page=comments#action_60207 ] Geoffrey De Smet commented on MJAR-31: -- This patch makes point 1 of http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] obsolete, but not point 2, according to Tim Kettler on the mojo user list. [webstart] NPE when signing dependencies Key: MJAR-31 URL: http://jira.codehaus.org/browse/MJAR-31 Project: Maven 2.x Jar Plugin Type: Bug Environment: WinXP Maven 2.0.2 Latest maven-jar-plugin from SVN Latest webstart checkout Reporter: Michael Böckling Priority: Critical Attachments: MOJO-295.diff In JarSignMojo, the call to this.signedjar.getPath() produces a NPE, because in JnlpMojo:863, signJar.setSignedJar() has been commented out. Stacktrace: [debug] jarsigner executable=[C:\Programme\Java\jdk1.5.0_06\jre\..\bin\jarsigner .exe] [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failure to run the plugin: [INFO] - --- [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failure to run the plugi n: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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.MojoExecutionException: Failure to run the pl ugin: at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:479) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:531) ... 16 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.jar.JarSignMojo.signJar(JarSignMojo.java:227) at org.apache.maven.plugin.jar.JarSignMojo.execute(JarSignMojo.java:185) at org.codehaus.mojo.webstart.JnlpMojo.signJars(JnlpMojo.java:865) at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:441) ... 18 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MJAR-31) [webstart] NPE when signing dependencies
[ http://jira.codehaus.org/browse/MJAR-31?page=comments#action_60208 ]
Geoffrey De Smet commented on MJAR-31:
--
for the record, point 2 is the following HACK:
2) Nullpointer on org.apache.maven.plugin.jar.JarSignMojo, line 282
+if (project.getArtifact() != null) {
project.getArtifact().setFile( signedjar );
+}
[webstart] NPE when signing dependencies
Key: MJAR-31
URL: http://jira.codehaus.org/browse/MJAR-31
Project: Maven 2.x Jar Plugin
Type: Bug
Environment: WinXP
Maven 2.0.2
Latest maven-jar-plugin from SVN
Latest webstart checkout
Reporter: Michael Böckling
Priority: Critical
Attachments: MOJO-295.diff
In JarSignMojo, the call to this.signedjar.getPath() produces a NPE, because
in JnlpMojo:863, signJar.setSignedJar() has been commented out.
Stacktrace:
[debug] jarsigner
executable=[C:\Programme\Java\jdk1.5.0_06\jre\..\bin\jarsigner
.exe]
[INFO]
-
---
[ERROR] BUILD ERROR
[INFO]
-
---
[INFO] Failure to run the plugin:
[INFO]
-
---
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Failure to run the
plugi
n:
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:472)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
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.MojoExecutionException: Failure to run the
pl
ugin:
at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:479)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:415)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:531)
... 16 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.jar.JarSignMojo.signJar(JarSignMojo.java:227)
at
org.apache.maven.plugin.jar.JarSignMojo.execute(JarSignMojo.java:185)
at org.codehaus.mojo.webstart.JnlpMojo.signJars(JnlpMojo.java:865)
at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:441)
... 18 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: signing jar and webstart plugin
It was already there:
http://jira.codehaus.org/browse/MJAR-31
Note that my solutions are hacks as I don't have an idea of the overall
design or program flow.
Brett Porter wrote:
Can you please submit these to jira? There are already some there
(MJAR), so please check for existing ones first.
Geoffrey De Smet wrote:
For networktools.sf.net I used the webstart plugin,
which uses the jar plugin to sign jars.
I 've had a bunch of problems, most of wrong configuration on my part,
but some I believe lay in the jar plugin.
In the end I changed these few lines in the jar plugin to get it
working, even if it's a quick dirty hack:
1) Nullpointer on org.apache.maven.plugin.jar.JarSignMojo, line 217
addArgIfNotEmpty( arguments, -keypass, this.keypass );
+if (this.signedjar != null) {
addArgIfNotEmpty( arguments, -signedjar,
this.signedjar.getPath() );
+}
addArgIfNotEmpty( arguments, -storetype, this.type );
2) Nullpointer on org.apache.maven.plugin.jar.JarSignMojo, line 282
+if (project.getArtifact() != null) {
project.getArtifact().setFile( signedjar );
+}
Maybe this helps other people having the same issues.
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tests of 1.0
Currently, the Bazaar provider tests fail for me under Windows (I have Bazaar installed in Cygwin). What version of bazaar do you use? (Version 0.7 is the current stable, pre 0.7 is failing on *nix like systems) I'd actually like to have the tests not require svn, cvs, bzr installed to pass, and move those tests to integration tests in some way. WDYT? I agree. But it's a dangerous decision. It will end up in broken baselines (providers) more often. We should encourage developers eg. myself to test with every provider. What about a configuration option? How is it done with the other VCSs? Torbjørn
[jira] Updated: (MNG-2124) Incorrect resolution of parent POM properties
[ http://jira.codehaus.org/browse/MNG-2124?page=all ]
Brett Porter updated MNG-2124:
--
Priority: Blocker (was: Major)
Fix Version: 2.0.3
promoting if it is a regression
Incorrect resolution of parent POM properties
-
Key: MNG-2124
URL: http://jira.codehaus.org/browse/MNG-2124
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.2
Environment: Windows XP, JDK 1.4.2_11
Reporter: Kjetil Ødegaard
Priority: Blocker
Fix For: 2.0.3
Attachments: maven-bug.zip
Unzip maven-bug to current dir and cd to maven-bug/artifact.
Now, Maven 2.0.1 handles things correctly (irrelevant output removed):
{code}[echo] Parent: parentartifact, project: artifact{code}
But Maven 2.0.2 has a bug:
{code}[echo] Parent: artifact, project: artifact{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tests of 1.0
Torbjørn Smørgrav wrote: Currently, the Bazaar provider tests fail for me under Windows (I have Bazaar installed in Cygwin). What version of bazaar do you use? (Version 0.7 is the current stable, pre 0.7 is failing on *nix like systems) $ bzr --version bzr (bazaar-ng) 0.7 Copyright 2005,06 Canonical Development Ltd. http://bazaar-ng.org/ I'd actually like to have the tests not require svn, cvs, bzr installed to pass, and move those tests to integration tests in some way. WDYT? I agree. But it's a dangerous decision. It will end up in broken baselines (providers) more often. We should encourage developers eg. myself to test with every provider. What about a configuration option? That's exactly what I meant - make it an integration test (perhaps in a profile) so that the builds only run unit tests (which should still do most of the testing, and just compare command lines rather than execute them). The integration tests can be run in an integration environment where the VCSs are installed (obviously, some will be limited to particular ones). This isn't required before 1.0, but the tests need to pass before 1.0. - Brett
RE: Tests of 1.0
- since Bazaar, VSS, etc are partially implemented, according to the site, should they be omitted from this release? Or do they do enough to be useful? Can we list what is implemented and what is not? We should at least define when a provider is implemented and not only partially implemented. Now supporting a system before version 1.0 (Bazaar is currently 0.7) is almost by definition partially. However I think its usefull and complete enough to be released. Torbjørn
[jira] Commented: (MAVEN-1741) maven 1.1 fails to run commons-attributes in mutliproject mode on a war project
[ http://jira.codehaus.org/browse/MAVEN-1741?page=comments#action_60213 ] nicolas de loof commented on MAVEN-1741: I can agree with this 1.1 new requirement for only-1-run preGoals. This may then require some upgrade to commons-attributes and html2xdoc plugins : html2xodc uses a xdoc:init preGoal to run if maven.html2xdoc.enabled=true (I don't know other official plugins that use pre/post Goals) So this bug can be moved from MAVEN to MPHTMLXDOC maven 1.1 fails to run commons-attributes in mutliproject mode on a war project --- Key: MAVEN-1741 URL: http://jira.codehaus.org/browse/MAVEN-1741 Project: Maven Type: Bug Versions: 1.1-beta-2 Reporter: nicolas de loof Priority: Minor Attachments: test_maven11_commons-attributes.zip Attached zip contains a minimalist multiproject using commons-attributes that demonstrates the bug. - head (top level project) - jar (minimalist jar project) : Sample.java has a java.util.Date attribute - war (minimalist war project) : Sample.java has a java.util.Date attribute When runing maven war:install on war project, attributes are generated as expected. When running from head project using maven multiproject:install, commons-attributes are - generated as expected for the jar - NOT generated in the war (no log from plugin) I don't know if this is a maven, multiproject-plugin, war-plugin or commons-attributes-plugin bug. Please notice commons-attributes plugin uses a preGoal to automatically register itself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPIR-17) Create XML documents containing report data.
[ http://jira.codehaus.org/browse/MPIR-17?page=all ] Edwin Punzalan updated MPIR-17: --- Assign To: Edwin Punzalan Remaining Estimate: 10 hours Original Estimate: 10 hours Create XML documents containing report data. Key: MPIR-17 URL: http://jira.codehaus.org/browse/MPIR-17 Project: Maven 2.x Project Info Reports Plugin Type: Improvement Versions: 2.0-beta-3 Reporter: Chris Hagmann Assignee: Edwin Punzalan Original Estimate: 10 hours Remaining: 10 hours It would be a huge improvement if each report was written as as XML document before optionally rendering it. If you did that, then other plugins could use those XML reports, apply XSLT or whatever to generate their own version of a report. It would make the whole reporting thing much more flexible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Mon Mar 6 11:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060306.111501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060306.111501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Mon Mar 6 11:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060306.113000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060306.113000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPIR-17) Create XML documents containing report data.
[ http://jira.codehaus.org/browse/MPIR-17?page=comments#action_60214 ] Brett Porter commented on MPIR-17: -- that said, I think it's minor and can be omitted from 2.0. Create XML documents containing report data. Key: MPIR-17 URL: http://jira.codehaus.org/browse/MPIR-17 Project: Maven 2.x Project Info Reports Plugin Type: Improvement Versions: 2.0-beta-3 Reporter: Chris Hagmann Assignee: Edwin Punzalan Original Estimate: 10 hours Remaining: 10 hours It would be a huge improvement if each report was written as as XML document before optionally rendering it. If you did that, then other plugins could use those XML reports, apply XSLT or whatever to generate their own version of a report. It would make the whole reporting thing much more flexible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposed mailing lists names
On Mon, 6 Mar 2006, Brett Porter wrote: +1 for these names. Btw, for completeness: we also have 'users@' and 'announce@' (right?). Just one question: commits@maven.apache.org * for commits - we already have it (each subproject has its own) what do you mean by this? My first impression is that you mean the maven1, maven2 and continuum (and other subprojects) have their own commits list - if so, what are they called? I probably misunderstood.. -- Kenney Since we've voted to do this, I'm just going to give people 48 hours to object to these particular names. [see MPA-50] Our dev list traffic has gone nuts. Let's create: [EMAIL PROTECTED] * this will be for CI, error reports from the repository manager, and so on * depending on policy, this may not be archived (we won't archive it unless it's required - I don't think it's necessary, but there is no harm in it if it is) * this will be for all maven projects (ie, no continuum-notifications, etc). [EMAIL PROTECTED] * this will be for JIRA issues. For now, just one will be created. If it is later determined to split one set off, we can create more. commits@maven.apache.org * for commits - we already have it (each subproject has its own) dev@maven.apache.org * for human discussion - we already have it Note that all subscribers to dev@maven.apache.org will be automatically subscribed to these lists at creation, but going forward you will need to subscribe to each individually. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposed mailing lists names
Kenney Westerhof wrote: * for commits - we already have it (each subproject has its own) what do you mean by this? My first impression is that you mean the maven1, maven2 and continuum (and other subprojects) have their own commits list - if so, what are they called? I probably misunderstood.. not quite. 1.x and 2.x share. commits@maven.apache.org continuum-commits@maven.apache.org ... http://people.apache.org/~coar/mlists.html#maven.apache.org - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3 (second attempt)
This should go into JIRA as a blocker on 2.0.3 to make sure we keep track of it properly. There was another 2.0.1 - 2.0.2 regression filed that I just put in as a blocker. IT might be dismissed with investigation, but I'd like this to be the release where all those are cleared up so I slotted it in. Once open bugs not part of the release = 0, another RC + vote will be needed. - Brett Fabrizio Giustina wrote: Still playing with this rc with multiproject builds with a flat layout: after the DefaultModelInheritanceAssembler fix everything work as expected but I got my website broken due to a different behaviour during publishing. In my root module the website root directory is /x/htdocs. With the previous m2 releases the root module got published to /x/htdocs and child modules to /x/htdocs/modulename. Now what happens is that the root module is still published to /x/htdocs but child modules are (unsuccessfully) published at /x/modulename (argh, out of the webserver root). Is this an intentional change in MNG-2006 ? I would expect that pom relative urls should not influence the website location (while they do influence the svn url, since the parent path need to be used to get the parent pom location... but this has nothing to do with published website) WDYT? fabrizio On 3/3/06, John Casey [EMAIL PROTECTED] wrote: This is the newest RC binary, including Kenney's fixes for MNG-1317 and MNG-1318, along with the fix for the NPE noted earlier in DefaultModelInheritanceAssembler. http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.193236.tar.gz Enjoy, John - 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: some major issues with reactors and dependency handling
I believe this is solely a reactor issue (it should be naming the files at the target, as the source filename could be anything). So MWAR-7 is the issue and should be easily fixed. - Brett Brian E. Fox wrote: I've seen some major issues with the way maven handles dependencies in a multi project setting. Consider the following project: parent Project A 1.0 - Jar Project B 1.0 - War If I build the parent, when project A is included in the war, it's included as project-a.jar. If I build Project B, then the jar is included as project-a-1.0.jar This is just one example of some weird issues, I know that people have mentioned problems similar to this with compiling. Maven is all about reproducibility, but this one clearly breaks that because the produced artifact is completely dependant on if it was build standalong or part of a reactor. Can any of the maven developers explain what was attempted to be solved by this and if/when we might see it get fixed. Some jiras I can see that are related to this: http://jira.codehaus.org/browse/MWAR-7 http://jira.codehaus.org/browse/MOJO-286 I don't yet see an actual issue related to this, just the side effects of it on the WAR and Dependency plugin. Should I create a separate one in the MNG group? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2 REPO] mess in /servicemix
Brett Porter wrote: Sure, but they don't really need to redistribute half of eclipse themselves. How about a simple rule of not allowing the deployment of anything outside that projects groupId. In the case of external dependencies I'm not sure what the best route is because one project could potentially harm another project where snapshots are involved or simply accidentally where an artifact is named incorrectly and overwrites a correctly deployed version. In this case we could make projects use their groupId so those externally pulled in deps can't pollute the repository it only affects that project. I think this would be a decent compromise as it lets projects redistribute according to the license covering the artifacts but they can't harm others. I'm not sure we can easily enforce this now but something the repository manager could do. - Brett Carlos Sanchez wrote: servicemix is in progress of migrating to m2 and theri artifacts will be at org.apache.servicemix groupid On 3/5/06, Brett Porter [EMAIL PROTECTED] wrote: Moderation is something we'd all like. Getting there. This is not pretty. I will find out what's going on. - Brett Giorgio Gallo wrote: Hi! I'm sorry to write at an inappropriate address (got this from http://maven.apache.org/project-faq.html) - I just couldn't find anything like [EMAIL PROTECTED] or similar. Please forward to a more appropriate one (if there is one). This email is to let you know i stumbled into http://www.ibiblio.org/maven2/servicemix/ and - I fear - there is far too mutch stuff in there (eg: eclipse components, xalan, xerces, ...). I would also like to suggest creating some kind of facility to mantain and moderate the m2 repo (I'm ready to help if needed). - 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] -- 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] - 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: proposed mailing lists names
+1 Brett Porter wrote: Since we've voted to do this, I'm just going to give people 48 hours to object to these particular names. [see MPA-50] Our dev list traffic has gone nuts. Let's create: [EMAIL PROTECTED] * this will be for CI, error reports from the repository manager, and so on * depending on policy, this may not be archived (we won't archive it unless it's required - I don't think it's necessary, but there is no harm in it if it is) * this will be for all maven projects (ie, no continuum-notifications, etc). [EMAIL PROTECTED] * this will be for JIRA issues. For now, just one will be created. If it is later determined to split one set off, we can create more. commits@maven.apache.org * for commits - we already have it (each subproject has its own) dev@maven.apache.org * for human discussion - we already have it Note that all subscribers to dev@maven.apache.org will be automatically subscribed to these lists at creation, but going forward you will need to subscribe to each individually. - Brett - 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: [M2 REPO] mess in /servicemix
That's exactly the problem in this case - they're all in the servicemix groupId. This becomes harmful in transitive dependencies, as there's no way to express equivalence. So if you depend on OSGi and ServiceMix, you get two copies of OSGi, and all its dependencies. - Brett Jason van Zyl wrote: Brett Porter wrote: Sure, but they don't really need to redistribute half of eclipse themselves. How about a simple rule of not allowing the deployment of anything outside that projects groupId. In the case of external dependencies I'm not sure what the best route is because one project could potentially harm another project where snapshots are involved or simply accidentally where an artifact is named incorrectly and overwrites a correctly deployed version. In this case we could make projects use their groupId so those externally pulled in deps can't pollute the repository it only affects that project. I think this would be a decent compromise as it lets projects redistribute according to the license covering the artifacts but they can't harm others. I'm not sure we can easily enforce this now but something the repository manager could do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2 REPO] mess in /servicemix
Brett Porter wrote on Monday, March 06, 2006 2:29 PM: That's exactly the problem in this case - they're all in the servicemix groupId. This becomes harmful in transitive dependencies, as there's no way to express equivalence. So if you depend on OSGi and ServiceMix, you get two copies of OSGi, and all its dependencies. Well, - apart from wasted space on ibiblio - this is ServiceMix' problem. Any application using ServiceMix and OSCi will have the same problem, wether they use Maven or something else to build their app. As soon as one of their customers has another 3rdParty component with an OSCi dependency (or one of all the other assimilated packages), this customer will get in trouble. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2 REPO] mess in /servicemix
You're new to this, aren't you? Everything's Maven's fault! :) Yes, you are right. Anyway, I've pinged a couple of the guys on the project. - Brett Jörg Schaible wrote: Brett Porter wrote on Monday, March 06, 2006 2:29 PM: That's exactly the problem in this case - they're all in the servicemix groupId. This becomes harmful in transitive dependencies, as there's no way to express equivalence. So if you depend on OSGi and ServiceMix, you get two copies of OSGi, and all its dependencies. Well, - apart from wasted space on ibiblio - this is ServiceMix' problem. Any application using ServiceMix and OSCi will have the same problem, wether they use Maven or something else to build their app. As soon as one of their customers has another 3rdParty component with an OSCi dependency (or one of all the other assimilated packages), this customer will get in trouble. - Jörg - 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: [M2 REPO] mess in /servicemix
Brett Porter wrote on Monday, March 06, 2006 2:44 PM: You're new to this, aren't you? Everything's Maven's fault! :) Ups. Right, sorry, I forgot! Damn Maven gets anything wrong ... :D Yes, you are right. Anyway, I've pinged a couple of the guys on the project. Just like the jMock guys always pretend, it is helping a dev to get their architecture right, Maven is doing the same for deps - a whole new use case ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPNATIVE-16) native:compile failure due to invalid compile line (missing space after -o option)
native:compile failure due to invalid compile line (missing space after -o option) -- Key: MPNATIVE-16 URL: http://jira.codehaus.org/browse/MPNATIVE-16 Project: maven-native-plugin Type: Bug Environment: Solaris 8, Maven 2.0, Sun CC, native-maven-plugin 1.0-alpha-1-SNAPSHOT Reporter: Gary Collier Priority: Blocker native:compile fails because the generated compilation command line does not leave a space between the -o switch and the subsequent object file name. This is demonstrated by the pom file and mvn:compile output below. project modelVersion4.0.0/modelVersion groupIdMQ/groupId artifactIdMQ/artifactId nameMan Quant/name packagingso/packaging version1.0-SNAPSHOT/version urlhttp://maven.apache.org/url build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdnative-maven-plugin/artifactId version1.0-alpha-1-SNAPSHOT/version extensionstrue/extensions configuration compilerProvidergeneric/compilerProvider compilerExecutableCC/compilerExecutable linkerExecutableCC/linkerExecutable compilerStartOptions compilerStartOption-g -Kpic/compilerStartOption /compilerStartOptions linkerStartOptions linkerStartOption-b -G/linkerStartOption /linkerStartOptions sources source directorysrc/main/src/directory fileNames fileNameMQCommon.cc/fileName /fileNames /source source directorysrc/main/include/mq/directory /source /sources /configuration /plugin /plugins /build repositories repository idMaven Snapshots/id urlhttp://snapshots.maven.codehaus.org/maven2//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories pluginRepositories pluginRepository idMaven Snapshots/id urlhttp://snapshots.maven.codehaus.org/maven2//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /pluginRepository /pluginRepositories /project $ mvn native:compile [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'native'. [INFO] [INFO] Building Man Quant [INFO]task-segment: [native:compile] [INFO] [INFO] [native:compile] [INFO] CC -g -Kpic -I/users/is/gcollier/SubversionWorking/MQ/src/main/src -I/users/is/gcollier/SubversionWorking/MQ/src/main/include/mq -o/users/is/gcollier/SubversionWorking/MQ/target/MQCommon.o -c /users/is/gcollier/SubversionWorking/MQ/src/main/src/MQCommon.cc CC: Warning: Option -o/users/is/gcollier/SubversionWorking/MQ/target/MQCommon.o passed to ld, if ld is invoked, ignored otherwise [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error: /users/is/gcollier/SubversionWorking/MQ/target/MQCommon.o not found after successfull compilation. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Mon Mar 06 12:09:10 GMT 2006 [INFO] Final Memory: 4M/184M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Improving poms on ibiblio
06-03-06, Grzegorz Słowikowski [EMAIL PROTECTED] napisał(a): Hi Wendy Now I have some time and I started preparing poms for all Tomcat artifacts. I have checked out all modules from svn (tags TOMCAT_5_5_15) and now I'm preparing poms for them. I already see, that I will have many questions. Where can we discuss it all? On Tomcat Bugzilla? Witaj Grzegorz, Isn't it already sorted out? See http://jira.codehaus.org/browse/MAVENUPLOAD-761. Greg Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Created: (MAVENUPLOAD-768) Please upload SIP Servlet API 1.0
Please upload SIP Servlet API 1.0 - Key: MAVENUPLOAD-768 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-768 Project: maven-upload-requests Type: Bug Reporter: Vincent Siveton Attachments: pom.xml The SIP Servlet API defines a high-level extension API for SIP servers. It enables SIP applications to be deployed and managed based on the servlet model. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
Just some things for the record:
- I don't really like the artifact.../artifact element here as it
isn't normal to a POM.
- The POM doesn't do the full inheritence thing, so it might not behave
as expected. This could be confusing
I think if the file is not really a POM, it shouldn't be construed as
one for the sake of clarity. Maybe we can just use the normal Xpp3Dom
configuration lookup, and that can be created from xpp3 dom builder from
a file with just the config element.
I assume if there are project elements to be populated that are not part
of a plugin, they would be set on the stub project housed in the stub
expression evaluator, which could be done in java code?
Also:
- I think we should be adding getters/setters and being able to
construct a normal mojo and set fields by hand (components and
expressions should still be prepopulated in the lookup).
It seems like most of this is in place, just issues of clarity and
perhaps preference.
Thanks again!
- Brett
Jesse McConnell wrote:
we can now inject StubArtifacts into the mojo's :)
project
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
compileSourceRoots
compileSourceRootsrc/main/java/compileSourceRoot
/compileSourceRoots
compilerIdjavac/compilerId
outputDirectorytarget/classes/outputDirectory
artifactorg.apache.maven.artifact.Artifact/artifact
/configuration
/plugin
/plugins
/build
/project
for the time being I am sticking all of the Stub* maven artifacts in the
maven-plugin-testing-harness and they are all referenced in the
components.xml file in the same project. I am not sure if we want them to
ultimately reside next to the Default* implementations or not...anyone have
thoughts on that? I could go either way on that.
I am pretty however pretty happy with the way this is fleshing out :)
very useful and by the time more unit tests are written we should have a
pretty decent set of stub's for mojo's to work with.
Not everything will have to be a stub either here, jason is working on the
ArtifactRepository and aggregating some things together but I can see the
need where we are going to need a real one or more of those since some
plugins make use of it...the axistools plugin for one :)
cheers,
jesse
On 2/23/06, Jesse McConnell [EMAIL PROTECTED] wrote:
updating this thread again
Jason and I talked over the above idea and he took a few minutes and put
together the basic jist of the concept and shoved it into the mojo-sandbox
so I could work with it.
mojo-sandbox/maven-plugin-testing/maven-plugin-testing-harness
that has version 1.0-SNAPSHOT of the AbstractMojoTestCase which is what
the test cases can subclass from to get the ability to dynamically load the
mojo based on an arbitary pom.
I modified the maven-clean-plugin again to make use of this and it turned
out quite well I'd say.
/**
* tests the ability of the plugin to clean out a set of directories
*
* @throws Exception
*/
public void testClean() throws Exception {
CleanMojo mojo = (CleanMojo) lookupMojo (clean, testPom );
assertNotNull( mojo );
mojo.execute();
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildDirectory ) );
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildOutputDirectory ) );
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildTestDirectory ) );
}
This method in the CleanMojoTest class coupled with this pom.xml @
src/test/resources/unit/clean/pom.xml execute the unit test very easily.
project
build
plugins
plugin
artifactIdmaven-clean-plugin/artifactId
configuration
directorytarget/test/testDirectoryStructure/buildDirectory/directory
outputDirectorytarget/test/testDirectoryStructure/buildOutputDirectory/outputDirectory
testOutputDirectorytarget/test/testDirectoryStructure/buildTestDirectory/testOutputDirectory
/configuration
/plugin
/plugins
/build
/project
I am going to take this approach and work on testing another plugin in
maven now, get a couple of plugins under my belt with this and the abstract
base class ought to be pretty tight.
jesse
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tests of 1.0
I updated the matrix : http://docs.codehaus.org/display/SCM/SCM+Matrix Emmanuel Torbjørn Smørgrav a écrit : - since Bazaar, VSS, etc are partially implemented, according to the site, should they be omitted from this release? Or do they do enough to be useful? Can we list what is implemented and what is not? We should at least define when a provider is implemented and not only partially implemented. Now supporting a system before version 1.0 (Bazaar is currently 0.7) is almost by definition partially. However I think its usefull and complete enough to be released. Torbjørn
Re: plugin testing
project
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
compileSourceRoots
compileSourceRoot{$basedir}target/classes/unit/compiler-basic-test/src/main/java/compileSourceRoot
/compileSourceRoots
compilerIdjavac/compilerId
outputDirectory{$basedir}/target/test/unit/compiler-basic-test/target/outputDirectory
artifact implementation=
org.apache.maven.plugin.testing.stubs.StubArtifact/
/configuration
/plugin
/plugins
/build
/project
I should have sent this eariler, but this is actually what that test file is
looking like atm.
jesse
On 3/6/06, Brett Porter [EMAIL PROTECTED] wrote:
Just some things for the record:
- I don't really like the artifact.../artifact element here as it
isn't normal to a POM.
- The POM doesn't do the full inheritence thing, so it might not behave
as expected. This could be confusing
I think if the file is not really a POM, it shouldn't be construed as
one for the sake of clarity. Maybe we can just use the normal Xpp3Dom
configuration lookup, and that can be created from xpp3 dom builder from
a file with just the config element.
I assume if there are project elements to be populated that are not part
of a plugin, they would be set on the stub project housed in the stub
expression evaluator, which could be done in java code?
Also:
- I think we should be adding getters/setters and being able to
construct a normal mojo and set fields by hand (components and
expressions should still be prepopulated in the lookup).
It seems like most of this is in place, just issues of clarity and
perhaps preference.
Thanks again!
- Brett
Jesse McConnell wrote:
we can now inject StubArtifacts into the mojo's :)
project
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
compileSourceRoots
compileSourceRootsrc/main/java/compileSourceRoot
/compileSourceRoots
compilerIdjavac/compilerId
outputDirectorytarget/classes/outputDirectory
artifactorg.apache.maven.artifact.Artifact/artifact
/configuration
/plugin
/plugins
/build
/project
for the time being I am sticking all of the Stub* maven artifacts in the
maven-plugin-testing-harness and they are all referenced in the
components.xml file in the same project. I am not sure if we want them
to
ultimately reside next to the Default* implementations or not...anyone
have
thoughts on that? I could go either way on that.
I am pretty however pretty happy with the way this is fleshing out :)
very useful and by the time more unit tests are written we should have a
pretty decent set of stub's for mojo's to work with.
Not everything will have to be a stub either here, jason is working on
the
ArtifactRepository and aggregating some things together but I can see
the
need where we are going to need a real one or more of those since some
plugins make use of it...the axistools plugin for one :)
cheers,
jesse
On 2/23/06, Jesse McConnell [EMAIL PROTECTED] wrote:
updating this thread again
Jason and I talked over the above idea and he took a few minutes and
put
together the basic jist of the concept and shoved it into the
mojo-sandbox
so I could work with it.
mojo-sandbox/maven-plugin-testing/maven-plugin-testing-harness
that has version 1.0-SNAPSHOT of the AbstractMojoTestCase which is what
the test cases can subclass from to get the ability to dynamically load
the
mojo based on an arbitary pom.
I modified the maven-clean-plugin again to make use of this and it
turned
out quite well I'd say.
/**
* tests the ability of the plugin to clean out a set of
directories
*
* @throws Exception
*/
public void testClean() throws Exception {
CleanMojo mojo = (CleanMojo) lookupMojo (clean, testPom );
assertNotNull( mojo );
mojo.execute();
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildDirectory ) );
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildOutputDirectory ) );
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildTestDirectory ) );
}
This method in the CleanMojoTest class coupled with this pom.xml @
src/test/resources/unit/clean/pom.xml execute the unit test very
easily.
project
build
plugins
plugin
artifactIdmaven-clean-plugin/artifactId
configuration
directorytarget/test/testDirectoryStructure/buildDirectory/directory
outputDirectorytarget/test/testDirectoryStructure/buildOutputDirectory/outputDirectory
testOutputDirectorytarget/test/testDirectoryStructure/buildTestDirectory/testOutputDirectory
/configuration
[jira] Created: (MIDEA-31) idea mojo doesn't work with dependency with classifier
idea mojo doesn't work with dependency with classifier -- Key: MIDEA-31 URL: http://jira.codehaus.org/browse/MIDEA-31 Project: Maven 2.x Idea Plugin Type: Bug Versions: 2.0 Reporter: Emmanuel Venisse Assigned to: Edwin Punzalan Priority: Blocker Fix For: 2.0 dependency like : dependency groupIdpostgresql/groupId artifactIdpostgresql/artifactId version7.4.1/version classifierjdbc3/classifier scopetest/scope /dependency fail idea mojo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: [m2] Howto custom CharsetProvider implementations ?]
Hi, I am forwarding this to the dev mailing list since I got no answer on the users list. Any ideas or workarounds highly appreciated. Ursprüngliche Nachricht - Betreff: [m2] Howto custom CharsetProvider implementations ? Von: Christian Schulte [EMAIL PROTECTED] Datum: Do, Februar 23, 2006 12:04 An: users@maven.apache.org -- Hi, I have a problem with unit testing custom charset provider implementations. In some module I have a src/main/resources/META-INF/services/java.nio.charset.spi.CharsetProvider file defining custom charsets implemented in the same module. The jar file produced with this module works outside of maven. When I now reference this module during unit testing as a dependency in some other module the custom charset providers are not available. What is the correct way of using the custom charset providers during build time ? Everything works correctly outside of maven. During the build the custom charset providers are not available to the classloader loading these charsets. I really need to use the custom charsets during build time. -- Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
Cool. so I was thinking we could drop all the wrapping elements to make it:
Jesse McConnell wrote:
configuration
compileSourceRoots
compileSourceRoot{$basedir}target/classes/unit/compiler-basic-test/src/main/java/compileSourceRoot
/compileSourceRoots
compilerIdjavac/compilerId
outputDirectory{$basedir}/target/test/unit/compiler-basic-test/target/outputDirectory
artifact implementation=
org.apache.maven.plugin.testing.stubs.StubArtifact/
/configuration
This raises another question:
artifact implementation=
org.apache.maven.plugin.testing.stubs.StubArtifact/
Do these have default implementations when the harness is in play?
Trying to think if that is even possible...
Having extended PlexusTestCase, you can already do that by:
TestCaseName.xml:
[...]
component
roleo.a.m.a.Artifact/role
implementationo.a.m.p.t.s.StubArtifact/implemnetation
/component
[...]
Not sure I really prefer that, of course. Still like to write Java
tests, but alternatives are good :)
Also, I assume its ${basedir} and you haven't changed the behaviour of
the expression eval? :)
Cheers,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r380051 - in /maven/repository-manager/trunk/maven-repository-webapp: ./ src/main/java/org/apache/maven/repository/manager/web/action/ src/main/resources/ src/main/webapp/WEB-INF/ src/
ping
Brett Porter wrote:
Why was this needed?
[EMAIL PROTECTED] wrote:
configuration
+
webAppSourceDirectory${basedir}/target/${artifactId}/webAppSourceDirectory
scanIntervalSeconds10/scanIntervalSeconds
- contextPath//contextPath
/configuration
-
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]
[jira] Closed: (CONTINUUM-615) Add maven.scm.starteam.deleteLocal=true to DefaultContinuumScm
[ http://jira.codehaus.org/browse/CONTINUUM-615?page=all ] Emmanuel Venisse closed CONTINUUM-615: -- Assign To: Emmanuel Venisse Resolution: Fixed Applied. Thanks. Add maven.scm.starteam.deleteLocal=true to DefaultContinuumScm -- Key: CONTINUUM-615 URL: http://jira.codehaus.org/browse/CONTINUUM-615 Project: Continuum Type: Improvement Versions: 1.0.2 Environment: starteam xp Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0.3 Attachments: CONTINUUM-615.patch this property is crucial for starteam operation under Continuum see http://jira.codehaus.org/browse/SCM-67 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-354) Need a way to poll for new projects
[ http://jira.codehaus.org/browse/CONTINUUM-354?page=all ] Emmanuel Venisse updated CONTINUUM-354: --- Assign To: (was: nick gonzalez) Fix Version: (was: 1.0.3) 1.1 Need a way to poll for new projects --- Key: CONTINUUM-354 URL: http://jira.codehaus.org/browse/CONTINUUM-354 Project: Continuum Type: Improvement Versions: 1.0-beta-1 Reporter: Matthew Beermann Fix For: 1.1 The feature where Continuum can populate its build list from a URL is wonderful; it'd be even more wonderful if it could remember that URL and poll it periodically. We have a master build list of all projects that we'll use to initially populate the build database; but ideally we could simply add a new project to that in CVS and have Continuum just pick it up. This is a feature that we've (somewhat painfully) managed to implement in CruiseControl, and it's a must-have if we're going to switch over... this might or might not depend on CONTINUUM-330. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: plugin testing
works for things like the artifact, but MavenProject isn't a component and I
can't use a role lookup on it, that was my first direction where I used
components.xml for stub role-hint versions of things..
${basedir} works the same as before, I ended up pulling that part out and
putting it into the StubExpressionEvaluator that I made since we don't have
project instances and things to initialize the maven expression evaluator
with.
jesse
On 3/6/06, Brett Porter [EMAIL PROTECTED] wrote:
Cool. so I was thinking we could drop all the wrapping elements to make
it:
Jesse McConnell wrote:
configuration
compileSourceRoots
compileSourceRoot{$basedir}target/classes/unit/compiler-basic-test/src/main/java/compileSourceRoot
/compileSourceRoots
compilerIdjavac/compilerId
outputDirectory{$basedir}/target/test/unit/compiler-basic-test/target/outputDirectory
artifact implementation=
org.apache.maven.plugin.testing.stubs.StubArtifact/
/configuration
This raises another question:
artifact implementation=
org.apache.maven.plugin.testing.stubs.StubArtifact/
Do these have default implementations when the harness is in play?
Trying to think if that is even possible...
Having extended PlexusTestCase, you can already do that by:
TestCaseName.xml:
[...]
component
roleo.a.m.a.Artifact/role
implementationo.a.m.p.t.s.StubArtifact/implemnetation
/component
[...]
Not sure I really prefer that, of course. Still like to write Java
tests, but alternatives are good :)
Also, I assume its ${basedir} and you haven't changed the behaviour of
the expression eval? :)
Cheers,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
[jira] Updated: (CONTINUUM-580) Fails to build on OS X
[ http://jira.codehaus.org/browse/CONTINUUM-580?page=all ] Emmanuel Venisse updated CONTINUUM-580: --- Fix Version: (was: 1.0.3) Fails to build on OS X -- Key: CONTINUUM-580 URL: http://jira.codehaus.org/browse/CONTINUUM-580 Project: Continuum Type: Bug Components: Core system Environment: OS X Reporter: Henri Yandell Attachments: org.apache.maven.continuum.it.ShellIntegrationTest.txt The build currently does not complete from the 1.0.x branch of Continuum. An error occurs in the ShellIntegrationTest (see attachment). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-589) Configure JPOX to use a database pool
[ http://jira.codehaus.org/browse/CONTINUUM-589?page=all ] Emmanuel Venisse updated CONTINUUM-589: --- Fix Version: (was: 1.0.3) Configure JPOX to use a database pool - Key: CONTINUUM-589 URL: http://jira.codehaus.org/browse/CONTINUUM-589 Project: Continuum Type: Improvement Components: Core system Reporter: Emmanuel Venisse http://www.jpox.org/docs/faq.html#datasource_pools -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-609) Continuum deployment repository
[ http://jira.codehaus.org/browse/CONTINUUM-609?page=all ] Emmanuel Venisse updated CONTINUUM-609: --- Fix Version: (was: 1.0.3) 1.1 Continuum deployment repository --- Key: CONTINUUM-609 URL: http://jira.codehaus.org/browse/CONTINUUM-609 Project: Continuum Type: Improvement Components: Core system Reporter: Brett Porter Fix For: 1.1 What I was thinking of was having Continuum be configured to have a repository that is the default location for deploying JARs to and that can be served up without requiring an additional web server. This would make configuration of a snapshot repository much simpler. I'm thinking this wouldn't be required in the POM at all - that even though the goals are clean install, that Continuum would deploy to this repository itself after the build completed successfully. Using deploy wouldn't be desirable because you might accidentally wind up deploying a release which is probably not what you want. I was thinking this is purely a deployment repository, so would not be the local repository for continuum at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-618) Refresh after Build Now create multiple builds
[ http://jira.codehaus.org/browse/CONTINUUM-618?page=all ] Emmanuel Venisse updated CONTINUUM-618: --- Fix Version: (was: 1.0.3) 1.1-alpha-1 Refresh after Build Now create multiple builds Key: CONTINUUM-618 URL: http://jira.codehaus.org/browse/CONTINUUM-618 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Environment: xp Reporter: Dan Tran Fix For: 1.1-alpha-1 After hitting build now, the browser pauses for sometime and user loses patient by hitting multiple refreshes creating multiple forced builds For a long build, it can be very annoyed. Worst, we user put up a daily release build in Continuum, it will cause multiple release builds -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Fwd: [m2] Howto custom CharsetProvider implementations ?]
Christian Schulte wrote: Hi, I am forwarding this to the dev mailing list since I got no answer on the users list. Generally better to just send a gentle reminder in reply on the users list. Any ideas or workarounds highly appreciated. No idea off the top of my head, but it sounds familiar. Have you searched the archive for something similar? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONTINUUM-609) Continuum deployment repository
[ http://jira.codehaus.org/browse/CONTINUUM-609?page=all ] Emmanuel Venisse updated CONTINUUM-609: --- Assign To: Brett Porter Fix Version: (was: 1.1) 1.0.3 Continuum deployment repository --- Key: CONTINUUM-609 URL: http://jira.codehaus.org/browse/CONTINUUM-609 Project: Continuum Type: Improvement Components: Core system Reporter: Brett Porter Assignee: Brett Porter Fix For: 1.0.3 What I was thinking of was having Continuum be configured to have a repository that is the default location for deploying JARs to and that can be served up without requiring an additional web server. This would make configuration of a snapshot repository much simpler. I'm thinking this wouldn't be required in the POM at all - that even though the goals are clean install, that Continuum would deploy to this repository itself after the build completed successfully. Using deploy wouldn't be desirable because you might accidentally wind up deploying a release which is probably not what you want. I was thinking this is purely a deployment repository, so would not be the local repository for continuum at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r382337 - in /maven/repository-manager/trunk/maven-repository-webapp: ./ src/main/java/org/apache/maven/repository/manager/web/action/ src/main/java/org/apache/maven/repository/manager
ping
Emmanuel Venisse a écrit :
I think it will be better to use a logger instead of System.out.println
in DiscoverJob.
Emmanuel
[EMAIL PROTECTED] a écrit :
Author: epunzalan
Date: Thu Mar 2 01:53:40 2006
New Revision: 382337
URL: http://svn.apache.org/viewcvs?rev=382337view=rev
Log:
PR: MRM-36
Submitted by: Maria Odea Ching
Applied patch for discovery and indexing schedule
Added:
maven/repository-manager/trunk/maven-repository-webapp/src/main/java/org/apache/maven/repository/manager/web/action/BaseAction.java
maven/repository-manager/trunk/maven-repository-webapp/src/main/java/org/apache/maven/repository/manager/web/job/DiscovererJob.java
maven/repository-manager/trunk/maven-repository-webapp/src/main/java/org/apache/maven/repository/manager/web/job/DiscovererScheduler.java
Modified:
maven/repository-manager/trunk/maven-repository-webapp/pom.xml
maven/repository-manager/trunk/maven-repository-webapp/src/main/java/org/apache/maven/repository/manager/web/job/Configuration.java
maven/repository-manager/trunk/maven-repository-webapp/src/main/resources/xwork.xml
maven/repository-manager/trunk/maven-repository-webapp/src/main/webapp/WEB-INF/jsp/browse.jsp
maven/repository-manager/trunk/maven-repository-webapp/src/main/webapp/WEB-INF/jsp/form.jspf
maven/repository-manager/trunk/maven-repository-webapp/src/main/webapp/WEB-INF/jsp/generalresults.jsp
maven/repository-manager/trunk/maven-repository-webapp/src/main/webapp/WEB-INF/jsp/results.jsp
maven/repository-manager/trunk/maven-repository-webapp/src/main/webapp/WEB-INF/plexus.xml
Modified: maven/repository-manager/trunk/maven-repository-webapp/pom.xml
URL:
http://svn.apache.org/viewcvs/maven/repository-manager/trunk/maven-repository-webapp/pom.xml?rev=382337r1=382336r2=382337view=diff
==
--- maven/repository-manager/trunk/maven-repository-webapp/pom.xml
(original)
+++ maven/repository-manager/trunk/maven-repository-webapp/pom.xml Thu
Mar 2 01:53:40 2006
@@ -42,7 +42,7 @@
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty6-plugin/artifactId
configuration
-
webAppSourceDirectory${basedir}/target/${artifactId}/webAppSourceDirectory
+
webAppSourceDirectory${basedir}/target/${artifactId}/webAppSourceDirectory
scanIntervalSeconds10/scanIntervalSeconds
/configuration
/plugin
Added:
maven/repository-manager/trunk/maven-repository-webapp/src/main/java/org/apache/maven/repository/manager/web/action/BaseAction.java
URL:
http://svn.apache.org/viewcvs/maven/repository-manager/trunk/maven-repository-webapp/src/main/java/org/apache/maven/repository/manager/web/action/BaseAction.java?rev=382337view=auto
==
---
maven/repository-manager/trunk/maven-repository-webapp/src/main/java/org/apache/maven/repository/manager/web/action/BaseAction.java
(added)
+++
maven/repository-manager/trunk/maven-repository-webapp/src/main/java/org/apache/maven/repository/manager/web/action/BaseAction.java
Thu Mar 2 01:53:40 2006
@@ -0,0 +1,57 @@
+package org.apache.maven.repository.manager.web.action;
+
+/*
+ * Copyright 2005-2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import com.opensymphony.xwork.Action;
+import org.apache.maven.repository.manager.web.job.DiscovererScheduler;
+
+/**
+ * This is the Action class of index.jsp, which is the initial page
of the web application.
+ * It invokes the DiscovererScheduler to set the DiscoverJob in the
scheduler.
+ *
+ * @plexus.component role=com.opensymphony.xwork.Action
role-hint=org.apache.maven.repository.manager.web.action.BaseAction
+ */
+public class BaseAction
+implements Action
+{
+
+/**
+ * @plexus.requirement
+ */
+private DiscovererScheduler discovererScheduler;
+
+/**
+ * Method that executes the action
+ *
+ * @return a String that specifies if the action executed was a
success or a failure
+ */
+public String execute()
+{
+try
+{
+discovererScheduler.setSchedule();
+}
+catch ( Exception e )
+{
+e.printStackTrace();
+return ERROR;
+}
+
+return SUCCESS;
+}
+
+}
Modified:
release diaries and 2.0.3
http://docs.codehaus.org/display/MAVEN/2.0.1+Release+Diary http://docs.codehaus.org/display/MAVEN/2.0.2+Release+Diary http://docs.codehaus.org/display/MAVEN/2.0.3+Release+Diary Is it possible these could be brought together into a cohesive set of instructions as a result of this release? It would need to add those 2 issues in jira that are outstanding as part of the release process. The goal would then be to cut as much out of it through automation as possible ;) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Mon Mar 6 14:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060306.143000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060306.143000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build branches/continuum-1.0.x - SUCCESS - update] Mon Mar 6 14:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060306.143000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060306.143000.txt
Re: [M2 REPO] mess in /servicemix
Brett Porter wrote: That's exactly the problem in this case - they're all in the servicemix groupId. This becomes harmful in transitive dependencies, as there's no way to express equivalence. So if you depend on OSGi and ServiceMix, you get two copies of OSGi, and all its dependencies. Projects are always going to do this for the sake of expediency and under the license they can. They obviously did this as not to claim to have provided the official JARs which I think is correct and being a good citizen. This is going to happen again I'm sure because projects don't want to push the official project JARs into the repository. For highly used components do we just push them in, maybe a flag on the dependency to indicate this scenerio? We definitely prefer that projects themselves issue to the repository but this isn't always going to happen and we should probably account for it. Jason van Zyl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Development Process
Hi, If anyone has anything to add take a peek at: http://docs.codehaus.org/display/MAVEN/Development+Process Nothing is cast in stone but would be nice to get some feedback as only four people I know of have taken a look. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2125) [doc] when and how to define plugins in a pom
[doc] when and how to define plugins in a pom - Key: MNG-2125 URL: http://jira.codehaus.org/browse/MNG-2125 Project: Maven 2 Type: Improvement Components: POM, Plugins and Lifecycle, Documentation: Faqs, Design, Patterns Best Practices Reporter: Brett Porter some simple rules to document 1) define lifecycle per packaging, according to default behaviour 2) if a project needs to add a mojo, use execution/ + phase/ (if needed) 3) if a project needs to remove a mojo, make mojo configurable such that it can be skipped via POM configuration 4) if there is a pattern in common for adjusting lifecycle for several projects, define a new packaging -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tests of 1.0
It runs fine for me on linux, cygwin and WinXP. Can you give me the junit log? Regards Torbjørn -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 6. mars 2006 11:39 To: scm-dev@maven.apache.org Subject: Re: Tests of 1.0 Torbjørn Smørgrav wrote: Currently, the Bazaar provider tests fail for me under Windows (I have Bazaar installed in Cygwin). What version of bazaar do you use? (Version 0.7 is the current stable, pre 0.7 is failing on *nix like systems) $ bzr --version bzr (bazaar-ng) 0.7 Copyright 2005,06 Canonical Development Ltd. http://bazaar-ng.org/ I'd actually like to have the tests not require svn, cvs, bzr installed to pass, and move those tests to integration tests in some way. WDYT? I agree. But it's a dangerous decision. It will end up in broken baselines (providers) more often. We should encourage developers eg. myself to test with every provider. What about a configuration option? That's exactly what I meant - make it an integration test (perhaps in a profile) so that the builds only run unit tests (which should still do most of the testing, and just compare command lines rather than execute them). The integration tests can be run in an integration environment where the VCSs are installed (obviously, some will be limited to particular ones). This isn't required before 1.0, but the tests need to pass before 1.0. - Brett
[jira] Created: (WAGONSSH-42) Cannot deploy files over existing files if someone else originally uploaded them.
Cannot deploy files over existing files if someone else originally uploaded them. - Key: WAGONSSH-42 URL: http://jira.codehaus.org/browse/WAGONSSH-42 Project: wagon-ssh Type: Bug Versions: 1.0-alpha-6 Environment: Desktop OS is Windows XP. Deploying to Solaris server using Tectia SSH2 Client. Reporter: Frank Russo Priority: Critical Attachments: File sharing issue with maven-deploy using wagon.txt On first deploy, everything works fine. On next deploy, if a different developer runs the command, the attached error occurs(see attached the original email posted to the Maven Users Mailing List.) The file is owned by the first developer, but has full rwx access (777). If developer 2 directly connects to the machine, they can do anything to the file, so it's not a Unix permissions issue... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2 REPO] mess in /servicemix
When we implement something like provides, so that these can say treat me like the real one if it ever turns up, then this is probably a reasonably expedient way. I'd much rather they use a private repo where they can do what they want until they get it into ibiblio. I think that's a better solution. WDYT? - Brett Jason van Zyl wrote: Brett Porter wrote: That's exactly the problem in this case - they're all in the servicemix groupId. This becomes harmful in transitive dependencies, as there's no way to express equivalence. So if you depend on OSGi and ServiceMix, you get two copies of OSGi, and all its dependencies. Projects are always going to do this for the sake of expediency and under the license they can. They obviously did this as not to claim to have provided the official JARs which I think is correct and being a good citizen. This is going to happen again I'm sure because projects don't want to push the official project JARs into the repository. For highly used components do we just push them in, maybe a flag on the dependency to indicate this scenerio? We definitely prefer that projects themselves issue to the repository but this isn't always going to happen and we should probably account for it. Jason van Zyl - 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: Tests of 1.0
Oh, got it sorted out. Had to install the real python and bzr, not the cygwin versions of such. See updated readme. - Brett Torbjørn Smørgrav wrote: It runs fine for me on linux, cygwin and WinXP. Can you give me the junit log? Regards Torbjørn -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 6. mars 2006 11:39 To: scm-dev@maven.apache.org Subject: Re: Tests of 1.0 Torbjørn Smørgrav wrote: Currently, the Bazaar provider tests fail for me under Windows (I have Bazaar installed in Cygwin). What version of bazaar do you use? (Version 0.7 is the current stable, pre 0.7 is failing on *nix like systems) $ bzr --version bzr (bazaar-ng) 0.7 Copyright 2005,06 Canonical Development Ltd. http://bazaar-ng.org/ I'd actually like to have the tests not require svn, cvs, bzr installed to pass, and move those tests to integration tests in some way. WDYT? I agree. But it's a dangerous decision. It will end up in broken baselines (providers) more often. We should encourage developers eg. myself to test with every provider. What about a configuration option? That's exactly what I meant - make it an integration test (perhaps in a profile) so that the builds only run unit tests (which should still do most of the testing, and just compare command lines rather than execute them). The integration tests can be run in an integration environment where the VCSs are installed (obviously, some will be limited to particular ones). This isn't required before 1.0, but the tests need to pass before 1.0. - Brett
[jira] Created: (MRELEASE-82) SvnTagCommand doesn't work?
SvnTagCommand doesn't work?
---
Key: MRELEASE-82
URL: http://jira.codehaus.org/browse/MRELEASE-82
Project: Maven 2.x Release Plugin
Type: Bug
Reporter: Gareth Williams
mvn release:prepare fails with the following output:
Provider message:
The svn tag command failed.
Command output:
svn: Local, non-commit operations do not take a log message
Have looked at source, and suspect SvnTagCommand needs to be fixed - in SVN the
copy command does not accept a log message
Package:org.apache.maven.scm.provider.svn.svnexe.command.tag
Class: SvnTagCommand
private static Commandline createCommandLine( SvnScmProviderRepository
repository, File workingDirectory,
String tag, File messageFile )
{
cl.createArgument().setValue( copy );
XXXcl.createArgument().setValue( --file );
XXXcl.createArgument().setValue( messageFile.getAbsolutePath() );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Mon Mar 6 15:15:02 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060306.151503.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060306.151503.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCM-170) SvnTagCommand doesn't work?
[ http://jira.codehaus.org/browse/SCM-170?page=all ]
Brett Porter updated SCM-170:
-
Priority: Critical (was: Major)
Fix Version: 1.0
SvnTagCommand doesn't work?
---
Key: SCM-170
URL: http://jira.codehaus.org/browse/SCM-170
Project: Maven SCM
Type: Bug
Reporter: Gareth Williams
Priority: Critical
Fix For: 1.0
mvn release:prepare fails with the following output:
Provider message:
The svn tag command failed.
Command output:
svn: Local, non-commit operations do not take a log message
Have looked at source, and suspect SvnTagCommand needs to be fixed - in SVN
the copy command does not accept a log message
Package: org.apache.maven.scm.provider.svn.svnexe.command.tag
Class:SvnTagCommand
private static Commandline createCommandLine( SvnScmProviderRepository
repository, File workingDirectory,
String tag, File
messageFile )
{
cl.createArgument().setValue( copy );
XXXcl.createArgument().setValue( --file );
XXXcl.createArgument().setValue( messageFile.getAbsolutePath() );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [M2 REPO] mess in /servicemix
Brett Porter wrote: When we implement something like provides, so that these can say treat me like the real one if it ever turns up, then this is probably a reasonably expedient way. The meaning of provides/ is really i am the real one, but an equivalent _will_ show up. I'd much rather they use a private repo where they can do what they want until they get it into ibiblio. I think that's a better solution. WDYT? That's probably the best solution. Anyone can still build against a project hosted repository and it stays out of the ibiblio population. Then the project can take whatever measures to get the real dependencies to ibiblio but everything can still function. Sounds like a good concept to promote. - Brett Jason van Zyl wrote: Brett Porter wrote: That's exactly the problem in this case - they're all in the servicemix groupId. This becomes harmful in transitive dependencies, as there's no way to express equivalence. So if you depend on OSGi and ServiceMix, you get two copies of OSGi, and all its dependencies. Projects are always going to do this for the sake of expediency and under the license they can. They obviously did this as not to claim to have provided the official JARs which I think is correct and being a good citizen. This is going to happen again I'm sure because projects don't want to push the official project JARs into the repository. For highly used components do we just push them in, maybe a flag on the dependency to indicate this scenerio? We definitely prefer that projects themselves issue to the repository but this isn't always going to happen and we should probably account for it. Jason van Zyl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Development Process
Perhaps we can add something about the use of priority (if correct) and then votes to schedule issues that are in the unscheduled bucket? These are highly diluted across all those plugins now, but we could pull them together at some point. It would be a good practice for core, continuum, etc. - Brett Jason van Zyl wrote: Hi, If anyone has anything to add take a peek at: http://docs.codehaus.org/display/MAVEN/Development+Process Nothing is cast in stone but would be nice to get some feedback as only four people I know of have taken a look. Jason. - 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: [jira] Commented: (MNG-1766) release:prepare should not require multimodule artifacts to be in the local repository
John, any chance you remember the answer to this? I just had the message flagged. - Brett Brett Porter wrote: Project references - I assume you mean project.getArtifact() ? This can only happen when the artifact is created (or a semblance of it) - ie at compile, package, install phases where it is target/classes, target/XXX.jar or the local repository versions respectively. - Brett John Casey (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-1766?page=comments#action_52916 ] John Casey commented on MNG-1766: - appears that the project references aren't being resolved correctly. I'll have to attach a debugger and figure out why. UPDATE: To duplicate this problem, you actually need to: 1. Remove all traces of org/apache/maven/it2002/* from your local repo 2. Comment out the line: 'mvn clean install' in it2002/test.sh 3. Run test.sh in it2002 dir. release:prepare should not require multimodule artifacts to be in the local repository -- Key: MNG-1766 URL: http://jira.codehaus.org/browse/MNG-1766 Project: Maven 2 Type: Bug Components: maven-release-plugin Versions: 2.0.1 Reporter: John Casey Assignee: John Casey Fix For: 2.0.2 Currently, if you try to run release:prepare on a multimodule project after removing any of that build's artifacts from the local repository, it will fail. Investigate why release:prepare needs the multimodule artifacts installed in the local repository before it can succeed. To reproduce, comment the following line in it2002/test.sh: mvn clean install NOTE: This may have to do with the version resolution code, which is used to resolve SNAPSHOT versions. - 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: plugin testing
Brett Porter wrote: Just some things for the record: - I don't really like the artifact.../artifact element here as it isn't normal to a POM. - The POM doesn't do the full inheritence thing, so it might not behave as expected. This could be confusing I think if the file is not really a POM, it shouldn't be construed as one for the sake of clarity. Maybe we can just use the normal Xpp3Dom configuration lookup, and that can be created from xpp3 dom builder from a file with just the config element. This was just the first stage. I just whacked in the DOM reader because we need some more testing code to create a local repository for the MavenProjectBuilder. The MavenProjectBuilder should be used. I assume if there are project elements to be populated that are not part of a plugin, they would be set on the stub project housed in the stub expression evaluator, which could be done in java code? Also: - I think we should be adding getters/setters and being able to construct a normal mojo and set fields by hand (components and expressions should still be prepopulated in the lookup). Why? I don't think you should have to add methods in order to be able to test the mojos. It's not how they would ever be used, so you're not really testing how they would be used in the field by adding properties. I think the POM style testing will be most familiar to people writing plugins and ultimately allows for completely declarative testing of Mojos which I think would be excellent. In almost all cases you have to execute the mojo in order to test it and in order to execute it you need to populate the configuration elements. You could very clearly outline different test scenerios using different POMs. You could do this in Java but does it really matter if the inputs come via Java or another mechanism? I honestly don't think so. At any rate I don't think you should alter classes for testing. Especially in this case as we know Mojos work just fine without properties. I think the Artifact/MavenProject population could use a little tweaking but we could probably do that with a special expression evaluator. I think people writing tests will like this declarative method of writing tests. It will be less error prone and take less effort and provide a standard way for writing Mojo tests. That was what I thought was beautiful about SuiteRunner, the same notions I pushed into Surefire, where test invocation can come from anywhere: Java, XML, text files. The same idea used in Fitnesse where users can write tests for webapps using simple markup. I think we can easily provide some Java code for those that want to do the Java thing but I imagine the desire to do that would fade given the declarative option. But you still shouldn't have to add properties to a mojo to make that work unless that's what you wanted to do to make it reusable. It seems like most of this is in place, just issues of clarity and perhaps preference. Thanks again! - Brett Jesse McConnell wrote: we can now inject StubArtifacts into the mojo's :) project build plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration compileSourceRoots compileSourceRootsrc/main/java/compileSourceRoot /compileSourceRoots compilerIdjavac/compilerId outputDirectorytarget/classes/outputDirectory artifactorg.apache.maven.artifact.Artifact/artifact /configuration /plugin /plugins /build /project for the time being I am sticking all of the Stub* maven artifacts in the maven-plugin-testing-harness and they are all referenced in the components.xml file in the same project. I am not sure if we want them to ultimately reside next to the Default* implementations or not...anyone have thoughts on that? I could go either way on that. I am pretty however pretty happy with the way this is fleshing out :) very useful and by the time more unit tests are written we should have a pretty decent set of stub's for mojo's to work with. Not everything will have to be a stub either here, jason is working on the ArtifactRepository and aggregating some things together but I can see the need where we are going to need a real one or more of those since some plugins make use of it...the axistools plugin for one :) cheers, jesse On 2/23/06, Jesse McConnell [EMAIL PROTECTED] wrote: updating this thread again Jason and I talked over the above idea and he took a few minutes and put together the basic jist of the concept and shoved it into the mojo-sandbox so I could work with it. mojo-sandbox/maven-plugin-testing/maven-plugin-testing-harness that has version 1.0-SNAPSHOT of the AbstractMojoTestCase which is what the test cases can subclass from to get the ability to dynamically load the mojo based on an arbitary pom. I modified the maven-clean-plugin again to make use of this and it turned out quite well I'd say. /** * tests the
Re: plugin testing
Jason van Zyl wrote: This was just the first stage. I just whacked in the DOM reader because we need some more testing code to create a local repository for the MavenProjectBuilder. The MavenProjectBuilder should be used. A stub of the maven project builder, or the real one? The real one uses the repo, and that's not really conducive to unit testing. Why? I don't think you should have to add methods in order to be able to test the mojos. It's not how they would ever be used, so you're not really testing how they would be used in the field by adding properties. At one point, we were doing away with private field injection and recommending setters, so it is how they'd be used. I think the POM style testing will be most familiar to people writing plugins and ultimately allows for completely declarative testing of Mojos which I think would be excellent. In almost all cases you have to execute the mojo in order to test it and in order to execute it you need to populate the configuration elements. You could very clearly outline different test scenerios using different POMs. You could do this in Java but does it really matter if the inputs come via Java or another mechanism? I honestly don't think so. No, neither do I. I said having both is a good idea, but that calling it a POM is misleading, and to cut it back to just a configuration. At any rate I don't think you should alter classes for testing. Especially in this case as we know Mojos work just fine without properties. But they *are* properties, it's just a matter of whether it is injected using private fields, setters or constructors. Adding getters is probably a bit more lame, but I think that's unavoidable in either case. I think the Artifact/MavenProject population could use a little tweaking but we could probably do that with a special expression evaluator. Cool. I have to look at the actual code yet... I think people writing tests will like this declarative method of writing tests. It will be less error prone and take less effort and provide a standard way for writing Mojo tests. In some cases, but when you are only setting one field, its a pain, and when you are doing the same thing over and over and changing one field, it's a pain (though you could combine the two techniques for that). I think we can easily provide some Java code for those that want to do the Java thing but I imagine the desire to do that would fade given the declarative option. But you still shouldn't have to add properties to a mojo to make that work unless that's what you wanted to do to make it reusable. As long as the assertions are still in Java, I don't think its a declarative option, and I'd prefer to have my pre-conditions next to the post-conditions to make the tests more readable, myself. But, we can do both, and learn from experience which works, right? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
On 3/6/06, Brett Porter [EMAIL PROTECTED] wrote: Jason van Zyl wrote: This was just the first stage. I just whacked in the DOM reader because we need some more testing code to create a local repository for the MavenProjectBuilder. The MavenProjectBuilder should be used. A stub of the maven project builder, or the real one? The real one uses the repo, and that's not really conducive to unit testing. the repo will need to be real at some point, some plugins needs to interact with the real thing, for getting jars for packaging or for just looking into for resources or something..so the artifact repo seems to be a required part of actual unit tests.. Why? I don't think you should have to add methods in order to be able to test the mojos. It's not how they would ever be used, so you're not really testing how they would be used in the field by adding properties. At one point, we were doing away with private field injection and recommending setters, so it is how they'd be used. I think the POM style testing will be most familiar to people writing plugins and ultimately allows for completely declarative testing of Mojos which I think would be excellent. In almost all cases you have to execute the mojo in order to test it and in order to execute it you need to populate the configuration elements. You could very clearly outline different test scenerios using different POMs. You could do this in Java but does it really matter if the inputs come via Java or another mechanism? I honestly don't think so. No, neither do I. I said having both is a good idea, but that calling it a POM is misleading, and to cut it back to just a configuration. simple, I'll take care of this today... plugin-config.xml maybe? At any rate I don't think you should alter classes for testing. Especially in this case as we know Mojos work just fine without properties. But they *are* properties, it's just a matter of whether it is injected using private fields, setters or constructors. Adding getters is probably a bit more lame, but I think that's unavoidable in either case? I think we can get away with all this without actually needing to add getters and setters, personally I think adding setters somewhat clouds the interaction with mojo's, have a combo of setters and private field injection seems prone to some kind of abuse I think the Artifact/MavenProject population could use a little tweaking but we could probably do that with a special expression evaluator. Cool. I have to look at the actual code yet... I think people writing tests will like this declarative method of writing tests. It will be less error prone and take less effort and provide a standard way for writing Mojo tests. In some cases, but when you are only setting one field, its a pain, and when you are doing the same thing over and over and changing one field, it's a pain (though you could combine the two techniques for that). I was getting visions of people just making one test pom and either reusing or copying and modifying a bit. I think we can easily provide some Java code for those that want to do the Java thing but I imagine the desire to do that would fade given the declarative option. But you still shouldn't have to add properties to a mojo to make that work unless that's what you wanted to do to make it reusable. As long as the assertions are still in Java, I don't think its a declarative option, and I'd prefer to have my pre-conditions next to the post-conditions to make the tests more readable, myself. I agree with you here, it is disjointed to have the configuration and the asserts in another place...but if we are going to route of a new file for configuring these things, how about just building out an assert setup in the configuration xml? test configuration ... /configuration asserts assertTrueexpression/ .. .. The expression could be fed into the test case somehow...then they are bound together jesse -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
Testing maven-scm with continuum
How do I add a changelog report for non cvs providers? Maven gives me: If using another scm, maven.changelog.factory must be set. See the maven changelog plugin documentation for correct settings. I don't see it in the documentation. Is there other setup eg. reports or client software, I should try to test maven-scm? Torbjørn
[jira] Commented: (MECLIPSE-71) eclipse:clean delets too much
[ http://jira.codehaus.org/browse/MECLIPSE-71?page=comments#action_60229 ] Reinhard Poetz commented on MECLIPSE-71: Are there any implications if I don't run eclipse:clean before I run eclipse:eclipse? Is it possible that the plugin creates some inconsistent Eclipse settings files? If no, I agree with you that deleting isn't necessary. (Although Maven delets a file that it doesn't generate *completly* -- org.eclipse.jdt.core.prefs) I'd propose following cleaning procedure: - eclipse:clean delets all files it generates/manipulates - if after deleting these files, something is left (e.g. .svn directory) the .settings directory is _not_ deleted - if .settings is empty, the .settings directory is deleted too. WDYT? eclipse:clean delets too much - Key: MECLIPSE-71 URL: http://jira.codehaus.org/browse/MECLIPSE-71 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.1 Reporter: Reinhard Poetz If I call eclipse:clean, the complete .settings directory is deleted. In my projects we share some Eclipse settings in our team by adding the .settings directory to SVN. This behaviour is unpractical for us as SVN gets confused by the missing ./settings/.svn directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
Brett Porter wrote: Jason van Zyl wrote: This was just the first stage. I just whacked in the DOM reader because we need some more testing code to create a local repository for the MavenProjectBuilder. The MavenProjectBuilder should be used. A stub of the maven project builder, or the real one? The real one uses the repo, and that's not really conducive to unit testing. The harness somewhat blurs the lines but once you execute the Mojo I don't really consider it a unit test anymore. Even with the simple clean plugin example that you started with executed the Mojo. I think that's what's useful for testing and many Mojos need a local repository so I was suggesting using the real project builder passing in a local repository created for testing purposes. Why? I don't think you should have to add methods in order to be able to test the mojos. It's not how they would ever be used, so you're not really testing how they would be used in the field by adding properties. At one point, we were doing away with private field injection and recommending setters, so it is how they'd be used. Hasn't happened yet. Not sure if that will happen as I'm not sure how many Ant tasks are actually used outside of Ant. Given what we do in promoting the creation of components that get wrapped by a Mojo to expose them in Maven I'm not sure if there's much point to properties. If that's what we decide then we can do that. I'm not fussed one way or the other. I think the POM style testing will be most familiar to people writing plugins and ultimately allows for completely declarative testing of Mojos which I think would be excellent. In almost all cases you have to execute the mojo in order to test it and in order to execute it you need to populate the configuration elements. You could very clearly outline different test scenerios using different POMs. You could do this in Java but does it really matter if the inputs come via Java or another mechanism? I honestly don't think so. No, neither do I. I said having both is a good idea, but that calling it a POM is misleading, and to cut it back to just a configuration. But there are plugins that require a MavenProject and other parts of the POM not in the configuration for the plugin. The IDEA plugin is one example that needs a POM so having the pom.xml file actually be the source of a MavenProject I think would work. There is also the resources plugin which requires elements in the build/ element. I don't think we'll get away with just the configuration/ element for the plugin. At any rate I don't think you should alter classes for testing. Especially in this case as we know Mojos work just fine without properties. But they *are* properties, it's just a matter of whether it is injected using private fields, setters or constructors. Adding getters is probably a bit more lame, but I think that's unavoidable in either case. We've had this discussion before :-) They are not properties. We happen to abuse the field name being the same as the configuration element. But with a property the configuration element can be different then the field name as the setter would intervene. I think the Artifact/MavenProject population could use a little tweaking but we could probably do that with a special expression evaluator. Cool. I have to look at the actual code yet... I think people writing tests will like this declarative method of writing tests. It will be less error prone and take less effort and provide a standard way for writing Mojo tests. In some cases, but when you are only setting one field, its a pain, and when you are doing the same thing over and over and changing one field, it's a pain (though you could combine the two techniques for that). In how many cases in a Mojo can you only set one field and actually make it do anything? I'm all for a Java way, but I think the pom.xml will be the most thorough and actually correspond most accurately to real use. Whatever kind of testing that actually is. I think we can easily provide some Java code for those that want to do the Java thing but I imagine the desire to do that would fade given the declarative option. But you still shouldn't have to add properties to a mojo to make that work unless that's what you wanted to do to make it reusable. As long as the assertions are still in Java, I don't think its a declarative option, and I'd prefer to have my pre-conditions next to the post-conditions to make the tests more readable, myself. But, we can do both, and learn from experience which works, right? In SuiteRunner the input and assertions were in the same file. Sure, it can't hurt to have both methods and I think we need a method in Java simply because we will probably find holes in the declarative structure and that shouldn't stop you from testing. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For
[maven2 build branches/maven-2.0.x - SUCCESS - update] Mon Mar 6 16:45:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060306.164501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060306.164501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing maven-scm with continuum
whith m1 or m2? For testing a provider with continuum, provider lib must be in continuum lib directory, add your project and click on build now Emmanuel Torbjørn Smørgrav a écrit : How do I add a changelog report for non cvs providers? Maven gives me: If using another scm, maven.changelog.factory must be set. See the maven changelog plugin documentation for correct settings. I don't see it in the documentation. Is there other setup eg. reports or client software, I should try to test maven-scm? Torbjørn
[jira] Closed: (CONTINUUM-544) there is no xmlrpc client code for contacting the server.
[ http://jira.codehaus.org/browse/CONTINUUM-544?page=all ] Emmanuel Venisse closed CONTINUUM-544: -- Assign To: Emmanuel Venisse Resolution: Fixed Applied. Thanks. there is no xmlrpc client code for contacting the server. - Key: CONTINUUM-544 URL: http://jira.codehaus.org/browse/CONTINUUM-544 Project: Continuum Type: New Feature Components: XMLRPC Interface Reporter: Milos Kleint Assignee: Emmanuel Venisse Fix For: 1.0.3 Attachments: ProjectsReader.java, continuum-rpc-client.zip sibmitting a simple library for client code interaction, currently used at mevenide -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[maven2 build trunk - SUCCESS - update] Mon Mar 6 17:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060306.17.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060306.17.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [m2] Howto custom CharsetProvider implementations ?]
On Mo, März 6, 2006 15:41, Brett Porter wrote: Christian Schulte wrote: Hi, I am forwarding this to the dev mailing list since I got no answer on the users list. Generally better to just send a gentle reminder in reply on the users list. Any ideas or workarounds highly appreciated. No idea off the top of my head, but it sounds familiar. Have you searched the archive for something similar? - Brett I just noticed that I need to change the path separator used in the property file for the classpath by surefire-booter to get the fork-mode working on windows. See the attached patch. After applying this patch fork-mode starts working also on windows. Just wanted to let you know. The UnsupportdEncodingException problem still is not solved - also tried with various forkMode and childDelegation settings now. -- Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2126) Snapshot plugin repositories are not searched for plugins that do not explicitly specify a snapshot version.
Snapshot plugin repositories are not searched for plugins that do not explicitly specify a snapshot version. Key: MNG-2126 URL: http://jira.codehaus.org/browse/MNG-2126 Project: Maven 2 Type: Bug Reporter: John Allen Priority: Minor Only release repositories are queried for version-unscoped plugins. Deploy a plugin (say x-maven-plugin, version 1-SNAPSHOT) to a snapshot repository via mvn -P performRelease deploy. clear local repository so client has no copy of the snapshot. Build a project that tries to use the x-maven-plugin but does not specify the plugin's version. Results in client searching release respository only, does not query the snapshot repository or attempt to merge the metadata in any way. Is this as designed? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Testing maven-scm with continuum
I have been running continuum with my bazaar projects for some time now, but I have only done the regular checkout, build, install, deploy and site-deploy. What I want is to add a chengelog report: changelog-maven-plugin [m2] Or what I really want is to use client software (like continuum) that use changelog and diff to see if they work with bazaar. Torbjørn -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: 6. mars 2006 18:06 To: scm-dev@maven.apache.org Subject: Re: Testing maven-scm with continuum whith m1 or m2? For testing a provider with continuum, provider lib must be in continuum lib directory, add your project and click on build now Emmanuel Torbjørn Smørgrav a écrit : How do I add a changelog report for non cvs providers? Maven gives me: If using another scm, maven.changelog.factory must be set. See the maven changelog plugin documentation for correct settings. I don't see it in the documentation. Is there other setup eg. reports or client software, I should try to test maven-scm? Torbjørn
[jira] Commented: (MNG-2126) Snapshot plugin repositories are not searched for plugins that do not explicitly specify a snapshot version.
[ http://jira.codehaus.org/browse/MNG-2126?page=comments#action_60231 ] Carlos Sanchez commented on MNG-2126: - I think this is the right behaviour Snapshot plugin repositories are not searched for plugins that do not explicitly specify a snapshot version. Key: MNG-2126 URL: http://jira.codehaus.org/browse/MNG-2126 Project: Maven 2 Type: Bug Reporter: John Allen Priority: Minor Only release repositories are queried for version-unscoped plugins. Deploy a plugin (say x-maven-plugin, version 1-SNAPSHOT) to a snapshot repository via mvn -P performRelease deploy. clear local repository so client has no copy of the snapshot. Build a project that tries to use the x-maven-plugin but does not specify the plugin's version. Results in client searching release respository only, does not query the snapshot repository or attempt to merge the metadata in any way. Is this as designed? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (SCM-170) SvnTagCommand doesn't work?
[ http://jira.codehaus.org/browse/SCM-170?page=all ]
Emmanuel Venisse closed SCM-170:
Resolution: Won't Fix
Fix Version: (was: 1.0)
svn copy accept --file parameter :
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.ref.svn.c.copy
I guess you don't have define the tagBase parameter. You must define it to
specify the location of tags directory in your svn
SvnTagCommand doesn't work?
---
Key: SCM-170
URL: http://jira.codehaus.org/browse/SCM-170
Project: Maven SCM
Type: Bug
Reporter: Gareth Williams
Priority: Critical
mvn release:prepare fails with the following output:
Provider message:
The svn tag command failed.
Command output:
svn: Local, non-commit operations do not take a log message
Have looked at source, and suspect SvnTagCommand needs to be fixed - in SVN
the copy command does not accept a log message
Package: org.apache.maven.scm.provider.svn.svnexe.command.tag
Class:SvnTagCommand
private static Commandline createCommandLine( SvnScmProviderRepository
repository, File workingDirectory,
String tag, File
messageFile )
{
cl.createArgument().setValue( copy );
XXXcl.createArgument().setValue( --file );
XXXcl.createArgument().setValue( messageFile.getAbsolutePath() );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Testing maven-scm with continuum
continuum can't use directly changelog and diff plugin, it's the maven work. (http://mojo.codehaus.org/changelog-maven-plugin/howto.html), you must use snapshot version of changelog plugin continuum use changelog scm api via update scm command, the result is in continuum build results Emmanuel Torbjørn Smørgrav a écrit : I have been running continuum with my bazaar projects for some time now, but I have only done the regular checkout, build, install, deploy and site-deploy. What I want is to add a chengelog report: changelog-maven-plugin [m2] Or what I really want is to use client software (like continuum) that use changelog and diff to see if they work with bazaar. Torbjørn -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: 6. mars 2006 18:06 To: scm-dev@maven.apache.org Subject: Re: Testing maven-scm with continuum whith m1 or m2? For testing a provider with continuum, provider lib must be in continuum lib directory, add your project and click on build now Emmanuel Torbjørn Smørgrav a écrit : How do I add a changelog report for non cvs providers? Maven gives me: If using another scm, maven.changelog.factory must be set. See the maven changelog plugin documentation for correct settings. I don't see it in the documentation. Is there other setup eg. reports or client software, I should try to test maven-scm? Torbjørn
Re: proposed mailing lists names
+1 On 3/5/06, Brett Porter [EMAIL PROTECTED] wrote: Since we've voted to do this, I'm just going to give people 48 hours to object to these particular names. [see MPA-50] Our dev list traffic has gone nuts. Let's create: [EMAIL PROTECTED] * this will be for CI, error reports from the repository manager, and so on * depending on policy, this may not be archived (we won't archive it unless it's required - I don't think it's necessary, but there is no harm in it if it is) * this will be for all maven projects (ie, no continuum-notifications, etc). [EMAIL PROTECTED] * this will be for JIRA issues. For now, just one will be created. If it is later determined to split one set off, we can create more. commits@maven.apache.org * for commits - we already have it (each subproject has its own) dev@maven.apache.org * for human discussion - we already have it Note that all subscribers to dev@maven.apache.org will be automatically subscribed to these lists at creation, but going forward you will need to subscribe to each individually. - Brett - 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]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60241 ] Eugene Kuleshov commented on MNGECLIPSE-85: --- I'd organize view like this: project1 +--- pom1 +--- launch config1 +--- launch config2 +--- launch config3 +--- launch config4 +--- pom2 +--- launch config1 +--- launch config2 Basically it would look similar to Spring beans view from Spring IDE, but show poms instead of config files. You could also set a default launch configuration that would be launched when clicking on project of pom node. MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposed mailing lists names
+1 (non-binding) Bill Dudney MyFaces - myfaces.apache.org On Mar 6, 2006, at 12:01 AM, Brett Porter wrote: Since we've voted to do this, I'm just going to give people 48 hours to object to these particular names. [see MPA-50] Our dev list traffic has gone nuts. Let's create: [EMAIL PROTECTED] * this will be for CI, error reports from the repository manager, and so on * depending on policy, this may not be archived (we won't archive it unless it's required - I don't think it's necessary, but there is no harm in it if it is) * this will be for all maven projects (ie, no continuum- notifications, etc). [EMAIL PROTECTED] * this will be for JIRA issues. For now, just one will be created. If it is later determined to split one set off, we can create more. commits@maven.apache.org * for commits - we already have it (each subproject has its own) dev@maven.apache.org * for human discussion - we already have it Note that all subscribers to dev@maven.apache.org will be automatically subscribed to these lists at creation, but going forward you will need to subscribe to each individually. - Brett - 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]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60243 ] Thorsten Kamann commented on MNGECLIPSE-85: --- I have uploaded a screenshot to visualize the view i am planning. What do you think about it? MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch, screenshot-1.jpg The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=all ] Thorsten Kamann updated MNGECLIPSE-85: -- Attachment: screenshot-1.jpg MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch, screenshot-1.jpg The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Improving poms on ibiblio
- Original Message - From: Jacek Laskowski [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Monday, March 06, 2006 3:09 PM Subject: Re: [discussion] Improving poms on ibiblio 06-03-06, Grzegorz Słowikowski [EMAIL PROTECTED] napisał(a): Hi Wendy Now I have some time and I started preparing poms for all Tomcat artifacts. I have checked out all modules from svn (tags TOMCAT_5_5_15) and now I'm preparing poms for them. I already see, that I will have many questions. Where can we discuss it all? On Tomcat Bugzilla? Witaj Grzegorz, Isn't it already sorted out? See http://jira.codehaus.org/browse/MAVENUPLOAD-761. No, Brett made only commons-modeler pom and uploaded it with jar. Tomcat artifacts still wait for poms. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60245 ] Eugene Kuleshov commented on MNGECLIPSE-85: --- Thorsten, take a look at my previous comment. I don't think it is a good idea to show all the goals like you did because it is too much noise (that why Ant view is practically useless). Two other imortant things to note: -- each project can have more then one pom. Eg. each module could have its own pom and view should reflect that. -- launch configuration allows to execute more then one goal at once and allows to specify additional configuration parameters. So, I think it is a good idea to reuse it as is in this view. E.g. when doubleclicking on project or pom that does not has no launch configurations, new ne would be created. MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch, screenshot-1.jpg The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60246
]
Eugene Kuleshov commented on MNGECLIPSE-85:
---
Damn, formatting got screwed. Here it is:
{noformat}
project1
+--- pom1
+--- launch config1
+--- launch config2
+--- launch config3
+--- launch config4
+--- pom2
+--- launch config1
+--- launch config2
{noformat}
MavenLauncher should be externalized
Key: MNGECLIPSE-85
URL: http://jira.codehaus.org/browse/MNGECLIPSE-85
Project: Maven 2.x Extension for Eclipse
Type: Improvement
Components: Maven Launcher
Versions: 0.0.5
Reporter: Thorsten Kamann
Assignee: Eugene Kuleshov
Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java,
ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch,
screenshot-1.jpg
The MavenLauncher is included in the ExecutePomAction. To allow other views
to use this launcher I want to extract the code in a seperate class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposed mailing lists names
+1 (non-binding) -- Dennis Lundberg Brett Porter wrote: Since we've voted to do this, I'm just going to give people 48 hours to object to these particular names. [see MPA-50] Our dev list traffic has gone nuts. Let's create: [EMAIL PROTECTED] * this will be for CI, error reports from the repository manager, and so on * depending on policy, this may not be archived (we won't archive it unless it's required - I don't think it's necessary, but there is no harm in it if it is) * this will be for all maven projects (ie, no continuum-notifications, etc). [EMAIL PROTECTED] * this will be for JIRA issues. For now, just one will be created. If it is later determined to split one set off, we can create more. commits@maven.apache.org * for commits - we already have it (each subproject has its own) dev@maven.apache.org * for human discussion - we already have it Note that all subscribers to dev@maven.apache.org will be automatically subscribed to these lists at creation, but going forward you will need to subscribe to each individually. - Brett - 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]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60249 ] Thorsten Kamann commented on MNGECLIPSE-85: --- Hmm, ok it seems you are not interested. How can i add more then one Launchconfiguration for one pom? If i right-click on a pom and there is already a launchconfiguration i have no chance to create a new one. Is there planned to add a menu entry like Maven2 Build ...? Another question: How can I set a property to emulate the -e switch of the Maven2 command-line client. Thorsten MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch, screenshot-1.jpg The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=comments#action_60252 ] Eugene Kuleshov commented on MNGECLIPSE-85: --- Hmm, ok it seems you are not interested. Not true. We are interested, but in little different implementation, wich makes more sense to us. How can i add more then one Launchconfiguration for one pom? If i right-click on a pom and there is already a launchconfiguration i have no chance to create a new one. All launch configurations can be edited in Run / External Tools... / External Tools... dialog. Maven view would just expose the same configurations and group them along projects and poms. Is there planned to add a menu entry like Maven2 Build ...? MNGECLIPSE-84 Another question: How can I set a property to emulate the -e switch of the Maven2 command-line client. Fill an issue for this. There should be additional check boxes for this and debug flags on Main tab of the launch configuration panel. Patches are welcome, though I am not sure if embedder is currently support this. MavenLauncher should be externalized Key: MNGECLIPSE-85 URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Maven Launcher Versions: 0.0.5 Reporter: Thorsten Kamann Assignee: Eugene Kuleshov Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch, screenshot-1.jpg The MavenLauncher is included in the ExecutePomAction. To allow other views to use this launcher I want to extract the code in a seperate class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-71) activemq tests fail - system property not set
[ http://jira.codehaus.org/browse/MSUREFIRE-71?page=comments#action_60254 ]
Carlos Sanchez commented on MSUREFIRE-71:
-
System.getProperty( basedir ) returns null for me
This fails:
import junit.framework.TestCase;
public class BasedirTest
extends TestCase
{
public void testBasedir()
{
final String baseDir = System.getProperty( basedir );
assertNotNull( baseDir );
}
}
activemq tests fail - system property not set
-
Key: MSUREFIRE-71
URL: http://jira.codehaus.org/browse/MSUREFIRE-71
Project: Maven 2.x Surefire Plugin
Type: Improvement
Versions: 2.2
Reporter: Brett Porter
Assignee: Brett Porter
Fix For: 2.2
see activemq-jaas
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-71) System properties are not set
[ http://jira.codehaus.org/browse/MSUREFIRE-71?page=all ] Carlos Sanchez updated MSUREFIRE-71: Priority: Blocker (was: Major) Version: 2.2 Summary: System properties are not set (was: activemq tests fail - system property not set) System properties are not set - Key: MSUREFIRE-71 URL: http://jira.codehaus.org/browse/MSUREFIRE-71 Project: Maven 2.x Surefire Plugin Type: Improvement Versions: 2.2 Reporter: Brett Porter Assignee: Brett Porter Priority: Blocker Fix For: 2.2 see activemq-jaas -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-255) Problem with junit-addons 1.4
[ http://jira.codehaus.org/browse/MEV-255?page=comments#action_60256 ] md commented on MEV-255: Yes. I have trimmed it down to the following: project modelVersion4.0.0/modelVersion groupIdjunit-addons/groupId artifactIdjunit-addons/artifactId version1.4/version dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version /dependency dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.6.2/version /dependency dependency groupIdxerces/groupId artifactIdxmlParserAPIs/artifactId version2.6.2/version /dependency /dependencies /project I am not sure if xerces is needed. I haven't looked at the addons source yet. Problem with junit-addons 1.4 - Key: MEV-255 URL: http://jira.codehaus.org/browse/MEV-255 Project: Maven Evangelism Type: Task Reporter: David Eric Pugh junit-addons's M2 pom: http://www.ibiblio.org/maven2/junit-addons/junit-addons/1.4/junit-addons-1.4.pom says taht it depends on junit-addons-runner-1.0-alpha1. However, this jar doesn't exist on ibiblio or Maven2 repositories. Additionally, www.ibiblio.org/maven/junit-addons/jars/ didn't have it either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
