[continuum build - SUCCESS - checkout] Sun Nov 27 01:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051127.013000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051127.013000.txt
[jira] Created: (CONTINUUM-476) jdo model improvements
jdo model improvements -- Key: CONTINUUM-476 URL: http://jira.codehaus.org/browse/CONTINUUM-476 Project: Continuum Type: Improvement Components: Core system Reporter: Brett Porter Fix For: 1.1 some notes I sent to the dev list earlier in the year There are afew areas I'm still not happy with. The fetch groups don't seem to fit well with what is required a lot of the time. I'm wondering whether we are better off making everything be in the default fetch group, and lazy loading the lists instead. It seems since we are only doing this as an optimization that'd be a better way to do it. We'd still need to avoid long lists, ie build results. I think that should not be a field on the project, and instead it should just have references to the last successful build, last finished build, current build (either in progress or finished). I'm not particularly happy with using store methods mid-way through a block of code. I'm not sure if it does any dirty checking when you do a re-attach,but I see potential to read something, have it changed externally, then write over the top of it. The fact that we are re-retrieving from the db at random points could make this harder to track. I think we should be in the practise of getting all we need from the db at the start, modifying the detached objects, then updating them with dirty check at the end. We need to be able to resolve common cases where we can recover, and fail gracefully when it can't. At the end of the day, this isn't preventing it working now, so I'll just schedule a review of the use of the store later as it may be a source of ongoing bugs otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52050 ] Vincent Massol commented on MNG-678: FYI, I've just rebuilt m2 from trunk (26 Nov 2005 - 9:33GMT+1) and I still get the session is down error message: [...] [INFO] [deploy:deploy] [INFO] Retrieving previous build number from cargo-snapshot [DEBUG] repository metadata for: 'snapshot org.codehaus.cargo:cargo-core-api-util:0.7-SNAPSHOT' could not be found on repository: cargo-snapshot [DEBUG] adding permissions to wagon connection: 664 775 Uploading: scp://beaver.codehaus.org/home/projects/cargo/dist2-snapshot/org/codehaus/cargo/cargo-core-api-util/0.7-SNAPSHOT/cargo- core-api-util-0.7-20051126.083301-1.jar 11K uploaded [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Error performing commands for file transfer session is down [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Error performing commands for file transfer at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) 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:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying artifact: Error performing commands for file transfer at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:158) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) ... 16 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Error performing commands for file transfer at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:147) ... 18 more Caused by: org.apache.maven.wagon.TransferFailedException: Error performing commands for file transfer at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:91) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:202) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77) ... 19 more Caused by: org.apache.maven.wagon.CommandExecutionException: Cannot execute remote command: umask 2 at org.apache.maven.wagon.providers.ssh.AbstractSshWagon.executeCommand(AbstractSshWagon.java:292) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:81) ... 22 more Caused by: com.jcraft.jsch.JSchException: session is down at com.jcraft.jsch.Channel.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.AbstractSshWagon.executeCommand(AbstractSshWagon.java:279) ... 23 more scp intermittently failing deploying artifact - Key: MNG-678 URL: http://jira.codehaus.org/browse/MNG-678 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0-alpha-3 Environment: JDK 1.5, Red Hat 9
[jira] Commented: (MNG-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52055 ] fabrizio giustina commented on MNG-1605: Source downloading, even (especially?) for sources that don't exist, is very time consuming. Time consuming only for sources that don't exist in the local repository. Once a source jar has been downloaded, the eclipse plugin will never spend time anymore for checking remote repositories. I don't think adding a dependency-specific flag could be a good solution, the eclipse.downloadSources should remain a global flag. You have the following options: - don't set eclipse.downloadSources to true and only sources in the local repo will be used (note that this is broken in the current release, but it's how it's expected to work) - if you want to download sources for artifact run eclipse:eclipse with eclipse.downloadSources=true once a while. If a source jar is available on the remote repo it will be downloaded, and it will be used in future without the need for additional checks. - You can manually add source jars to your local repositories for dependencies that don't exist in the remote repo. The eclipse plugin will use those and will not try do download them anymore. Also note that recently a good number of source jars have been uploaded to the m2 repository, and the number of sources available is expected to grow. Said that, I would like to close this issue as a won't fix. Other thoughts? Allow eclipse source to be specified at the dependency level Key: MNG-1605 URL: http://jira.codehaus.org/browse/MNG-1605 Project: Maven 2 Type: New Feature Components: maven-eclipse-plugin Versions: 2.0 Reporter: Barry Kaplan Many (most?) projects do not have sources uploaded. And in any case, most projects only need a small subset of the sources. Source downloading, even (especially?) for sources that don't exist, is very time consuming. Therefore, it would be nice to specify this eclipse plugin specific option as the dependency level. Maybe something like: dependency groupIdbackport-util-concurrent/groupId artifactIdbackport-util-concurrent/artifactId version2.0_01_pd/version scoperuntime/scope properties property name=eclipse.downloadSources value=true/ /properties /dependency (For this to be general, it would of course require a much different model than the simple plugin-level property injection. ) -- 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-1430) add j2ee project nature/builders to generated .project file
[ http://jira.codehaus.org/browse/MNG-1430?page=all ] fabrizio giustina closed MNG-1430: -- Assign To: fabrizio giustina Resolution: Fixed Committed to svn, with a few changes: - the output dir is always set to target. This is required for compatibility with users that don't use wtp and WTP can handle it without problems (as you already saw, you can override it as you like and WTP will always use .deployables) - added a new switch wtpversion for forward compatibility. At the moment the plugin will add configuration for wtp R7 only add j2ee project nature/builders to generated .project file --- Key: MNG-1430 URL: http://jira.codehaus.org/browse/MNG-1430 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Environment: maven 2.0 on linux Reporter: Dan Allen Assignee: fabrizio giustina Attachments: MNG-1430.txt When the eclipse:eclipse target generates the .project file for a war project in maven, the .project file contains only the natures and builders for a regular java project. The additional information is as follows for WTP 0.71 buildCommand nameorg.eclipse.wst.common.modulecore.ComponentStructuralBuilder/name arguments /arguments /buildCommand buildCommand buildCommand nameorg.eclipse.wst.validation.validationbuilder/name arguments /arguments /buildCommand buildCommand nameorg.eclipse.wst.common.modulecore.ComponentStructuralBuilderDependen arguments /arguments /buildCommand buildCommand nameorg.eclipse.wst.common.modulecore.DependencyGraphBuilder/name arguments /arguments /buildCommand natureorg.eclipse.jem.workbench.JavaEMFNature/nature natureorg.eclipse.wst.common.modulecore.ModuleCoreNature/nature -- 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-1324) System dependencies path non correctly added to eclipse buildpath
[ http://jira.codehaus.org/browse/MNG-1324?page=all ]
fabrizio giustina closed MNG-1324:
--
Resolution: Fixed
this is definitively fixed in the current svn version of the eclipse plugin.
Just try to update the maven-eclipse-plugin dir and install it, it will work.
System dependencies path non correctly added to eclipse buildpath
---
Key: MNG-1324
URL: http://jira.codehaus.org/browse/MNG-1324
Project: Maven 2
Type: Bug
Components: maven-eclipse-plugin
Environment: SVN snapshot a few days old
Reporter: Giorgio Gallo
Assignee: fabrizio giustina
Eclipse plugin handles systemPath as if it was a path into the repository,
transforming a dependency like this one:
dependency
...
scopesystem/scope
systemPath${basebir}/lib/myjdbcdriver.jar/systemPath
/dependency
into
M2_REPO/pom.xml location dir/lib/myjdbcdriver.jar
--
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-1412) .classpath should have nearest order
[ http://jira.codehaus.org/browse/MNG-1412?page=comments#action_52058 ] fabrizio giustina commented on MNG-1412: Is there a reason for this order or it's only a cosmetic reason? AFAIK unless you have the same classes in multiple dependencies the order has no effect. .classpath should have nearest order Key: MNG-1412 URL: http://jira.codehaus.org/browse/MNG-1412 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Hobson The .classpath file entries should be ordered by nearest transitiveness (if that's a word). For example, I have project A that depends on B that depends on C. The classpath for A is generated in the order C, B. Ideally the classpath should be in order of how near they are to the project, i.e. B, C. -- 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-1648) Use canonical paths in eclipse project files
[ http://jira.codehaus.org/browse/MNG-1648?page=all ] fabrizio giustina closed MNG-1648: -- Assign To: fabrizio giustina Resolution: Fixed fixed in SVN. All the existing tests now works also using cygwin under windows. Also absolute paths returned by maven are converted to canonical paths, and this required many changes to the existing code, please test it and report any issue found. Use canonical paths in eclipse project files Key: MNG-1648 URL: http://jira.codehaus.org/browse/MNG-1648 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Hobson Assignee: fabrizio giustina Need to ensure all absolute file paths are moved to canonical paths as discussed on dev: http://www.nabble.com/-m2-eclipse-plugin-test-failures-t488244.html -- 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]
plexus and meta component
Hi, Is there a way in plexus to define a meta component without going in endless regression ? component rolerole/role role-hintmeta/role-hint implementationmeta-component/implementation requirements requirement !-- same role here -- rolerole/role field-namelittle-brothers/field-name /requirement /requirements /component I just need to exclude the role-hint 'meta' in the little-brothers map. Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/26-Nov-2005_08.30.45/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1020) Improve JRE_CONTAINER classpath entry
[ http://jira.codehaus.org/browse/MNG-1020?page=comments#action_52061 ] fabrizio giustina commented on MNG-1020: Now you can add optional _container_ classpath in front of the JRE. Just specify a list of container classpath entries with the org.eclipse.jdt.launching.JRE_CONTAINER and this list will not be modified. Not sure about allowing project dependencies (jar) before the JRE classpath, since the resulting project will have a classpath different from the one used in maven and the scope of the plugin is to make a maven project usable with eclipse. Improve JRE_CONTAINER classpath entry - Key: MNG-1020 URL: http://jira.codehaus.org/browse/MNG-1020 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0-beta-1 Reporter: Mark Hobson Same as MPECLIPSE-104 but for m2, although this only really makes sense for dependencies in the bootclasspath as only they can override the JRE. Hence this issue depends on MNG-973. -- 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-1604) Boot classpath incomplete in generated .classpath
[ http://jira.codehaus.org/browse/MNG-1604?page=all ] fabrizio giustina closed MNG-1604: -- Assign To: fabrizio giustina Resolution: Fixed Already fixed in svn, javadocs for plugin properties have been updated Boot classpath incomplete in generated .classpath - Key: MNG-1604 URL: http://jira.codehaus.org/browse/MNG-1604 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Environment: Eclipse 3.2M3 Reporter: Jochen Wiedmann Assignee: fabrizio giustina The .classpath file, which is generated by the maven-eclipse-plugin, specifies the boot classpath as follows: classpathentry kind=var rootpath=JRE_SRCROOT path=JRE_LIB sourcepath=JRE_SRC/ Unfortunately, this entry doesn't include the complete boot classpath, but rt.jar only. But a modern JRE's (= 1.4) boot classpath includes more jar files, for example jsse.jar, or jce.jar. Current workaround: Edit the generated .classpath file manually and replace the above line with classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ Specifying this container in the classpathContainers property does *not* work: In that case, Eclipse refuses the generated .classpath file, because it contains both of the above two lines: The rt.jar file is specified twice. Suggested solutions: a) Replace the JRE_LIB line with the container definition. I must admit, that I have no idea, whether this works with previous Eclipse versions and which. Side effects seem possible. b) Same thing than a), but optional: User must set a certain plugin property. c) Check the classpathContainers property: If it does include the JRE_CONTAINER, then omit the JRE_LIB line. I am ready to specify a patch for the plugin, if a developer decides which of the above solutions is the way to go or has another idea. -- 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-1020) Improve JRE_CONTAINER classpath entry
[ http://jira.codehaus.org/browse/MNG-1020?page=all ] fabrizio giustina updated MNG-1020: --- Environment: type: Improvement (was: Bug) Improve JRE_CONTAINER classpath entry - Key: MNG-1020 URL: http://jira.codehaus.org/browse/MNG-1020 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0-beta-1 Reporter: Mark Hobson Same as MPECLIPSE-104 but for m2, although this only really makes sense for dependencies in the bootclasspath as only they can override the JRE. Hence this issue depends on MNG-973. -- 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: (MNG-1688) Link to source repository broken
Link to source repository broken Key: MNG-1688 URL: http://jira.codehaus.org/browse/MNG-1688 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Reporter: Jochen Wiedmann According to http://maven.apache.org/plugins/maven-eclipse-plugin/source-repository.html the eclipse plugins source can be found at http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-eclipse-plugin or http://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-eclipse-plugin However, both URL's are obviously broken: There is no directory maven-plugins in components/trunk. -- 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-441) surefire plugin needs to be able to fork tests
[ http://jira.codehaus.org/browse/MNG-441?page=comments#action_52064 ] Mark Proctor commented on MNG-441: -- Is that .java and .pom working? If so any chance we could have a surefire snapshot release? We are currently blocked from moving Drools to M2 as maven tests for jython fail if we can't fork. surefire plugin needs to be able to fork tests -- Key: MNG-441 URL: http://jira.codehaus.org/browse/MNG-441 Project: Maven 2 Type: Improvement Components: maven-surefire-plugin Reporter: Brett Porter Fix For: 2.0.1 Attachments: SurefirePlugin.java, pom.xml they can leak memory, so a fork once for all option would be good. -- 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-1688) Link to source repository broken
[ http://jira.codehaus.org/browse/MNG-1688?page=all ] fabrizio giustina closed MNG-1688: -- Assign To: fabrizio giustina Resolution: Fixed Fixed in SVN and uploaded. Link to source repository broken Key: MNG-1688 URL: http://jira.codehaus.org/browse/MNG-1688 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Reporter: Jochen Wiedmann Assignee: fabrizio giustina According to http://maven.apache.org/plugins/maven-eclipse-plugin/source-repository.html the eclipse plugins source can be found at http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-eclipse-plugin or http://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-eclipse-plugin However, both URL's are obviously broken: There is no directory maven-plugins in components/trunk. -- 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: (MPECLIPSE-105) Ability to add projects of local group to build path
[ http://jira.codehaus.org/browse/MPECLIPSE-105?page=comments#action_52067 ] fabrizio giustina commented on MPECLIPSE-105: - why the eclipse.dependency in project.xml can't be used in this situation? Just add: properties eclipse.dependencytrue/eclipse.dependency /properties to the dependencies you want to link as project references in eclipse and you should achieve the same result. Is this correct (and so we can close the issue) or I'm missing something? Ability to add projects of local group to build path Key: MPECLIPSE-105 URL: http://jira.codehaus.org/browse/MPECLIPSE-105 Project: maven-eclipse-plugin Type: Improvement Versions: 1.9 Reporter: Rodion Zhitomirsky Fix For: 1.9 Attachments: PATCH We are using eclipse and maven for our internal project. Our project is splitted up into multiple semi-independent projects (modules). So, using repository and maven eclipse plugin we were able to work. However, there is still one important feature of Eclipse that is not available anymore after we swtiched to maven: sources of different projects got decoupled and you can not search, for instance, for references to some class or method. This could be only fixed by adding referencing projects' source code from other projects. So, I decided to write a patch for this. The point is: during generation of .classpath plugin behaves as usually, with an exception of cases, where groupId is the same as maven.eclipse.localgroupid. For this case there will be an additional classpathentry with reference to project. Hope, my patch explains more then this text (it is a little bit mixed :). -- 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-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52068 ] Bart Selders commented on MNG-678: -- I was also affected by this session is down problem. It just started at once, no explanation, while it used to work fine before. For us, it turned out to be a DNS problem: in this case primary DNS server down, the repository server was resolving network addresses using its secondary DNS server. We did not notice it that quick, although some other things did not work as fast as well. After correcting this, everything turned back to normal, and scp deployment works fine again. I am not suggesting that this is the root cause for this issue, but i would at least recommend to investigate your network to see whether there are any network issues known. scp intermittently failing deploying artifact - Key: MNG-678 URL: http://jira.codehaus.org/browse/MNG-678 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0-alpha-3 Environment: JDK 1.5, Red Hat 9 Reporter: Joe Futrelle Assignee: Brett Porter Fix For: 2.0.1 Some of the time, deploying artifacts fails during the scp transfer. The bottom of the stack trace is reproduced below. If I run the m2 deploy enough times, it succeeds; not sure why. This is not an unknown issue with Jsch; apparently client code can cause behavior like this if it doesn't dispose of connections properly. Possibly a plugin that's runs before the deploy phase is messing up the connection state somehow? Caused by: org.apache.maven.wagon.TransferFailedException: Error occured while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) ... 17 more Caused by: com.jcraft.jsch.JSchException: session is down at com.jcraft.jsch.Channel.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPECLIPSE-103) Allow to skip dependencies from being included in .classpath file
[ http://jira.codehaus.org/browse/MPECLIPSE-103?page=all ] fabrizio giustina closed MPECLIPSE-103: --- Assign To: fabrizio giustina Resolution: Won't Fix Fix Version: 1.9 In my project, we generate some enumerations using Castor (using xerces-2.4). The generated code is completely independent of XML or Castor. If I understood correclty, you added the castor dependency in order to generate source code: the castor dependency, however, should not be a project dependency but a plugin dependency. For example this should work if you are using the maven castor plugin at http://maven.apache.org/maven-1.x/reference/plugins/castor/index.html (do you?). If you are using a custom ant task you will need castor and xerces in the classpath, but this is not the recommended way. First of all, castor will be in the classpath used by maven when executing tests, and this is the same situation you are seeing in eclipse (so, it SHOULD fail in eclipse if it fails with maven). As a solution you should: - use a plugin to generate sources and, if such plugin doesn't exist, extract your code from maven.xml and put it in a plugin (recommended) - manually modify the classpath before calling the ant task used to generate sources, removing the castor jar from project.xml Allow to skip dependencies from being included in .classpath file - Key: MPECLIPSE-103 URL: http://jira.codehaus.org/browse/MPECLIPSE-103 Project: maven-eclipse-plugin Type: New Feature Versions: 1.9 Reporter: Werner Schulz Assignee: fabrizio giustina Fix For: 1.9 Need a means to specify that some maven dependencies are NOT included in the generated .classpath file. Reason: Maven builds a project. This may include generating source via castor, InjectJ, etc. Once the source code is generated, the generated source may not depend on the various jars that helped generate it. That means, the Eclipse project should not depend on these jars. Currently, it is not possible to exclude these jars. Can you add an additional property, like eclipse.classpath.includeno/eclipse.classpath.include, which will not add the dependency to the generated classpath file. -- 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: (MPECLIPSE-105) Ability to add projects of local group to build path
[ http://jira.codehaus.org/browse/MPECLIPSE-105?page=all ] fabrizio giustina updated MPECLIPSE-105: Fix Version: (was: 1.9) Ability to add projects of local group to build path Key: MPECLIPSE-105 URL: http://jira.codehaus.org/browse/MPECLIPSE-105 Project: maven-eclipse-plugin Type: Improvement Versions: 1.9 Reporter: Rodion Zhitomirsky Attachments: PATCH We are using eclipse and maven for our internal project. Our project is splitted up into multiple semi-independent projects (modules). So, using repository and maven eclipse plugin we were able to work. However, there is still one important feature of Eclipse that is not available anymore after we swtiched to maven: sources of different projects got decoupled and you can not search, for instance, for references to some class or method. This could be only fixed by adding referencing projects' source code from other projects. So, I decided to write a patch for this. The point is: during generation of .classpath plugin behaves as usually, with an exception of cases, where groupId is the same as maven.eclipse.localgroupid. For this case there will be an additional classpathentry with reference to project. Hope, my patch explains more then this text (it is a little bit mixed :). -- 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: (MPECLIPSE-88) allow relative paths for overriden jars
[ http://jira.codehaus.org/browse/MPECLIPSE-88?page=all ]
fabrizio giustina updated MPECLIPSE-88:
---
Fix Version: (was: 1.10)
allow relative paths for overriden jars
---
Key: MPECLIPSE-88
URL: http://jira.codehaus.org/browse/MPECLIPSE-88
Project: maven-eclipse-plugin
Type: Improvement
Versions: 1.9
Environment: All
Reporter: Guido Schreuder
Priority: Trivial
Original Estimate: 5 minutes
Remaining: 5 minutes
Please consider the following;
A very small change will allow for jars to be kept inside your project folders
without hardcoded paths ending up in your Eclipse .classpath file.
Excuse me for the format, but i've no diff available at the moment
in file templates/classpath.jelly, near the end change the following
Old:
j:otherwise
classpathentry kind=lib path=${lib.path}/
/j:otherwise
New:
j:otherwise
maven:makeRelativePath var=localJarPath basedir=${basedir}
path=${lib.path} separator=//
classpathentry kind=lib path=${localJarPath}/
/j:otherwise
maven:makeRelativePath will leave the path as it is not relative to
basedir
kind regards,
Guido
--
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: (MPECLIPSE-104) Improve JRE_CONTAINER classpath entry
[ http://jira.codehaus.org/browse/MPECLIPSE-104?page=all ] fabrizio giustina updated MPECLIPSE-104: Fix Version: (was: 1.10) Improve JRE_CONTAINER classpath entry - Key: MPECLIPSE-104 URL: http://jira.codehaus.org/browse/MPECLIPSE-104 Project: maven-eclipse-plugin Type: Improvement Versions: 1.9 Environment: Windows XP, JDK 1.5 Reporter: Holger Hoffstätte Situation: Sun's jaxrpc has a QName class but also put out a fix jar with an update to make that class compatible with JDK 1.5. In mule we missed out on the patch jar but since the .classpath generated by maven-eclipse-plugin-1.9 references the JRE_CONTAINER ahead of other jars, people who used JDK 1.5 for development missed this since a working QName was found when it really should not have been (correctly raising an error caused by the 'bad' class and the lack of the patch jar instead). Solution and proposed fix: move the JRE_CONTAINER to the end of the dependency list, after the j:forEach block that follows in the current version. IMHO the JRE_CONTAINER should *always* come last. This is unlikely to cause problems because you cannot accidentally override essential classes (e.g. java.lang), but it is essential when you do want to handle optional packages correctly (say a working QName or JMX). -- 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: (MPECLIPSE-69) Make plugin work better out of the box
[ http://jira.codehaus.org/browse/MPECLIPSE-69?page=all ]
fabrizio giustina updated MPECLIPSE-69:
---
Fix Version: (was: 1.9)
Make plugin work better out of the box
Key: MPECLIPSE-69
URL: http://jira.codehaus.org/browse/MPECLIPSE-69
Project: maven-eclipse-plugin
Type: Improvement
Versions: 1.9
Reporter: Chad Woolley
Attachments: maven_eclipse_plugin_patch.txt
Hi,
Attached is a patch which makes the following changes to the
eclipse:external-tools-21 goal:
1. Makes default action to run goal against project.xml in the current
project.
2. Makes default to refresh project containing the selected resource
3. Removes code to add each entry to favorites list, because they fill up the
list and makes user have to scroll to see the bottom of the external tools
menu.
I think these would be much more intuitive and convenient defaults for the
majority of the plugin users.
Thanks,
Chad
Index: eclipse/src/plugin-resources/templates/launch.jelly
===
RCS file:
/home/cvspublic/maven-plugins/eclipse/src/plugin-resources/templates/launch.jelly,v
retrieving revision 1.4
diff -u -r1.4 launch.jelly
--- eclipse/src/plugin-resources/templates/launch.jelly 4 Mar 2004
18:04:37 - 1.4
+++ eclipse/src/plugin-resources/templates/launch.jelly 1 Feb 2005
06:55:58 -
@@ -19,13 +19,17 @@
launchConfiguration
type=org.eclipse.ui.externaltools.ProgramLaunchConfigurationType
stringAttribute
-key=org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS value=-e -p
$${resource_name} ${goal}/
+key=org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS value=-e -p
project.xml ${goal}/
stringAttribute
key=org.eclipse.ui.externaltools.ATTR_REFRESH_SCOPE
value=$${project}/
+stringAttribute
+key=org.eclipse.debug.core.ATTR_REFRESH_SCOPE value=$${project}/
+!-- don't add favorites, they overfill the menu
listAttribute key=org.eclipse.debug.ui.favoriteGroups
listEntry value=org.eclipse.ui.externaltools.launchGroup/
/listAttribute
+--
stringAttribute
-key=org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY
value=$${container_loc}/
+key=org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY
value=$${project_loc}/
stringAttribute key=org.eclipse.ui.externaltools.ATTR_LOCATION
value=${tool.loc}/
/launchConfiguration
--
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: (MPECLIPSE-84) PATCH - Add project name prefix for working with multiple versions of artifact.
[ http://jira.codehaus.org/browse/MPECLIPSE-84?page=all ]
fabrizio giustina updated MPECLIPSE-84:
---
Fix Version: (was: 1.10)
PATCH - Add project name prefix for working with multiple versions of
artifact.
---
Key: MPECLIPSE-84
URL: http://jira.codehaus.org/browse/MPECLIPSE-84
Project: maven-eclipse-plugin
Type: New Feature
Versions: 1.10
Environment: Maven 1.0.2 and Eclipse (OS neutral)
Reporter: Joakim Erdfelt
Priority: Minor
Attachments: eclipse-plugin-prefix.diff
The maven-eclipse-plugin creates a .project file with a name of
${pom.artifactId}, which is fine if working with a single version of that
single project, but when working on multiple version (maintenance on an old
version, bug fixing current release, and active research on a future release)
then that simple of a name makes things confusing in eclipse.
The patch (hopefully attached) will allow for a maven.eclipse.project.prefix
variable that will prepend some text to the project name to allow for eclipse
to have multiple versions of the same project loaded.
Ideally, this approach would also allow for a multiproject ecilpse generation
with all of the projects having the same prefix (since Eclipse sorts the
projects by name, this would have the effect of grouping all of those related
multiprojects together)
--
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: (MPECLIPSE-60) Downloading source zips
[ http://jira.codehaus.org/browse/MPECLIPSE-60?page=all ]
fabrizio giustina updated MPECLIPSE-60:
---
Fix Version: (was: 1.9)
Downloading source zips
---
Key: MPECLIPSE-60
URL: http://jira.codehaus.org/browse/MPECLIPSE-60
Project: maven-eclipse-plugin
Type: New Feature
Versions: 1.9
Reporter: Krystian Nowak
Attachments: plugin.jelly.patch
Original Estimate: 30 minutes
Remaining: 30 minutes
I've attached plugin.jelly for maven-eclipse-plugin downloading sources from
${repo}/${groupId}/src/${artifactId}-${version}.zip and installing it as
${maven.repo.local}/${groupId}/src/${artifactId}-${version}.zip.
It does it for all jar dependencies having eclipse.source property set to
true. Example project.xml:
(...)
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
urlhttp://www.junit.org//url
properties
eclipse.sourcetrue/eclipse.source
/properties
/dependency
/dependencies
(...)
What you have to do now is to call maven eclipse and refresh your project
in Eclipse.
And here is the code of plugin.jelly - a patch made in Eclipse:
Index: plugin.jelly
===
RCS file: /home/cvspublic/maven-plugins/eclipse/plugin.jelly,v
retrieving revision 1.31
diff -u -r1.31 plugin.jelly
--- plugin.jelly 16 Nov 2004 10:48:15 - 1.31
+++ plugin.jelly 6 Dec 2004 08:10:33 -
@@ -78,7 +78,8 @@
!-- Generate Eclipse .classpath file--
!--==--
goal name=eclipse:generate-classpath
-description=Generate Eclipse .classpath file
+description=Generate Eclipse .classpath file
+prereqs=eclipse:sources:download
ant:echoCreating ${basedir}/.classpath .../ant:echo
j:file name=${basedir}/.classpath prettyPrint=true outputMode=xml
xmlns=dummy
@@ -263,5 +264,73 @@
ant:echoCleaned up eclipse generated files/ant:echo
/goal
+
+
+
+ !--==--
+ !-- Download project dependency sources
--
+ !--==--
+
+ goal name=eclipse:sources:download
+ j:forEach var=depItem items=${pom.getDependencies()}
+ j:if
test=${depItem.getType().equalsIgnoreCase('jar')}
+ j:if
test=${depItem.getProperty('eclipse.source') == 'true'}
+ j:set var=groupId
value=${depItem.getGroupId()}/
+ j:set var=artifactId
value=${depItem.getArtifactId()}/
+ j:set var=version
value=${depItem.getVersion()}/
+ attainGoal
name=eclipse:source:download/
+ j:remove var=groupId/
+ j:remove var=artifactId/
+ j:remove var=version/
+ /j:if
+ /j:if
+ /j:forEach
+ /goal
+
+
+ !--==--
+ !-- Download single source --
+ !--==--
+
+ goal name=eclipse:source:download
+ !--
+ param: groupId
+ param: artifactId
+ param: version
+ --
+ echoChecking sources for ${groupId}:${artifactId}
ver.${version}/echo
+ util:file var=localSrcFile
name=${maven.repo.local}/${groupId}/src/${artifactId}-${version}.zip /
+j:if test=${!localSrcFile.exists()}
+ mkdir dir=${maven.repo.local}/${groupId}/src /
+ j:set var=repoList${maven.repo.remote}/j:set
+ util:tokenize var=repos
delim=,${repoList.trim()}/util:tokenize
+ j:forEach var=repo items=${repos}
+ echorepo is '${repo}'/echo
+ j:set var=remoteFile
value=${repo}/${groupId}/src/${artifactId}-${version}.zip /
+ echotrying to download ${remoteFile}/echo
+ j:catch var=ex
+ j:invokeStatic var=dummy method=getFile
className=org.apache.maven.util.HttpUtils
+ j:arg type=java.lang.String
value=${remoteFile} /
+ j:arg type=java.io.File value=${localSrcFile}/
+ j:arg type=boolean value=false/
+
[jira] Commented: (MNG-1430) add j2ee project nature/builders to generated .project file
[ http://jira.codehaus.org/browse/MNG-1430?page=comments#action_52070 ] Dan Allen commented on MNG-1430: Awesome! Good work. I like your idea for the wtpversion. I am assuming to override the output location, one would just use the project.build.outputDirectory and set it to .deployables add j2ee project nature/builders to generated .project file --- Key: MNG-1430 URL: http://jira.codehaus.org/browse/MNG-1430 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Environment: maven 2.0 on linux Reporter: Dan Allen Assignee: fabrizio giustina Attachments: MNG-1430.txt When the eclipse:eclipse target generates the .project file for a war project in maven, the .project file contains only the natures and builders for a regular java project. The additional information is as follows for WTP 0.71 buildCommand nameorg.eclipse.wst.common.modulecore.ComponentStructuralBuilder/name arguments /arguments /buildCommand buildCommand buildCommand nameorg.eclipse.wst.validation.validationbuilder/name arguments /arguments /buildCommand buildCommand nameorg.eclipse.wst.common.modulecore.ComponentStructuralBuilderDependen arguments /arguments /buildCommand buildCommand nameorg.eclipse.wst.common.modulecore.DependencyGraphBuilder/name arguments /arguments /buildCommand natureorg.eclipse.jem.workbench.JavaEMFNature/nature natureorg.eclipse.wst.common.modulecore.ModuleCoreNature/nature -- 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-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52072 ] Barry Kaplan commented on MNG-1605: --- If [in the non-broke state] the sources will be used if they exists even without the flag, then running with the flag once in a while should be fine. Much simpler than adding dependency-level complexity, and agree with the wont-fix. But when you say remote repository, do you mean anything other then the local cache? Or are repositories explictly defined considered non-remote also? Allow eclipse source to be specified at the dependency level Key: MNG-1605 URL: http://jira.codehaus.org/browse/MNG-1605 Project: Maven 2 Type: New Feature Components: maven-eclipse-plugin Versions: 2.0 Reporter: Barry Kaplan Many (most?) projects do not have sources uploaded. And in any case, most projects only need a small subset of the sources. Source downloading, even (especially?) for sources that don't exist, is very time consuming. Therefore, it would be nice to specify this eclipse plugin specific option as the dependency level. Maybe something like: dependency groupIdbackport-util-concurrent/groupId artifactIdbackport-util-concurrent/artifactId version2.0_01_pd/version scoperuntime/scope properties property name=eclipse.downloadSources value=true/ /properties /dependency (For this to be general, it would of course require a much different model than the simple plugin-level property injection. ) -- 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: (MPECLIPSE-108) Scope system in dependencies not supported
Scope system in dependencies not supported
--
Key: MPECLIPSE-108
URL: http://jira.codehaus.org/browse/MPECLIPSE-108
Project: maven-eclipse-plugin
Type: Bug
Environment: Maven2-maven-eclipse-plugin 2.0-beta-2 + Windows XP
Reporter: J-C
Attachments: EclipseClasspathWriter.java
In my pom.xml, I have a dependency:
dependency
groupIdjavax.persistence/groupId
artifactIdejb/artifactId
scopesystem/scope
version3.0/version
systemPath
${jboss.deploy}/ejb3.deployer/ejb3-persistence.jar
/systemPath
/dependency
With scope sytem, in .classpath file, a lib shoud be generated insted of a var.
To fix that see EclipseClasspathWriter.addDependency in attachment.
//
//path = M2_REPO/ //$NON-NLS-1$
//+ EclipseUtils.toRelativeAndFixSeparator(
// localRepositoryFile, fullPath, false);
//MODIF///
if
(Artifact.SCOPE_SYSTEM.equalsIgnoreCase(artifact.getScope())) {
path = EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath,
false);
kind = lib; //$NON-NLS-1$
} else {
path = M2_REPO/ //$NON-NLS-1$
+
EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath, false);
kind = var; //$NON-NLS-1$
}
//
// END MODIF///
.
/// REMOVED
/// kind = var; //$NON-NLS-1$
--
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-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=all ] fabrizio giustina closed MNG-1605: -- Assign To: fabrizio giustina Resolution: Won't Fix But when you say remote repository, do you mean anything other then the local cache? anything other than the (single) local repository specified in settings.xml. Since you agree on the current solution I close this issue as fixed. A new version of the plugin with the fixed download flag will be out ASAP, in the meanwhile you can install the version currently in SVN by running: svn checkout http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin maven-eclipse-plugin cd maven-eclipse-plugin mvn install Allow eclipse source to be specified at the dependency level Key: MNG-1605 URL: http://jira.codehaus.org/browse/MNG-1605 Project: Maven 2 Type: New Feature Components: maven-eclipse-plugin Versions: 2.0 Reporter: Barry Kaplan Assignee: fabrizio giustina Many (most?) projects do not have sources uploaded. And in any case, most projects only need a small subset of the sources. Source downloading, even (especially?) for sources that don't exist, is very time consuming. Therefore, it would be nice to specify this eclipse plugin specific option as the dependency level. Maybe something like: dependency groupIdbackport-util-concurrent/groupId artifactIdbackport-util-concurrent/artifactId version2.0_01_pd/version scoperuntime/scope properties property name=eclipse.downloadSources value=true/ /properties /dependency (For this to be general, it would of course require a much different model than the simple plugin-level property injection. ) -- 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-1412) .classpath should have nearest order
[ http://jira.codehaus.org/browse/MNG-1412?page=all ] fabrizio giustina closed MNG-1412: -- Resolution: Won't Fix Please reopen the issue if you can find a valid reason why this kind of order is needed; in the meanwhile I'm closing the issue since the order actually used for the eclipse classpath is the same order used by maven during compilation and IMHO this is definitively the correct behaviour. .classpath should have nearest order Key: MNG-1412 URL: http://jira.codehaus.org/browse/MNG-1412 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Hobson Assignee: fabrizio giustina The .classpath file entries should be ordered by nearest transitiveness (if that's a word). For example, I have project A that depends on B that depends on C. The classpath for A is generated in the order C, B. Ideally the classpath should be in order of how near they are to the project, i.e. B, C. -- 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]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/26-Nov-2005_12.30.55/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPECLIPSE-108) Scope system in dependencies not supported
[ http://jira.codehaus.org/browse/MPECLIPSE-108?page=all ]
fabrizio giustina closed MPECLIPSE-108:
---
Assign To: fabrizio giustina
Resolution: Duplicate
Fix Version: 1.10
this is related to the M2 eclipse plugin and it has already been fixed in SVN
time ago. The patched EclipseClasspathWriter.java is pretty old, be sure to
checkout the code from trunk when posting patches.
Scope system in dependencies not supported
--
Key: MPECLIPSE-108
URL: http://jira.codehaus.org/browse/MPECLIPSE-108
Project: maven-eclipse-plugin
Type: Bug
Environment: Maven2-maven-eclipse-plugin 2.0-beta-2 + Windows XP
Reporter: J-C
Assignee: fabrizio giustina
Fix For: 1.10
Attachments: EclipseClasspathWriter.java
In my pom.xml, I have a dependency:
dependency
groupIdjavax.persistence/groupId
artifactIdejb/artifactId
scopesystem/scope
version3.0/version
systemPath
${jboss.deploy}/ejb3.deployer/ejb3-persistence.jar
/systemPath
/dependency
With scope sytem, in .classpath file, a lib shoud be generated insted of a
var.
To fix that see EclipseClasspathWriter.addDependency in attachment.
//
//path = M2_REPO/ //$NON-NLS-1$
//+ EclipseUtils.toRelativeAndFixSeparator(
// localRepositoryFile, fullPath, false);
//MODIF///
if
(Artifact.SCOPE_SYSTEM.equalsIgnoreCase(artifact.getScope())) {
path = EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath,
false);
kind = lib; //$NON-NLS-1$
} else {
path = M2_REPO/ //$NON-NLS-1$
+
EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath, false);
kind = var; //$NON-NLS-1$
}
//
//END MODIF///
.
/// REMOVED
/// kind = var; //$NON-NLS-1$
--
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: (MPCLOVER-50) Add support for span
[ http://jira.codehaus.org/browse/MPCLOVER-50?page=comments#action_52077 ] Vincent Massol commented on MPCLOVER-50: Hi Matt, Sure please submit a patch and I'll apply it (make sure you also patch the documentation). Thanks Add support for span Key: MPCLOVER-50 URL: http://jira.codehaus.org/browse/MPCLOVER-50 Project: maven-clover-plugin Type: Improvement Versions: 1.10 Reporter: Matt Read Priority: Minor Would it be possible add support for the span attribute of the appropriate ant tasks? Currently I modify plugin.jelly each time I upgrade to a new version by adding span=5h to all the ant:clover-report / tags and the ant:clover-historypoint / tag. The reason being my Maven project delegates out to a number of legacy ant scripts, each of which may run a clover-enabled task. Without the addition of the span attribute, the reports do not include all of the results I want. If you want me to supply a patch to the plugin then please let me know. Matt. -- 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: (MEV-238) jWebunit 1.2 has invalid artifact/groupId for servletapi
jWebunit 1.2 has invalid artifact/groupId for servletapi Key: MEV-238 URL: http://jira.codehaus.org/browse/MEV-238 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Currently is: dependency groupIdservletapi/groupId artifactIdservletapi/artifactId version2.3/version /dependency Should be: dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-238) jWebunit 1.2 has invalid artifact/groupId for servletapi
[ http://jira.codehaus.org/browse/MEV-238?page=comments#action_52078 ] Matt Raible commented on MEV-238: - Should also have scope set to provided. jWebunit 1.2 has invalid artifact/groupId for servletapi Key: MEV-238 URL: http://jira.codehaus.org/browse/MEV-238 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Currently is: dependency groupIdservletapi/groupId artifactIdservletapi/artifactId version2.3/version /dependency Should be: dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-232) DWR POM should list dependencies as optional
[ http://jira.codehaus.org/browse/MEV-232?page=comments#action_52079 ] Matt Raible commented on MEV-232: - The servletapi dependency needs updating as well - to prevent warnings when using Maven 2's Ant Tasks. It should use the new group/artifactId's, as well as set the scope to provided. dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version scopeprovided/scope /dependency DWR POM should list dependencies as optional Key: MEV-232 URL: http://jira.codehaus.org/browse/MEV-232 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible AFAIK, DWR doesn't require any dependencies at runtime, therefore all it's dependencies should be marked optional (except servlet which should be provided). Current: http://www.ibiblio.org/maven2/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom Updated: http://static.appfuse.org/repository/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-231) OJB should list commons-dbcp as a dependency
[ http://jira.codehaus.org/browse/MEV-231?page=comments#action_52080 ] Carlos Sanchez commented on MEV-231: From Thomas Dudziak here is the list for current OJB 1.0.4rc, 1.0.3 shouldn't be too different: Necessary: commons-beanutils-1.7.0.jar commons-collections-3.1.jar commons-dbcp-1.2.1.jar commons-lang-2.0.jar commons-logging-1.0.4.jar commons-pool-1.2.jar For ODMG/JDO Api: antlr-2.7.5.jar jdo.jar jdori.jar jdori-enhancer.jar Optional: asm.jar (1.5.3) cglib-2.1.jar commons-transaction-1.1.jar log4j-1.2.8.jar jcs.jar (1.0 dev, but should work with newer) p6spy-1.3-patched.jar prevayler.jar jakarta-regexp-1.3.jar For compilation: ant-1.6.2.jar ant-junit-1.6.2.jar ant-launcher-1.6.2.jar ant-swing-1.6.2.jar ant-trax-1.6.2.jar geronimo-spec-jta-1.0.1B-rc2.jar geronimo-spec-servlet-2.4-rc2.jar geronimo-spec-j2ee-1.4-rc2.jar hsqldb.jar (1.8) junit.jar (3.8.1) torque-gen-3.1.1.jar velocity-1.3.1.jar village-2.0-dev-20030825.jar xalan.jar xdoclet-1.2.3.jar xdoclet-ojb-module-1.2.3.jar xercesImpl.jar xjavadoc-1.1.jar xml-apis.jar OJB should list commons-dbcp as a dependency Key: MEV-231 URL: http://jira.codehaus.org/browse/MEV-231 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Assignee: Edwin Punzalan This POM works much better than the one at: http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom project modelVersion4.0.0/modelVersion groupIdojb/groupId artifactIddb-ojb/artifactId version1.0.3/version dependencies dependency artifactIdcommons-dbcp/artifactId groupIdcommons-dbcp/groupId version1.2/version /dependency /dependencies /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]
[jira] Created: (MNG-1689) Only print relocation warnings in standard output for the current pom
Only print relocation warnings in standard output for the current pom - Key: MNG-1689 URL: http://jira.codehaus.org/browse/MNG-1689 Project: Maven 2 Type: Improvement Components: Logging Versions: 2.0 Reporter: Carlos Sanchez Fix For: 2.0.1 Relocation warnings of transitive dependencies shouldn't be printed in standard output because people gets confused, ask questions and try to change other people poms although they work correctly We should only print the warnings of the current pom so the author can improve it. -- 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: (MNG-1690) [maven-ejb3-plugin] NPE in EJB3Mojo.java
[maven-ejb3-plugin] NPE in EJB3Mojo.java Key: MNG-1690 URL: http://jira.codehaus.org/browse/MNG-1690 Project: Maven 2 Type: Bug Components: Sandbox Reporter: Tim Kettler Attachments: maven-ejb3-plugin.patch running mvn package fails with: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error assembling EJB3 [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling EJB3 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) 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.plugin.MojoExecutionException: Error assembling EJB3 at org.apache.maven.plugin.ejb3.Ejb3Mojo.execute(Ejb3Mojo.java:146) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) ... 16 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.ejb3.Ejb3Mojo.execute(Ejb3Mojo.java:136) ... 18 more A look at the source shows that the archiver is never initialized. The attached patch initializes the archiver with a JarArchiver. -- 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: (MNG-1691) [maven-par-plugin] NPE in ParMojo.java
[maven-par-plugin] NPE in ParMojo.java -- Key: MNG-1691 URL: http://jira.codehaus.org/browse/MNG-1691 Project: Maven 2 Type: Bug Components: Sandbox Reporter: Tim Kettler Attachments: maven-par-plugin.patch Same problem as described in MNG-1690. -- 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-1324) System dependencies path non correctly added to eclipse buildpath
[ http://jira.codehaus.org/browse/MNG-1324?page=comments#action_52082 ]
Brill Pappin commented on MNG-1324:
---
What do you mean update the maven-eclipse-plugin?
What should end users do to get this fix in place?
System dependencies path non correctly added to eclipse buildpath
---
Key: MNG-1324
URL: http://jira.codehaus.org/browse/MNG-1324
Project: Maven 2
Type: Bug
Components: maven-eclipse-plugin
Environment: SVN snapshot a few days old
Reporter: Giorgio Gallo
Assignee: fabrizio giustina
Eclipse plugin handles systemPath as if it was a path into the repository,
transforming a dependency like this one:
dependency
...
scopesystem/scope
systemPath${basebir}/lib/myjdbcdriver.jar/systemPath
/dependency
into
M2_REPO/pom.xml location dir/lib/myjdbcdriver.jar
--
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]
Release maven-one-plugin?
Hi there, Could we release an alpha of the maven-one-plugin plugin? I am using it in the cargo's build but it's failing the build when people try to build as it's not available on ibiblio. Is it available from an existing repo (I don't mind using a snapshot version)? Also, what's the status about the continuum instance of maven zones running all projects and making them available in a repo? That would be really the best for everyone I think. Thanks -Vincent ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-238) jWebunit 1.2 has invalid artifact/groupId for servletapi
[ http://jira.codehaus.org/browse/MEV-238?page=comments#action_52083 ] Matt Raible commented on MEV-238: - Here's a strange one - if I set the scope to provided, even though I have the following in my pom.xml, the servlet-api isn't included and compilation fails. dependency artifactIdservlet-api/artifactId groupIdjavax.servlet/groupId version2.4/version scopeprovided/scope /dependency jWebunit 1.2 has invalid artifact/groupId for servletapi Key: MEV-238 URL: http://jira.codehaus.org/browse/MEV-238 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Currently is: dependency groupIdservletapi/groupId artifactIdservletapi/artifactId version2.3/version /dependency Should be: dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency -- 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]
Problems preventing the cargo m2 build from working perfectly
Hi, Just a heads up on the progress on the cargo m2 build. Things are progressing but we still have the following annoying issues: * No forking of tests in the surefire plugin. This prevents building all the functional tests. MNG-441 * Deploy pluging failing because of scp command hardcoded even when using custom scp and ssh executable. MNG-1587 * Deploy plugin failing with session down when using scp protocol to deploy. MNG-678 * Custom checkstyle rule configuration not working. MNG-1113 * maven-one-plugin not on ibiblio nor in any snapshot repository. * Error when running the assembly plugin as part of a multimodule build. JIRA issue exists. MNG-1684 I'm probably forgetting a few. There are also several other issues but they are minor. Thanks -Vincent ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52084 ] Bart Selders commented on MNG-678: -- Vincent, In our case the repository host was failing to execute proper lookups. I just looked at beaver.codehaus.org and it is also failing lookups on its primary DNS server. So that I think the reason for you current problem! Beaver.codehaus.org DNS is not working properly. its /etc/resolv.conf contains: nameserver 127.0.0.1 nameserver 199.212.134.1 nameserver 199.212.134.2 nameserver 64.7.153.49 nameserver 63.246.20.110 and when I try to use beaver to do lookups it won't anser. [EMAIL PROTECTED] ~]$ nslookup server beaver.codehaus.org Default server: beaver.codehaus.org Address: 64.7.141.17#53 www.apache.org ;; connection timed out; no servers could be reached scp intermittently failing deploying artifact - Key: MNG-678 URL: http://jira.codehaus.org/browse/MNG-678 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0-alpha-3 Environment: JDK 1.5, Red Hat 9 Reporter: Joe Futrelle Assignee: Brett Porter Fix For: 2.0.1 Some of the time, deploying artifacts fails during the scp transfer. The bottom of the stack trace is reproduced below. If I run the m2 deploy enough times, it succeeds; not sure why. This is not an unknown issue with Jsch; apparently client code can cause behavior like this if it doesn't dispose of connections properly. Possibly a plugin that's runs before the deploy phase is messing up the connection state somehow? Caused by: org.apache.maven.wagon.TransferFailedException: Error occured while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) ... 17 more Caused by: com.jcraft.jsch.JSchException: session is down at com.jcraft.jsch.Channel.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52085 ] Bart Selders commented on MNG-678: -- Sorry, I did speak too quick with possibly the wrong conclusion: DNS on beaver.codehaus.org is likely configured to be not accessible from outside, so my test is not valid. scp intermittently failing deploying artifact - Key: MNG-678 URL: http://jira.codehaus.org/browse/MNG-678 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0-alpha-3 Environment: JDK 1.5, Red Hat 9 Reporter: Joe Futrelle Assignee: Brett Porter Fix For: 2.0.1 Some of the time, deploying artifacts fails during the scp transfer. The bottom of the stack trace is reproduced below. If I run the m2 deploy enough times, it succeeds; not sure why. This is not an unknown issue with Jsch; apparently client code can cause behavior like this if it doesn't dispose of connections properly. Possibly a plugin that's runs before the deploy phase is messing up the connection state somehow? Caused by: org.apache.maven.wagon.TransferFailedException: Error occured while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) ... 17 more Caused by: com.jcraft.jsch.JSchException: session is down at com.jcraft.jsch.Channel.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52086 ] Vincent Massol commented on MNG-678: Thanks Bart for helping me on this :-) I have tried your nslookup command on beaver.codehaus.org and it seems to have worked fine (but then I'm no DNS expert): [EMAIL PROTECTED] vmassol]$ nslookup www.apache.org Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: Name: www.apache.org Address: 209.237.227.195 scp intermittently failing deploying artifact - Key: MNG-678 URL: http://jira.codehaus.org/browse/MNG-678 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0-alpha-3 Environment: JDK 1.5, Red Hat 9 Reporter: Joe Futrelle Assignee: Brett Porter Fix For: 2.0.1 Some of the time, deploying artifacts fails during the scp transfer. The bottom of the stack trace is reproduced below. If I run the m2 deploy enough times, it succeeds; not sure why. This is not an unknown issue with Jsch; apparently client code can cause behavior like this if it doesn't dispose of connections properly. Possibly a plugin that's runs before the deploy phase is messing up the connection state somehow? Caused by: org.apache.maven.wagon.TransferFailedException: Error occured while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) ... 17 more Caused by: com.jcraft.jsch.JSchException: session is down at com.jcraft.jsch.Channel.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-227) struts 1.2.4 and 1.2.8 dependencies still broken
[ http://jira.codehaus.org/browse/MEV-227?page=comments#action_52087 ] Matt Raible commented on MEV-227: - The one you've sent me looks good Wendy, I'm using it now in my custom repo: http://static.appfuse.org/repository/struts/struts/1.2.4/struts-1.2.4.pom struts 1.2.4 and 1.2.8 dependencies still broken Key: MEV-227 URL: http://jira.codehaus.org/browse/MEV-227 Project: Maven Evangelism Type: Sub-task Reporter: denis Cabasson Looks like the dependencies are still broken -- 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]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/26-Nov-2005_04.30.48/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-238) jWebunit 1.2 has invalid artifact/groupId for servletapi
[ http://jira.codehaus.org/browse/MEV-238?page=comments#action_52088 ] Matt Raible commented on MEV-238: - Disregard my last comment - my compilation fails because Struts 1.2.4 doesn't have scopeprovided/scope on its servletapi dependency, and my 2.4 version gets overridden with Struts' 2.2 version. jWebunit 1.2 has invalid artifact/groupId for servletapi Key: MEV-238 URL: http://jira.codehaus.org/browse/MEV-238 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Currently is: dependency groupIdservletapi/groupId artifactIdservletapi/artifactId version2.3/version /dependency Should be: dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.3/version /dependency -- 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: [jira] Commented: (MNG-1430) add j2ee project nature/builders to generated .project file
By the wat, wtp M9 doesn't use the .deployables directory anymore. Don't know if it has a effect on eclipse-plugin and now you can choose easily your project structure so it's quite easy to make it fit the maven way. On 11/26/05, Dan Allen (JIRA) [EMAIL PROTECTED] wrote: [ http://jira.codehaus.org/browse/MNG-1430?page=comments#action_52070 ] Dan Allen commented on MNG-1430: Awesome! Good work. I like your idea for the wtpversion. I am assuming to override the output location, one would just use the project.build.outputDirectory and set it to .deployables add j2ee project nature/builders to generated .project file --- Key: MNG-1430 URL: http://jira.codehaus.org/browse/MNG-1430 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Environment: maven 2.0 on linux Reporter: Dan Allen Assignee: fabrizio giustina Attachments: MNG-1430.txt When the eclipse:eclipse target generates the .project file for a war project in maven, the .project file contains only the natures and builders for a regular java project. The additional information is as follows for WTP 0.71 buildCommand nameorg.eclipse.wst.common.modulecore.ComponentStructuralBuilder/name arguments /arguments /buildCommand buildCommand buildCommand nameorg.eclipse.wst.validation.validationbuilder/name arguments /arguments /buildCommand buildCommand nameorg.eclipse.wst.common.modulecore.ComponentStructuralBuilderDependen arguments /arguments /buildCommand buildCommand nameorg.eclipse.wst.common.modulecore.DependencyGraphBuilder/name arguments /arguments /buildCommand natureorg.eclipse.jem.workbench.JavaEMFNature/nature natureorg.eclipse.wst.common.modulecore.ModuleCoreNature/nature -- 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] -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-610) Upload XWork-Spring Integration to central Maven Repository
Upload XWork-Spring Integration to central Maven Repository --- Key: MAVENUPLOAD-610 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-610 Project: maven-upload-requests Type: Task Reporter: Matt Raible Please upload xwork-spring integration bundle for integration WebWork and Spring in WebWork 2.x. -- 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: Release maven-one-plugin?
It was on snapshots.maven.codehaus.org like the other snapshots at one point. I assume it still is. I literally put it together in 15 minutes, so I don't know if it is sufficiently tested for a release, but I'll try and take a look at this one. - Brett Vincent Massol wrote: Hi there, Could we release an alpha of the maven-one-plugin plugin? I am using it in the cargo's build but it's failing the build when people try to build as it's not available on ibiblio. Is it available from an existing repo (I don't mind using a snapshot version)? Also, what's the status about the continuum instance of maven zones running all projects and making them available in a repo? That would be really the best for everyone I think. Thanks -Vincent ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1684) Problem with reactor when using attached goal
[ http://jira.codehaus.org/browse/MNG-1684?page=all ] Brett Porter updated MNG-1684: -- Fix Version: 2.0.1 Problem with reactor when using attached goal - Key: MNG-1684 URL: http://jira.codehaus.org/browse/MNG-1684 Project: Maven 2 Type: Bug Components: maven-assembly-plugin Versions: 2.0 Reporter: Vincent Massol Fix For: 2.0.1 Here's my project dir structure: trunk/ |_ core/ |_ api/ |_ (several projects here) |_ uberjar/ (assembly project) |_ samples |_ testdata |_ empty-jar |_ (...) If I build the trunk/core/ubjerjar project alone it works fine. Note: I have attached the attached goal to the verify phase so the assembly can be created when calling mvn install. If I build the project from the trunk by typing mvn install, the uberjar/ project fails saying that the empty-jar artifact cannot be found in the local repository. That's normal it cannot be found because there are no dependencies on it in the core/ branch and it hasn't been built yet when the uberjar project executes. Of course there are no dependencies to it in the uberjar project. It seems there's something fishy happening in the assembly plugin implementation... :-) Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems preventing the cargo m2 build from working perfectly
Vincent Massol wrote: Hi, Just a heads up on the progress on the cargo m2 build. Things are progressing but we still have the following annoying issues: * No forking of tests in the surefire plugin. This prevents building all the functional tests. MNG-441 Yes its annoying for all of us. Are you volunteering to help fix it? This is high on my todo list, but I have other things to do. * Deploy pluging failing because of scp command hardcoded even when using custom scp and ssh executable. MNG-1587 Got a patch? * Deploy plugin failing with session down when using scp protocol to deploy. MNG-678 I saw some discussion today, I'll have a look. I also intend to try the latest jsch release. Unless anyone intends to dig into jsch and fix it, the only alternative is a workaround I think that the original reporter suggested. I'll try it. * Custom checkstyle rule configuration not working. MNG-1113 I got no response to Vincent, what do you think of this patch?. There's still some discussion and I'm afraid I don't understand the issue. * maven-one-plugin not on ibiblio nor in any snapshot repository. I'm pretty sure it is as that's how I gave it to Dain to use when I created it. * Error when running the assembly plugin as part of a multimodule build. JIRA issue exists. MNG-1684 Given it is the weekend, not surprising nobody's looked at it. I've scheduled for 2.0.1. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-610) Upload XWork-Spring Integration to central Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-610?page=comments#action_52089 ] Patrick Lightbody commented on MAVENUPLOAD-610: --- My name is Patrick Lightbody and I approve this message. Upload XWork-Spring Integration to central Maven Repository --- Key: MAVENUPLOAD-610 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-610 Project: maven-upload-requests Type: Task Reporter: Matt Raible Please upload xwork-spring integration bundle for integration WebWork and Spring in WebWork 2.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems preventing the cargo m2 build from working perfectly
Brett Porter wrote: Vincent Massol wrote: Hi, Just a heads up on the progress on the cargo m2 build. Things are progressing but we still have the following annoying issues: * No forking of tests in the surefire plugin. This prevents building all the functional tests. MNG-441 Looking at this now. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-232) DWR POM should list dependencies as optional
[ http://jira.codehaus.org/browse/MEV-232?page=comments#action_52091 ] Julien Dubois commented on MEV-232: --- Matt, the Maven 2 pom is still under testing, so : 1- If you want to use the Maven 1 project.xml (for DWR 1.0), you can use my own list of exclusions from here : http://cvs.sourceforge.net/viewcvs.py/tudu/tudu/pom.xml?rev=1.7view=markup 2- I'm going to speed up my testing, merge it into the HEAD (it's the 1.0 branch), so that you have a nice clean pom ASAP. 3- If you are ready for it, you can still participate in the making of DWR 1.1 by using our snapshot release I mentioned earlier. It's working fine for Tudu Lists, so it's useable. DWR POM should list dependencies as optional Key: MEV-232 URL: http://jira.codehaus.org/browse/MEV-232 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible AFAIK, DWR doesn't require any dependencies at runtime, therefore all it's dependencies should be marked optional (except servlet which should be provided). Current: http://www.ibiblio.org/maven2/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom Updated: http://static.appfuse.org/repository/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom -- 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 - SUCCESS - checkout] Sun Nov 27 00:15:01 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051127.001501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051127.001501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1471) Module paths for system scope are relative to parent pom instead of its own
[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_52092 ] Brett Porter commented on MNG-1471: --- systemPath was only intended for use in finding system libraries. This was for two specific purposes: - location of Java system libraries (tools.jar, for example). We hope to have this handled by specification dependencies - location of system libraries in a native build. This now can be handled by custom resolvers Aside from that, its use was originally going to be omitted so it will be discouraged going forward. Module paths for system scope are relative to parent pom instead of its own --- Key: MNG-1471 URL: http://jira.codehaus.org/browse/MNG-1471 Project: Maven 2 Type: Bug Components: maven-compiler-plugin Versions: 2.0 Environment: Win XP, Maven 2.0 Reporter: Jeff Jensen Assignee: John Casey Priority: Critical Fix For: 2.0.1 Attachments: MNG-1471-maven-project.patch Original Estimate: 30 minutes Remaining: 30 minutes When building from the parent POM dir, all paths are relative to it. A problem occurs when its modules have dependencies of scopesystem/scope - the module's corresponding systemPath is relative to the parent POM dir, instead of the module's POM dir. With a module's systemPath set to compile correctly it on its own, compiling from its parent POM dir gives this error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: thegrp ArtifactId: subsystem Version: 2.1-SNAPSHOT Reason: System artifact: thegrp:subsystem:jar:2.1-SNAPSHOT not found in path: src\lib\subsystem.jar thegrp:subsystem:2.1-SNAPSHOT:jar (would be nice to have the fully qualified path name listed there, instead of the relative one so users would know where it is really looking for it from) Expected behavior is that Maven treats system scope paths relative to the module POM, not the parent's POM. -- 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]
using votes
Hi, Just following a thread on the users list about whether we use votes for determining priorities. I've never used it as they were generally low, though that's possibly a chicken and egg problem. I've also never really focused on it because basically we schedule everything and do it in an appropriate release. Votes for scheduled issues are unlikely to change whether it gets done - though now we are starting to see a lot more issues unscheduled, so it may be a better way of gauging priorities. We would need to promote their use more, and that in turn could encourage less duplicates as filing a duplicate instead of voting dilutes its priority. Thoughts? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-710) Add ability to fork the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MNG-710?page=comments#action_52094 ] Brett Porter commented on MNG-710: -- Mark - yes. But what do you mean will? Add ability to fork the maven-compiler-plugin - Key: MNG-710 URL: http://jira.codehaus.org/browse/MNG-710 Project: Maven 2 Type: Improvement Reporter: Rod Coffin Assignee: Trygve Laugstol Fix For: 2.0-beta-1 Attachments: maven-compiler-plugin.diff.txt, maven-compiler-plugin.diff3.txt, plexus-compiler-api.diff.txt, plexus-compiler-api.diff3.txt, plexus-compiler-javac.diff.txt, plexus-compiler-javac.diff2.txt, plexus-compiler-javac.diff3.txt Add the ability to fork the maven-compiler-plugin. This would allow projects to be compiled with a JDK other than the one used to run Maven from. -- 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-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52095 ] Brett Porter commented on MNG-678: -- has anyone tried using IP addresses instead of host names to see if it helps? I didn't think that was related. scp intermittently failing deploying artifact - Key: MNG-678 URL: http://jira.codehaus.org/browse/MNG-678 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0-alpha-3 Environment: JDK 1.5, Red Hat 9 Reporter: Joe Futrelle Assignee: Brett Porter Fix For: 2.0.1 Some of the time, deploying artifacts fails during the scp transfer. The bottom of the stack trace is reproduced below. If I run the m2 deploy enough times, it succeeds; not sure why. This is not an unknown issue with Jsch; apparently client code can cause behavior like this if it doesn't dispose of connections properly. Possibly a plugin that's runs before the deploy phase is messing up the connection state somehow? Caused by: org.apache.maven.wagon.TransferFailedException: Error occured while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) ... 17 more Caused by: com.jcraft.jsch.JSchException: session is down at com.jcraft.jsch.Channel.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPECLIPSE-108) Scope system in dependencies not supported
[ http://jira.codehaus.org/browse/MPECLIPSE-108?page=all ]
Brett Porter reopened MPECLIPSE-108:
Scope system in dependencies not supported
--
Key: MPECLIPSE-108
URL: http://jira.codehaus.org/browse/MPECLIPSE-108
Project: maven-eclipse-plugin
Type: Bug
Environment: Maven2-maven-eclipse-plugin 2.0-beta-2 + Windows XP
Reporter: J-C
Assignee: fabrizio giustina
Attachments: EclipseClasspathWriter.java
In my pom.xml, I have a dependency:
dependency
groupIdjavax.persistence/groupId
artifactIdejb/artifactId
scopesystem/scope
version3.0/version
systemPath
${jboss.deploy}/ejb3.deployer/ejb3-persistence.jar
/systemPath
/dependency
With scope sytem, in .classpath file, a lib shoud be generated insted of a
var.
To fix that see EclipseClasspathWriter.addDependency in attachment.
//
//path = M2_REPO/ //$NON-NLS-1$
//+ EclipseUtils.toRelativeAndFixSeparator(
// localRepositoryFile, fullPath, false);
//MODIF///
if
(Artifact.SCOPE_SYSTEM.equalsIgnoreCase(artifact.getScope())) {
path = EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath,
false);
kind = lib; //$NON-NLS-1$
} else {
path = M2_REPO/ //$NON-NLS-1$
+
EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath, false);
kind = var; //$NON-NLS-1$
}
//
//END MODIF///
.
/// REMOVED
/// kind = var; //$NON-NLS-1$
--
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: (MPECLIPSE-108) Scope system in dependencies not supported
[ http://jira.codehaus.org/browse/MPECLIPSE-108?page=all ]
Brett Porter closed MPECLIPSE-108:
--
Resolution: Duplicate
Fix Version: (was: 1.10)
Scope system in dependencies not supported
--
Key: MPECLIPSE-108
URL: http://jira.codehaus.org/browse/MPECLIPSE-108
Project: maven-eclipse-plugin
Type: Bug
Environment: Maven2-maven-eclipse-plugin 2.0-beta-2 + Windows XP
Reporter: J-C
Assignee: fabrizio giustina
Attachments: EclipseClasspathWriter.java
In my pom.xml, I have a dependency:
dependency
groupIdjavax.persistence/groupId
artifactIdejb/artifactId
scopesystem/scope
version3.0/version
systemPath
${jboss.deploy}/ejb3.deployer/ejb3-persistence.jar
/systemPath
/dependency
With scope sytem, in .classpath file, a lib shoud be generated insted of a
var.
To fix that see EclipseClasspathWriter.addDependency in attachment.
//
//path = M2_REPO/ //$NON-NLS-1$
//+ EclipseUtils.toRelativeAndFixSeparator(
// localRepositoryFile, fullPath, false);
//MODIF///
if
(Artifact.SCOPE_SYSTEM.equalsIgnoreCase(artifact.getScope())) {
path = EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath,
false);
kind = lib; //$NON-NLS-1$
} else {
path = M2_REPO/ //$NON-NLS-1$
+
EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath, false);
kind = var; //$NON-NLS-1$
}
//
//END MODIF///
.
/// REMOVED
/// kind = var; //$NON-NLS-1$
--
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: r348621 - in /maven/site/trunk: pom.xml src/site/site.xml
Hi Brett, Modified: maven/site/trunk/src/site/site.xml URL: http://svn.apache.org/viewcvs/maven/site/trunk/src/site/site.xml?rev=34862 1r1=348620r2=348621view=diff == --- maven/site/trunk/src/site/site.xml (original) +++ maven/site/trunk/src/site/site.xml Wed Nov 23 18:36:35 2005 @@ -17,7 +17,17 @@ item name=SCM href=http://maven.apache.org/scm/ item name=Wagon href=http://maven.apache.org/wagon/ item name=JXR href=http://maven.apache.org/jxr/ + item name=Doxia href=http://maven.apache.org/doxia/ /links + +head + script src=http://www.google-analytics.com/urchin.js; type=text/javascript + /script + script type=text/javascript +_uacct = UA-140879-1; +urchinTracker(); + /script +/head menu name=Quick Links item name=Features href=/maven-features.html/ According to this change, it seems that we have now a JS error on http://maven.apache.org Cheers, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/26-Nov-2005_08.30.48/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] 2.0.1/2.1 dev process
Alan D. Cabrera wrote: Brett Porter wrote, On 11/24/2005 4:23 PM: My thoughts: - this is more risky that it will be missed if someone misses one This is not as likely if the commits are made to both lines at the same time. I don't understand this reasoning. If using this technique, if one is missed, you have to backtrack and find what was missed. If you use the weekly technique (or whatever interval), you are merging everything since last merge ensuring nothing is missed. Also, there will be times when it will not make sense to apply the branch change in the trunk. You want the original patch author to make that investigation and decision at the time of the checkin not a third party branch merger at the time of a branch merge. I don't exactly agree. The only case where I feel something should go onto the branch and not the trunk is if that functionality was removed on the trunk for some reason. In that case, the merge will conflict on that change and it can be easily thrown away. Do you have a specific use case? - its more cumbersome on an individual commit Not more cumbersome. Waiting to do the work at the uber merge merely postpones the inevitable. I can't agree here. Assuming no review, per commit adds a command for every commit, per week adds a command per week. Getting into review stage - you've already said that the review is the same at either point. I'd prefer to do them sequentially myself. I understand that there might be some issues that require the original author to be involved. In this case I'd instead encourage authors to still be aware of the affect of their changes and if they think they will be problematic - to call for an early merge to raise a flag on it. That fits the community style better too :) Blind merges that just dump whatever is in a branch into the trunk are always dangerous without careful scrutiny; performing this due diligence makes it the same, usually more, amount of work as individual multi branch commits. I agree blind merges are bad. When I do it, I always review the resulting commit to ensure it still makes sense. And aside from that, you rely a lot on your automated testing to ensure everything is still sane. I see where you are going, and it probably becomes more the case as you get to a much larger project size than what we are dealing with (100's of developers instead of 10's). The fact is that the majority of commits in the project at present are comfortably isolated and merge nicely. And you want to know of the clash and have that discussion asap, at the time of the checkin, not later. Issues like this need to be resolved before the trunk evolves further and while things are still fresh in everyone's mind. That's true. I've thought about Maven tracking last merge points and allowing CI to automatically perform that merge on the trunk automatically and alert when it has a conflict and then let someone resolve that, and then test the build. The paradigm I espouse applies to what ever product management style that is in place. The issues that I raise are not as relevant for more mature product lines that do not change that radically. But it has always been my experience that a blind merge at the end of a branch release is always more work and error prone than multi branch checkins. Just my 2 cents. :) That's fair enough, but I just don't see it here where we are doing very little (well, currently no) trunk work. And its super tedious and anything tedious is error prone. I'd grumble about doing it, and anything you have to grumble about is going to cause some sort of issues. Others are welcome to disagree with me :) Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r348621 - in /maven/site/trunk: pom.xml src/site/site.xml
Odd, it's fine when I generate it. Republished, will look into why it got there. (whoever last did it, it came out as quot; instead of around UA-...) - Brett Vincent Siveton wrote: Hi Brett, Modified: maven/site/trunk/src/site/site.xml URL: http://svn.apache.org/viewcvs/maven/site/trunk/src/site/site.xml?rev=34862 1r1=348620r2=348621view=diff == --- maven/site/trunk/src/site/site.xml (original) +++ maven/site/trunk/src/site/site.xml Wed Nov 23 18:36:35 2005 @@ -17,7 +17,17 @@ item name=SCM href=http://maven.apache.org/scm/ item name=Wagon href=http://maven.apache.org/wagon/ item name=JXR href=http://maven.apache.org/jxr/ + item name=Doxia href=http://maven.apache.org/doxia/ /links + +head + script src=http://www.google-analytics.com/urchin.js; type=text/javascript + /script + script type=text/javascript +_uacct = UA-140879-1; +urchinTracker(); + /script +/head menu name=Quick Links item name=Features href=/maven-features.html/ According to this change, it seems that we have now a JS error on http://maven.apache.org Cheers, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-227) struts 1.2.4 and 1.2.8 dependencies still broken
[ http://jira.codehaus.org/browse/MEV-227?page=all ] Carlos Sanchez closed MEV-227: -- Assign To: Carlos Sanchez Resolution: Fixed Used the one provided by Wendy at matt's repo struts 1.2.4 and 1.2.8 dependencies still broken Key: MEV-227 URL: http://jira.codehaus.org/browse/MEV-227 Project: Maven Evangelism Type: Sub-task Reporter: denis Cabasson Assignee: Carlos Sanchez Looks like the dependencies are still broken -- 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: (MEV-230) Struts POM should have Cactus dependencies listed with scopetest/scope
[ http://jira.codehaus.org/browse/MEV-230?page=all ] Carlos Sanchez closed MEV-230: -- Assign To: Carlos Sanchez (was: Edwin Punzalan) Resolution: Duplicate Dupe of MEV-227 Struts POM should have Cactus dependencies listed with scopetest/scope -- Key: MEV-230 URL: http://jira.codehaus.org/browse/MEV-230 Project: Maven Evangelism Type: Improvement Components: Invalid POM Reporter: Matt Raible Assignee: Carlos Sanchez [DEBUG] struts:struts:jar:1.2.4 (selected for compile) [DEBUG] junit:junit:jar:3.8.1 (not setting scope to: compile; local scope test wins) [WARNING] Artifact junit:junit:jar:3.8.1 retains local scope 'test' overriding broader scope 'compile' given by a dependency. If this is not intended, modify or remove the local scope. [DEBUG] junit:junit:jar:3.8.1 (selected for compile) [DEBUG] oro:oro:jar:2.0.7 (selected for compile) [DEBUG] commons-logging:commons-logging:jar:1.0.4 (selected for compile) [DEBUG] commons-collections:commons-collections:jar:2.1 (removed - nearer found: 2.1.1) [DEBUG] commons-collections:commons-collections:jar:2.1 (selected for compile) [DEBUG] xalan:xalan:jar:2.5.1 (selected for compile) [DEBUG] commons-digester:commons-digester:jar:1.5 (selected for compile) [DEBUG] commons-beanutils:commons-beanutils:jar:1.6.1 (setting scope to: compile) [DEBUG] commons-beanutils:commons-beanutils:jar:1.6 (removed - nearer found: 1.6.1) [DEBUG] commons-beanutils:commons-beanutils:jar:1.6 (selected for compile) [DEBUG] commons-logging:commons-logging:jar:1.0 (removed - nearer found: 1.0.4) [DEBUG] commons-logging:commons-logging:jar:1.0 (selected for compile) [DEBUG] commons-collections:commons-collections:jar:2.1 (removed - nearer found: 2.1.1) [DEBUG] commons-collections:commons-collections:jar:2.1 (selected for compile) [DEBUG] cactus:cactus:jar:12-1.4.1 (selected for compile) [DEBUG] commons-lang:commons-lang:jar:2.0 (selected for compile) [DEBUG] commons-validator:commons-validator:jar:1.1.3 (selected for compile) [DEBUG] cactus:cactus-ant:jar:1.4.1 (selected for compile) [DEBUG] commons-fileupload:commons-fileupload:jar:1.0 (selected for compile) [DEBUG] commons-beanutils:commons-beanutils:jar:1.6.1 (selected for compile) [DEBUG] antlr:antlr:jar:2.7.2 (selected for compile) [DEBUG] struts:struts-el:jar:1.2.4 (selected for compile) -- 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] Reopened: (MEV-227) struts 1.2.4 and 1.2.8 dependencies still broken
[ http://jira.codehaus.org/browse/MEV-227?page=all ] Carlos Sanchez reopened MEV-227: Fixed 1.2.4 but not yet 1.2.8 struts 1.2.4 and 1.2.8 dependencies still broken Key: MEV-227 URL: http://jira.codehaus.org/browse/MEV-227 Project: Maven Evangelism Type: Sub-task Reporter: denis Cabasson Assignee: Carlos Sanchez Looks like the dependencies are still broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-231) OJB should list commons-dbcp as a dependency
[ http://jira.codehaus.org/browse/MEV-231?page=comments#action_52099 ] Carlos Sanchez commented on MEV-231: Let's add only the necessary or this will be a mess. OJB should list commons-dbcp as a dependency Key: MEV-231 URL: http://jira.codehaus.org/browse/MEV-231 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Assignee: Edwin Punzalan This POM works much better than the one at: http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom project modelVersion4.0.0/modelVersion groupIdojb/groupId artifactIddb-ojb/artifactId version1.0.3/version dependencies dependency artifactIdcommons-dbcp/artifactId groupIdcommons-dbcp/groupId version1.2/version /dependency /dependencies /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]
[jira] Commented: (MEV-227) struts 1.2.4 and 1.2.8 dependencies still broken
[ http://jira.codehaus.org/browse/MEV-227?page=comments#action_52100 ] Wendy Smoak commented on MEV-227: - The corrected m1 pom (with dependency scope hints added) for 1.2.8 is in the Struts repository: https://svn.apache.org/repos/asf/struts/action/branches/STRUTS_1_2_BRANCH/project.xml It has not yet been uploaded to the Apache repo; I'm hoping the release manager will do that tomorrow. struts 1.2.4 and 1.2.8 dependencies still broken Key: MEV-227 URL: http://jira.codehaus.org/browse/MEV-227 Project: Maven Evangelism Type: Sub-task Reporter: denis Cabasson Assignee: Carlos Sanchez Looks like the dependencies are still broken -- 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-609) maven taglib plugin 1.4.2 for maven 1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-609?page=comments#action_52101 ] Carlos Sanchez commented on MAVENUPLOAD-609: id needs to be removed maven taglib plugin 1.4.2 for maven 1 - Key: MAVENUPLOAD-609 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-609 Project: maven-upload-requests Type: Task Reporter: fabrizio giustina -- 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-610) Upload XWork-Spring Integration to central Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-610?page=comments#action_52102 ] Carlos Sanchez commented on MAVENUPLOAD-610: The pom has to be called pom.xml The groupId should be net.java.dev.xwork-optional Upload XWork-Spring Integration to central Maven Repository --- Key: MAVENUPLOAD-610 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-610 Project: maven-upload-requests Type: Task Reporter: Matt Raible Please upload xwork-spring integration bundle for integration WebWork and Spring in WebWork 2.x. -- 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-610) Upload XWork-Spring Integration to central Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-610?page=comments#action_52103 ] Matt Raible commented on MAVENUPLOAD-610: - Sorry about that Carlos - I've fixed the bundle and re-uploaded it. Upload XWork-Spring Integration to central Maven Repository --- Key: MAVENUPLOAD-610 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-610 Project: maven-upload-requests Type: Task Reporter: Matt Raible Please upload xwork-spring integration bundle for integration WebWork and Spring in WebWork 2.x. -- 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-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52104 ] Barry Kaplan commented on MNG-1605: --- Thanks Fabrizio. All works except the output path. I have the following defined: pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId configuration outputDirectory/target/eclipse-classes/outputDirectory /configuration /plugin ... When the eclipse project is generated from the leaf project directory, the output path is created correctly as target/eclipse-classes. However, when I generated eclipse projects via the root project using multi-project, the output path has a drive letter prepended, eg R:target/eclipse-classes. (I haven't yet tried to see why this might be.) Allow eclipse source to be specified at the dependency level Key: MNG-1605 URL: http://jira.codehaus.org/browse/MNG-1605 Project: Maven 2 Type: New Feature Components: maven-eclipse-plugin Versions: 2.0 Reporter: Barry Kaplan Assignee: fabrizio giustina Many (most?) projects do not have sources uploaded. And in any case, most projects only need a small subset of the sources. Source downloading, even (especially?) for sources that don't exist, is very time consuming. Therefore, it would be nice to specify this eclipse plugin specific option as the dependency level. Maybe something like: dependency groupIdbackport-util-concurrent/groupId artifactIdbackport-util-concurrent/artifactId version2.0_01_pd/version scoperuntime/scope properties property name=eclipse.downloadSources value=true/ /properties /dependency (For this to be general, it would of course require a much different model than the simple plugin-level property injection. ) -- 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-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52105 ] Barry Kaplan commented on MNG-1605: --- A correct output path would have the project prepended, eg: iris-infra/target/eclipse-classes. This is indeed what is created when running from the leaf project, not what I showed above. It appears the only thing that could have broke with were the changes to EclipseClasspathWriter and EclipseUtils. Allow eclipse source to be specified at the dependency level Key: MNG-1605 URL: http://jira.codehaus.org/browse/MNG-1605 Project: Maven 2 Type: New Feature Components: maven-eclipse-plugin Versions: 2.0 Reporter: Barry Kaplan Assignee: fabrizio giustina Many (most?) projects do not have sources uploaded. And in any case, most projects only need a small subset of the sources. Source downloading, even (especially?) for sources that don't exist, is very time consuming. Therefore, it would be nice to specify this eclipse plugin specific option as the dependency level. Maybe something like: dependency groupIdbackport-util-concurrent/groupId artifactIdbackport-util-concurrent/artifactId version2.0_01_pd/version scoperuntime/scope properties property name=eclipse.downloadSources value=true/ /properties /dependency (For this to be general, it would of course require a much different model than the simple plugin-level property injection. ) -- 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-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52106 ]
Barry Kaplan commented on MNG-1605:
---
Workaround: I changed the plugin config to:
configuration
outputDirectory//${project.artifactId}/target/eclipse-classes/outputDirectory
/configuration
This caused the following warnings:
[INFO] [eclipse:eclipse]
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
Which caused noticable delays for the directories with lots of files. But it
did create the correct output path.
Allow eclipse source to be specified at the dependency level
Key: MNG-1605
URL: http://jira.codehaus.org/browse/MNG-1605
Project: Maven 2
Type: New Feature
Components: maven-eclipse-plugin
Versions: 2.0
Reporter: Barry Kaplan
Assignee: fabrizio giustina
Many (most?) projects do not have sources uploaded. And in any case, most
projects only need a small subset of the sources. Source downloading, even
(especially?) for sources that don't exist, is very time consuming.
Therefore, it would be nice to specify this eclipse plugin specific option as
the dependency level. Maybe something like:
dependency
groupIdbackport-util-concurrent/groupId
artifactIdbackport-util-concurrent/artifactId
version2.0_01_pd/version
scoperuntime/scope
properties
property name=eclipse.downloadSources value=true/
/properties
/dependency
(For this to be general, it would of course require a much different model
than the simple plugin-level property injection. )
--
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-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52107 ] Barry Kaplan commented on MNG-1605: --- BTW, only with the double slashes do I get the warning. But the double slash was the only thing I could find that worked. I tried all kinds other combinations. Allow eclipse source to be specified at the dependency level Key: MNG-1605 URL: http://jira.codehaus.org/browse/MNG-1605 Project: Maven 2 Type: New Feature Components: maven-eclipse-plugin Versions: 2.0 Reporter: Barry Kaplan Assignee: fabrizio giustina Many (most?) projects do not have sources uploaded. And in any case, most projects only need a small subset of the sources. Source downloading, even (especially?) for sources that don't exist, is very time consuming. Therefore, it would be nice to specify this eclipse plugin specific option as the dependency level. Maybe something like: dependency groupIdbackport-util-concurrent/groupId artifactIdbackport-util-concurrent/artifactId version2.0_01_pd/version scoperuntime/scope properties property name=eclipse.downloadSources value=true/ /properties /dependency (For this to be general, it would of course require a much different model than the simple plugin-level property injection. ) -- 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: (MNG-1692) Project scoped Repository
Project scoped Repository - Key: MNG-1692 URL: http://jira.codehaus.org/browse/MNG-1692 Project: Maven 2 Type: Wish Components: Artifacts and Repositories Reporter: Mark Proctor Fix For: 2.1 In multi module builds I would like jars to not instally locally until I instruct it and still be able to build individual modules. At the moment if I try and build an invidiual module it insists on looking in the local repo. In Maven 1 we worked around this by using jar override. The use case for this is for when you are messing around with multiple checkouts of the same version and don't want them to interact with each other. With current M2 I either have to create different versions in the pom for each checkout, when all changes are likely to end up in the master checkout for a specific verison. Or I can specify the repo to be in the project, but that means I have to checkout everything each time I want to build something. This could be achieve by using root/target as a project level repo for the produced jars which would use the local repo for anything that it can't find it the project repo. Only when I tell it to install will it copy the jars from the project repo to the local repo. -- 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-1693) .wtpmodules does not use same output directory as compiler
[ http://jira.codehaus.org/browse/MNG-1693?page=comments#action_52108 ] Barry Kaplan commented on MNG-1693: --- And I think this is causing some eclipse validators to scan surefire generated files (which I target to a different output directory than eclipse), which can get quite slow at times. .wtpmodules does not use same output directory as compiler -- Key: MNG-1693 URL: http://jira.codehaus.org/browse/MNG-1693 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0.1 Reporter: Barry Kaplan When the output path is overriden via the outputDirectory configuration property, the 'java-output-path' property in .wtpmodules does not use this value. -- 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: (MNG-1693) .wtpmodules does not use same output directory as compiler
.wtpmodules does not use same output directory as compiler -- Key: MNG-1693 URL: http://jira.codehaus.org/browse/MNG-1693 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0.1 Reporter: Barry Kaplan When the output path is overriden via the outputDirectory configuration property, the 'java-output-path' property in .wtpmodules does not use this value. -- 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: (MNG-1694) Build execution order control in fine grained projects.
Build execution order control in fine grained projects. --- Key: MNG-1694 URL: http://jira.codehaus.org/browse/MNG-1694 Project: Maven 2 Type: Wish Components: maven-compiler-plugin Reporter: Mark Proctor Currently in multi module projects you can only work in 2 modes. 1) Build everything 2) Build a single module, IF you have built and installed all its dependency modules I would like to be able to work the following way: 1) Build everything 2) Build an individual module, will build all the modules prior to it in the reactor list. 3) Build a module module and all modules after it in the reactor list, will build missing prior modules. Use Case 1) perform checkout and build 2) module fails 3) keep fixing module and running just its unit tests 3) once all its unit tests pass build it and all modules after it in the reactor list. I don't need to build ones prior as they are unnaffected by the changes. In large mutli module projects this will save a LOT of time especially when you are gearing up for deployment and want to check that everything works - currently this is time consuming and repetitive, with much of the repetition uneeded. -- 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-1692) Project scoped Repository
[ http://jira.codehaus.org/browse/MNG-1692?page=comments#action_52111 ] Brett Porter commented on MNG-1692: --- I don't know if this is the right solution to the problem. It could be useful, however if the workspace functionality is able to identify where the project output files are even without running the build mojos (which would be ideal), then the local repo becomes unnecessary as everything is sourced from the workspace. However, if that becomes a longer term feature, this could be a quicker fix, and would also assist with interim plugin development. Project scoped Repository - Key: MNG-1692 URL: http://jira.codehaus.org/browse/MNG-1692 Project: Maven 2 Type: Wish Components: Artifacts and Repositories Reporter: Mark Proctor Fix For: 2.1 In multi module builds I would like jars to not instally locally until I instruct it and still be able to build individual modules. At the moment if I try and build an invidiual module it insists on looking in the local repo. In Maven 1 we worked around this by using jar override. The use case for this is for when you are messing around with multiple checkouts of the same version and don't want them to interact with each other. With current M2 I either have to create different versions in the pom for each checkout, when all changes are likely to end up in the master checkout for a specific verison. Or I can specify the repo to be in the project, but that means I have to checkout everything each time I want to build something. This could be achieve by using root/target as a project level repo for the produced jars which would use the local repo for anything that it can't find it the project repo. Only when I tell it to install will it copy the jars from the project repo to the local repo. -- 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-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=comments#action_52112 ] Brett Porter commented on MNG-1694: --- I think what you really want here is - build this project and its *dependencies* inside this workspace - continue from last failed build Both reasonable ideas, but I also worry about introducing this kind of multi-mode operation too much. I would prefer to work on the ability to make some builds simply skip by as the files are unchanged. This makes the behaviour the same always and protects the user from their own error in not knowing what is updated. Build execution order control in fine grained projects. --- Key: MNG-1694 URL: http://jira.codehaus.org/browse/MNG-1694 Project: Maven 2 Type: Wish Components: maven-compiler-plugin Reporter: Mark Proctor Currently in multi module projects you can only work in 2 modes. 1) Build everything 2) Build a single module, IF you have built and installed all its dependency modules I would like to be able to work the following way: 1) Build everything 2) Build an individual module, will build all the modules prior to it in the reactor list. 3) Build a module module and all modules after it in the reactor list, will build missing prior modules. Use Case 1) perform checkout and build 2) module fails 3) keep fixing module and running just its unit tests 3) once all its unit tests pass build it and all modules after it in the reactor list. I don't need to build ones prior as they are unnaffected by the changes. In large mutli module projects this will save a LOT of time especially when you are gearing up for deployment and want to check that everything works - currently this is time consuming and repetitive, with much of the repetition uneeded. -- 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-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=all ] Brett Porter updated MNG-1694: -- Component: (was: maven-compiler-plugin) Reactor and workspace Build execution order control in fine grained projects. --- Key: MNG-1694 URL: http://jira.codehaus.org/browse/MNG-1694 Project: Maven 2 Type: Wish Components: Reactor and workspace Reporter: Mark Proctor Currently in multi module projects you can only work in 2 modes. 1) Build everything 2) Build a single module, IF you have built and installed all its dependency modules I would like to be able to work the following way: 1) Build everything 2) Build an individual module, will build all the modules prior to it in the reactor list. 3) Build a module module and all modules after it in the reactor list, will build missing prior modules. Use Case 1) perform checkout and build 2) module fails 3) keep fixing module and running just its unit tests 3) once all its unit tests pass build it and all modules after it in the reactor list. I don't need to build ones prior as they are unnaffected by the changes. In large mutli module projects this will save a LOT of time especially when you are gearing up for deployment and want to check that everything works - currently this is time consuming and repetitive, with much of the repetition uneeded. -- 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]
Ruby-Mojo support
Maven developers: I have just completed a couple projects to add Ruby support for Maven 2, allowing one to write mojos in Ruby as well as generate mojo descriptors based upon RDoc markup. But I have run into a hurdle. I currently am making the plugin:descriptor run my RubyExtractor by adding the maven-plugin-tools-ruby project to the maven-plugin-plugin dependency list. I figured when running the descriptor goal on the plugin project, it populates the mojoDescriptorExtractors with those injected by Plexus, which naturally must exist in the classpath space (I believe I am correct here). So my question is: is there another way I am missing in which to add my RubyExtractor to the plugin descriptor which does not include modifying the maven-plugin-plugin project in any way? Thanks! Eric
Re: Ruby-Mojo support
The project building the plugin can add this without modifying the original plugin plugin: plugins plugin artifactIdmaven-plugin-plugin/artifactId dependencies dependency groupId.../groupId artifactIdmaven-plugin-tools-ruby/artifactId version.../version /dependency We'd be very interested in this support. Are you willing to contribute it back to the project? Cheers, Brett Eric Redmond wrote: Maven developers: I have just completed a couple projects to add Ruby support for Maven 2, allowing one to write mojos in Ruby as well as generate mojo descriptors based upon RDoc markup. But I have run into a hurdle. I currently am making the plugin:descriptor run my RubyExtractor by adding the maven-plugin-tools-ruby project to the maven-plugin-plugin dependency list. I figured when running the descriptor goal on the plugin project, it populates the mojoDescriptorExtractors with those injected by Plexus, which naturally must exist in the classpath space (I believe I am correct here). So my question is: is there another way I am missing in which to add my RubyExtractor to the plugin descriptor which does not include modifying the maven-plugin-plugin project in any way? Thanks! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=comments#action_52114 ] Mark Proctor commented on MNG-1694: --- skipping is fine by me, as long as its fast. Thats what I did for M1, I implemented my own build goal that iterates the reactor and calls jar:jar if a jar doesn't exist. Build execution order control in fine grained projects. --- Key: MNG-1694 URL: http://jira.codehaus.org/browse/MNG-1694 Project: Maven 2 Type: Wish Components: Reactor and workspace Reporter: Mark Proctor Currently in multi module projects you can only work in 2 modes. 1) Build everything 2) Build a single module, IF you have built and installed all its dependency modules I would like to be able to work the following way: 1) Build everything 2) Build an individual module, will build all the modules prior to it in the reactor list. 3) Build a module module and all modules after it in the reactor list, will build missing prior modules. Use Case 1) perform checkout and build 2) module fails 3) keep fixing module and running just its unit tests 3) once all its unit tests pass build it and all modules after it in the reactor list. I don't need to build ones prior as they are unnaffected by the changes. In large mutli module projects this will save a LOT of time especially when you are gearing up for deployment and want to check that everything works - currently this is time consuming and repetitive, with much of the repetition uneeded. -- 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: Ruby-Mojo support
Eric Redmond wrote: Maven developers: I have just completed a couple projects to add Ruby support for Maven 2, allowing one to write mojos in Ruby as well as generate mojo descriptors based upon RDoc markup. But I have run into a hurdle. I currently am making the plugin:descriptor run my RubyExtractor by adding the maven-plugin-tools-ruby project to the maven-plugin-plugin dependency list. I figured when running the descriptor goal on the plugin project, it populates the mojoDescriptorExtractors with those injected by Plexus, which naturally must exist in the classpath space (I believe I am correct here). So my question is: is there another way I am missing in which to add my RubyExtractor to the plugin descriptor which does not include modifying the maven-plugin-plugin project in any way? I'll definitely help you integrate your code into maven/plexus as I've been playing around with Ruby in the last month and I would really like to see this in Maven. We're generally in IRC if you want to chat about integration: irc.codehaus.org: #maven. Thanks! Eric -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/27-Nov-2005_12.30.45/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
