[jira] Commented: (MNG-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[ http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190721#action_190721 ] Frank Cornelis commented on MNG-4211: - Apparently 2.2.1 still has some proxy issues. At work I'm having difficulties compiling my software because we're sitting behind a proxy over there. I have a mixture of both http and https repositories, and this doesn't really work apparently. At home (direct connection) the build works as expected. [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+ - Key: MNG-4211 URL: http://jira.codehaus.org/browse/MNG-4211 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.1.0, 2.2.0 Environment: WinXP SP2 Reporter: Robert Glover Jr Priority: Blocker Fix For: 2.2.2 Attachments: jira_files_4_total.zip At a large company, maven become impossible to use via proxy when maven upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9 and continues to work fine. however maven via proxy always fails in version 2.1.0 and higher. Attached is a zip file containing 1) log of GMAIL chat between the creater of this JIRA and a maven developer. 2) two console outputs of running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml (with comments stripped out) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2601) Sync'ing the UJO Framework to the central repository
Sync'ing the UJO Framework to the central repository Key: MAVENUPLOAD-2601 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2601 Project: Maven Upload Requests Issue Type: Wish Reporter: Pavel Ponec org.ujoframework,mavens...@web.sourceforge.net:/home/groups/u/uj/ujoframework/htdocs/m2repo,rsync_ssh,Paul Ponec,ppo...@gmail.com,, Hallo, add the project 'UJO Framework' to the list of automatically synced repositories, please. Thank you, reguards Paul -- 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] Created: (SUREFIRE-574) additionalClasspathElements-feature improved
additionalClasspathElements-feature improved
Key: SUREFIRE-574
URL: http://jira.codehaus.org/browse/SUREFIRE-574
Project: Maven Surefire
Issue Type: Improvement
Components: plugin
Affects Versions: 2.4.3
Environment: any
Reporter: Christian Moser
Priority: Minor
Attachments: surefireAddClasspath.diff
I need to extend the classpath of the surefire-plugin by a standard java
classpath (file.jar;file2.jar;file3.jar) contained in a property accessible by
the executing pom file.
Unfortunatelly you have to add every single file by your own:
additionalClasspathElements
additionalClasspathElementfile1.jar/additionalClasspathElement
additionalClasspathElementfile2.jar/additionalClasspathElement
/additionalClasspathElements
So I've wrote a simple patch to extend the classpath by adding just one element:
additionalClasspathElements
additionalClasspathElement${var.cp}/additionalClasspathElement (var.cp
contains: file1.jar;file2.jar;file3.jar etc)
/additionalClasspathElements
What do you think about it and will you add this improvement to the release
version?
I need this feature in my daily busines..
--
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] Created: (MJAVADOC-262) Parameters like sourcepath depend on system path separator (colon/semicolon)
Parameters like sourcepath depend on system path separator (colon/semicolon)
Key: MJAVADOC-262
URL: http://jira.codehaus.org/browse/MJAVADOC-262
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6
Reporter: Vincent Siveton
Using the following conf on Windows box doesnt generate javadoc
{noformat}
sourcepath${basedir}/src/main/java:${basedir}/src/main/javadoc/sourcepath
{noformat}
It is due to the colon separator (solaris) instead of the semi-colon (windows)
Other path options (docletPath, extdirs, sourcepath, tagletpath, bootclasspath)
are also plateform dependant.
--
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: (MWAR-203) overlay include to strip the original path
[
http://jira.codehaus.org/browse/MWAR-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190767#action_190767
]
Damon Silver commented on MWAR-203:
---
FWIW, I came up with a workaround after my original post using maven 2.0.9 (and
later 2.2.1) and maven-war-plugin 2.1-beta-1 (its version is defined in a
parent pom):
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
...
overlays
overlay
idsome-id/id
groupId${company.groupId}/groupId
artifactIdmyArtifact/artifactId
typewar/type
includes
includefoo/bar/**/include
/includes
/overlay
overlay
!--
Empty groupId/artifactId detected as the current build.
myArtifact
overlays must come before this for webResources block below
to work
properly!
--
/overlay
webResources
!--
These war/work moves are horrible hacks, but necessary for now
because other resource manipulation isn't working properly. -
9/2/09 DTS
--
resource
directory${project.build.directory}/war/work/${company.groupId}/myArtifact/foo/bar/directory
targetPathrandom/new/directory/targetPath
includes
includefile1/include
includefile2/include
includefile3/include
/includes
/resource
resource
directory${project.build.directory}/war/work/${company.groupId}/myArtifact/foo/bar/directory
targetPathsome/other/directory/targetPath
includes
include**/*.jsp/include
/includes
/resource
/webResources
/configuration
/plugin
/plugins
/build
overlay include to strip the original path
Key: MWAR-203
URL: http://jira.codehaus.org/browse/MWAR-203
Project: Maven 2.x WAR Plugin
Issue Type: Improvement
Environment: 2.1-beta-1
Reporter: Adam Hamer
Priority: Minor
I have a base-war project which I'd like to overlay into my project-war. To
avoid filename conflicts I use targetPath, but the result is
project//targetPath/WEB-INF/... and I don't really want the WEB-INF in there.
I came across this posting with the same issue:
http://www.coderanch.com/t/447258/Ant-Maven-Other-Build-Tools/Maven-war-dependencies-moving-files.
I also tried an assembly approach, but this also includes WEB-INF. Other
ideas could include using the dependency plugin, antrun-plugin, cargo plugin
or some other option? However, I would like to use jetty now that it is
supporting overlays http://jira.codehaus.org/browse/JETTY-1027.
Perhaps some mechanism like this could be added:
under includes or include
excludePathPrefix/WEB-INF//excludePathPrefix !-- ignores the prefix
given --
excludePathtrue/excludePath !-- copies only the filename --
--
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] Closed: (MJAVADOC-262) Parameters like sourcepath depend on system path separator (colon/semicolon)
[
http://jira.codehaus.org/browse/MJAVADOC-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MJAVADOC-262.
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.6.1
fixed in [r814171|http://svn.apache.org/viewvc?rev=814171view=rev], snap
deployed
Parameters like sourcepath depend on system path separator (colon/semicolon)
Key: MJAVADOC-262
URL: http://jira.codehaus.org/browse/MJAVADOC-262
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6
Reporter: Vincent Siveton
Assignee: Vincent Siveton
Fix For: 2.6.1
Using the following conf on Windows box doesnt generate javadoc
{noformat}
sourcepath${basedir}/src/main/java:${basedir}/src/main/javadoc/sourcepath
{noformat}
It is due to the colon separator (solaris) instead of the semi-colon (windows)
Other path options (docletPath, extdirs, sourcepath, tagletpath,
bootclasspath) are also plateform dependant.
--
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] Created: (MAVENUPLOAD-2602) rsync_ssh request for objectfanatics.jp
rsync_ssh request for objectfanatics.jp --- Key: MAVENUPLOAD-2602 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2602 Project: Maven Upload Requests Issue Type: Wish Reporter: Makoto Sato jp.objectfanatics,mvns...@shell.sourceforge.jp:/home/groups/d/do/domaingen/htdocs/m2central,rsync_ssh,Makoto Sato,beyondsee...@yahoo.co.jp,, Whois : http://whois.jprs.jp/en/?type=DOMkey=objectfanatics.jp -- 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] Created: (MPLUGIN-160) PluginDescriptorGenerator doesn't generate component requirements for MojoDescriptor.getRequirements()
PluginDescriptorGenerator doesn't generate component requirements for
MojoDescriptor.getRequirements()
--
Key: MPLUGIN-160
URL: http://jira.codehaus.org/browse/MPLUGIN-160
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: API
Affects Versions: 2.5
Reporter: Stefan Grinsted
Priority: Minor
Attachments: patch.txt
The part that generates the requirements section for a mojo in
PluginDescriptorGenerator, only includes requirements for components, if they
are specified via a parameter with expression=${component.*}, not if it is
actually specified as a required component using the components element.
I have created a patch, which includes the ComponentRequirements as
requirements when generating the requirements element.
Until released, the following workaround can be used in the module.mojos.xml,
to get the required component in the plugin.xml:
parameter
nameworkaroundForPathTransformer/name
requiredtrue/required
expression${component.org.apache.maven.project.path.PathTranslator}/expression
typeorg.apache.maven.project.path.PathTranslator/type
descriptionThis is a workaround to get the PathTransformer as a
Requirement in the plugin.xml./description
/parameter
--
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: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190788#action_190788 ] Dean Ashby commented on SUREFIRE-482: - I'm a relative newcomer to Maven and this one bit me too. Seems odd that I should have to rename my class called DomainTestCase to something without Test in it in order to get Maven to process my tests without complaining. This really should be fixed. Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Attachments: test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by Surefire. -- 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] Maven - Unable to download artifact
Complete Error Message: roha...@roharme:~$ sudo mvn org.andromda.maven.plugins:andromdapp-maven-plugin:3.2:generate [sudo] password for roharme: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/andromda/maven/plugins/andromdapp-maven-plugin/3.2/andromdapp-maven-plugin-3.2.pom Downloading: http://repo1.maven.org/maven2/org/andromda/maven/plugins/andromdapp-maven-plugin/3.2/andromdapp-maven-plugin-3.2.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.andromda.maven.plugins ArtifactId: andromdapp-maven-plugin Version: 3.2 Reason: Unable to download the artifact from any repository org.andromda.maven.plugins:andromdapp-maven-plugin:pom:3.2 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Sep 13 10:47:43 IST 2009 [INFO] Final Memory: 1M/2M [INFO] Some light will be appreciated. -- View this message in context: http://www.nabble.com/Maven---Unable-to-download-artifact-tp25420704p25420704.html Sent from the Maven - Issues mailing list archive at Nabble.com.
