[jira] Reopened: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier reopened MECLIPSE-346: -- Some tests cases are failing > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (MRM-588) proxy logging is not always effective for diagnosing issues
[ http://jira.codehaus.org/browse/MRM-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114422 ] Brett Porter commented on MRM-588: -- * Do we consider the target repository id to be important to always log? yes, even more so than the managed (source) repo * Do we show the resource (the path) or the artifact (the group:artifact:version:classifier:type key) in the log? don't care as long as it's consistent. Will there be instances before calculating the artifact that it needs to be logged? What about metadata? * Do we show in the log a "whats left" list of repositories that can/will be checked next? (and indications if no more proxies are being checked?) No, just one time log them all. I don't think it should be necessary if the log line aggregates that information which I think is what I was suggesting. * Do we log the network proxy setting? that it is being used? If so, then at what severity level? I don't think I want to see it all the time - maybe just when a conn fails. > proxy logging is not always effective for diagnosing issues > --- > > Key: MRM-588 > URL: http://jira.codehaus.org/browse/MRM-588 > Project: Archiva > Issue Type: Task >Affects Versions: 1.0-beta-4 >Reporter: Brett Porter > Fix For: 1.1 > > > I would like to open discussion for what exactly needs to be logged, and at > what level, for proxy issues to be effectively diagnosed. With the current > configuration, I was unable to pinpoint some problems easily. > Some thoughts: > - don't talk about policies, but state what is happening > - always include the artifact and repository requested > - log more if it results in a NotFoundException > - condense information onto fewer lines where possible (if there are > concurrent requests, without an NDC these will start getting mixed up in the > logs) > Here are my thoughts: > DEBUG Artifact [x/y/z.jar] will not be requested from remote repository [foo] > as it didn't match whitelist items > DEBUG Artifact [x/y/z.jar] will not be requested from remote repository [foo] > as it matched blacklist item x/** > INFO Artifact [x/y/z.jar] requested from managed repository [internal], > checking remote repositories [central,java.net], excluding remote > repositories [foo] > Then: > INFO Artifact [x/y/z.jar] retrieved from remote repository [central], > skipping others > or > INFO Artifact [x/y/z.jar] not retrieved as it failed post-download policy > [bar-policy] (include reason) > And so on... > Thoughts? > An open question is what level to log this at: I feel that it should be at > INFO, but that might be too noisy by default. Perhaps the right thing to do > here is to add a connector configuration property that says whether to log > all requests (and if not, only log at debug level). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-599) maven-metadata.xml is not part of defined whitelist (skipping transfer).
[ http://jira.codehaus.org/browse/MRM-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-599: - Fix Version/s: 1.1 I currently have more than 6 connectors on a repository without problems - will need more investigation to the specific issue > maven-metadata.xml is not part of defined whitelist (skipping transfer). > > > Key: MRM-599 > URL: http://jira.codehaus.org/browse/MRM-599 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-4 > Environment: solaris 10, jdk 1.6 >Reporter: Mathias Arens > Fix For: 1.1 > > > Starting with a clean archiva internal repository and a clean local maven > repository the download of maven plugins fails. > The error message is: > Path [org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml] is not > part of defined whitelist (skipping transfer). > See the full logs below. But I didn't modified the white list for the central > repository. It is still '**/*'. > Steps to reproduce the problem: > 1. Clean the archiva managed internal repository. > 2. Scan the internal repository > 3. Clean the local maven repository > 4. run 'mvn clean install' on a maven project > Here is the log: > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [cache-failures] policy with [no] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to > fetch, check-failures policy set to NO. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [releases] policy with [once] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [snapshots] policy with [never] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - No > authentication for remote repository needed > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml > from Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,338 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,339 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving > org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.sha1 from > Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Checksum.sha1 Downloaded: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.sha1 > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.md5 > from Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Checksum.md5 Downloaded: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.md5 > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [checksum] policy with [fix] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,818 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.common.utils.Checksums:default - Valid checksum: > /p/cred/sp5e/factory/rmsc/archivarepos/
[jira] Created: (CONTINUUM-1574) Schedule Editor: Unable to set Week day
Schedule Editor: Unable to set Week day --- Key: CONTINUUM-1574 URL: http://jira.codehaus.org/browse/CONTINUUM-1574 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-4 Reporter: Gerhard Langs Attachments: weekday.JPG Tried to setup a "weekend" schedule, to run Jobs only Saturday evening. However, the WEB Gui fails, when I enter other values than "?" in the "Day of Week" field. e.g "SAT", "WED" etc fail. with the message: "Invalid cron expression value(s)" attached a screenhot -- 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: (MRM-587) further changes to logging needed
[ http://jira.codehaus.org/browse/MRM-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-587. Resolution: Fixed Fixed in -r596996. - changed log level of archiva from debug to info > further changes to logging needed > - > > Key: MRM-587 > URL: http://jira.codehaus.org/browse/MRM-587 > Project: Archiva > Issue Type: Task >Affects Versions: 1.0-beta-4 >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0 > > > I have noticed that debug level is still enabled for some components. > Please see the following: > http://mail-archives.apache.org/mod_mbox/maven-archiva-dev/200710.mbox/[EMAIL > PROTECTED] -- 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: (CONTINUUM-1574) Schedule Editor: Unable to set Week day
[ http://jira.codehaus.org/browse/CONTINUUM-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1574. --- Assignee: Emmanuel Venisse Resolution: Won't Fix When you set the DAY_OF_WEEK field, you must set the DAY_OF_MONTH field to "?" > Schedule Editor: Unable to set Week day > --- > > Key: CONTINUUM-1574 > URL: http://jira.codehaus.org/browse/CONTINUUM-1574 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-4 >Reporter: Gerhard Langs >Assignee: Emmanuel Venisse > Attachments: weekday.JPG > > > Tried to setup a "weekend" schedule, to run Jobs only Saturday evening. > However, the WEB Gui fails, when I enter other values than "?" in the "Day > of Week" field. > e.g "SAT", "WED" etc fail. with the message: "Invalid cron expression > value(s)" > attached a screenhot -- 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: (CONTINUUM-1574) Schedule Editor: Unable to set Week day
[ http://jira.codehaus.org/browse/CONTINUUM-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114429 ] Emmanuel Venisse commented on CONTINUUM-1574: - >From http://www.opensymphony.com/quartz/api/org/quartz/CronTrigger.html : "Pay attention to the effects of '?' and '*' in the day-of-week and day-of-month fields!" > Schedule Editor: Unable to set Week day > --- > > Key: CONTINUUM-1574 > URL: http://jira.codehaus.org/browse/CONTINUUM-1574 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-4 >Reporter: Gerhard Langs >Assignee: Emmanuel Venisse > Attachments: weekday.JPG > > > Tried to setup a "weekend" schedule, to run Jobs only Saturday evening. > However, the WEB Gui fails, when I enter other values than "?" in the "Day > of Week" field. > e.g "SAT", "WED" etc fail. with the message: "Invalid cron expression > value(s)" > attached a screenhot -- 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: (CONTINUUM-1574) Schedule Editor: Unable to set Week day
[ http://jira.codehaus.org/browse/CONTINUUM-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114430 ] Gerhard Langs commented on CONTINUUM-1574: -- Hmpf, you're right, I have to specify a "?" on the "Day of Month" Sorry for creating this issue. Could be a request for improvement for the GUI, like improving the error message in such situations Thanks anyway for your quick assistance :-) Gerhard > Schedule Editor: Unable to set Week day > --- > > Key: CONTINUUM-1574 > URL: http://jira.codehaus.org/browse/CONTINUUM-1574 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-4 >Reporter: Gerhard Langs >Assignee: Emmanuel Venisse > Attachments: weekday.JPG > > > Tried to setup a "weekend" schedule, to run Jobs only Saturday evening. > However, the WEB Gui fails, when I enter other values than "?" in the "Day > of Week" field. > e.g "SAT", "WED" etc fail. with the message: "Invalid cron expression > value(s)" > attached a screenhot -- 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-385) Booter can't decode properties when contains commas
Booter can't decode properties when contains commas Key: SUREFIRE-385 URL: http://jira.codehaus.org/browse/SUREFIRE-385 Project: Maven Surefire Issue Type: Bug Components: TestNG support Reporter: Dan Fabulich Use multiple TestNG groups, like this: foo, bar The booter will fail to parse the groups string properly, since we use Properties.toString to serialize, which isn't guaranteed to be safe to deserialize. -- 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: (SUREFIRE-385) Booter can't decode properties when contains commas
[ http://jira.codehaus.org/browse/SUREFIRE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-385. - Resolution: Fixed Fix Version/s: 2.4 Fixed in revision 597008 > Booter can't decode properties when contains commas > > > Key: SUREFIRE-385 > URL: http://jira.codehaus.org/browse/SUREFIRE-385 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Reporter: Dan Fabulich > Fix For: 2.4 > > > Use multiple TestNG groups, like this: foo, bar The booter > will fail to parse the groups string properly, since we use > Properties.toString to serialize, which isn't guaranteed to be safe to > deserialize. -- 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: (SUREFIRE-325) when parsing excludedGroups config prop, trim leading and trailing whitespace off of group names
[ http://jira.codehaus.org/browse/SUREFIRE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-325. - Resolution: Fixed This was fixed a while back by just passing the string along to TestNG as a configurable property. (But watch out for SUREFIRE-385 which was just fixed a minute ago.) > when parsing excludedGroups config prop, trim leading and trailing whitespace > off of group names > > > Key: SUREFIRE-325 > URL: http://jira.codehaus.org/browse/SUREFIRE-325 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support >Affects Versions: 2.3 >Reporter: Ian Springer >Priority: Minor > Fix For: 2.4 > > > If I specify: > agent-comm, comm-client, native-system > it gets parsed into: > "agent-comm", " comm-client", " native-system" > It would be nice if, after tokenizing on commas, leading and trailing > whitespace were stripped off of the group names. That is, so results for the > above example would be: > "agent-comm", "comm-client", "native-system" > I know that TestNG group names technically could truly contain leading or > trailing whitespace, but realistically I don't think anyone would ever do > such a thing. -- 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: (MEV-558) Spring 2.5 jar incomplete
Spring 2.5 jar incomplete - Key: MEV-558 URL: http://jira.codehaus.org/browse/MEV-558 Project: Maven Evangelism Issue Type: Bug Reporter: Damien Lecan This jar http://repo1.maven.org/maven2/org/springframework/spring/2.5/spring-2.5.jar is incomplete It is only 315ko where it should be 2.7Mo (as in http://repo1.maven.org/maven-spring/org/springframework/spring/2.5/spring-2.5.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
[jira] Closed: (SUREFIRE-352) Get rid of hardcoded TestNG dependency name.
[
http://jira.codehaus.org/browse/SUREFIRE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi closed SUREFIRE-352.
-
Resolution: Fixed
Added optional properties junitArtifactName and testNGArtifactName which
default to junit:junit and org.testng:testng, as in 2.3.
Fix also addresses SUREFIRE-370.
> Get rid of hardcoded TestNG dependency name.
>
>
> Key: SUREFIRE-352
> URL: http://jira.codehaus.org/browse/SUREFIRE-352
> Project: Maven Surefire
> Issue Type: Improvement
> Components: TestNG support
>Affects Versions: 2.4
>Reporter: jdoe
>Assignee: Mauro Talevi
> Fix For: 2.4
>
> Attachments: custom_testng_dep_name.diff
>
>
> The name of the TestNG dependency is hardcoded ('org.testng:testng'). Some
> ppl are using internal repositories where artifacts are published under
> different names. It would be nice to able to specify the name of dependency,
> e.g.:
> {code:title=build.pom|borderStyle=solid}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.4-SNAPSHOT
>
> testng:testng
>
> testng.xml
>
>
>
> {code}
> Proposed patch attached.
--
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: (CONTINUUM-836) Improve HTTP access to POMs for adding a multi-module project
[ http://jira.codehaus.org/browse/CONTINUUM-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114442 ] Daniel Schulz commented on CONTINUUM-836: - If your SCM is CVS with ViewCVS/ViewVC on top of it, simply use the ViewCVS-Download-Link of your pom.xml as the POM-URL. My continuum version is 1.1beta4. Repository-URLs still don't work. > Improve HTTP access to POMs for adding a multi-module project > - > > Key: CONTINUUM-836 > URL: http://jira.codehaus.org/browse/CONTINUUM-836 > Project: Continuum > Issue Type: New Feature > Components: Core system >Affects Versions: 1.0.3 >Reporter: Aaron Mulder > Fix For: Future > > > If you're not using SVN, there's no obvious way to load a multi-module POM > into continuum. > If you point it to a M2 repo, then the child module paths are all resolved > relative to the parent's group/artifact/version/ directory, which doesn't > work (parent-group/parent-artifact/parent-version/child-module-name/...) > If you point it to a file:// URL it doesn't work because that's disabled by > default. > If you're using CVS, there is no clear way to get the POMs into the web -- > perhaps exporting the whole source tree onto an HTTP server, but that's going > to be manual. > Ideally, you could point Continuum to the parent POM in the M2 repository and > it would check out the tree to access the child POMs, which would avoid this > whole issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1815) upload new release 1.11 to org.mentaframework
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114443 ] Fernando Boaglio commented on MAVENUPLOAD-1815: --- The point is most of users won't compile Mentawai from the source, they will just use the compiled jar. That's why is not necessary to obligate downloading tons of jars if they won't use it anyway. If , for example, an user needs Hibernate, it will be in his pom.xml application. We will document this new approach for our maven users be ok. Actually some users have been complaining about this "everything dependent" behavior, that's why we changed in the first place. > upload new release 1.11 to org.mentaframework > -- > > Key: MAVENUPLOAD-1815 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1815 > Project: maven-upload-requests > Issue Type: Task >Reporter: Fernando Boaglio > > The Mentawai goal is to be a simple, flexible, joyful and productive Java web > framework. > This is a new release with a lot of improvements . > TIA -- 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: (MNG-3296) mvn.bat looses error code on windows NT type platforms
mvn.bat looses error code on windows NT type platforms
--
Key: MNG-3296
URL: http://jira.codehaus.org/browse/MNG-3296
Project: Maven 2
Issue Type: Bug
Components: Command Line
Affects Versions: 2.0.7
Reporter: Matthias Kerkhoff
There is a bug in the mvn.bat script that prevents that an error code is
properly returned to the caller of the script.
The batch script executes the following lines after maven has been invoked if
an error occurs:
if ERRORLEVEL 1 goto error
:error
set ERROR_CODE=1
:end
if "%OS%"=="Windows_NT" goto endNT
:endNT
@endlocal
if exist "%HOME%\mavenrc_post.bat" call "%HOME%\mavenrc_post.bat"
if "%MAVEN_BATCH_PAUSE%" == "on" pause
if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERROR_CODE%
exit /B %ERROR_CODE%
The problem is the endlocal statement. Calling endlocal ends the scope in which
ERROR_CODE was set to 1. The previous value of ERROR_CODE will be
reinstantiated (which is always 0, see line 46).
To fix the problem make the ERROR_CODE value known in the outer ("global")
scope by changing the endlocal statement into
@endlocal & set ERROR_CODE=%ERROR_CODE%
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-348) Transitive dependencies are resolved in an inhomogeneous manner
Transitive dependencies are resolved in an inhomogeneous manner --- Key: MECLIPSE-348 URL: http://jira.codehaus.org/browse/MECLIPSE-348 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: dependency resolution Affects Versions: 2.4 Environment: Maven 2.0.7, Windows XP SP 2, JDK 1.5.0 Reporter: Michael Albrecht Priority: Critical Fix For: 2.4 Attachments: module.zip There are four modules/projects moduleA, moduleB, moduleC and moduleD. moduleA depends on moduleB-1.0.jar moduleC depends on moduleB-2.0.jar moduleD depends on moduleC-1.0.jar and moduleA-1.0.jar What constellation has to be built if I build moduleD-1.0.jar without explicit dependency management? In my opinion D should be built with A-1.0.jar, B-2.0.jar, C-1.0.jar and (hopefully) A-1.0.jar can also run with this version. This even happens with the common mvn goals like e.g. mvn test: --- T E S T S --- Running AppTest call me from modulD call me from modulC call me from modulB - Version 2.0 call me from modulA call me from modulB - Version 2.0 But with mvn eclipse:eclipse I will get the following classpathentries: That's inhomogenous. What can I do to resolve it (without dependency management, of course)? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-348) Transitive dependencies are resolved in an inhomogeneous manner
[ http://jira.codehaus.org/browse/MECLIPSE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-348: - Testcase included: yes Fix Version/s: (was: 2.4) > Transitive dependencies are resolved in an inhomogeneous manner > --- > > Key: MECLIPSE-348 > URL: http://jira.codehaus.org/browse/MECLIPSE-348 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.4 > Environment: Maven 2.0.7, Windows XP SP 2, JDK 1.5.0 >Reporter: Michael Albrecht >Priority: Critical > Attachments: module.zip > > > There are four modules/projects moduleA, moduleB, moduleC and moduleD. > moduleA depends on moduleB-1.0.jar > moduleC depends on moduleB-2.0.jar > moduleD depends on moduleC-1.0.jar and moduleA-1.0.jar > What constellation has to be built if I build moduleD-1.0.jar without > explicit dependency management? > In my opinion D should be built with A-1.0.jar, B-2.0.jar, C-1.0.jar and > (hopefully) A-1.0.jar can also run with this version. > This even happens with the common mvn goals like e.g. mvn test: > --- > T E S T S > --- > Running AppTest > call me from modulD > call me from modulC > call me from modulB - Version 2.0 > call me from modulA > call me from modulB - Version 2.0 > But with mvn eclipse:eclipse I will get the following classpathentries: > > > > That's inhomogenous. > What can I do to resolve it (without dependency management, of course)? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-346: - Affects Version/s: (was: 2.5) 2.4 > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-346: - Component/s: WTP support dependency resolution > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (MNG-3297) maven should not give dependencies to plugins that don't @requireDependencyResolution
maven should not give dependencies to plugins that don't @requireDependencyResolution - Key: MNG-3297 URL: http://jira.codehaus.org/browse/MNG-3297 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.7 Reporter: Brian Fox Currently we seem to hand over the dependencies as resolved by the last plugin. This leads to scenarios where sometimes plugins work because they get the right ones but it is subject to break at anytime in subtle ways. Therefore, we should give nothing to the plugin so the plugin author will realize the mistake immediately. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3297) maven should not give dependencies to plugins that don't @requireDependencyResolution
[ http://jira.codehaus.org/browse/MNG-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3297: --- Description: Currently we seem to hand over the dependencies as resolved by the last plugin. This leads to scenarios where sometimes plugins work because they get the right ones but it is subject to break at any time in subtle ways. Therefore, we should give nothing to the plugin so the plugin author will realize the mistake immediately. (was: Currently we seem to hand over the dependencies as resolved by the last plugin. This leads to scenarios where sometimes plugins work because they get the right ones but it is subject to break at anytime in subtle ways. Therefore, we should give nothing to the plugin so the plugin author will realize the mistake immediately.) > maven should not give dependencies to plugins that don't > @requireDependencyResolution > - > > Key: MNG-3297 > URL: http://jira.codehaus.org/browse/MNG-3297 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Brian Fox > > Currently we seem to hand over the dependencies as resolved by the last > plugin. This leads to scenarios where sometimes plugins work because they get > the right ones but it is subject to break at any time in subtle ways. > Therefore, we should give nothing to the plugin so the plugin author will > realize the mistake immediately. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-1806) rsync request: gr.abiss
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manos Batsis updated MAVENUPLOAD-1806: -- Attachment: gr.abiss.md4j.sh gr.abiss.mvn.plugins.maven-jstools-plugin.sh gr.abiss.js.sarissa.sh These sh files replace the original "gr.abiss.sh (0.1 kb)", but I could not find a way to delete that (to avoid any confusion). The sh files now point to the SF release repo for each project. The scripts follow the [EMAIL PROTECTED] convention used by most SF rsync-ed repos, I assume (and hope) the public key etc is already setup and working out of the box. > rsync request: gr.abiss > > > Key: MAVENUPLOAD-1806 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1806 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Manos Batsis >Assignee: Carlos Sanchez > Attachments: gr.abiss.js.sarissa.sh, gr.abiss.md4j.sh, > gr.abiss.mvn.plugins.maven-jstools-plugin.sh, gr.abiss.sh > > > Hello, > This is an rsync request. You can verify I'm (Manos Batsis) a team member in > all projects of dev.abiss.gr by checking out the m2 team report for each > project (I'm also a co-fouder of Abiss.gr), for example [1]. Our releases > repo is at [2] and our OS project list at [3]. Anyway, have not done this > before so tried to work out a basic, non-ssh version of the script > (attached), hope it works :-) > [1] http://dev.abiss.gr/md4j/team-list.html > [2] http://dev.abiss.gr/m2repo/releases > [3] http://dev.abiss.gr > Thanks, > Manos -- 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: (MECLIPSE-349) Move integration tests in the integration-tests profile
Move integration tests in the integration-tests profile --- Key: MECLIPSE-349 URL: http://jira.codehaus.org/browse/MECLIPSE-349 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.4 Reporter: Arnaud Heritier -- 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: (MECLIPSE-350) Allow to bypass the automatic search of JEE (and related) APIs versions
Allow to bypass the automatic search of JEE (and related) APIs versions --- Key: MECLIPSE-350 URL: http://jira.codehaus.org/browse/MECLIPSE-350 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: dependency resolution, RAD support, WTP support Affects Versions: 2.4 Reporter: Arnaud Heritier Actually the plugin tries to find the version of JEE, Servlets, JSPs APIs in project dependencies. We should be able propose to set the version of JEE (or of each API) in the plugin configuration to setup WTP without doing this search -- 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: (MECLIPSE-351) Refactor the plugin to extract services in plexus components
Refactor the plugin to extract services in plexus components Key: MECLIPSE-351 URL: http://jira.codehaus.org/browse/MECLIPSE-351 Project: Maven 2.x Eclipse Plugin Issue Type: Task Affects Versions: 2.4 Reporter: Arnaud Heritier Actually in the plugin we are using a lot of statics methods. We don't have access to logs, and it's not easy to reuse these services. We could put them in plexus components to be able if necessary extract them one day in a library used by others projects. -- 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: (MECLIPSE-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114452 ] Richard van Nieuwenhoven commented on MECLIPSE-172: --- To really fix this bug, should the eclipse plugin not read the workspace file: .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.launching.prefs and select from there the JRE to use, depending on the configured executable in the maven-compiler-plugin? > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- 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: (CONTINUUM-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114454 ] Ionut S commented on CONTINUUM-884: --- The problem didn't occurred since we syncronized the time on both machines.. From our point of view, this bug is fixed... Thank you ! > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > Attachments: continuum.log.tar.gz, log4j.xml > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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: (MRM-599) maven-metadata.xml is not part of defined whitelist (skipping transfer).
[ http://jira.codehaus.org/browse/MRM-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114456 ] Mathias Arens commented on MRM-599: --- I just started with a clean archiva installation again. I cleaned the archiva managed repositories and reinstalled archiva. The only additional settings I added were the remote repositories/proxy connectors from above. I also removed my local maven repository. Starting a build with 'mvn clean install' and archiva failed immediately. It tried to download the maven-clean-plugin from the codehaus repository and not from central. Thus I cannot download anything with a fresh beta-4 installation. I noticed that proxy connectors are displayed differently in the overview concerning the policies. There are connectors having the cache-failures policy displayed on top and others where the cache failure policy is displayed at bottom. Why are the connector policies displayed so differently? (See the screenshot) If I remove all connectors having the cache failures policy on top the download works. I don't know if this issue is connected to my problem but it is true. I tested it with several combinations. If there is no proxy connector configured which has the cache-failures policy on top the download works. Here is a log about the download of the maven-clean-plugin where the download fails: INFO | jvm 1| 2007/11/21 13:38:58 | 2007-11-21 13:38:58,898 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [cache-failures] policy with [yes] INFO | jvm 1| 2007/11/21 13:38:58 | 2007-11-21 13:38:58,899 [SocketListener0-0] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to fetch, check-failures detected no issues. INFO | jvm 1| 2007/11/21 13:38:58 | 2007-11-21 13:38:58,899 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [releases] policy with [once] INFO | jvm 1| 2007/11/21 13:38:58 | 2007-11-21 13:38:58,899 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [snapshots] policy with [never] INFO | jvm 1| 2007/11/21 13:38:58 | 2007-11-21 13:38:58,900 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - No authentication for remote repository needed INFO | jvm 1| 2007/11/21 13:38:58 | 2007-11-21 13:38:58,901 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml from Central Repository INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,151 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Downloaded successfully. INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,152 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.sha1 from Central Repository INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,382 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Downloaded successfully. INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,383 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Checksum.sha1 Downloaded: /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.sha1 INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,383 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.md5 from Central Repository INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,617 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Downloaded successfully. INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,617 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Checksum.md5 Downloaded: /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.md5 INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,617 [SocketListener0-0] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [checksum] policy with [fix] INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:59,622 [SocketListener0-0] DEBUG org.apache.maven.archiva.common.utils.Checksums:default - Valid checksum: /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.sha1 INFO | jvm 1| 2007/11/21 13:38:59 | 2007-11-21 13:38:
[jira] Updated: (MRM-599) maven-metadata.xml is not part of defined whitelist (skipping transfer).
[ http://jira.codehaus.org/browse/MRM-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Arens updated MRM-599: -- Attachment: screenshot-1.jpg There are connectors having the cache-failures policy on top and at bottom. Why are the connectors displayed so differently? > maven-metadata.xml is not part of defined whitelist (skipping transfer). > > > Key: MRM-599 > URL: http://jira.codehaus.org/browse/MRM-599 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-4 > Environment: solaris 10, jdk 1.6 >Reporter: Mathias Arens > Fix For: 1.1 > > Attachments: screenshot-1.jpg > > > Starting with a clean archiva internal repository and a clean local maven > repository the download of maven plugins fails. > The error message is: > Path [org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml] is not > part of defined whitelist (skipping transfer). > See the full logs below. But I didn't modified the white list for the central > repository. It is still '**/*'. > Steps to reproduce the problem: > 1. Clean the archiva managed internal repository. > 2. Scan the internal repository > 3. Clean the local maven repository > 4. run 'mvn clean install' on a maven project > Here is the log: > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [cache-failures] policy with [no] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to > fetch, check-failures policy set to NO. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [releases] policy with [once] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [snapshots] policy with [never] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - No > authentication for remote repository needed > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml > from Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,338 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,339 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving > org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.sha1 from > Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Checksum.sha1 Downloaded: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.sha1 > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.md5 > from Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Checksum.md5 Downloaded: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.md5 > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [checksum] policy with [fix] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,818 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.common.utils.Checksums:default - Val
[jira] Commented: (MNG-1977) Global dependency exclusions
[ http://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114464 ] Wolfgang Nagele commented on MNG-1977: -- I can just agree to others here, this is indeed a VERY important feature. It would ease the development a lot. As if you currently have such a bogus dependency you'll have to copy and paste every possible exclusion to every dependency. This is really ugly and costs a lot of time. > Global dependency exclusions > > > Key: MNG-1977 > URL: http://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 2.1 > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > 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
[jira] Commented: (MECLIPSE-348) Transitive dependencies are resolved in an inhomogeneous manner
[ http://jira.codehaus.org/browse/MECLIPSE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114467 ] Arnaud Heritier commented on MECLIPSE-348: -- I reproduced your problem There's certainly a bug in the dependency resolution strategy used by the plugin > Transitive dependencies are resolved in an inhomogeneous manner > --- > > Key: MECLIPSE-348 > URL: http://jira.codehaus.org/browse/MECLIPSE-348 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.4 > Environment: Maven 2.0.7, Windows XP SP 2, JDK 1.5.0 >Reporter: Michael Albrecht >Priority: Critical > Attachments: module.zip > > > There are four modules/projects moduleA, moduleB, moduleC and moduleD. > moduleA depends on moduleB-1.0.jar > moduleC depends on moduleB-2.0.jar > moduleD depends on moduleC-1.0.jar and moduleA-1.0.jar > What constellation has to be built if I build moduleD-1.0.jar without > explicit dependency management? > In my opinion D should be built with A-1.0.jar, B-2.0.jar, C-1.0.jar and > (hopefully) A-1.0.jar can also run with this version. > This even happens with the common mvn goals like e.g. mvn test: > --- > T E S T S > --- > Running AppTest > call me from modulD > call me from modulC > call me from modulB - Version 2.0 > call me from modulA > call me from modulB - Version 2.0 > But with mvn eclipse:eclipse I will get the following classpathentries: > > > > That's inhomogenous. > What can I do to resolve it (without dependency management, of course)? -- 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: (MECLIPSE-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114468 ] Arnaud Heritier commented on MECLIPSE-172: -- Yes it's certainly the best solution but it's less easy to implement > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- 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: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-346. Resolution: Fixed Fixed. Snapshot deployed. I you can review please. > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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-342) Tests fail if JAVA_HOME path contains spaces
[ http://jira.codehaus.org/browse/SUREFIRE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114471 ] Scott Stephenson commented on SUREFIRE-342: --- Hmm... well, ok. But for what it's worth, I was able to reproduce this just moments ago. I'm getting my snapshots from: http://people.apache.org/repo/m2-snapshot-repository Is that correct? Latest snapshot was 2.4-20071121.115034-16 > Tests fail if JAVA_HOME path contains spaces > > > Key: SUREFIRE-342 > URL: http://jira.codehaus.org/browse/SUREFIRE-342 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows XP >Reporter: Scott Stephenson > Fix For: 2.4 > > > Did default install of jdk1.5.0_12 > Set JAVA_HOME environment variable to C:\Program Files\Java\jdk1.5.0_12 > Did 'mvn clean test' > Maven fails with this message: > [DEBUG] Using JVM: C:\Program Files\Java\jdk1.5.0_12\jre\bin\java > [INFO] Surefire report directory: > C:\EclipseProjects\TNManage\target\surefire-reports > Forking command line: "C:\Program Files\Java\jdk1.5.0_12\jre\bin\java" > -classpath "C:\Documents and > Settings\ssteph\.m2\repository\org\codehaus\plexus\plexus-archiver\1.0-alpha-7\plexus-archiver-1.0-alpha-7.jar;C:\Documents > and > Settings\ssteph\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar;C:\Documents > and > Settings\ssteph\.m2\repository\org\codehaus\plexus\plexus-container-default\1.0-alpha-8\plexus-container-default-1.0-alpha-8.jar;C:\Documents > and > Settings\ssteph\.m2\repository\org\apache\maven\surefire\surefire-booter\2.4-SNAPSHOT\surefire-booter-2.4-SNAPSHOT.jar;C:\Documents > and > Settings\ssteph\.m2\repository\classworlds\classworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar;C:\Documents > and > Settings\ssteph\.m2\repository\org\apache\maven\surefire\surefire-api\2.4-SNAPSHOT\surefire-api-2.4-SNAPSHOT.jar;C:\Documents > and > Settings\ssteph\.m2\repository\commons-lang\commons-lang\2.1\commons-lang-2.1.jar;C:\Documents > and > Settings\ssteph\.m2\repository\org\codehaus\plexus\plexus-utils\1.4.1-SNAPSHOT\plexus-utils-1.4.1-SNAPSHOT.jar;C:\Documents > and > Settings\ssteph\.m2\repository\org\testng\testng\5.5\testng-5.5-jdk15.jar" > org.apache.maven.surefire.booter.SurefireBooter > C:\DOCUME~1\ssteph\LOCALS~1\Temp\surefire60476tmp > C:\DOCUME~1\ssteph\LOCALS~1\Temp\surefire60477tmp > 'C:\Program' is not recognized as an internal or external command, > operable program or batch file. > [ERROR] mojo-execute : surefire:test > Diagnosis: There are test failures. > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : edu.washington.cac.rome.tnmanage:TNManage:war:1.0 ( > task-segment: [clean, test] ) > Diagnosis: There are test failures. > FATAL ERROR: Error executing Maven for a project > org.apache.maven.BuildFailureException: There are test failures. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:424) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 8 more > It fails because of the whitespace in C:\Program Files. I can make it work > by copying the JDK to a folder whose name does not contain spaces and point > JAVA_HOME to it. When I do this, everything works fine. This isn't a > long-term solution though, as it requires a special-case install of the JDK. > This seems to be a new bug in the 2.4-SNAPSHOT. We had to move to this > because we're using the latest TestNG, which requires it. Before this, we > used jUnit with version 2.3 of SUREFIRE and things worked fine. -- This message is automatically generated by
[jira] Reopened: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin reopened MECLIPSE-346: - Not fixed. I am still getting instead of for an ear project. > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated MECLIPSE-346: Attachment: test-project-MECLIPSE-346.zip Attaching a test project that reproduces the issue > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (SUREFIRE-384) Allow TestNG to generate its native XML output
[ http://jira.codehaus.org/browse/SUREFIRE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-384. - Resolution: Fixed fixed in revision 597190 > Allow TestNG to generate its native XML output > -- > > Key: SUREFIRE-384 > URL: http://jira.codehaus.org/browse/SUREFIRE-384 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support, xml generation >Reporter: Dan Fabulich > Fix For: 2.4 > > > TestNG's native XML output is way richer than JUnit's output. It specifies > details about which suites were invoked, which classes contain which methods, > which parameters were used in parameterized tests, etc. It can also include > the messages printed to stdout, as well as logging information generated with > Reporter.log. It's also the basis for TestNG's "rerun failed tests" feature. > Several other bugs and enhancements can't really be done until we do this. -- 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: (SUREFIRE-378) junit-dep 4.4 isn't detected; tests are treated as POJO tests.
[ http://jira.codehaus.org/browse/SUREFIRE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-378. - Resolution: Fixed fixed in revision 597192 > junit-dep 4.4 isn't detected; tests are treated as POJO tests. > -- > > Key: SUREFIRE-378 > URL: http://jira.codehaus.org/browse/SUREFIRE-378 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4 >Reporter: Dan Fabulich > Fix For: 2.4 > > Attachments: junit44-dep.zip > > > Run "mvn test" with the attached project. The setup will fail as "setup" > never runs. > This test depends on junit:junit-dep rather than junit:junit. junit-dep is > just like regular junit, except it doesn't bundle hamcrest in the junit jar; > junit-dep.jar includes only junit.* stuff. The junit-dep pom depends on > hamcrest-core 1.1. > Surefire fails to detect junit:junit-dep and treats the test as a POJO test. -- 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-386) TestNG native XML is generated even if you specify disableXmlReport
TestNG native XML is generated even if you specify disableXmlReport --- Key: SUREFIRE-386 URL: http://jira.codehaus.org/browse/SUREFIRE-386 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4 Reporter: Dan Fabulich Priority: Minor Run testng-simple integration test with -DdisableXmlReport=true. The JUnit XML report will be suppressed, but the new native TestNG XML report will still appear. -- 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: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114482 ] Arnaud Heritier commented on MECLIPSE-346: -- Ok I think I found the problem. It's due to the usage of the provided scope for the dependency. These dependencies aren't transitive :-( Let me search how we can bypass this ... > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114483 ] Siarhei Dudzin commented on MECLIPSE-346: - What about my solution that looks into the referenced projects and then into their direct dependencies (the original patch attachment)? > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (MANTTASKS-86) Resolution of java.net dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114485 ] Werner Guttmann commented on MANTTASKS-86: -- I assume the should go into a Ant target, right ? > Resolution of java.net dependencies > --- > > Key: MANTTASKS-86 > URL: http://jira.codehaus.org/browse/MANTTASKS-86 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Werner Guttmann > Attachments: build.bat, build.xml, pom.xml > > > I am trying to use the Ant task for Maven with the root Maven POM for > the Castor project for download the dependencies and place them into a > lib directory. > What I have observed is that there's a few dependencies missing when I > run the corresponding Ant target. But if I use Maven for the build > process, the missing JARs are downloaded as well and placed into my > local repository. > I have tried to define remoteRepository entries for the java.net and the > Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B > resides), but this does not make a difference. > Any idea what I could try in addition ? Having said that, all other > dependencies are resolved and copied without any problems. It looks like > it's just the dependencies that are not synced globally that create a > problem. -- 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: (MANTTASKS-86) Resolution of java.net dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114484 ] Werner Guttmann commented on MANTTASKS-86: -- > the second point is to try to work starting with an empty local repository: > if javax.transaction:jta is broken in your local repository > for whatever reason, starting from scratch will help Herve, that could not be the case, as that would prevent Castor (the project where I am committer) from compiling at all. With, Castor, we currently use Maven (partially) to compile and test the code before final deployment. If things were broken in my local repo, I could not build at all. But I'll remove the JTA JAR from my local repo and see how it goes. > Resolution of java.net dependencies > --- > > Key: MANTTASKS-86 > URL: http://jira.codehaus.org/browse/MANTTASKS-86 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Werner Guttmann > Attachments: build.bat, build.xml, pom.xml > > > I am trying to use the Ant task for Maven with the root Maven POM for > the Castor project for download the dependencies and place them into a > lib directory. > What I have observed is that there's a few dependencies missing when I > run the corresponding Ant target. But if I use Maven for the build > process, the missing JARs are downloaded as well and placed into my > local repository. > I have tried to define remoteRepository entries for the java.net and the > Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B > resides), but this does not make a difference. > Any idea what I could try in addition ? Having said that, all other > dependencies are resolved and copied without any problems. It looks like > it's just the dependencies that are not synced globally that create a > problem. -- 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: (MANTTASKS-86) Resolution of java.net dependencies
[
http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114486
]
Werner Guttmann commented on MANTTASKS-86:
--
Output from runnin gthe command as part of some An target ...
{noformat}
Apache Ant version 1.6.5 compiled on June 2 2005
Buildfile: C:\workspace\MavenJiraIssue\build.xml
parsing buildfile C:\workspace\MavenJiraIssue\build.xml with URI =
file:///C:/workspace/MavenJiraIssue/build.xml
Project base dir set to: C:\workspace\MavenJiraIssue
parsing buildfile
jar:file:/D:/bin/maven-2.0.8/maven-ant-tasks-2.0.8-SNAPSHOT.jar!/org/apache/maven/artifact/ant/antlib.xml
with URI =
jar:file:/D:/bin/maven-2.0.8/maven-ant-tasks-2.0.8-SNAPSHOT.jar!/org/apache/maven/artifact/ant/antlib.xml
[artifact:dependencies] Maven Ant Tasks version: 2.0.8-SNAPSHOT
[artifact:dependencies] Loading Maven settings file: C:\Dokumente und
Einstellungen\me\.m2\settings.xml
[artifact:dependencies] Using local repository: D:\dev\maven\repository
[artifact:dependencies] Resolving dependencies...
[artifact:dependencies] Using remote repositories:
- id=java.net.maven2.repository, url=http://download.java.net/maven/2,
releases=enabled, snapshots=enabled
- id=maven2-repository.dev.java.net, url=http://download.java.net/maven/2,
releases=enabled, snapshots=enabled
- id=central, url=http://repo1.maven.org/maven2, releases=enabled,
snapshots=disabled
org.codehaus.castor:castor:jar:1.1.3-SNAPSHOT (selected)
javax.transaction:jta:jar:1.0.1B:compile (selected)
log4j:log4j:jar:1.2.13:compile (selected)
xerces:xerces:jar:1.4.0:compile (selected)
Build sequence for target(s) `get.manually' is [get.manually]
Complete build sequence is [get.manually, test-pom-deps, ]
get.manually:
[get] Getting:
http://download.java.net/maven/2/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
[get] To: C:\workspace\MavenJiraIssue\newlib\jta-1.0.1b.jar
BUILD SUCCESSFUL
Total time: 2 seconds
{noformat}
> Resolution of java.net dependencies
> ---
>
> Key: MANTTASKS-86
> URL: http://jira.codehaus.org/browse/MANTTASKS-86
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Werner Guttmann
> Attachments: build.bat, build.xml, pom.xml
>
>
> I am trying to use the Ant task for Maven with the root Maven POM for
> the Castor project for download the dependencies and place them into a
> lib directory.
> What I have observed is that there's a few dependencies missing when I
> run the corresponding Ant target. But if I use Maven for the build
> process, the missing JARs are downloaded as well and placed into my
> local repository.
> I have tried to define remoteRepository entries for the java.net and the
> Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B
> resides), but this does not make a difference.
> Any idea what I could try in addition ? Having said that, all other
> dependencies are resolved and copied without any problems. It looks like
> it's just the dependencies that are not synced globally that create a
> problem.
--
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: (MANTTASKS-99) Create a nightly snapshot build on a CI server
[ http://jira.codehaus.org/browse/MANTTASKS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MANTTASKS-99. -- Assignee: Herve Boutemy Resolution: Fixed Maven Ant Tasks are available on Maven's Continuum zone for some time now. When working on MANTTASKS-22, the link was http://maven.zones.apache.org/continuum/workingCopy.action?projectId=524&projectName=Maven+Ant+Task&userDirectory=target But for the moment, Continuum doesn't seem to work well... > Create a nightly snapshot build on a CI server > -- > > Key: MANTTASKS-99 > URL: http://jira.codehaus.org/browse/MANTTASKS-99 > Project: Maven 2.x Ant Tasks > Issue Type: Task >Affects Versions: 2.0.7 >Reporter: Ben Hale >Assignee: Herve Boutemy > > Currently, there is no way to get nightly snapshots of fixes made to the > Maven ANT Tasks. Please create a nightly snapshot build on > http://maven.zones.apache.org:8080 so that we can get access to snapshots and > test them. -- 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: (MANTTASKS-86) Resolution of java.net dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114490 ] Werner Guttmann commented on MANTTASKS-86: -- Just wondering whether the problem could be related to the fact that I am using a local repo which is not at the standard location.I might be completely wrong, but at least I have asked .. ;-). > Resolution of java.net dependencies > --- > > Key: MANTTASKS-86 > URL: http://jira.codehaus.org/browse/MANTTASKS-86 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Werner Guttmann > Attachments: build.bat, build.xml, pom.xml > > > I am trying to use the Ant task for Maven with the root Maven POM for > the Castor project for download the dependencies and place them into a > lib directory. > What I have observed is that there's a few dependencies missing when I > run the corresponding Ant target. But if I use Maven for the build > process, the missing JARs are downloaded as well and placed into my > local repository. > I have tried to define remoteRepository entries for the java.net and the > Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B > resides), but this does not make a difference. > Any idea what I could try in addition ? Having said that, all other > dependencies are resolved and copied without any problems. It looks like > it's just the dependencies that are not synced globally that create a > problem. -- 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: (MANTTASKS-86) Resolution of java.net dependencies
[
http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114491
]
Herve Boutemy commented on MANTTASKS-86:
{noformat}
[get] Getting:
http://download.java.net/maven/2/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
[get] To: C:\workspace\MavenJiraIssue\newlib\jta-1.0.1b.jar
{noformat}
requesting {{jta-1.0.1B.jar}} you get {{jta-1.0.1b.jar}}: I don't really know
if this little case difference could explain the problem.
can you delete files in your local repo before running Ant?
I'd like to see the output of the tasks downloading artifacts from repositories
> Resolution of java.net dependencies
> ---
>
> Key: MANTTASKS-86
> URL: http://jira.codehaus.org/browse/MANTTASKS-86
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Werner Guttmann
> Attachments: build.bat, build.xml, pom.xml
>
>
> I am trying to use the Ant task for Maven with the root Maven POM for
> the Castor project for download the dependencies and place them into a
> lib directory.
> What I have observed is that there's a few dependencies missing when I
> run the corresponding Ant target. But if I use Maven for the build
> process, the missing JARs are downloaded as well and placed into my
> local repository.
> I have tried to define remoteRepository entries for the java.net and the
> Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B
> resides), but this does not make a difference.
> Any idea what I could try in addition ? Having said that, all other
> dependencies are resolved and copied without any problems. It looks like
> it's just the dependencies that are not synced globally that create a
> problem.
--
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: (MANTTASKS-98) NPE if user settings file doesn't exist
[ http://jira.codehaus.org/browse/MANTTASKS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MANTTASKS-98. -- Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: 2.0.8 fixed, thank you > NPE if user settings file doesn't exist > --- > > Key: MANTTASKS-98 > URL: http://jira.codehaus.org/browse/MANTTASKS-98 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: POM Integration >Affects Versions: 2.0.8 > Environment: 2.0.08-SNAPSHOT from 18-Nov-2007 >Reporter: Pete Muir >Assignee: Herve Boutemy > Fix For: 2.0.8 > > Attachments: MANTTASKS-98.patch > > > When running > > > > > you get, if ~/.m2/settings.xml is missing, > java.lang.NullPointerException >at > org.apache.maven.settings.SettingsUtils.merge(SettingsUtils.java:110) >at > org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(Abstr > actArtifactTask.java:264) >at > org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractAr > tifactTask.java:643) >at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) -- 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-1948) reporting section should allow additional dependencies in plugins as well
[ http://jira.codehaus.org/browse/MNG-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114497 ] md commented on MNG-1948: - I would appreciate it if this gets a "Critical" priority. My usage is related to being able to specify custorm PMD rules in an external jar that I need to be in the classpath for the maven-pmd-plugin. This is a serious deficiency and is requiring us to use cumbersome workarounds and potentially making our builds brittle > reporting section should allow additional dependencies in plugins as well > - > > Key: MNG-1948 > URL: http://jira.codehaus.org/browse/MNG-1948 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle, POM >Reporter: Brett Porter > Fix For: 2.1 > > > currently, you can only do this in the build section -- 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: (MNG-3298) invoker MavenCommandLineBuilder#checkRequiredState() should not throw Exception if envvar M2_HOME exists
invoker MavenCommandLineBuilder#checkRequiredState() should not throw Exception if envvar M2_HOME exists Key: MNG-3298 URL: http://jira.codehaus.org/browse/MNG-3298 Project: Maven 2 Issue Type: Bug Components: Shared Reporter: Olivier Lamy currently MavenCommandLineBuilder#checkRequiredState() failed if System.getProperty( "maven.home" ). Whereas we can accept the envar M2_HOME. -- 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: (MANTTASKS-100) Deploy tasks creates incorrect checksums
[
http://jira.codehaus.org/browse/MANTTASKS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MANTTASKS-100.
---
Assignee: Herve Boutemy
Resolution: Cannot Reproduce
I looked at the link to the repo you gave me.
I checked checksums for every files: {{spring-core-2.5-sources.jar}},
{{spring-core-2.5.jar}} and {{spring-core-2.5.pom}}
I found that they were correct for both .jar files, but incorrect for pom file.
I checked Maven Ant Tasks unit tests on my machine and found that the checksums
were correct.
I checked the code: Maven Ant Tasks use deployment classes from
maven-artifact-manager exactly like Maven itself.
Then I don't see where the tasks could have done anything different from Maven.
You say the artifacts were uploaded for synchronization: could the pom file
have been modified during the transfert, like an end-of-line replacement with
FTP?
I transformed the downloaded pom file with {{unix2dos}} command and calculated
checksums: bingo, the new checksums are like those in checksum files.
Then the problem is in your transfert process.
> Deploy tasks creates incorrect checksums
>
>
> Key: MANTTASKS-100
> URL: http://jira.codehaus.org/browse/MANTTASKS-100
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: deploy task
>Affects Versions: 2.0.7
>Reporter: Ben Hale
>Assignee: Herve Boutemy
>Priority: Critical
>
> When releasing Spring 2.5.0, I used the maven deploy tasks to deploy all
> artifacts to a filesystem which were then uploaded for synchronization
> (http://fisheye1.cenqua.com/browse/springframework/spring/build-continuous.xml?r=1.18).
>
> However, now that users have started downloading them, it's come to our
> attention that the MD5 and SHA1 sums that the task created are incorrect
> (http://repo1.maven.org/maven2/org/springframework/spring-core/2.5/) for all
> artifacts.
--
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: (MNG-3298) invoker MavenCommandLineBuilder#checkRequiredState() should not throw Exception if envvar M2_HOME exists
[ http://jira.codehaus.org/browse/MNG-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MNG-3298. - Resolution: Fixed Fix Version/s: 2.0.8 committed in rev 597230. > invoker MavenCommandLineBuilder#checkRequiredState() should not throw > Exception if envvar M2_HOME exists > > > Key: MNG-3298 > URL: http://jira.codehaus.org/browse/MNG-3298 > Project: Maven 2 > Issue Type: Bug > Components: Shared >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.0.8 > > > currently MavenCommandLineBuilder#checkRequiredState() failed if > System.getProperty( "maven.home" ). > Whereas we can accept the envar M2_HOME. -- 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: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114500 ] Arnaud Heritier commented on MECLIPSE-346: -- Your solution is quite good, but in theory we should have to use MavenProject.getDependencies, MavenProject.getArtifacts or MavenProject.getProjectReferences to be sure that we don't ask to maven to resolve itself the dependencies (or we will have some problems, for example to create the eclipse config if the project has some dependencies not yet built). That's why we have some methods like AbstractIdeSupportMojo.doDependencyResolution() I wouldn't break something by using this method > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (SUREFIRE-379) When an exception occurs in @BeforeMethod, the exception is not recorded.
[ http://jira.codehaus.org/browse/SUREFIRE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-379. - Resolution: Fixed fixed in revision 597234 > When an exception occurs in @BeforeMethod, the exception is not recorded. > - > > Key: SUREFIRE-379 > URL: http://jira.codehaus.org/browse/SUREFIRE-379 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Reporter: Dan Fabulich >Priority: Critical > Fix For: 2.4 > > Attachments: testng-beforeMethodFailure.zip > > > Run "mvn test" in the attached project. You'll get 1 skipped test. But why? > There's no record of the failure exception in the XML test output or in the > txt file or on the console. The diagnostic information is lost. -- 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: (SUREFIRE-376) TestNG @AfterSuite failures are ignored
[
http://jira.codehaus.org/browse/SUREFIRE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-376.
-
Resolution: Fixed
fixed in revision 597234
> TestNG @AfterSuite failures are ignored
> ---
>
> Key: SUREFIRE-376
> URL: http://jira.codehaus.org/browse/SUREFIRE-376
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Reporter: Dan Fabulich
>Priority: Critical
> Fix For: 2.4
>
> Attachments: testng-afterSuiteFailure.zip
>
>
> Run the attached test, which includes a TestNG test like this:
> public class TestNGSuiteTest {
> @Test public void doNothing() {}
> @AfterSuite public void failAfterSuite() { Assert.fail(); }
> }
> When you run "mvn test", the test will pass, but it should fail.
--
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: (MRELEASE-299) Add SCM informations in the manifest
Add SCM informations in the manifest Key: MRELEASE-299 URL: http://jira.codehaus.org/browse/MRELEASE-299 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-7 Reporter: Vincent Siveton It should be great if some SCM informations like url and revision could be put in the MANIFEST.MF -- 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: (CONTINUUM-1575) Confusing behavior when continuum can't construct MavenProject from pom
Confusing behavior when continuum can't construct MavenProject from pom --- Key: CONTINUUM-1575 URL: http://jira.codehaus.org/browse/CONTINUUM-1575 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-beta-4 Environment: not environment-specific Reporter: Adrian Sox If a POM that fails validation is checked in, continuum's behavior makes it difficult to determine the actual cause. In this case, Continuum produces two build results from a single build. The first build result is an error result, with output like org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'update-project-from-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:434) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:139) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Error while mapping metadata:add.project.validation.error add.project.project.building.error add.project.unknown.error at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:157) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:75) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:408) ... 8 more This is not exactly descriptive, although it does suggest a validation error. This initial build result is the latest build result for an extremely short window (~2 seconds); it is quickly supplanted by a second result (Warning): [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [clean, deploy] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Wed Nov 21 14:17:02 CST 2007 [INFO] Final Memory: 1M/2M [INFO] This error is extremely confusing. The apparent cause of the error (no pom) is confirmed if we look at the build directory, but it isn't clear why that pom is gone. (It turns out that in the error handling of DefaultMavenBuilderHelper.getMavenProject, Continuum deletes the POM file.) So, to summarize: 1. Continuum produces two conflicting build results for a single build. 2. Continuum deletes the pom if it can't construct a MavenProject from the pom. 3. The first error message is very difficult to interpret. The second is perfectly clear, but completely irrelevant. -- 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: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114506 ] Siarhei Dudzin commented on MECLIPSE-346: - Well just as you suggested this is exactly what is used in the patch: MavenProject.getProjectReferences and MavenProject.getDependencies so I dont see the problem here (unless I misunderstood what you just meant). Anyway, what are your plans for this issue? I have pretty high need for this issue to be resolved. > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (MINVOKER-8) invoker unit tests fail
[ http://jira.codehaus.org/browse/MINVOKER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-8. --- Resolution: Fixed Fix Version/s: 1.1 Looks ok now (build is fine on the ci server). Reopen it if you have issues again. > invoker unit tests fail > --- > > Key: MINVOKER-8 > URL: http://jira.codehaus.org/browse/MINVOKER-8 > Project: Maven 2.x Invoker Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: John Casey > Fix For: 1.1 > > > I get the following failure on my Mac: > testBuildShouldSucceed(org.apache.maven.shared.invoker.DefaultInvokerTest) > Time elapsed: 1.058 sec <<< FAILURE! > junit.framework.AssertionFailedError: expected:<0> but was:<1> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:201) > at junit.framework.Assert.assertEquals(Assert.java:207) > at > org.apache.maven.shared.invoker.DefaultInvokerTest.testBuildShouldSucceed(DefaultInvokerTest.java:44) > at > org.apache.maven.shared.invoker.DefaultInvokerTest.testBuildShouldSucceed(DefaultInvokerTest.java:44) > The same issue is being seen in CI: > http://maven.zones.apache.org/continuum/surefireReport.action?buildId=13387&projectId=57#org.apache.maven.shared.invoker.DefaultInvokerTest > this is building the shared component. -- 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: (MAVENUPLOAD-1799) Upload request for swingx 0.9 for jdk 1.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114508 ] Jan Haderka commented on MAVENUPLOAD-1799: -- 0.9 bundle is at http://swinglabs.org/hudson/job/maven-temp/ws/dist/0.9/swingx-bundle.jar 0.9.1 bundle is at http://swinglabs.org/hudson/job/maven-temp/ws/dist/0.9.1/swingx-bundle.jar > Upload request for swingx 0.9 for jdk 1.5 > - > > Key: MAVENUPLOAD-1799 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1799 > Project: maven-upload-requests > Issue Type: Task >Reporter: Wim Deblauwe > Attachments: pom.xml > > > SwingX is all about Swing components. It focuses both on extensions to > existing Swing components as well as brand new ones. SwingX contains a lot of > great components that you can use in your applications today. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-377: -- Fix Version/s: (was: 2.4) IMO, this problem is probably too hard to be worth solving. See the mailing list archive thread here: http://mail-archives.apache.org/mod_mbox/maven-surefire-dev/200711.mbox/[EMAIL PROTECTED] http://tinyurl.com/32745g Alex suggested a good way to tell the different between JUnit and TestNG runs, but trying to dynamically construct multiple test runs from two arrays of classes that don't clobber each other when you go to run them is harder than it has any right to be. > When JUnit and TestNG tests are in same project, only one set gets run > -- > > Key: SUREFIRE-377 > URL: http://jira.codehaus.org/browse/SUREFIRE-377 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 >Reporter: Dan Fabulich > Attachments: testng-junit-together.zip > > > The attached Maven project has two tests: one JUnit test and one TestNG test. > According to the documentation, in this case TestNG should run both tests. > Run "mvn test". Only the TestNG test will run. If you modify the pom to set > the property "junit=true", only the JUnit test will run. > > org.apache.maven.plugins > maven-surefire-plugin > 2.4-SNAPSHOT > > > > junit > true > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-377: -- Attachment: surefire377.patch I'm going to revert my workspace to blow away my current work on this; in the meantime, here's the current check-in. It sort-of works, but the TestNG XML output is clobbered when you run TestNG twice; I don't see a good way to fix that. > When JUnit and TestNG tests are in same project, only one set gets run > -- > > Key: SUREFIRE-377 > URL: http://jira.codehaus.org/browse/SUREFIRE-377 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 >Reporter: Dan Fabulich > Attachments: surefire377.patch, testng-junit-together.zip > > > The attached Maven project has two tests: one JUnit test and one TestNG test. > According to the documentation, in this case TestNG should run both tests. > Run "mvn test". Only the TestNG test will run. If you modify the pom to set > the property "junit=true", only the JUnit test will run. > > org.apache.maven.plugins > maven-surefire-plugin > 2.4-SNAPSHOT > > > > junit > true > > > -- 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: (SUREFIRE-52) XML Reports include testcases from previous tests
[
http://jira.codehaus.org/browse/SUREFIRE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-52.
Resolution: Cannot Reproduce
This got fixed at some point. Checked in an integration test in revision
597279.
> XML Reports include testcases from previous tests
> -
>
> Key: SUREFIRE-52
> URL: http://jira.codehaus.org/browse/SUREFIRE-52
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.0 (2.2 plugin)
>Reporter: bin zhu
>Priority: Minor
> Fix For: 2.4
>
> Attachments: patch.txt
>
>
> to reproduce
> 1. create the following JUnit tests:
> public class TestA extends TestCase {
>public void test1() {
>}
> }
> public class TestB extends TestCase {
>public void test2() {
> }
> 2. run 'mvn clean install'
> note that in TEST-TestB.xml includes testcase results from test1 and test2,
> even though TestB only has test2()
> name="TestB">
> ...
>
>
>
--
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: (SUREFIRE-160) Bug into xml report generation
[ http://jira.codehaus.org/browse/SUREFIRE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-160. - Resolution: Cannot Reproduce This got fixed at some point. Integration test checked in revision 597279. > Bug into xml report generation > -- > > Key: SUREFIRE-160 > URL: http://jira.codehaus.org/browse/SUREFIRE-160 > Project: Maven Surefire > Issue Type: Bug > Components: xml generation > Environment: release 2.0 of maven-surfire-plugin > mvn 2.0.4 >Reporter: Christophe Lallement > Fix For: 2.4 > > Attachments: nick.zip, > TEST-deai.ft.archi.common.debug.ThreadWarningSystemTest.xml, > ThreadWarningSystem.java, ThreadWarningSystemTest.java > > > since 2-3 weeks i have wrong information into my junit test tun (mvn test for > example) > In fact, the *.txt are right, but the corresponding xml file have wrong > entry. i means additionnal testcase are present ninto the testcase section. > you can find exmple in attachement (ThreadWarningSystemTest for example). You > can see that the error number are good (because read into the attribute of > the first xml tag) but in several TestSuite, we have testcase form other > testsuite. > I don't know if this errors comes from maven dependancies update. > What i am sure is: > 1/ a little bit of source modification into my project since this error > appears. > 2/ no new maven dependancies into my project > 3/ i use only ibilio/maven2 as repository. > This errors can'be shown on other projet and other not ... > I have a workaround to solve this issue but with low performance: > I use the option "fork per test" and the reports is right. > Maybe a way to be investigate can be the temporaly file created by the > command line: > Forking command line: java -classpath > > C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-api\2.0\surefire-api-2.0.jar;C:\HOMEWARE\maven-2_local\o > > rg\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-booter\2.0\surefire-booter-2.0.jar > > or > > g.apache.maven.surefire.booter.SurefireBooter C:\temp\surefire40840tmp > > C:\temp\surefire40841tmp > Any Idea ? > Thx > Christophe -- 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: (MANTTASKS-99) Create a nightly snapshot build on a CI server
[ http://jira.codehaus.org/browse/MANTTASKS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114521 ] Brett Porter commented on MANTTASKS-99: --- the zones have been a bit unstable - they are having some maintenance work this weekend and hopefully that will help > Create a nightly snapshot build on a CI server > -- > > Key: MANTTASKS-99 > URL: http://jira.codehaus.org/browse/MANTTASKS-99 > Project: Maven 2.x Ant Tasks > Issue Type: Task >Affects Versions: 2.0.7 >Reporter: Ben Hale >Assignee: Herve Boutemy > > Currently, there is no way to get nightly snapshots of fixes made to the > Maven ANT Tasks. Please create a nightly snapshot build on > http://maven.zones.apache.org:8080 so that we can get access to snapshots and > test them. -- 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: (MEV-558) Spring 2.5 jar incomplete
[ http://jira.codehaus.org/browse/MEV-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-558. -- Assignee: Carlos Sanchez Resolution: Fixed > Spring 2.5 jar incomplete > - > > Key: MEV-558 > URL: http://jira.codehaus.org/browse/MEV-558 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Damien Lecan >Assignee: Carlos Sanchez > > This jar > http://repo1.maven.org/maven2/org/springframework/spring/2.5/spring-2.5.jar > is incomplete > It is only 315ko where it should be 2.7Mo (as in > http://repo1.maven.org/maven-spring/org/springframework/spring/2.5/spring-2.5.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
[jira] Closed: (MEV-556) jaxws jar is incorrect
[ http://jira.codehaus.org/browse/MEV-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-556. -- Assignee: Carlos Sanchez Resolution: Duplicate > jaxws jar is incorrect > -- > > Key: MEV-556 > URL: http://jira.codehaus.org/browse/MEV-556 > Project: Maven Evangelism > Issue Type: Bug > Components: Problem with Jar >Reporter: Bill Simons >Assignee: Carlos Sanchez > > The jar in the primary maven repository located at > http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.jar > has the same groupId, artifactId and version as the jar located in the > java.net repository at > http://download.java.net/maven/1/javax.xml.ws/jars/jaxws-api-2.1.jar. > However, the jars are different. The jar located in the java.net repository > is correct and contains all the necessary classes. The problem is that poms > resolve the main maven repo first and so we get the wrong jar. > I'm looking for a workaround, but in the meantime, it would be great if you > could get the correct jar deployed. -- 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: (MRM-600) sort policies in web UI for proxy connector admin
sort policies in web UI for proxy connector admin - Key: MRM-600 URL: http://jira.codehaus.org/browse/MRM-600 Project: Archiva Issue Type: Bug Components: web application Affects Versions: 1.0-beta-4 Reporter: Brett Porter see screenshot in MRM-599 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-600) sort policies in web UI for proxy connector admin
[ http://jira.codehaus.org/browse/MRM-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-600: - Fix Version/s: 1.1 > sort policies in web UI for proxy connector admin > - > > Key: MRM-600 > URL: http://jira.codehaus.org/browse/MRM-600 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-4 >Reporter: Brett Porter > Fix For: 1.1 > > > see screenshot in MRM-599 -- 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: (MRM-599) maven-metadata.xml is not part of defined whitelist (skipping transfer).
[ http://jira.codehaus.org/browse/MRM-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114526 ] Brett Porter commented on MRM-599: -- I filed MRM-600 for the different order of the policies (cache-failures). This is just cosmetic :) I believe the problem is a consequence of the proxy exception - which has been fixed post beta-4. Marking as a duplicate of MRM-586, and we can reopen for a bugfix release if not. Thanks! > maven-metadata.xml is not part of defined whitelist (skipping transfer). > > > Key: MRM-599 > URL: http://jira.codehaus.org/browse/MRM-599 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-4 > Environment: solaris 10, jdk 1.6 >Reporter: Mathias Arens > Fix For: 1.1 > > Attachments: screenshot-1.jpg > > > Starting with a clean archiva internal repository and a clean local maven > repository the download of maven plugins fails. > The error message is: > Path [org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml] is not > part of defined whitelist (skipping transfer). > See the full logs below. But I didn't modified the white list for the central > repository. It is still '**/*'. > Steps to reproduce the problem: > 1. Clean the archiva managed internal repository. > 2. Scan the internal repository > 3. Clean the local maven repository > 4. run 'mvn clean install' on a maven project > Here is the log: > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [cache-failures] policy with [no] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to > fetch, check-failures policy set to NO. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [releases] policy with [once] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [snapshots] policy with [never] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - No > authentication for remote repository needed > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml > from Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,338 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,339 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving > org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.sha1 from > Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Checksum.sha1 Downloaded: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.sha1 > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.md5 > from Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Checksum.md5 Downloaded: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.md5 > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [checksum] policy with [fix] > INF
[jira] Closed: (MRM-599) maven-metadata.xml is not part of defined whitelist (skipping transfer).
[ http://jira.codehaus.org/browse/MRM-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-599. Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 1.1) > maven-metadata.xml is not part of defined whitelist (skipping transfer). > > > Key: MRM-599 > URL: http://jira.codehaus.org/browse/MRM-599 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-4 > Environment: solaris 10, jdk 1.6 >Reporter: Mathias Arens >Assignee: Brett Porter > Attachments: screenshot-1.jpg > > > Starting with a clean archiva internal repository and a clean local maven > repository the download of maven plugins fails. > The error message is: > Path [org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml] is not > part of defined whitelist (skipping transfer). > See the full logs below. But I didn't modified the white list for the central > repository. It is still '**/*'. > Steps to reproduce the problem: > 1. Clean the archiva managed internal repository. > 2. Scan the internal repository > 3. Clean the local maven repository > 4. run 'mvn clean install' on a maven project > Here is the log: > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [cache-failures] policy with [no] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to > fetch, check-failures policy set to NO. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [releases] policy with [once] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [snapshots] policy with [never] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - No > authentication for remote repository needed > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,105 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml > from Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,338 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,339 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving > org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.sha1 from > Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Checksum.sha1 Downloaded: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.sha1 > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,573 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml.md5 > from Central Repository > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Downloaded successfully. > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Checksum.md5 Downloaded: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata-central.xml.md5 > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,817 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [checksum] policy with [fix] > INFO | jvm 1| 2007/11/20 11:33:04 | 2007-11-20 11:33:04,818 > [SocketListener0-5] DEBUG > org.apache.maven.archiva.common.utils.Checksums:default - Valid checksum: > /p/cred/sp5e/factory/rmsc/archivarepos/internal/
[jira] Created: (MAVENUPLOAD-1824) Upload bndlib 0.0.213
Upload bndlib 0.0.213 - Key: MAVENUPLOAD-1824 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1824 Project: maven-upload-requests Issue Type: Task Reporter: Stuart McCulloch bndlib 0.0.213 removes some caching of class data that was causing the bundle-plugin to use large amounts of memory when processing jars such as xalan and xerces (for instance Felix Commons "xml-apis" memory usage drops from 80mb to 18mb using this new bndlib). -- 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: (MECLIPSE-114) eclipse:eclipse creates overlapping source directories
[ http://jira.codehaus.org/browse/MECLIPSE-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114528 ] Vivek Pandey commented on MECLIPSE-114: --- Surprising that the issue is written off like this !! support for nested sources is an eclipse feature, not a limitation. When sources are nested, eclipse needs exclusion filters to take care of them. Should the maven-eclipse-plugin not take care of this and generate the exclusion filters ? > eclipse:eclipse creates overlapping source directories > -- > > Key: MECLIPSE-114 > URL: http://jira.codehaus.org/browse/MECLIPSE-114 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Matthew Beermann > > If I have a POM that looks like this: > > src > > > . > > foo.xml > > > > > ...then I'll get a .classpath file that looks like this: > > > This is illegal, as far as Eclipse is concerned - build paths cannot be > nested inside of one another. -- 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: (CONTINUUM-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-884. -- Assignee: Emmanuel Venisse Resolution: Cannot Reproduce Fix Version/s: (was: Future) > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz >Assignee: Emmanuel Venisse > Attachments: continuum.log.tar.gz, log4j.xml > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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
