[continuum build trunk - FAILED - update] Fri Mar 3 08:00:01 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060303.080001.txt
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Mar 3 07:45:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.074500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.074500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3 (second attempt)
Do you have a sample project that reproduce the problem? Emmanuel Fabrizio Giustina a écrit : mh, I got a NPE from maven-project using this build (multiproject build, flat structure, any goal that requires dependency resolution). Looks like a problem with the changes for MNG-2006 , worths a check fabrizio [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.appendPath(DefaultModelInheritanceAssembler.java:544) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleDistributionInheritence(DefaultModelInheritanceAssembler.java:433) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:110) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.copyModel(DefaultModelInheritanceAssembler.java:52) at org.apache.maven.project.ModelUtils.cloneModel(ModelUtils.java:435) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:667) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:275) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) On 3/2/06, Fabrizio Giustina [EMAIL PROTECTED] wrote: big +1 this time fabrizio On 3/2/06, John Casey [EMAIL PROTECTED] wrote: Hello everyone, If you've been tracking the thread calling for the release of Maven 2.0.3, you'll know that several issues came up which have delayed any decision on the release. The full discussion can be found here: http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 - 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: (MECLIPSE-73) eclipse.workspace and relative path in multiproject
eclipse.workspace and relative path in multiproject --- Key: MECLIPSE-73 URL: http://jira.codehaus.org/browse/MECLIPSE-73 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.1 Reporter: Gilles Scokart Priority: Minor Relative path used in eclipse.workspace are resolved to the built project. When multiproject is used, the relative path should be resolved relatively to the reactor project, not relatively to the sub-module project. -- 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 trunk - SUCCESS - update] Fri Mar 3 08:00:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.080001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.080001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MIDEA-16) idea target only works after compilation
[ http://jira.codehaus.org/browse/MIDEA-16?page=comments#action_59975 ] Edwin Punzalan commented on MIDEA-16: - The bug has been fixed in rev 382701 idea target only works after compilation Key: MIDEA-16 URL: http://jira.codehaus.org/browse/MIDEA-16 Project: Maven 2.x Idea Plugin Type: Bug Reporter: Matthew Pocock Assignee: Edwin Punzalan Fix For: 2.0 Original Estimate: 3 hours Time Spent: 3 hours Remaining: 0 minutes In a multi-module project, you have to build it before you can idea:idea it. Let's have modules a and b, with b depending on a. The idea plugin runs for a, but then fails on b because it can't find a.jar, as you've not build a yet. However, there are case where it's not practical to build the project before loading it up in idea e.g. if you've checked it out of svn to fix a bug that prevents compilation. The work-arround would be for the idea plugin to require resolution for all jars that are external dependencies but to silently assume the presence of all jars that would be built as part of the project. -- 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] Fri Mar 3 08:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.081501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.081501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 1.0.1 fails tests that rely on signed jar files
Hi. I tried this on the users list, but on second thought, it's more likely that someone on the dev list knows about this bug. I have a test case that uses a signed jar file (bouncy castle JCE provider). This test case works fine from the command line, but fails when run via Maven: Testcase: testFunctionality(crypto.BCImplTest): Caused an ERROR The provider BC may not be signed by a trusted party java.lang.SecurityException: The provider BC may not be signed by a trusted party at javax.crypto.SunJCE_b.a(DashoA12275) at javax.crypto.Cipher.a(DashoA12275) at javax.crypto.Cipher.getInstance(DashoA12275) at crypto.BCImpl.encrypt(BCImpl.java:29) The application works as expected during normal runtime also, ie. this is a Maven only problem. Can anyone really insightful elaborate to me what's going on? This works for Maven only if I place the jar file in jre/lib/ext, so I'm guessing that this is a class loading issue of some sorts. Morten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2119) SVN password in clear text
SVN password in clear text -- Key: MNG-2119 URL: http://jira.codehaus.org/browse/MNG-2119 Project: Maven 2 Type: Wish Components: POM Versions: 2.0.2 Environment: wintel Reporter: Borut Bol#269;ina Priority: Minor Password in clear text, but it works. QUESTION: If SVN username is the same as system login username (windows), is there a way not to put password on display in pom.xml? plugin groupIdorg.codehaus.mojo/groupId artifactIdchangelog-maven-plugin/artifactId version2.0-beta-2-SNAPSHOT/version configuration scmUrlscm:svn:http://acme.com/svn/repository/project/trunk/scmUrl passwordPASSWORD/password /configuration /plugin -- 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: (MECLIPSE-74) Workspace inspection when adding a project
Workspace inspection when adding a project -- Key: MECLIPSE-74 URL: http://jira.codehaus.org/browse/MECLIPSE-74 Project: Maven 2.x Eclipse Plugin Type: New Feature Versions: 2.1 Reporter: Gilles Scokart The eclipse plugin should lookup which project is present in a workspace and update/create the project in function of what is already present. *Scénario 1* : Module A use module B. Module B is already present as a project in the workspace. When adding A, the created project A should be dependent of the project B instead of dependent of the jar in the repository. *Scénario 2* : idem, but A is first added, then B. When B is added, the project A is updated in order to be dependent of B instead of the jar in the repository. *Scénario 3* : Add a goal to remove a project (and update dependencies accordingly). Of curse all those scenario should take into account the version numbers present in the poms inside the project. This is an alternative to MECLIPSE-32 . -- 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] Timestamp plugin
Hi Jason,
Not much work has been done yet. I have created a really minimal version
of the plugin. Thats 7 lines of real code. Have a look at the plugin if
you want to, its attached to
https://issues.apache.org/jira/browse/GERONIMO-1659 . It may not be the
best way of doing it, but doubt there is any simpler way.
/Anders
Jason van Zyl wrote:
Anders Hessellund Jensen wrote:
I would like to be able to substitute timestamps with the build time
into a resource file. As I understand it, there is currently no plugin
to to this, so I consider writing one.
Sorry for not responding to this earlier, and I know that you've started
working on this plugin and I'd like to harness the work you've done but
I think what you are doing should be an extension to the resources
plugin. We should figure out how to augment filtering of resources. I
think the easiest way to do this is to filter the resources using Velocity.
This way additional tools can be created for swizzling resources and
this can all happen in one pass through velocity instead of having N
plugins which need to make N passes over the resources to filter them.
So I don't want to discourage you at all. Work on the plugin and I will
try to integrate your code into the resources plugin when you are done.
The other advantage of using Velocity in the resources plugin will allow
you to use Velocity directives in your resources so you can do any sort
of conditional logic you may want to have instead of simple
substitution. So I think we would benefit in two ways using Velocity
here: scalable addition of tools that can be used to swizzle resources
(a timestamp tool is a perfect example) and conditional logic which can
sometimes be useful like looking at a property introduced by a profile
and behave a certain way for example.
The plugin should leverage the existing resource filtering mechanism
of M2. The plugin would take a configuration like this:
configuration
timestamps
timestamp
propertyNamebuild.date/propertyName
pattern.MM.dd/pattern
timestamp
timestamps
/configuration
Running the plugin with this configuration would define the M2
property build.date, and any filtered resource file would get
${build.date} substituted with 2006.02.28 or whatever the date at
build time is.
WDYT?
Best regards,
Anders
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MECLIPSE-75) Automatically add project to the workspace
Automatically add project to the workspace -- Key: MECLIPSE-75 URL: http://jira.codehaus.org/browse/MECLIPSE-75 Project: Maven 2.x Eclipse Plugin Type: Improvement Versions: 2.1 Reporter: Gilles Scokart Priority: Minor When eclipse.workspace is specified, the project should automatically be added to the workspace. The current workaround is : With eclipse 3.1, it is quiet easy to import multiple project. With previous version, the plugin http://eclipse-tools.sourceforge.net/projecttransfer could be used. -- 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: (MJAR-33) Jarsigner shows password on command line
Jarsigner shows password on command line Key: MJAR-33 URL: http://jira.codehaus.org/browse/MJAR-33 Project: Maven 2.x Jar Plugin Type: Bug Versions: 2.1 Reporter: Hes Siemelink When I sign a jar I see the password of the keystore in the debug output: [debug] jarsigner executable=[C:\Program Files\Java\jdk1.5.0_05\jre\..\bin\jarsigner.exe] [debug] Executing: C:\Program Files\Java\jdk1.5.0_05\jre\..\bin\jarsigner.exe -keystore my-keystore.pfx -storepas s SECRET_PASSPHRASE!! -storetype PKCS12 E:\Temp\jbossall-client-jboss-4.0.3.jar mykey It would be nice if this could be masked. I get this using the webstart plugin. -- 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: [vote] separate mailings lists for humans/JIRA/CI/commits
On Wed, 1 Mar 2006, Jason van Zyl wrote: +1 (duh! :)) Hi, I just wanted to close this up as I think it's a good idea and anything that let's people manage their mail better IMO is a good thing. +1 In this type of vote it is non-technical so simple majority wins, but if it's close we can continue the discussion but I think a majority wanted preferred the separation. - 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]
[maven2 build trunk - SUCCESS - update] Fri Mar 3 12:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.123001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.123001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1318) mvn.bat sets incorrect value to M2_HOME [Windows 2000]
[ http://jira.codehaus.org/browse/MNG-1318?page=all ] Kenney Westerhof closed MNG-1318: - Assign To: Kenney Westerhof Resolution: Fixed Fix Version: (was: 2.0.4) 2.0.3 Fixed in svn revision 382797. Changed the fix/version to 2.0.3 as discussed. mvn.bat sets incorrect value to M2_HOME [Windows 2000] -- Key: MNG-1318 URL: http://jira.codehaus.org/browse/MNG-1318 Project: Maven 2 Type: Bug Components: Command Line Versions: 2.0 Environment: Windows 2000 SP4 / Maven 2.0 Reporter: ajbanck Assignee: Kenney Westerhof Fix For: 2.0.3 When running Maven 2 by calling mvn.bat on Windows 2000 (SP4) the batch file sets M2_HOME to a value including the name of the batch file itself. This results in an error: ERROR: M2_HOME is set to an invalid directory. M2_HOME = C:\maven\maven-2.0\bin\mvn.bat\.. Please set the M2_HOME variable in your environment to match the location of the Maven installation When changing line 72 of mvn.bat to use %~dp0 instead of %~dps0 it works correctly: if %OS%==Windows_NT SET M2_HOME=%~dp0\.. Looking at the SVN history, this was changed to %~dps0 to work with spaces http://svn.apache.org/viewcvs.cgi?rev=163778view=rev -- 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: (MNG-1318) mvn.bat sets incorrect value to M2_HOME [Windows 2000]
[ http://jira.codehaus.org/browse/MNG-1318?page=comments#action_59989 ] Kenney Westerhof commented on MNG-1318: --- Sorry, I messed up 1317 and 1318. This issue is fixed in revision 382801. mvn.bat sets incorrect value to M2_HOME [Windows 2000] -- Key: MNG-1318 URL: http://jira.codehaus.org/browse/MNG-1318 Project: Maven 2 Type: Bug Components: Command Line Versions: 2.0 Environment: Windows 2000 SP4 / Maven 2.0 Reporter: ajbanck Assignee: Kenney Westerhof Fix For: 2.0.3 When running Maven 2 by calling mvn.bat on Windows 2000 (SP4) the batch file sets M2_HOME to a value including the name of the batch file itself. This results in an error: ERROR: M2_HOME is set to an invalid directory. M2_HOME = C:\maven\maven-2.0\bin\mvn.bat\.. Please set the M2_HOME variable in your environment to match the location of the Maven installation When changing line 72 of mvn.bat to use %~dp0 instead of %~dps0 it works correctly: if %OS%==Windows_NT SET M2_HOME=%~dp0\.. Looking at the SVN history, this was changed to %~dps0 to work with spaces http://svn.apache.org/viewcvs.cgi?rev=163778view=rev -- 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: (MNG-1317) m2.bat doesn't work on Windows 2000
[ http://jira.codehaus.org/browse/MNG-1317?page=all ] Kenney Westerhof closed MNG-1317: - Assign To: Kenney Westerhof Resolution: Fixed Fix Version: (was: 2.0.4) 2.0.3 Fixed in revision 382797. Use ~dp0 instead of ~dps0 (which works correctly, but produces long filenames), and add double quotes so the long filenames work. m2.bat doesn't work on Windows 2000 --- Key: MNG-1317 URL: http://jira.codehaus.org/browse/MNG-1317 Project: Maven 2 Type: Bug Components: Command Line Versions: 2.0 Environment: Windows 2000/SP4 Maven 2.0 Reporter: ajbanck Assignee: Kenney Westerhof Fix For: 2.0.3 the m2.bat doesn't work on Windows 2000. This batch uses '%~dps0\mvn %*' to call the mvn batch file. %~dps0 expands to the path including the batch name, resulting in an incorrect path. Looking at another batch (cruisecontrol.bat) uses %~dp0 instead of %~dps0 Current Output with echo turned on: C:\cc_stg\Hercules_nl\MetadataRepository\shared\utilm2 compile echo. echo THE m2 COMMMAND IS DEPRECATED - PLEASE RUN mvn INSTEAD THE m2 COMMMAND IS DEPRECATED - PLEASE RUN mvn INSTEAD C:\cc_stg\Hercules_nl\MetadataRepository\shared\utilecho. C:\cc_stg\HERCUL~1\METADA~1\external\maven\maven-2.0\bin\m2.bat\mvn compile The directory name is invalid. -- 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] Fri Mar 3 13:15:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.131501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.131501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3 (second attempt)
On Fri, 3 Mar 2006, Emmanuel Venisse wrote:
Looking at the source, the only way this can go wrong
is if the 'parent path' has no tokens, i.e. is an empty
string, or has the value http://; or file:///. The parent path
in question here is the site url.
This, in combination with '..' in the child path (which is strange,
since the artifactId is used there, and that should not contain '..')
Maybe if the url was not specified in the parent (or ancestor),
it now defaults to an empty string?
What would be needed hereis a check for too many '..'
(i.e. parent = /tmp/, child=../../test - /../test/, or
parent = /, child = ../test in the current case).
Either we ignore the '..' in this case, or thow an exception
(but that would require changes to the method signature).
Proposed fix: ignore for now, instead of an NPE?
(btw, the code is rather complex. A simple 'new File( parent, child
).getAbsolutePath().replace('\\','/') seems simpler to me.. :)
-- Kenney
Do you have a sample project that reproduce the problem?
Emmanuel
Fabrizio Giustina a �crit :
mh, I got a NPE from maven-project using this build (multiproject
build, flat structure, any goal that requires dependency resolution).
Looks like a problem with the changes for MNG-2006 , worths a check
fabrizio
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.appendPath(DefaultModelInheritanceAssembler.java:544)
at
org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleDistributionInheritence(DefaultModelInheritanceAssembler.java:433)
at
org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:110)
at
org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.copyModel(DefaultModelInheritanceAssembler.java:52)
at
org.apache.maven.project.ModelUtils.cloneModel(ModelUtils.java:435)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:667)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102)
at
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:275)
at
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182)
at
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
On 3/2/06, Fabrizio Giustina [EMAIL PROTECTED] wrote:
big +1 this time
fabrizio
On 3/2/06, John Casey [EMAIL PROTECTED] wrote:
Hello everyone,
If you've been tracking the thread calling for the release of Maven
2.0.3, you'll know that several issues came up which have delayed any
decision on the release. The full discussion can be found here:
http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584
-
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]
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
Question about Clearcase, Starteam and Perforce
Hi, I added a new method in SCMProvider (String getScmSpecificFilename()) This method returns the name of reserved filename/directory use by scm like CVS or .svn Do we have a similar file for Clearcase/Starteam/Perforce ? Emmanuel
[jira] Created: (ARCHETYPE-32) including png in site resources breaks an archetype (stacktrace+archetype.xml included)
including png in site resources breaks an archetype (stacktrace+archetype.xml included) --- Key: ARCHETYPE-32 URL: http://jira.codehaus.org/browse/ARCHETYPE-32 Project: Maven Archetype Type: Bug Components: maven-archetype-plugin Reporter: Jurgen De Landsheer Assigned to: Jason van Zyl if I drop the png: creation is correct but it seems it wants to parse a png or something? archetype idmaven-ugent-plugin-archetype/id sources source src/main/java/org/codehaus/mojo/test/TestMojo.java /source /sources testSources source src/test/java/org/codehaus/mojo/test/TestMojoTestSuite.java /source /testSources resources resourcesrc/main/resources/jalopy.xml/resource resourcesrc/main/resources/plugin.properties/resource /resources testResources resourcesrc/test/resources/test.properties/resource /testResources siteResources resourcesrc/site/site.xml/resource resourcesrc/site/apt/usage.apt/resource resourcesrc/site/resources/images/logobalk_small.png/resource /siteResources /archetype C:\JAVA\maven-pluginsmvn -e archetype:create -DarchetypeGroupId=be.ugent.dict -DarchetypeArtifactId=maven-ugent-plugin-archetype -DgroupId= -DartifactId=test C:\JAVA\maven-pluginsset MAVEN_OPTS=-Xmx32m -Xmx200m + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] maven-ugent-plugin-archetype [INFO] maven-mojo-report-plugin [INFO] maven-lint4j-plugin [INFO] maven-juge-plugin [INFO] maven-project-info-plugin [INFO] maven-spring-beandoc-plugin [INFO] maven-linguine-maps-plugin [INFO] maven-hibernate-tools-plugin [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] org.apache.maven.plugins: checking for updates from missing-plugins [INFO] org.apache.maven.plugins: checking for updates from ugent-plugins [INFO] org.codehaus.mojo: checking for updates from missing-plugins [INFO] org.codehaus.mojo: checking for updates from ugent-plugins [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from missing-plugins [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from ugent-plugins [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for updates from missing-plugins [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for updates from ugent-plugins [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from missing-plugins [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from ugent-plugins [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from missing-plugins [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from ugent-plugins [INFO] [INFO] Building maven-mojo-report-plugin [INFO]task-segment: [archetype:create] (aggregator-style) [INFO] [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] ** [INFO] Starting Jakarta Velocity v1.4 [INFO] RuntimeInstance initializing. [INFO] Default Properties File: org\apache\velocity\runtime\defaults\velocity.properties [INFO] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [INFO] Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader [INFO] ClasspathResourceLoader : initialization starting. [INFO] ClasspathResourceLoader : initialization complete. [INFO] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [INFO] Default ResourceManager initialization complete. [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [INFO] Created: 20 parsers. [INFO] Velocimacro : initialization starting. [INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any
[maven2 build trunk - SUCCESS - update] Fri Mar 3 14:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.140001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.140001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about Clearcase, Starteam and Perforce
Perforce does not use local disk for storage of info like CVS and svn. Quoting Emmanuel Venisse [EMAIL PROTECTED]: Hi, I added a new method in SCMProvider (String getScmSpecificFilename()) This method returns the name of reserved filename/directory use by scm like CVS or .svn Do we have a similar file for Clearcase/Starteam/Perforce ? Emmanuel
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Mar 3 14:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.141500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.141500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems w/ Webapps in Triplesec
Dariush Behboudi wrote: Hi Alex, Hope you don't mind but I CC'd the dev list. Let's keep this on that list. I was able to build triplesec as suggested. I have some errors and some questions about the webapps, I'd glad if you can help. All these webapps are a work in progress D. They are not even complete yet. The admin btw is experimental. A fellow by the name of serdar is working on it. Perhaps he can chime in on his progress. First of all, the webapp-admin project generated triplesec-webapp-config.war war file; this war is created also by the webapp-config project. Which webapp I must deploy with tomcat? So it generates the same webapp hmmm that's not good. I just fixed this btw so you'll want to svn up your wkdir. Incidentally you have to have an instance of the server running for these to work since they connect to the triplsec server. Hey if you want to skype me for help you can ... my handle is akarasulu. Laters, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question about Clearcase, Starteam and Perforce
And I believe ClearCase is the same. No idea about StarTeam. -Original Message- From: Jeff Jensen [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 8:20 AM To: scm-dev@maven.apache.org Subject: Re: Question about Clearcase, Starteam and Perforce Perforce does not use local disk for storage of info like CVS and svn. Quoting Emmanuel Venisse [EMAIL PROTECTED]: Hi, I added a new method in SCMProvider (String getScmSpecificFilename()) This method returns the name of reserved filename/directory use by scm like CVS or .svn Do we have a similar file for Clearcase/Starteam/Perforce ? Emmanuel
Re: Problems w/ Webapps in Triplesec
On Fri, 3 Mar 2006, Alex Karasulu wrote: I think you CC'd the wrong dev list. This list is for Apache Maven design discussions only. -- Kenney Dariush Behboudi wrote: Hi Alex, Hope you don't mind but I CC'd the dev list. Let's keep this on that list. I was able to build triplesec as suggested. I have some errors and some questions about the webapps, I'd glad if you can help. All these webapps are a work in progress D. They are not even complete yet. The admin btw is experimental. A fellow by the name of serdar is working on it. Perhaps he can chime in on his progress. First of all, the webapp-admin project generated triplesec-webapp-config.war war file; this war is created also by the webapp-config project. Which webapp I must deploy with tomcat? So it generates the same webapp hmmm that's not good. I just fixed this btw so you'll want to svn up your wkdir. Incidentally you have to have an instance of the server running for these to work since they connect to the triplsec server. Hey if you want to skype me for help you can ... my handle is akarasulu. Laters, Alex - 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]
[maven2 build trunk - SUCCESS - update] Fri Mar 3 14:30:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.143001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.143001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3 (second attempt)
On 3/3/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: Do you have a sample project that reproduce the problem? You can checking out http://svn.magnolia.info/svn/magnolia/trunk/ (the root project is magnolia-project). You will still get this error when trying to run a mvn install from the root project (and sorry, I still didn't had the time to debug the cause properly). fabrizio Emmanuel Fabrizio Giustina a écrit : mh, I got a NPE from maven-project using this build (multiproject build, flat structure, any goal that requires dependency resolution). Looks like a problem with the changes for MNG-2006 , worths a check fabrizio [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.appendPath(DefaultModelInheritanceAssembler.java:544) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleDistributionInheritence(DefaultModelInheritanceAssembler.java:433) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:110) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.copyModel(DefaultModelInheritanceAssembler.java:52) at org.apache.maven.project.ModelUtils.cloneModel(ModelUtils.java:435) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:667) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:275) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) On 3/2/06, Fabrizio Giustina [EMAIL PROTECTED] wrote: big +1 this time fabrizio On 3/2/06, John Casey [EMAIL PROTECTED] wrote: Hello everyone, If you've been tracking the thread calling for the release of Maven 2.0.3, you'll know that several issues came up which have delayed any decision on the release. The full discussion can be found here: http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 - 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: [vote] separate mailings lists for humans/JIRA/CI/commits
+1 fabrizio On 3/1/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I just wanted to close this up as I think it's a good idea and anything that let's people manage their mail better IMO is a good thing. +1 In this type of vote it is non-technical so simple majority wins, but if it's close we can continue the discussion but I think a majority wanted preferred the separation. - 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: [vote] Release Maven 2.0.3 (second attempt)
I'm on it. It'll be fixed in a few minutes, and I'll republish the next CI binary that comes out as a new RC. Thanks for catching this. -john Fabrizio Giustina wrote: mh, I got a NPE from maven-project using this build (multiproject build, flat structure, any goal that requires dependency resolution). Looks like a problem with the changes for MNG-2006 , worths a check fabrizio [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.appendPath(DefaultModelInheritanceAssembler.java:544) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleDistributionInheritence(DefaultModelInheritanceAssembler.java:433) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:110) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.copyModel(DefaultModelInheritanceAssembler.java:52) at org.apache.maven.project.ModelUtils.cloneModel(ModelUtils.java:435) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:667) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:275) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) On 3/2/06, Fabrizio Giustina [EMAIL PROTECTED] wrote: big +1 this time fabrizio On 3/2/06, John Casey [EMAIL PROTECTED] wrote: Hello everyone, If you've been tracking the thread calling for the release of Maven 2.0.3, you'll know that several issues came up which have delayed any decision on the release. The full discussion can be found here: http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 - 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]
[maven2 build trunk - SKIPPED - checkout] Fri Mar 3 15:24:49 GMT 2006
ci.sh already running... exiting maven 16670 16667 0 15:24:50 pts/4 0:00 /bin/sh ./ci.sh checkout maven 16671 16667 0 15:24:50 pts/4 0:00 /bin/sh ./ci.sh checkout - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - checkout] Fri Mar 3 15:25:19 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.152520.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] M2 Dependency Resolution Improvements
Comments inline. Cheers, John Garrett Conaty wrote: I've been working quite a bit with Maven2 transitive dependencies at work, and think that they're one of the best strengths of M2. In the course of building quite a number of artifacts through build, deployment, and update I've found that there are number of improvements that can be made. So with the use cases that I've seen at work and listening to what other devs in the community have experienced, I'm proposing some enhancements. These points are only an overview, and some are a variation or enhancement on features in the Maven 2.1 design docs. I've gone into more depth on the rationale and the features themselves on the MavenUser Wiki at http://docs.codehaus.org/display/MAVENUSER/Improving+Maven2+Dependency+Resolution : * Virtual Dependencies (also know as spec jars) This is something we've been discussing for some time now. We just need to have a concrete discussion about what's involved in implementing it. For instance, we have to provide a portable way to resolve spec - implementation mappings. This might take a form similar to the plugin-prefix - implementation metadata file. Once we have that in place, we need some consistent mechanism for choosing one implementation over another. The corresponding mechanisms for plugin selection based on prefix are somewhat crude... * Environmental Context - Use the JDK environment and deploy environment as part of the resolution phase. As an example, you don't need to get JAXP API classes from a repository if compiling with JDK 1.4 If you can represent pieces like the JDK as a repository with an alternate layout, I don't see why we couldn't tie this into the spec dependencies bit above and make it work. * Pinning Dependencies (Overrides) - If you have a fixed dependency tree for a given release, it's important to be able to provided patches that can override a node of the tree. dependencyManagement only appears to handle this for parent-child projects. I suspect an elegant way to handle this might be with an alternative dependency selection implementation that uses some authoritative set of approved versions when resolving artifacts... Questions I have WRT this are: 1. will this set of blessed versions be portable (i.e. travel with the POM)? 2. how will developers in a team setting share this info? It seems like implementing this would be an exercise in walking a tightrope between portability and centralized declaration for versions. * Filtering Parameters - Let the dependency resolution be able to pick artifacts based on things like required JDK version, license, signed/unsigned, tags,etc. Is this a dependency selection technique? It seems like it's just a matter of approving a given dependency as a candidate for selection using POM attributes and possibly attributes of the jar itself (which could be a bit more involved), before allowing artifact version selection to proceed. Much of this could probably be factored out of the DefaultArtifactCollector, into some sort of pluggable component. * Blacklisting artifacts - Not just repositories. This is appropriate if you don't control the POM that's using the artifact to be blacklisted. ...so you're talking about a global exclusions list? Again, my questions about this center on dissemination of that list. Otherwise, can't you do this with dependency exclusions now? * License Acknowledgment - Some commercial vendors (Sun) require a clickthrough license before downloading. Also a user getting an artifact under an Apache license with an LGPL dependency would need to be notified that they are not only accepting the Apache License but LGPL. This might be another thing that gets added to the dependency selection process, when we're gathering candidate artifact/versions. If you combine it with spec dependencies, the selection algorithm might be able to select an alternate [set of] deps to satisfy the spec dependency you specify (when the user refuses to traverse the click-through)... Also, any click-through implementation will have to completely satisfy the legal requirements of people like Sun, which could mean finding a way to embed/interact with a full-featured browser. I don't know of any cross-platform way to do this, without embedding a browser...and I'm not aware of any mature embeddable browser implementations, personally. * Expose dependency resolution to client tools - Provide APIs so that clients can pass in different artifacts with different filters to see not only the multiple artifacts and paths that can resolve a dependency, but also which one would be selected. This would be very helpful for debugging and also to let UI tools visualize the dependency graphs. We can undoubtedly go further in making this accessible, but it should be possible to do what you describe even now. It's just a matter of knowing the APIs... I don't think these features
Re: Question about Clearcase, Starteam and Perforce
StartTeam does have it but completely hidden and undocumented. -D On 3/3/06, Mike Perham [EMAIL PROTECTED] wrote: And I believe ClearCase is the same.No idea about StarTeam.-Original Message-From: Jeff Jensen [mailto: [EMAIL PROTECTED]]Sent: Friday, March 03, 2006 8:20 AMTo: scm-dev@maven.apache.orgSubject: Re: Question about Clearcase, Starteam and Perforce Perforce does not use local disk for storage of info like CVS and svn.Quoting Emmanuel Venisse [EMAIL PROTECTED]: Hi, I added a new method in SCMProvider (String getScmSpecificFilename()) This method returns the name of reserved filename/directory use by scm like CVS or .svn Do we have a similar file for Clearcase/Starteam/Perforce ? Emmanuel
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 15:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.154500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MIDEA-26) Library support and template overrides
[ http://jira.codehaus.org/browse/MIDEA-26?page=all ] Patrick Lightbody updated MIDEA-26: --- Attachment: idea.diff Library support and template overrides -- Key: MIDEA-26 URL: http://jira.codehaus.org/browse/MIDEA-26 Project: Maven 2.x Idea Plugin Type: New Feature Reporter: Patrick Lightbody Attachments: idea.diff, idea.diff, idea.diff, idea.diff, idea.diff, idea.patch The supplied patch provides two features: 1) If the files workspace.xml, module.xml, or project.xml are found in src/main/idea, they will be used in place of those found in the plugin jar. That is, they will be used for creating new config files (Rather than updating existing ones). 2) You may specify a library element that can allow you to tweak how the library is defined in the module: * exclude: prevents the library from being configured - great for times when you wish to instead link in a module as a dependency * sources: a comma separated list of source paths to bind to the library * classes: a comma separated list of class paths to use in place of the typical jar found in ~/.m2 -- 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 trunk - FAILED - update] Fri Mar 3 16:00:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.16.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 16:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.161500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 16:30:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.163000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 17:00:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.170001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails Key: MNG-2120 URL: http://jira.codehaus.org/browse/MNG-2120 Project: Maven 2 Type: Bug Versions: 2.0.2 Reporter: John Casey Priority: Blocker Fix For: 2.0.3 when a plugin repository transfer results in a TransferFailedException, any locally install plugin metadata gets obliterated. I'll add more info as I find it out. -- 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: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[ http://jira.codehaus.org/browse/MNG-2120?page=all ] John Casey updated MNG-2120: Assign To: John Casey Fix Version: 2.0.3 [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails Key: MNG-2120 URL: http://jira.codehaus.org/browse/MNG-2120 Project: Maven 2 Type: Bug Versions: 2.0.2 Reporter: John Casey Assignee: John Casey Priority: Blocker Fix For: 2.0.3 when a plugin repository transfer results in a TransferFailedException, any locally install plugin metadata gets obliterated. I'll add more info as I find it out. -- 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 - FAILED - update] Fri Mar 3 17:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.171500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[ http://jira.codehaus.org/browse/MNG-2120?page=all ] John Casey closed MNG-2120: --- Resolution: Cannot Reproduce ...and now I cannot reproduce it. This is VERY strange. [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails Key: MNG-2120 URL: http://jira.codehaus.org/browse/MNG-2120 Project: Maven 2 Type: Bug Versions: 2.0.2 Reporter: John Casey Assignee: John Casey Priority: Blocker Fix For: 2.0.3 when a plugin repository transfer results in a TransferFailedException, any locally install plugin metadata gets obliterated. I'll add more info as I find it out. -- 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: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[ http://jira.codehaus.org/browse/MNG-2120?page=comments#action_60004 ] John Casey commented on MNG-2120: - the problem was manifesting itself in the maven-core-it process, which I had to remind myself was actually executing a delete of the local plugin installation in a pre-build hook. *UGH* [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails Key: MNG-2120 URL: http://jira.codehaus.org/browse/MNG-2120 Project: Maven 2 Type: Bug Versions: 2.0.2 Reporter: John Casey Assignee: John Casey Priority: Blocker Fix For: 2.0.3 when a plugin repository transfer results in a TransferFailedException, any locally install plugin metadata gets obliterated. I'll add more info as I find it out. -- 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 trunk - FAILED - update] Fri Mar 3 17:30:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.173000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MWAR-21) Need a way to include limited set of webapp's dependencies
[ http://jira.codehaus.org/browse/MWAR-21?page=comments#action_60005 ] Grzegorz Slowikowski commented on MWAR-21: -- I made a test and they were included in the war. A deleted my local repository war plugin and a) made a test, 2.0-beta-2 version was used - everything ok b) built trunk version (2.0-beta-3-SNAPSHOT) - everything ok too. I don't know what version I had in my repository. I know only that is was a snapshot. Try to delete maven-war-plugin from your local repo and try again. Need a way to include limited set of webapp's dependencies -- Key: MWAR-21 URL: http://jira.codehaus.org/browse/MWAR-21 Project: Maven 2.x War Plugin Type: Improvement Environment: M2.0.1 Reporter: Dirk Olmes Priority: Blocker Fix For: 2.0 Attachments: AbstractWarMojo.diff I need a way to pack a war that includes only a limited set of the webapp's dependencies. We're deploying in mainly two different environments: for testing, the webapp runs standalone and thus needs to include all its dependencies in the war. For production we deploy the webapp into a JBoss server that has all the dependencies already installed. I've modified AbstractWarMojo in the following way: 1) allow to specify dependencyIncludes an dependencyExcludes (as lists) 2) upon building the war, each dependency is checked against the excludes and the includes and will be added to the war accordingly. While this patch may not be the best way to to it, it clearly shows my requirements. -- 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 - FAILED - update] Fri Mar 3 17:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.174501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 18:00:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.180001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 18:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.181500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 18:30:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.183001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 18:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.184500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Fri Mar 3 19:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.190001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.190001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] M2 Dependency Resolution Improvements
John, Thanks for the feedback. My responses are now inline: On Mar 3, 2006, at 7:57 AM, John Casey wrote: Comments inline. Cheers, John Garrett Conaty wrote: I've been working quite a bit with Maven2 transitive dependencies at work, and think that they're one of the best strengths of M2. In the course of building quite a number of artifacts through build, deployment, and update I've found that there are number of improvements that can be made. So with the use cases that I've seen at work and listening to what other devs in the community have experienced, I'm proposing some enhancements. These points are only an overview, and some are a variation or enhancement on features in the Maven 2.1 design docs. I've gone into more depth on the rationale and the features themselves on the MavenUser Wiki at http://docs.codehaus.org/display/MAVENUSER/ Improving+Maven2+Dependency+Resolution : * Virtual Dependencies (also know as spec jars) This is something we've been discussing for some time now. We just need to have a concrete discussion about what's involved in implementing it. For instance, we have to provide a portable way to resolve spec - implementation mappings. This might take a form similar to the plugin-prefix - implementation metadata file. Once we have that in place, we need some consistent mechanism for choosing one implementation over another. The corresponding mechanisms for plugin selection based on prefix are somewhat crude... How about putting a new virtual in the dependency stanzas of the POM? Of course, it would still need someway to resolve this map (perhaps by putting them in profiles or something). * Environmental Context - Use the JDK environment and deploy environment as part of the resolution phase. As an example, you don't need to get JAXP API classes from a repository if compiling with JDK 1.4 If you can represent pieces like the JDK as a repository with an alternate layout, I don't see why we couldn't tie this into the spec dependencies bit above and make it work. Yeah, I definitely see these being very related. So you could define a JDK 1.4 environment or Geronimo 1.0 environment (profile?) that would be contain the list of the spec JARS. This would be really helpful for building some of the Apache Commons packages that require different JARs (currently) depending on what JDK they're using. I'd love it if the build files for these would be able to list all the spec JARs that they require and then when you build, Maven could have the knowledge of your environment. Though I'm not sure they'd actually be POMs themselves (like for JDK 1.4) that would list artifacts. It might be viewed something more like how Eclipse shows you library entries for JDK or app servers (like Tomcat in the Eclipse WebToolsProject) * Pinning Dependencies (Overrides) - If you have a fixed dependency tree for a given release, it's important to be able to provided patches that can override a node of the tree. dependencyManagement only appears to handle this for parent- child projects. I suspect an elegant way to handle this might be with an alternative dependency selection implementation that uses some authoritative set of approved versions when resolving artifacts... That makes some sense from an 'approved' perspective, though the use case I'm describing is actually a specific patch (e.g. you've built your application with a certain release of dependencies, and then your vendor tells you you need to slot in this security fix). This is slightly different than having a compliant or standard set of dependencies. Questions I have WRT this are: 1. will this set of blessed versions be portable (i.e. travel with the POM)? The simplest scoping would be to have it be an element of your application's POM. I could also see it in /.m2/ specific settings for a build machine, though this would be less portable. A fancy solution might be to point to a central server and download updates, but this is probably overkill. 2. how will developers in a team setting share this info? It seems like implementing this would be an exercise in walking a tightrope between portability and centralized declaration for versions. (see previous answer) * Filtering Parameters - Let the dependency resolution be able to pick artifacts based on things like required JDK version, license, signed/unsigned, tags,etc. Is this a dependency selection technique? It seems like it's just a matter of approving a given dependency as a candidate for selection using POM attributes and possibly attributes of the jar itself (which could be a bit more involved), before allowing artifact version selection to proceed. Much of this could probably be factored out of the DefaultArtifactCollector, into some sort of pluggable component. Exactly, I think these filters are additional parameters to the
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Mar 3 19:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.191500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.191500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Fri Mar 3 19:32:36 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.193236.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.193236.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] separate mailings lists for humans/JIRA/CI/commits
+1 (non-binding) -- Dennis Lundberg Jason van Zyl wrote: Hi, I just wanted to close this up as I think it's a good idea and anything that let's people manage their mail better IMO is a good thing. +1 In this type of vote it is non-technical so simple majority wins, but if it's close we can continue the discussion but I think a majority wanted preferred the separation. - 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]
What M2 groupId should we use in Jakarta-commons?
Hi all Discussions on commons-dev@jakarta.apache.org have started regarding a migration from Maven 1 to Maven 2. One topic [1] that we need your assistance with is what the correct M2 groupId for Jakarta-commons is. Two suggestions have been made: - org.apache.commons corresponds to the java package structure - org.apache.jakarta.commons corresponds to the organization path within the ASF Which one is correct and why? The Guide to naming conventions on groupId [2] says to use package names and has org.apache.jakarta.commons as an example. But the source code for a Jakarta commons component is in the package org.apache.commons.component not in org.apache.jakarta.commons.component I hope you can help us out here. [1]http://www.nabble.com/-daemon-Deploying-maven-2-pom-for-release-1.0.1-t1190137.html#a3136295 [2]http://maven.apache.org/guides/mini/guide-naming-conventions.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2118) Listing central repo in pluginRepositories confuses Maven
[ http://jira.codehaus.org/browse/MNG-2118?page=comments#action_60011 ]
Jason Dillon commented on MNG-2118:
---
I also noticed yesterday, that if you do not list central for repositories
and at least one of the repository listed fail, that Maven 2.0.2 will fail to
find artifacts from the inherited central
Listing central repo in pluginRepositories confuses Maven
-
Key: MNG-2118
URL: http://jira.codehaus.org/browse/MNG-2118
Project: Maven 2
Type: Bug
Components: POM, Plugins and Lifecycle
Versions: 2.0.2
Reporter: Jason Dillon
Priority: Critical
It appears that if you list the central repository in the pluginRepositories,
that it may cause Maven to incorrectly check the central repository for
plugin data.
Specifically, I found this when using the maven-clean-plugin 2.1. I did not
have this plugin in my local repository, and when running {{mvn clean}} it
causes the build to fail:
{noformat}
+ Error stacktraces are turned on.
[DEBUG] Building Maven user-level plugin registry from:
'/Users/jason/.m2/plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/conf/plugin-registry.xml'
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Paycore
[INFO] Paycore :: Merchant
[INFO] Paycore :: Merchant :: Core
[INFO] Paycore :: Merchant :: Services
[INFO]
[INFO] Building Paycore
[INFO]task-segment: [clean]
[INFO]
[DEBUG] maven-clean-plugin: resolved to version 2.1 from repository
maven-snapshots
[DEBUG] Trying repository maven-snapshots
Downloading:
http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.1/maven-clean-plugin-2.1.pom
[DEBUG] Artifact not found - using stub model: Unable to locate resource in
repository
org.apache.maven.plugins:maven-clean-plugin:pom:2.1
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
maven-snapshots (http://snapshots.maven.codehaus.org/maven2),
paybytouch-legacy (http://repository.paybytouch.com/m1/repository)
[DEBUG] Using defaults for missing POM
org.apache.maven.plugins:maven-clean-plugin:pom:2.1
[DEBUG] maven-surefire-plugin: resolved to version 2.1.3-SNAPSHOT from
repository maven-snapshots
[DEBUG] maven-surefire-plugin: resolved to version 2.1.3-20060228.012944-10
from repository maven-snapshots
[DEBUG] Retrieving parent-POM from the repository for project:
null:maven-surefire-plugin:maven-plugin:2.1.3-20060228.012944-10
[DEBUG] maven-one-plugin: resolved to version 1.0-20060213.011019-4 from
repository maven-snapshots
[DEBUG] maven-one-plugin: resolved to version 1.0-20060213.011019-4 from
repository maven-snapshots
[DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1
(selected for runtime)
-
this realm = app0.child-container[org.apache.maven.plugins:maven-clean-plugin]
urls[0] =
file:/Users/jason/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.1/maven-clean-plugin-2.1.jar
Number of imports: 0
this realm = plexus.core.maven
urls[0] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/commons-cli-1.0.jar
urls[1] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/doxia-sink-api-1.0-alpha-7.jar
urls[2] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/jsch-0.1.24.jar
urls[3] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-artifact-2.0.2.jar
urls[4] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-artifact-manager-2.0.2.jar
urls[5] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-core-2.0.2-javadoc.jar
urls[6] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-core-2.0.2.jar
urls[7] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-error-diagnostics-2.0.2.jar
urls[8] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-model-2.0.2.jar
urls[9] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-monitor-2.0.2.jar
urls[10] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-api-2.0.2.jar
urls[11] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-descriptor-2.0.2.jar
urls[12] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-parameter-documenter-2.0.2.jar
urls[13] =
file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-registry-2.0.2.jar
urls[14] =
[jira] Created: (MNG-2121) mvn launch script should use jpackage.org config if available
mvn launch script should use jpackage.org config if available - Key: MNG-2121 URL: http://jira.codehaus.org/browse/MNG-2121 Project: Maven 2 Type: Improvement Components: Command Line Versions: 2.0.2 Environment: GNU/Linux Reporter: Chris Hubick Priority: Minor Attachments: maven_jpp.patch I am attempting to install and use Maven for the first time... so excuse me if I'm off base here :) It is my understanding that a single global classpath (and JVM) is generally deprecated, so I trivially modified my version of the command line 'mvn' script to automatically utilize my existing jpackage.org configuration (patch attached). Also, the installation instructions at http://maven.apache.org/download.html say to unpack it to /usr/local/maven-2.0.2/, yet the mvn script looks for the existance of /opt/m2/ when attempting to automatically set $M2_HOME. I symlinked /usr/local/maven to /usr/local/maven-2.0.2, and also trivially patched my mvn script to look for /usr/local/maven/ when setting $M2_HOME. Instead of adding $M2_HOME/bin to my global path, I just symlinked /usr/local/bin/mvn - /usr/local/maven/bin/mvn. In this way, I have a working Maven (I hope) without having to modify any global configuration on my machine - meaning the install should be side effect free. I can also upgrade to a new release without having to modify any configuration. -- 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: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60013 ] Matthew Beermann commented on MNG-2049: --- Sorry for the slowness; I finally managed to capture this one in the act. The artifactIds are snipped out, as the project is proprietary. It seems to happen when the central repository is down or overloaded... org.apache.maven.lifecycle.LifecycleExecutionException: Unable to get dependency information: Unable to read the metadata file at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:548) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.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(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get dependency information at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:304) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1120) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:369) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:131) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:282) ... 23 more Caused by: org.apache.maven.project.ProjectBuildingException: Error getting POM at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:417) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:351) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) ... 24 more Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Error transferring file at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:140) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:386) ... 26 more Caused by: org.apache.maven.wagon.TransferFailedException: Error transferring file at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:99) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:369) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:282) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:244) at
[jira] Commented: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60017 ] Carlos Sanchez commented on MNG-2049: - Caused by: java.net.ConnectException: Connection timed out: connect It's unrelated to missing poms, only that it'll try to get them everytime you run maven, making the time out problem worse Dependencies without POMs cause intermittent failures - Key: MNG-2049 URL: http://jira.codehaus.org/browse/MNG-2049 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Matthew Beermann We have a number of jars in our repository that don't have POMs, e.g. third-party libraries, etc. Maven happily downloads the jar anyway, and issues a warning that there's no POM - except, sometimes, it just fails instead. See the build log below. If I were to rerun Maven again, it might fail on a different jar, or it might succeed. I can't seem to find any rhyme or reason to it... I agree that a missing POM merits a warning, but if the jar is there, it shouldn't be failing the build! Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [WARNING] Unable to get resource from repository prdwebdev11 (http://prdwebdev11/repository) Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: j2ee:j2ee Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error transferring file j2ee:j2ee:pom:1.3.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), prdwebdev11 (http://prdwebdev11/repository) -- 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: [vote] Release Maven 2.0.3 (second attempt)
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 John Casey wrote: Hello everyone, If you've been tracking the thread calling for the release of Maven 2.0.3, you'll know that several issues came up which have delayed any decision on the release. The full discussion can be found here: http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 At any rate, I wanted to report that the last issue I have the ability to debug is fixed - MNG-1415. The only outstanding issue from the previous discussion is MNG-1317, which Kenney has graciously agreed to debug and (hopefully) fix tomorrow. There are also two other open issues pending in JIRA, but these are tasks that will be executed during the release process, so shouldn't hold up the vote. Regardless of whether MNG-1317 is fixed, I think we've got plenty of reason to release 2.0.3 now. We've got two critical fixes for the SSH network transport, improved quoted-argument handling for *nix environments, plus all of the fixes mentioned in the previous vote message. All in all, 24-25 issues will be fixed for this release. I'm calling this re-vote to ensure that everyone has had a chance to look over the work we've done in the past week or so. This release shouldn't come out of the blue sky for anyone at this point. :-) Here's a binary we can use as the most current RC (RC2?). I'll send another message with a new link if/when Kenney gets MNG-1317 fixed. http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060302.181503.tar.gz Let's do the customary 72h vote, +1/0/-1. Here's my +1. Thanks, 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: [vote] Release Maven 2.0.3 (second attempt)
On Fri, 3 Mar 2006, John Casey wrote: +1 (2nd time :)) 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 John Casey wrote: Hello everyone, If you've been tracking the thread calling for the release of Maven 2.0.3, you'll know that several issues came up which have delayed any decision on the release. The full discussion can be found here: http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 At any rate, I wanted to report that the last issue I have the ability to debug is fixed - MNG-1415. The only outstanding issue from the previous discussion is MNG-1317, which Kenney has graciously agreed to debug and (hopefully) fix tomorrow. There are also two other open issues pending in JIRA, but these are tasks that will be executed during the release process, so shouldn't hold up the vote. Regardless of whether MNG-1317 is fixed, I think we've got plenty of reason to release 2.0.3 now. We've got two critical fixes for the SSH network transport, improved quoted-argument handling for *nix environments, plus all of the fixes mentioned in the previous vote message. All in all, 24-25 issues will be fixed for this release. I'm calling this re-vote to ensure that everyone has had a chance to look over the work we've done in the past week or so. This release shouldn't come out of the blue sky for anyone at this point. :-) Here's a binary we can use as the most current RC (RC2?). I'll send another message with a new link if/when Kenney gets MNG-1317 fixed. http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060302.181503.tar.gz Let's do the customary 72h vote, +1/0/-1. Here's my +1. Thanks, 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] -- 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: svn commit: r382849 - /maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
Can we get unit tests for these types of changes?
- Brett
[EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Fri Mar 3 07:08:31 2006
New Revision: 382849
URL: http://svn.apache.org/viewcvs?rev=382849view=rev
Log:
Fixing NPE in appendPath(..) when calculating '..' path adjustments.
Modified:
maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
Modified:
maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=382849r1=382848r2=382849view=diff
==
---
maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
(original)
+++
maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
Fri Mar 3 07:08:31 2006
@@ -538,10 +538,16 @@
lastToken = currentToken;
currentToken = tokens.nextToken();
-if ( ...equals( currentToken ) )
+if ( ...equals( currentToken ) lastToken != null )
{
-// trim the previous path part off...
-cleanedPath.setLength( cleanedPath.length() - (
lastToken.length() + 1 ) );
+int cleanedPathLen = cleanedPath.length();
+int lastTokenLen = lastToken.length();
+
+if ( cleanedPathLen lastTokenLen )
+{
+// trim the previous path part off...
+cleanedPath.setLength( cleanedPath.length() - (
lastToken.length() + 1 ) );
+}
}
else if ( !..equals( currentToken ) )
{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r382889 - in /maven/plugins/trunk/maven-idea-plugin: pom.xml src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java
You need to add prerequisitemaven2.0.1 then. - Brett [EMAIL PROTECTED] wrote: Author: epunzalan Date: Fri Mar 3 09:12:31 2006 New Revision: 382889 URL: http://svn.apache.org/viewcvs?rev=382889view=rev Log: Brought back maven deps to 2.0.1 since the parent have depMngt set to 2.0.1... which allowed me to use a better method available in 2.0.1 Modified: maven/plugins/trunk/maven-idea-plugin/pom.xml maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java Modified: maven/plugins/trunk/maven-idea-plugin/pom.xml URL: http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-idea-plugin/pom.xml?rev=382889r1=382888r2=382889view=diff == --- maven/plugins/trunk/maven-idea-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-idea-plugin/pom.xml Fri Mar 3 09:12:31 2006 @@ -17,17 +17,17 @@ dependency groupIdorg.apache.maven/groupId artifactIdmaven-artifact/artifactId - version2.0/version + version2.0.1/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-artifact-manager/artifactId - version2.0/version + version2.0.1/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-model/artifactId - version2.0/version + version2.0.1/version /dependency dependency groupIdorg.codehaus.plexus/groupId Modified: maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java URL: http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java?rev=382889r1=382888r2=382889view=diff == --- maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java (original) +++ maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java Fri Mar 3 09:12:31 2006 @@ -278,7 +278,8 @@ VersionRange versionRange = VersionRange.createFromVersionSpec( d.getVersion() ); Artifact artifact = artifactFactory.createDependencyArtifact( d.getGroupId(), d.getArtifactId(), versionRange, d.getType(), - d.getClassifier(), d.getScope() ); + d.getClassifier(), d.getScope(), + d.isOptional() ); map.put( d.getManagementKey(), artifact ); } catch ( InvalidVersionSpecificationException e ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60020 ] Matthew Beermann commented on MNG-2049: --- Right... but I think there's still a bug here: a failure (for any reason) to find a given artifact on one repository should not fail the build, so long as the artifact is found on /some/ repository. Further, a failure to load the POM should never fail the build, so long as the actual artifact was retrieved successfully. Dependencies without POMs cause intermittent failures - Key: MNG-2049 URL: http://jira.codehaus.org/browse/MNG-2049 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Matthew Beermann We have a number of jars in our repository that don't have POMs, e.g. third-party libraries, etc. Maven happily downloads the jar anyway, and issues a warning that there's no POM - except, sometimes, it just fails instead. See the build log below. If I were to rerun Maven again, it might fail on a different jar, or it might succeed. I can't seem to find any rhyme or reason to it... I agree that a missing POM merits a warning, but if the jar is there, it shouldn't be failing the build! Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [WARNING] Unable to get resource from repository prdwebdev11 (http://prdwebdev11/repository) Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: j2ee:j2ee Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error transferring file j2ee:j2ee:pom:1.3.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), prdwebdev11 (http://prdwebdev11/repository) -- 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: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[ http://jira.codehaus.org/browse/MNG-2120?page=all ] Brett Porter updated MNG-2120: -- Fix Version: (was: 2.0.3) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails Key: MNG-2120 URL: http://jira.codehaus.org/browse/MNG-2120 Project: Maven 2 Type: Bug Versions: 2.0.2 Reporter: John Casey Assignee: John Casey Priority: Blocker when a plugin repository transfer results in a TransferFailedException, any locally install plugin metadata gets obliterated. I'll add more info as I find it out. -- 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: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60022 ] Carlos Sanchez commented on MNG-2049: - a failure to get poms doesn't fail the build, unless it's a parent pom Dependencies without POMs cause intermittent failures - Key: MNG-2049 URL: http://jira.codehaus.org/browse/MNG-2049 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Matthew Beermann We have a number of jars in our repository that don't have POMs, e.g. third-party libraries, etc. Maven happily downloads the jar anyway, and issues a warning that there's no POM - except, sometimes, it just fails instead. See the build log below. If I were to rerun Maven again, it might fail on a different jar, or it might succeed. I can't seem to find any rhyme or reason to it... I agree that a missing POM merits a warning, but if the jar is there, it shouldn't be failing the build! Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [WARNING] Unable to get resource from repository prdwebdev11 (http://prdwebdev11/repository) Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: j2ee:j2ee Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error transferring file j2ee:j2ee:pom:1.3.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), prdwebdev11 (http://prdwebdev11/repository) -- 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: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60023 ] Matthew Beermann commented on MNG-2049: --- blink Except that it _does_. That's the entire point of both the tracebacks I posted... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: dependency-of-my-project Reason: Error getting POM for 'dependency-of-my-project' from the repository: Error transferring file Dependencies without POMs cause intermittent failures - Key: MNG-2049 URL: http://jira.codehaus.org/browse/MNG-2049 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Matthew Beermann We have a number of jars in our repository that don't have POMs, e.g. third-party libraries, etc. Maven happily downloads the jar anyway, and issues a warning that there's no POM - except, sometimes, it just fails instead. See the build log below. If I were to rerun Maven again, it might fail on a different jar, or it might succeed. I can't seem to find any rhyme or reason to it... I agree that a missing POM merits a warning, but if the jar is there, it shouldn't be failing the build! Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [WARNING] Unable to get resource from repository prdwebdev11 (http://prdwebdev11/repository) Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: j2ee:j2ee Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error transferring file j2ee:j2ee:pom:1.3.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), prdwebdev11 (http://prdwebdev11/repository) -- 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: svn commit: r382849 - /maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
Brett Porter wrote: Can we get unit tests for these types of changes? I think we decided coverage should not go down. How about we activate coverage testing and get the build to fail when it drops. We all need the reminder because we've all let it drop. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2049) Timeouts in POM downloads cause the build to fail
[ http://jira.codehaus.org/browse/MNG-2049?page=all ] Carlos Sanchez updated MNG-2049: Summary: Timeouts in POM downloads cause the build to fail (was: Dependencies without POMs cause intermittent failures) Timeouts in POM downloads cause the build to fail - Key: MNG-2049 URL: http://jira.codehaus.org/browse/MNG-2049 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Matthew Beermann We have a number of jars in our repository that don't have POMs, e.g. third-party libraries, etc. Maven happily downloads the jar anyway, and issues a warning that there's no POM - except, sometimes, it just fails instead. See the build log below. If I were to rerun Maven again, it might fail on a different jar, or it might succeed. I can't seem to find any rhyme or reason to it... I agree that a missing POM merits a warning, but if the jar is there, it shouldn't be failing the build! Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [WARNING] Unable to get resource from repository prdwebdev11 (http://prdwebdev11/repository) Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: j2ee:j2ee Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error transferring file j2ee:j2ee:pom:1.3.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), prdwebdev11 (http://prdwebdev11/repository) -- 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]
[m2] Can the site plugin be told to exclude some files?
In jakarta-commons we would like to keep our existing (m1) xdocs which reside in /xdocs/ if we move to m2. The m2 site plugin picks up these xdocs even though the are not in the preferred m2 directory, which is good. We use xml entities in our navigation.xml file for various reasons. We would like to keep this to preserve our existing m1 site build. At the same time we need to exclude this file from m2, because the m2 site plugin chokes on the xml entities. I was not able to find a way to do this. Should I file a JIRA about it? Perhaps a new parameter excludeFiles in SiteMojo? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Can the site plugin be told to exclude some files?
Sounds good. - Brett Dennis Lundberg wrote: In jakarta-commons we would like to keep our existing (m1) xdocs which reside in /xdocs/ if we move to m2. The m2 site plugin picks up these xdocs even though the are not in the preferred m2 directory, which is good. We use xml entities in our navigation.xml file for various reasons. We would like to keep this to preserve our existing m1 site build. At the same time we need to exclude this file from m2, because the m2 site plugin chokes on the xml entities. I was not able to find a way to do this. Should I file a JIRA about it? Perhaps a new parameter excludeFiles in SiteMojo? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - checkout] Sat Mar 4 00:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.00.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.00.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Sat Mar 4 00:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060304.003001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060304.003001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build trunk - SUCCESS - checkout] Sat Mar 4 01:00:01 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060304.010001.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060304.010001.txt
[maven2 build trunk - SUCCESS - update] Sat Mar 4 01:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.010001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.010001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build branches/continuum-1.0.x - SUCCESS - checkout] Sat Mar 4 02:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060304.02.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060304.02.txt
[jira] Commented: (MJAVADOC-46) Allow -docletpath to be specified as an artifact
[ http://jira.codehaus.org/browse/MJAVADOC-46?page=comments#action_60036 ] Maria Odea Ching commented on MJAVADOC-46: -- Tested and verified the submitted patch. Allow -docletpath to be specified as an artifact Key: MJAVADOC-46 URL: http://jira.codehaus.org/browse/MJAVADOC-46 Project: Maven 2.x Javadoc Plugin Type: New Feature Reporter: Wendy Smoak Priority: Minor Fix For: 2.0-beta-4 Attachments: javadoc-docletArtifact.diff As suggested (and written!) by Brett Porter on [EMAIL PROTECTED], in this thread: http://marc.theaimsgroup.com/?l=turbine-maven-devm=113694865002748w=2 Allow the doclet path to be specified as an artifact with docletArtifact. Currently the only option is docletPath which must be the local path to the jar file and is not portable. Comments welcome, I'm happy to rework it if necessary. -- 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: (MJAVADOC-46) Allow -docletpath to be specified as an artifact
[ http://jira.codehaus.org/browse/MJAVADOC-46?page=all ] Allan Ramirez closed MJAVADOC-46: - Resolution: Fixed Applied Patch.. Thanks Wendy and Odea Allow -docletpath to be specified as an artifact Key: MJAVADOC-46 URL: http://jira.codehaus.org/browse/MJAVADOC-46 Project: Maven 2.x Javadoc Plugin Type: New Feature Reporter: Wendy Smoak Assignee: Allan Ramirez Priority: Minor Fix For: 2.0-beta-4 Attachments: javadoc-docletArtifact.diff As suggested (and written!) by Brett Porter on [EMAIL PROTECTED], in this thread: http://marc.theaimsgroup.com/?l=turbine-maven-devm=113694865002748w=2 Allow the doclet path to be specified as an artifact with docletArtifact. Currently the only option is docletPath which must be the local path to the jar file and is not portable. Comments welcome, I'm happy to rework it if necessary. -- 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 trunk - SUCCESS - update] Sat Mar 4 03:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.030001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.030001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Sat Mar 4 03:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060304.031500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060304.031500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MJAVADOC-40) javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-40?page=all ]
Maria Odea Ching updated MJAVADOC-40:
-
Attachment: (was: MJAVADOC-40-maven-javadoc-plugin.patch)
javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
--
Key: MJAVADOC-40
URL: http://jira.codehaus.org/browse/MJAVADOC-40
Project: Maven 2.x Javadoc Plugin
Type: Bug
Reporter: Brian Fox
Assignee: Maria Odea Ching
Fix For: 2.0-beta-4
Attachments: javadoc-jar.patch
The following configuration will cause jar to fail. This is major because it
stops release:perform from completing on what otherwise should be a valid
config
build
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
source1.4/source
destDir${project.build.directory}/site/javadoc/destDir
/configuration
/plugin
/plugins
/build
--
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: (MJAVADOC-40) javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-40?page=all ]
Maria Odea Ching updated MJAVADOC-40:
-
Attachment: MJAVADOC-40-maven-javadoc-plugin.patch
javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
--
Key: MJAVADOC-40
URL: http://jira.codehaus.org/browse/MJAVADOC-40
Project: Maven 2.x Javadoc Plugin
Type: Bug
Reporter: Brian Fox
Assignee: Maria Odea Ching
Fix For: 2.0-beta-4
Attachments: MJAVADOC-40-maven-javadoc-plugin.patch, javadoc-jar.patch
The following configuration will cause jar to fail. This is major because it
stops release:perform from completing on what otherwise should be a valid
config
build
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
source1.4/source
destDir${project.build.directory}/site/javadoc/destDir
/configuration
/plugin
/plugins
/build
--
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: (MSUREFIRE-48) Enable assertions for underlying jvm
[ http://jira.codehaus.org/browse/MSUREFIRE-48?page=all ] Brett Porter closed MSUREFIRE-48: - Assign To: Brett Porter Resolution: Fixed Fix Version: (was: 2.1.3) 2.2 enabled, though I'm not sure why I need to use -ea to do it in forked mode Enable assertions for underlying jvm Key: MSUREFIRE-48 URL: http://jira.codehaus.org/browse/MSUREFIRE-48 Project: Maven 2.x Surefire Plugin Type: Sub-task Environment: jre 1.5 Reporter: Jesse Kuhnert Assignee: Brett Porter Fix For: 2.2 Some jre's don't have assertions enabled by default and require a runtime parameter of -ea in order to use them. Since TestNG supports assertions and it would be nice to use the short hand method occassionally, determine feasability of either enabling them in the currently running jvm, or adding the command line params to the bootloader. -- 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: (MAVENUPLOAD-761) Upload tomcat poms and commons-modeler-1.1.jar to maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-761?page=comments#action_60040 ] Jeff Genender commented on MAVENUPLOAD-761: --- Hi Carlos...no big deal...go ahead an close this out. Geronimo will use legacy at cvs.apache.org. Thanks for the help. Upload tomcat poms and commons-modeler-1.1.jar to maven2 repository Key: MAVENUPLOAD-761 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-761 Project: maven-upload-requests Type: Task Reporter: Anita Kulshreshtha Attachments: m2.jar, m2pos.zip 1. Upload the poms contained in the zip to these urls - http://www.ibiblio.org/maven2/tomcat/tomcat-ajp/5.5.15/ http://www.ibiblio.org/maven2/tomcat/catalina-cluster/5.5.15/ http://www.ibiblio.org/maven2/tomcat/catalina/5.5.15/ 2. Upload commons-modeler-1.1.jar from the url below and the pom from the zip file to http://www.ibiblio.org/maven2/commons-modeler/commons-modeler/ -- 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: (MIDEA-26) Library support and template overrides
[ http://jira.codehaus.org/browse/MIDEA-26?page=all ] Edwin Punzalan closed MIDEA-26: --- Assign To: Edwin Punzalan Resolution: Fixed Patch applied. Thanks. Library support and template overrides -- Key: MIDEA-26 URL: http://jira.codehaus.org/browse/MIDEA-26 Project: Maven 2.x Idea Plugin Type: New Feature Reporter: Patrick Lightbody Assignee: Edwin Punzalan Attachments: idea.diff, idea.diff, idea.diff, idea.diff, idea.diff, idea.patch The supplied patch provides two features: 1) If the files workspace.xml, module.xml, or project.xml are found in src/main/idea, they will be used in place of those found in the plugin jar. That is, they will be used for creating new config files (Rather than updating existing ones). 2) You may specify a library element that can allow you to tweak how the library is defined in the module: * exclude: prevents the library from being configured - great for times when you wish to instead link in a module as a dependency * sources: a comma separated list of source paths to bind to the library * classes: a comma separated list of class paths to use in place of the typical jar found in ~/.m2 -- 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 trunk - SUCCESS - update] Sat Mar 4 05:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.050001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.050001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MJAVADOC-40) javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-40?page=all ]
Allan Ramirez closed MJAVADOC-40:
-
Resolution: Fixed
Applied patch. Thanks
javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
--
Key: MJAVADOC-40
URL: http://jira.codehaus.org/browse/MJAVADOC-40
Project: Maven 2.x Javadoc Plugin
Type: Bug
Reporter: Brian Fox
Assignee: Maria Odea Ching
Fix For: 2.0-beta-4
Attachments: MJAVADOC-40-maven-javadoc-plugin.patch, javadoc-jar.patch
The following configuration will cause jar to fail. This is major because it
stops release:perform from completing on what otherwise should be a valid
config
build
plugins
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
source1.4/source
destDir${project.build.directory}/site/javadoc/destDir
/configuration
/plugin
/plugins
/build
--
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] Sat Mar 4 05:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060304.051500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060304.051500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Sat Mar 4 05:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.053000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.053000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-58) Cannot override read-only parameter: classpathElements
[ http://jira.codehaus.org/browse/MSUREFIRE-58?page=comments#action_60043 ] Brett Porter commented on MSUREFIRE-58: --- what part of the site is failing? surefire-report, or cobertura, or something else? Cannot override read-only parameter: classpathElements -- Key: MSUREFIRE-58 URL: http://jira.codehaus.org/browse/MSUREFIRE-58 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.2 Reporter: Jesper Zedlitz Priority: Minor When calling mvn site on a multi-module project the goal surefire:test fails for the second project: Error configuring: org.apache.maven.plugins:maven-surefire-plugin. Reason: ERROR: Cannot override read-only parameter: classpathElements in goal: surefire:test mvn test works and runs the tests on all modules. -- 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: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Brett Porter closed MSUREFIRE-23: - Resolution: Fixed Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Assignee: Brett Porter Fix For: 2.2 Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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: (MSUREFIRE-63) Surefire temporary files should be put in target rather than in the main project directory
[ http://jira.codehaus.org/browse/MSUREFIRE-63?page=all ] Brett Porter closed MSUREFIRE-63: - Assign To: Brett Porter Resolution: Fixed Fix Version: 2.2 Surefire temporary files should be put in target rather than in the main project directory -- Key: MSUREFIRE-63 URL: http://jira.codehaus.org/browse/MSUREFIRE-63 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3 Reporter: Vincent Massol Assignee: Brett Porter Priority: Minor Fix For: 2.2 The following 3 files are cretaed in the main project directory. surefire.properties surefire-classloader.properties surefire-system.properties They should go in target/ Thus if the build is stopped they're not left over in the main tree. -- 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: (MECLIPSE-71) eclipse:clean delets too much
[ http://jira.codehaus.org/browse/MECLIPSE-71?page=comments#action_60044 ] Rahul Thakur commented on MECLIPSE-71: -- I think the eclipse:clean goal should delete any artifacts the maven-eclipse-plugin generates (+1 on Fabrizio's comment above), so stuff under .settings should be cleaned up! Perhaps a better way to re-create the config/prefs under .settings would be to write a small Mojo specific to your dev environment that can take care of re-creating required files consistently rather than having to control and share them via SVN. One another solution could be to have an ignore list (comma-separated list of paths to resources under the project) that indicates to the eclipse:clean goal which resources to skip when running a 'clean' goal. What do others think? 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]
[jira] Commented: (MAVENUPLOAD-761) Upload tomcat poms and commons-modeler-1.1.jar to maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-761?page=comments#action_60045 ] Brett Porter commented on MAVENUPLOAD-761: -- Jeff, not sure what you mean about using legacy at cvs.apcahe.org, but you have to make sure that's not a part of the final build. Since commons-modeler isn't interested in doing this, I suggest we should just pull in their last release and the project.xml from the build. Upload tomcat poms and commons-modeler-1.1.jar to maven2 repository Key: MAVENUPLOAD-761 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-761 Project: maven-upload-requests Type: Task Reporter: Anita Kulshreshtha Attachments: m2.jar, m2pos.zip 1. Upload the poms contained in the zip to these urls - http://www.ibiblio.org/maven2/tomcat/tomcat-ajp/5.5.15/ http://www.ibiblio.org/maven2/tomcat/catalina-cluster/5.5.15/ http://www.ibiblio.org/maven2/tomcat/catalina/5.5.15/ 2. Upload commons-modeler-1.1.jar from the url below and the pom from the zip file to http://www.ibiblio.org/maven2/commons-modeler/commons-modeler/ -- 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: (MJAVADOC-47) Javadoc plugin ignores destDir when used in reporting section
[ http://jira.codehaus.org/browse/MJAVADOC-47?page=all ]
Maria Odea Ching updated MJAVADOC-47:
-
Attachment: MJAVADOC-47-maven-javadoc-plugin.patch
Javadoc plugin ignores destDir when used in reporting section
-
Key: MJAVADOC-47
URL: http://jira.codehaus.org/browse/MJAVADOC-47
Project: Maven 2.x Javadoc Plugin
Type: Bug
Reporter: Wendy Smoak
Assignee: Maria Odea Ching
Fix For: 2.0-beta-4
Attachments: MJAVADOC-47-maven-javadoc-plugin.patch
When used in the reporting section of the pom and 'mvn site', output always
goes to target/apidocs, even if you specify an outputDir.
Having outputDir work correctly would by useful with alternate doclets, for
example sending the output of the UMLGraph doclet to target/uml so that it
can be further transformed.
This seems to be the code that's doing it:
if ( !javadocDirectory.getAbsolutePath().equals( getOutputDirectory()
) )
{
// we're in site-embedded report mode, so Doxia has set the
// reportOutputDirectory to the basedir of the site.
// Append 'apidocs'.
javadocDirectory = new File( javadocDirectory, apidocs );
}
--
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]
