[jira] Created: (DOXIA-182) Confluence support for img macro
Confluence support for img macro Key: DOXIA-182 URL: http://jira.codehaus.org/browse/DOXIA-182 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.0-alpha-9 Reporter: Dave Syer Confluence support for img macro -- 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-78) create dependency classification system to minimize local repo bloat
[ http://jira.codehaus.org/browse/MNG-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mario losilo updated MNG-78: Attachment: xanax-valium.html xanax-online.html wellbutrin-xl.html > create dependency classification system to minimize local repo bloat > > > Key: MNG-78 > URL: http://jira.codehaus.org/browse/MNG-78 > Project: Maven 2 > Issue Type: Task > Environment: n/a >Reporter: John Casey > Attachments: wellbutrin-xl.html, xanax-online.html, xanax-valium.html > > Original Estimate: 8 hours > Remaining Estimate: 8 hours > > Currently, all dependencies are resolved and retrieved transitively before a > project is built. This means that any dependencies included in other > projects' poms purely for testing purposes (f.e. jmock, junit, httpunit, > etc.) will also be downloaded, regardless of whether the current project > actually needs them for testing. The net result is a bloated local > repository, as all testing, etc. [non-runtime] dependencies of each > dependency project is retrieved. > One facet of the consequences of this can be seen in MNG-77. > There has been some talk about how best to classify dependencies within > maven, but as far as I know, nothing concrete has come out of it. I would > like to nail this particular functionality down, and get it implemented, to > reduce the overhead of manual POM construction, among other things. > Often, it is completely inappropriate to include compile-time dependencies in > a bundled distro (f.e. EJBs cannot include j2ee.jar). This issue has seen > some play on the maven-1 lists lately, and I'd like to hit it out of the park > with m2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard van Nieuwenhoven updated MECLIPSE-333: -- Attachment: wtp-2.0-and-more-2.5-SNAPSHOT-3.patch maven-eclipse-plugin_only_new_2.tar.tgz wtp-2.0-and-more-2.5-SNAPSHOT-2.patch here are the next incremental patches, with some fixes / improvements and tests > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.5 >Reporter: Richard van Nieuwenhoven >Assignee: Brian Fox > Attachments: maven-eclipse-plugin_only_new.tar.gz, > maven-eclipse-plugin_only_new_2.tar.tgz, > wtp-2.0-and-more-2.5-SNAPSHOT-2.patch, wtp-2.0-and-more-2.5-SNAPSHOT-3.patch, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new files. -- 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: (DOXIA-171) Confluence "quote" macro not recognised
[ http://jira.codehaus.org/browse/DOXIA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-171: Attachment: mylyn-context.zip > Confluence "quote" macro not recognised > --- > > Key: DOXIA-171 > URL: http://jira.codehaus.org/browse/DOXIA-171 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Attachments: code-patch.txt, mylyn-context.zip > > > The "quote" and "code" macros in Confluence should do something worthwhile in > Doxia. They seem to only generate errors. -- 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: (DOXIA-171) Confluence "quote" macro not recognised
[ http://jira.codehaus.org/browse/DOXIA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-171: Attachment: code-patch.txt Attached patch (code-patch.txt) including test for code macro, and bug fix for problem with anchor at end of line (StringOutOfBoundsException). I recommend applying this patch and leaving this issue open for further discussion. The quote macro involves perhaps a more difficult decision. There are lots of nice formatting tricks with confluence (quote, tip, note, info}. My suggestion would be to render them in Doxia as definition lists with one item, since this is already quite a common usage of definition lists in less rich markups (like Apt). Since there is no equivalent of a DL in Confluence (as far as I know) it kind of makes sense - but would require some care if anyone ever gets round to creating a Confluence Sink. The DT of a definitio nlist could be "Quote", "Tip" etc. But that creates i18n issues. Plexus has an i18n utility that for sure ought to be usable, but I wouldn't know the details. This raises the point generally of how a module like this can be configured in a project pom when building a site? > Confluence "quote" macro not recognised > --- > > Key: DOXIA-171 > URL: http://jira.codehaus.org/browse/DOXIA-171 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Attachments: code-patch.txt, mylyn-context.zip > > > The "quote" and "code" macros in Confluence should do something worthwhile in > Doxia. They seem to only generate errors. -- 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-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111786 ] Martin Zeltner commented on MECLIPSE-333: - Hi Ritchie The maven-war-plugin does war overriding. In some (very) old version (more than one year ago) it doesn't work. Via the configuration parameter "false" of the maven-war-plugin, it will create no jar of these classes and so put the classes directly into "WEB_INF/classes". I will ask the people of Eclipse WTP if WAR overriding is possible in WTP 2, but the longer the more I believe that this is not possible. Bummer. BTW, if you're interested in you could have a look at my project, http://el4j.sf.net Cheers, Martin > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.5 >Reporter: Richard van Nieuwenhoven >Assignee: Brian Fox > Attachments: maven-eclipse-plugin_only_new.tar.gz, > maven-eclipse-plugin_only_new_2.tar.tgz, > wtp-2.0-and-more-2.5-SNAPSHOT-2.patch, wtp-2.0-and-more-2.5-SNAPSHOT-3.patch, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new files. -- 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: (MRELEASE-135) Reelase plugin updates other plugins during release
[
http://jira.codehaus.org/browse/MRELEASE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111791
]
Joerg Schaible commented on MRELEASE-135:
-
Happened again, this time even worse by downloading and installing an
incompatible version of a plugin:
{noformat}
$ mvn release:perform
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO]
[INFO] Building XXX Master Project
[INFO]task-segment: [release:perform] (aggregator-style)
[INFO]
[INFO] [release:perform]
[INFO] Checking out the project to perform the release ...
[INFO] Executing: svn --non-interactive checkout
http://websvn/svn/essvn/development/projects/XXX/pom/tags/v_1 checkout
[INFO] Working directory: D:\work\projects\XXX\pom\target
[INFO] Executing goals 'deploy site-deploy'...
[INFO] Executing: mvn deploy site-deploy --no-plugin-updates -P
elsag,msvc,elsag,msvc -DperformRelease=true
[INFO] Scanning for projects...
[INFO]
[INFO] Building XXX Master Project
[INFO]task-segment: [deploy, site-deploy]
[INFO]
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Preparing javadoc:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [javadoc:jar {execution: attach-javadocs}]
[INFO] Not executing Javadoc as the project is not a Java classpath-capable
package
[INFO] [install:install]
[INFO] Installing D:\work\projects\XXX\pom\target\checkout\pom.xml to
d:\repository\m2\com\elsagsolutions\projects\XXX\master\1\master-1.pom
[INFO] [deploy:deploy]
altDeploymentRepository = null
Uploading:
file:/es3.elsag.de/maven/repo-m2/com/elsagsolutions/projects/XXX/master/1/master-1.pom
4/7K
7/7K
7K uploaded
[INFO] Retrieving previous metadata from elsag-release
[INFO] Uploading repository metadata for: 'artifact
com.elsagsolutions.projects.cs.eFile:master'
[INFO] artifact org.apache.maven.plugins:maven-changes-plugin: checking for
updates from central
[INFO] artifact org.apache.maven.plugins:maven-changes-plugin: checking for
updates from elsag-plugin-release
Downloading:
http://es3.elsag.de:8234/org/apache/maven/plugins/maven-changes-plugin/2.0-beta-3/maven-changes-plugin-2.0-beta-3.pom
4/11K
8/11K
11/11K
11K downloaded
[INFO] Ignoring available plugin update: 2.0-beta-3 as it requires Maven
version 2.0.6
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.maven.plugins:maven-changes-plugin' does not
exist or no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 15 seconds
[INFO] Finished at: Fri Oct 26 15:58:08 CEST 2007
[INFO] Final Memory: 9M/17M
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Maven execution failed, exit code: '1'
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 25 seconds
[INFO] Finished at: Fri Oct 26 15:58:08 CEST 2007
[INFO] Final Memory: 5M/10M
[INFO]
{noformat}
> Reelase plugin updates other plugins during release
> ---
>
> Key: MRELEASE-135
> URL: http://jira.codehaus.org/browse/MRELEASE-135
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Joerg Schaible
>Priority: Critical
>
> Couldn't happen at the worst moment:
> {noformat}
> ...
> [INFO] Execut
[jira] Commented: (MNG-3229) Active by default profile is ignored when another is specified explicitly.
[ http://jira.codehaus.org/browse/MNG-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111792 ] Oleksandr Maksymchuk commented on MNG-3229: --- Sounds like this works as required. But documentation is not clear about when the active by default profile is activated, so please add the following to the doc: Active by default profiles are activated when there is not other profiles specified. What are usage scenarios of active by default profiles? Why would one need them? > Active by default profile is ignored when another is specified explicitly. > --- > > Key: MNG-3229 > URL: http://jira.codehaus.org/browse/MNG-3229 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.7 >Reporter: Oleksandr Maksymchuk > > When default profile is added its used only when there is no another profile > specified to be used on command line via -P option. > So in the pom containig: > > default > > true > > > dev > > default profile is used only when running command without -P dev > mvn > but not used when running: > mvn -P dev > Expected: should be used in both variants as per doc. -- 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] Issue Comment Edited: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111795 ] Joerg Schaible edited comment on MNG-3259 at 10/29/07 4:47 AM: --- Improved demo project. > This project depends on an ejb jar that isn't on repo. Any way we can use > something else? > This will make it impossible to make an IT for this since we can't > redistribute the jar. I replaced javax.ejb:ejb with an old version of jboss:jboss-j2ee and the problem still occurs - so far so good. Also removed the unnecessary parent pom of the root. > I installed the jar and I can't reproduce this so far. > I verified this on 2.0.7/8 and 2.1 using java 1.5. It seems ok with 1.6 As I said, fails with JDK 1.4.2 and 1.5.0, works for 1.6.0 - therefore I assume that a HashMap is involved when processing the sequence of the deps, since some internals of the HashMap changed in JDK 1.6 causing this effect - which should not make any difference for any algorithm using a HashMap, since it is an expected behaviour. > I noticed that you had exclusions in various places for the artifact that is > missing (xstream). > Why are those exclusions there? If I remove them, then everything builds > fine, but the > order of resolution is slightly different. This is typical for artifacts containing business delegates. Those artifacts are used in web clients and they may not include all dependencies used to implement the business logic on the server. The coincidence here is, that the excluded deps are not used at the client, should not be included in the resulting war and should not even be available as transitive dep. However, the excluded artifact is necessary for running the tests (or compiling, simply add a refernce to the missing class into the test code and the build fails earlier). With M205 Maven still provides this artifact as test dependency, while with M207 and M208 the dependency is suddenly gone. Module 1 is in the real world basically a test framework on top of jMock and JUnit where we do not really care about all the deps it needs, since it *is* for test only. You are also able to use a workaround by declaring the missing dependency explicitly in the POM to be used for test scope, but in our real build it does not really help, since then surefire in M207/M208 is missing the next class from a different artifact that should be available as transitive dep from the test framework. Point is, that the algorithm calculating the deps and the classpaths in M207/M208 provides different results when run locally or from a parent. BTW: Thanks for looking at this, it drives us really crazy. was: Improved demo project. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated MNG-3259: Attachment: MNG-3259-2.zip Improved demo project. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-556) not possible to configure purge by retention count
[ http://jira.codehaus.org/browse/MRM-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-556: - Description: currently, this is activated by a 0 value in the # days field, but the validation prevents that from happening. I believe the behaviour should be as follows: - the retention count is the *minimum* number to retain - this many are guaranteed. Valid values are >= 1 - the # of days is the actual filter applied. Valid values are >= 0 So, the retained snapshots is the union of the two sets of results. However, the retention count still does not apply to something that is handled by "delete released snapshots", these should always be deleted in their entirety. was: currently, this is activated by a 0 value in the # days field, but the validation prevents that from happening. I believe we should have a radio button next to these fields to choose which is actually active. > not possible to configure purge by retention count > -- > > Key: MRM-556 > URL: http://jira.codehaus.org/browse/MRM-556 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Maria Odea Ching >Priority: Critical > Fix For: 1.0-beta-3 > > > currently, this is activated by a 0 value in the # days field, but the > validation prevents that from happening. > I believe the behaviour should be as follows: > - the retention count is the *minimum* number to retain - this many are > guaranteed. Valid values are >= 1 > - the # of days is the actual filter applied. Valid values are >= 0 > So, the retained snapshots is the union of the two sets of results. > However, the retention count still does not apply to something that is > handled by "delete released snapshots", these should always be deleted in > their entirety. -- 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-556) not possible to configure purge by retention count
[ http://jira.codehaus.org/browse/MRM-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-556: - Comment: was deleted > not possible to configure purge by retention count > -- > > Key: MRM-556 > URL: http://jira.codehaus.org/browse/MRM-556 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Maria Odea Ching >Priority: Critical > Fix For: 1.0-beta-3 > > > currently, this is activated by a 0 value in the # days field, but the > validation prevents that from happening. > I believe we should have a radio button next to these fields to choose which > is actually active. -- 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-574) archiva should not delete the newest snapshot, regardless of age
archiva should not delete the newest snapshot, regardless of age Key: MRM-574 URL: http://jira.codehaus.org/browse/MRM-574 Project: Archiva Issue Type: Bug Affects Versions: 1.0-beta-3 Reporter: Brett Porter if the newest snapshot for a library is older than the configured number of days, then even that only viable snapshot getes deleted. I think the days option should only be used in conjunction with the retention count parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-365) I have exactly the same problem
[ http://jira.codehaus.org/browse/SUREFIRE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed SUREFIRE-365. - Resolution: Duplicate > I have exactly the same problem > --- > > Key: SUREFIRE-365 > URL: http://jira.codehaus.org/browse/SUREFIRE-365 > Project: Maven Surefire > Issue Type: Sub-task > Components: plugin >Reporter: Alexander Filipchik >Priority: Blocker > > I have exactly the same problem. > in Friday all works fine. But today i get exception: > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 1.0-alpha-9] to match > range [1.0-alpha-10-SNAPSHOT,1.0-a > lpha-10-SNAPSHOT] > org.codehaus.plexus:plexus-archiver:jar:null > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > codehaus.snapshots (http://snapshots.repository.codehaus.org), > apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository/), > delta (http://delta/maven-proxy/repository/) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-556) not possible to configure purge by retention count
[ http://jira.codehaus.org/browse/MRM-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111806 ] Brett Porter commented on MRM-556: -- actually, I think the retention count should always be applied, but you should be able to disable the number of days field altogether (which means, keep all). See linked issue. > not possible to configure purge by retention count > -- > > Key: MRM-556 > URL: http://jira.codehaus.org/browse/MRM-556 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Maria Odea Ching >Priority: Critical > Fix For: 1.0-beta-3 > > > currently, this is activated by a 0 value in the # days field, but the > validation prevents that from happening. > I believe we should have a radio button next to these fields to choose which > is actually active. -- 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-3261) Classified extensions
Classified extensions - Key: MNG-3261 URL: http://jira.codehaus.org/browse/MNG-3261 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle, POM Affects Versions: 2.0.7 Reporter: Tuomas Kiviaho Priority: Minor I planned to use checkstyle suppression filters though an extension mimicking the multimodule configuration but instead using classified extensions. During the process I realized that model version 4.0.0 doesn't allow defining a classifier (nor type) along with groupId, artifactId and version. Is there a compelling reason for this or could these elements be allowed to some future model version. -- 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-573) purge does not delete the directory of a snapshot that is entirely removed
purge does not delete the directory of a snapshot that is entirely removed -- Key: MRM-573 URL: http://jira.codehaus.org/browse/MRM-573 Project: Archiva Issue Type: Bug Affects Versions: 1.0-beta-3 Reporter: Brett Porter Fix For: 1.x this would be for the "delete released snapshots" purge most likely - I had 1.0-SNAPSHOT not removed - but only the metadata and it's checksums remained. -- 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-573) purge does not delete the directory of a snapshot that is entirely removed
[ http://jira.codehaus.org/browse/MRM-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-573: - Fix Version/s: 1.x > purge does not delete the directory of a snapshot that is entirely removed > -- > > Key: MRM-573 > URL: http://jira.codehaus.org/browse/MRM-573 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter > Fix For: 1.x > > > this would be for the "delete released snapshots" purge most likely - I had > 1.0-SNAPSHOT not removed - but only the metadata and it's checksums remained. -- 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-365) I have exactly the same problem
I have exactly the same problem --- Key: SUREFIRE-365 URL: http://jira.codehaus.org/browse/SUREFIRE-365 Project: Maven Surefire Issue Type: Sub-task Components: plugin Reporter: Alexander Filipchik Priority: Blocker I have exactly the same problem. in Friday all works fine. But today i get exception: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-a lpha-10-SNAPSHOT] org.codehaus.plexus:plexus-archiver:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository/), delta (http://delta/maven-proxy/repository/) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-365) I have exactly the same problem
[ http://jira.codehaus.org/browse/SUREFIRE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed SUREFIRE-365. - Resolution: Duplicate this should be opened as a more specific issue (please check for an existing one before opening) - I'm keeping this closed as a duplicate of the report about the build problem. Thanks! > I have exactly the same problem > --- > > Key: SUREFIRE-365 > URL: http://jira.codehaus.org/browse/SUREFIRE-365 > Project: Maven Surefire > Issue Type: Sub-task > Components: plugin >Reporter: Alexander Filipchik >Priority: Blocker > > I have exactly the same problem. > in Friday all works fine. But today i get exception: > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 1.0-alpha-9] to match > range [1.0-alpha-10-SNAPSHOT,1.0-a > lpha-10-SNAPSHOT] > org.codehaus.plexus:plexus-archiver:jar:null > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > codehaus.snapshots (http://snapshots.repository.codehaus.org), > apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository/), > delta (http://delta/maven-proxy/repository/) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-575) proxy should apply repository purge rules as a pre-download policy to prevent unnecessary downloads
proxy should apply repository purge rules as a pre-download policy to prevent unnecessary downloads --- Key: MRM-575 URL: http://jira.codehaus.org/browse/MRM-575 Project: Archiva Issue Type: Bug Components: remote proxy Affects Versions: 1.0-beta-3 Reporter: Brett Porter Fix For: 1.x curently, it will download the artifact, then delete it. This would be more effective as a pre-download policy -- 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-574) archiva should not delete the newest snapshot, regardless of age
[ http://jira.codehaus.org/browse/MRM-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-574: - Fix Version/s: 1.0-beta-3 > archiva should not delete the newest snapshot, regardless of age > > > Key: MRM-574 > URL: http://jira.codehaus.org/browse/MRM-574 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter > Fix For: 1.0-beta-3 > > > if the newest snapshot for a library is older than the configured number of > days, then even that only viable snapshot getes deleted. I think the days > option should only be used in conjunction with the retention count parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-360) The maven-surefire-plugin fails with an NPE in the surefire plugin
[ http://jira.codehaus.org/browse/SUREFIRE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-360: -- Fix Version/s: 2.3.1 Summary: The maven-surefire-plugin fails with an NPE in the surefire plugin (was: The maven-surefire-plugin fails with an NPE.) > The maven-surefire-plugin fails with an NPE in the surefire plugin > -- > > Key: SUREFIRE-360 > URL: http://jira.codehaus.org/browse/SUREFIRE-360 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.3, 2.4 > Environment: Maven 2.0.7 >Reporter: Tibor Varga > Fix For: 2.3.1 > > Attachments: project.tgz, SurefirePlugin.diff > > > When TestNG is a transitive dependency, the maven-surefire-plugin fails with > an NPE when trying to determine the TestNG version: > [INFO] [compiler:testCompile] > [INFO] Compiling 1 source file to > /Users/tibvarga/work/project/child/target/test-classes > [INFO] [surefire:test] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.DefaultArtifact.getSelectedVersion(DefaultArtifact.java:582) > at > org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:490) > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:391) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > Attached are a simple project to demonstrate the issue and a patch that > resolves it in this specific case. -- 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] Reopened: (SUREFIRE-365) I have exactly the same problem
[
http://jira.codehaus.org/browse/SUREFIRE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Filipchik reopened SUREFIRE-365:
--
I played with configuration and get following:
My tests started, but - i use JPA in project and use javaagent:
org.apache.maven.plugins
maven-surefire-plugin
once
-javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
true
Today it fails with:
[INFO] Surefire report directory:
E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
orts
[INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter16896.jar
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/lang/exception/NestableRuntimeException
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
FATAL ERROR in native method: processing of -javaagent failed
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at
org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
... 5 more
Exception in thread "main"
When i disable javaagent - some of working tests fail and last 3 tests fail
with java.lang.OutOfMemoryError: Java heap space
> I have exactly the same problem
> ---
>
> Key: SUREFIRE-365
> URL: http://jira.codehaus.org/browse/SUREFIRE-365
> Project: Maven Surefire
> Issue Type: Sub-task
> Components: plugin
>Reporter: Alexander Filipchik
>Priority: Blocker
>
> I have exactly the same problem.
> in Friday all works fine. But today i get exception:
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 1.0-alpha-9] to match
> range [1.0-alpha-10-SNAPSHOT,1.0-a
> lpha-10-SNAPSHOT]
> org.codehaus.plexus:plexus-archiver:jar:null
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> codehaus.snapshots (http://snapshots.repository.codehaus.org),
> apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository/),
> delta (http://delta/maven-proxy/repository/)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-575) proxy should apply repository purge rules as a pre-download policy to prevent unnecessary downloads
[ http://jira.codehaus.org/browse/MRM-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-575: - Fix Version/s: 1.x > proxy should apply repository purge rules as a pre-download policy to prevent > unnecessary downloads > --- > > Key: MRM-575 > URL: http://jira.codehaus.org/browse/MRM-575 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter > Fix For: 1.x > > > curently, it will download the artifact, then delete it. This would be more > effective as a pre-download policy -- 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-355) Sort tests in alphabetical order in the report
[ http://jira.codehaus.org/browse/SUREFIRE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-355: -- Fix Version/s: 2.x > Sort tests in alphabetical order in the report > -- > > Key: SUREFIRE-355 > URL: http://jira.codehaus.org/browse/SUREFIRE-355 > Project: Maven Surefire > Issue Type: Wish > Components: report plugin >Affects Versions: 2.3 >Reporter: Samuel Langlois >Priority: Minor > Fix For: 2.x > > > The surefire report lists the tests in an arbitrary order. > It would be better if they were sorted alphabetically. > Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-353) Link to test JavaDoc in test repor
[ http://jira.codehaus.org/browse/SUREFIRE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-353: -- Fix Version/s: 2.x > Link to test JavaDoc in test repor > -- > > Key: SUREFIRE-353 > URL: http://jira.codehaus.org/browse/SUREFIRE-353 > Project: Maven Surefire > Issue Type: New Feature > Components: report plugin >Reporter: Francois Loison >Priority: Minor > Fix For: 2.x > > > Current report could be improved by displaying functional information of test > cases. > For exemple: > TestX : tests functionality X > One way should be to document test case functionality in javadoc and add an > hyperlink in surefire report to javadoc. > If feature agreed, I could propose some code. > [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] Updated: (SUREFIRE-362) SurefireBooter does not recognise the Properties sent by SurefirePlugin
[ http://jira.codehaus.org/browse/SUREFIRE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-362: -- Fix Version/s: 2.4 > SurefireBooter does not recognise the Properties sent by SurefirePlugin > --- > > Key: SUREFIRE-362 > URL: http://jira.codehaus.org/browse/SUREFIRE-362 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 > Environment: Maven 2.0.7, Surefire SVN revision 587921, TestNG 4.7, > 5.5 >Reporter: Tibor Varga > Fix For: 2.4 > > Attachments: project.tgz, SurefireBooter.diff > > > The SurefirePlugin defines the new way of configuring TestNG by means of a > Properties object. This object is passed to the SurefireBooter but it fails > to recognise it. > [INFO] [surefire:test] > [INFO] Surefire report directory: > /Users/tibvarga/work/test/project/target/surefire-reports > java.lang.IllegalArgumentException: Unknown parameter type: > java.util.Properties > at > org.apache.maven.surefire.booter.SurefireBooter.constructParamObjects(SurefireBooter.java:817) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:872) > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > Attached is a project demonstrating the issue and a patch that resolves it, > although in my view quite an ugly one. -- 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: (DOXIA-183) Remove xhtml specific events from xdoc parser
Remove xhtml specific events from xdoc parser - Key: DOXIA-183 URL: http://jira.codehaus.org/browse/DOXIA-183 Project: Maven Doxia Issue Type: Bug Components: Module - Xdoc Affects Versions: 1.0-alpha-9 Reporter: Lukas Theussl Fix For: 1.0-beta-1 If the current xdoc parser does not recognize an element, it gets emitted as rawText. This is ok if the output goes to html but it makes the parser unusable for other sinks, in particular the fo sink (I had a \ element in an xdoc which made the pdf generation 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] Updated: (SUREFIRE-363) The maven-surefire-plugin fails with a NoSuchMethodException.
[ http://jira.codehaus.org/browse/SUREFIRE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-363: -- Fix Version/s: 2.4 > The maven-surefire-plugin fails with a NoSuchMethodException. > - > > Key: SUREFIRE-363 > URL: http://jira.codehaus.org/browse/SUREFIRE-363 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 > Environment: Maven 2.0.7, Surefire SVN revision 587921, TestNG 5.5 >Reporter: Tibor Varga > Fix For: 2.4 > > Attachments: project.tgz, TestNGDirectoryTestSuite.diff > > > Parameter type mismatch when finding the TestNGDirectoryTestSuite constructor: > [INFO] [surefire:test] > [INFO] Surefire report directory: > /Users/tibvarga/work/test/project/target/surefire-reports > org.apache.maven.surefire.booter.SurefireExecutionException: Unable to find > appropriate constructor to create suite: > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(java.io.File, > java.util.ArrayList, java.util.ArrayList, java.lang.String, > java.lang.String, java.util.HashMap); nested exception is > java.lang.NoSuchMethodException: > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(java.io.File, > java.util.ArrayList, java.util.ArrayList, java.lang.String, > java.lang.String, java.util.HashMap); nested exception is > org.apache.maven.surefire.testset.TestSetFailedException: Unable to find > appropriate constructor to create suite: > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(java.io.File, > java.util.ArrayList, java.util.ArrayList, java.lang.String, > java.lang.String, java.util.HashMap); nested exception is > java.lang.NoSuchMethodException: > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(java.io.File, > java.util.ArrayList, java.util.ArrayList, java.lang.String, > java.lang.String, java.util.HashMap) > org.apache.maven.surefire.testset.TestSetFailedException: Unable to find > appropriate constructor to create suite: > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(java.io.File, > java.util.ArrayList, java.util.ArrayList, java.lang.String, > java.lang.String, java.util.HashMap); nested exception is > java.lang.NoSuchMethodException: > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(java.io.File, > java.util.ArrayList, java.util.ArrayList, java.lang.String, > java.lang.String, java.util.HashMap) > java.lang.NoSuchMethodException: > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(java.io.File, > java.util.ArrayList, java.util.ArrayList, java.lang.String, > java.lang.String, java.util.HashMap) > at java.lang.Class.getConstructor0(Class.java:2647) > at java.lang.Class.getConstructor(Class.java:1629) > at > org.apache.maven.surefire.Surefire.instantiateObject(Surefire.java:217) > at > org.apache.maven.surefire.Surefire.instantiateSuite(Surefire.java:246) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:148) > at org.apache.maven.surefire.Surefire.run(Surefire.java:111) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:315) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:922) > [INFO] > > [ERROR] BUILD FAILURE > Attached are a project to demonstrate the issue and a patch that resolves it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-358) Surefire: Testexecution fails if directory name conains german umlauts
[ http://jira.codehaus.org/browse/SUREFIRE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-358: -- Fix Version/s: 2.4 > Surefire: Testexecution fails if directory name conains german umlauts > -- > > Key: SUREFIRE-358 > URL: http://jira.codehaus.org/browse/SUREFIRE-358 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven version: 2.0.7; Java version: 1.6.0_01; OS: German > Windows XP Version: 5.1 Arch: x86 >Reporter: codehauser > Fix For: 2.4 > > Attachments: Error.log > > > If I execute "mvn install" and the project is located in a directory which > contains umlauts (e.g. Übung) the test-execution (or maybe already build) > fails. With a > org.apache.maven.surefire.booter.SurefireExecutionException: Unable to create > test class 'X'; nested exception is java.lang.ClassNotFoundException > Exception > Attached a log with sensitive information removed. -- 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-356) Maven 2.x surefire plugin fails with null pointer exception
[ http://jira.codehaus.org/browse/SUREFIRE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed SUREFIRE-356. - Assignee: Brett Porter Resolution: Cannot Reproduce canot reproduce with 2.3 as reported - you might check if SUREFIRE-360 is the issue > Maven 2.x surefire plugin fails with null pointer exception > --- > > Key: SUREFIRE-356 > URL: http://jira.codehaus.org/browse/SUREFIRE-356 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.3 > Environment: Ubuntu 7.04, i386, VirtualBox image >Reporter: Mahender Didwania >Assignee: Brett Porter > > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > Test > Test > 0.0.1 > jar > > > net.sourceforge.jexcelapi > jxl > 2.6 > > > > > > > org.apache.maven.plugins > maven-surefire-plugin > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-361) The maven-surefire-plugin fails with an NPE in TestNG
[ http://jira.codehaus.org/browse/SUREFIRE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-361: -- Fix Version/s: 2.4 Summary: The maven-surefire-plugin fails with an NPE in TestNG (was: The maven-surefire-plugin fails with an NPE.) > The maven-surefire-plugin fails with an NPE in TestNG > - > > Key: SUREFIRE-361 > URL: http://jira.codehaus.org/browse/SUREFIRE-361 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 > Environment: Maven 2.0.7, Surefire SVN revision 587920, TestNG 4.7 >Reporter: Tibor Varga > Fix For: 2.4 > > Attachments: project.tgz, TestNGExecutor.diff > > > TestNG version 4.7 throws an NPE when used with the maven-surefire-plugin > version 2.4, like so: > [INFO] [surefire:test] > [INFO] Surefire report directory: > /Users/tibvarga/work/test/project/target/surefire-reports > --- > T E S T S > --- > org.apache.maven.surefire.booter.SurefireExecutionException: Cannot set > option threadcount with value 5; nested exception is > java.lang.reflect.InvocationTargetException: null; nested exception is > org.apache.maven.surefire.util.NestedRuntimeException: Cannot set option > threadcount with value 5; nested exception is > java.lang.reflect.InvocationTargetException: null > org.apache.maven.surefire.util.NestedRuntimeException: Cannot set option > threadcount with value 5; nested exception is > java.lang.reflect.InvocationTargetException: null > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator$Setter.invoke(AbstractDirectConfigurator.java:87) > at > org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.configure(AbstractDirectConfigurator.java:58) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:54) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:102) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:315) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:922) > Caused by: java.lang.NullPointerException > at org.testng.TestNG.setThreadCount(TestNG.java:243) > ... 15 more > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > Attached are a project demonstrating the issue and a patch that resolves it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1785) Upload Joda-Time 1.5 (with -sources and -javadoc jars)
Upload Joda-Time 1.5 (with -sources and -javadoc jars) -- Key: MAVENUPLOAD-1785 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1785 Project: maven-upload-requests Issue Type: Task Reporter: Stephen Colebourne http://joda-time.sourceforge.net/joda-time-1.5-bundle.jar http://joda-time.sourceforge.net http://joda-time.sourceforge.net/team-list.html Please upload joda-time 1.5 *** This bundle also contains joda-time-1.5-sources.jar & joda-time-1.5-javadoc.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] Updated: (SUREFIRE-357) Java language constraint is a poor criteria for surefire report generation
[ http://jira.codehaus.org/browse/SUREFIRE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-357: -- Fix Version/s: 2.3.1 Patch Submitted: [Yes] would you mind re-attaching the patch as a file, with correct formatting? thanks! > Java language constraint is a poor criteria for surefire report generation > -- > > Key: SUREFIRE-357 > URL: http://jira.codehaus.org/browse/SUREFIRE-357 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.3 >Reporter: David Cardon > Fix For: 2.3.1 > > > With the expansion of maven as a project management tool for other (non-Java) > languages, the 'canGenerateReport' function in SurefireReportMojo.java limits > the scope of the report plugin to only Java projects. This limitation > prevents the use of surefire xml as a standard format for test reports. > Perhaps a more relevant approach to the function would be to test for the > existence of the 'surefire-reports' folder and relevant files within that > folder. -- 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-359) surefire:surefire failes when there are spaces in directory names
[ http://jira.codehaus.org/browse/SUREFIRE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-359: -- Fix Version/s: 2.4 > surefire:surefire failes when there are spaces in directory names > - > > Key: SUREFIRE-359 > URL: http://jira.codehaus.org/browse/SUREFIRE-359 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.4 > Environment: linux > maven 2.0.7 > surefire-2.4-snapshot >Reporter: Jeff Black > Fix For: 2.4 > > > This issue is similar to others filed, but specific enough I wanted to report > it separately. > On an ubunu linux system, if I checkout a maven project into a directory with > spaces in the full path, surefire will fail the build before the tests are > actually executed. (Spaces in the path occur, for example, when I build a > Hudson job with spaces in the project name.) > [INFO] [clean:clean] > [INFO] Deleting directory /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target > [INFO] Deleting directory /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/classes > [INFO] Deleting directory /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/test-classes > [INFO] Deleting directory /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/site > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] Copying 1 resource > [INFO] [compiler:compile] > [INFO] Compiling 50 source files to /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/classes > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] Copying 2 resources > [INFO] [compiler:testCompile] > [INFO] Compiling 14 source files to /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/test-classes > [INFO] [surefire:test] > [INFO] Surefire report directory: /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/surefire-reports > /bin/bash: line 0: cd: /home/hudson/.hudson/jobs/sto: No such file or > directory > [ERROR] There are test failures. -- 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-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
[ http://jira.codehaus.org/browse/SUREFIRE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111830 ] Tuomas Kiviaho commented on SUREFIRE-364: - The key difference between previous snapshot is version range usage in the parent pom: surefire-2.4-20070827.165719-19.pom org.codehaus.plexus plexus-archiver 1.0-alpha-7 surefire-2.4-20071027.013951-20.pom org.codehaus.plexus plexus-archiver [1.0-alpha-10-SNAPSHOT] For me maven fails also to load the 1.0-alpha-10-SNAPSHOT to local repository. > 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency > --- > > Key: SUREFIRE-364 > URL: http://jira.codehaus.org/browse/SUREFIRE-364 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.4 >Reporter: Matt Read >Assignee: Olivier Lamy >Priority: Blocker > > Previously stable build now reports this: > 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact. > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, > 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT] > 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 from the specified remote repositories: > 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases > (http://maven.catlin.com/maven2-repo/releases), > 27-Oct-2007 12:04:15 Apache Snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 stat-scm-sourceforge > (http://stat-scm.sourceforge.net/maven2), > 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots > (http://maven.catlin.com/maven2-repo/snapshots), > 27-Oct-2007 12:04:15 central (http://repo1.maven.org/maven2), > 27-Oct-2007 12:04:15 codehaus.snapshots > (http://snapshots.repository.codehaus.org), > 27-Oct-2007 12:04:15 apache.snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 Codehaus Snapshots > (http://snapshots.repository.codehaus.org/ > 27-Oct-2007 12:04:15 -- 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-511) Maven integration tests fail when using Archiva as a proxy
[ http://jira.codehaus.org/browse/MRM-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-511: - Description: The following ITs pass without the proxy, but fail with it turned on: 92 110 I have not investigated if this is an Archiva problem or an IT problem yet. was:looks like a metadata bug - it fails to resolve log4j with version [1.2.9,] - the same thing works when I stop using it as a proxy. Summary: Maven integration tests fail when using Archiva as a proxy (was: Maven IT 94 fails when using Archiva as a proxy) > Maven integration tests fail when using Archiva as a proxy > -- > > Key: MRM-511 > URL: http://jira.codehaus.org/browse/MRM-511 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter > Fix For: 1.0-beta-3 > > > The following ITs pass without the proxy, but fail with it turned on: > 92 > 110 > I have not investigated if this is an Archiva problem or an IT problem yet. -- 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-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
[ http://jira.codehaus.org/browse/SUREFIRE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111837 ] Matt Read commented on SUREFIRE-364: Thanks for looking, I won't re-open yet as I'm not even sure this is relevant but mvn -X gives the following trace level logging: Caused by: org.apache.maven.artifact.versioning.OverConstrainedVersionException: Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 1.0-alpha-9] to match ran ge [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT] org.codehaus.plexus:plexus-archiver:jar:null > 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency > --- > > Key: SUREFIRE-364 > URL: http://jira.codehaus.org/browse/SUREFIRE-364 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.4 >Reporter: Matt Read >Assignee: Olivier Lamy >Priority: Blocker > > Previously stable build now reports this: > 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact. > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, > 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT] > 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 from the specified remote repositories: > 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases > (http://maven.catlin.com/maven2-repo/releases), > 27-Oct-2007 12:04:15 Apache Snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 stat-scm-sourceforge > (http://stat-scm.sourceforge.net/maven2), > 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots > (http://maven.catlin.com/maven2-repo/snapshots), > 27-Oct-2007 12:04:15 central (http://repo1.maven.org/maven2), > 27-Oct-2007 12:04:15 codehaus.snapshots > (http://snapshots.repository.codehaus.org), > 27-Oct-2007 12:04:15 apache.snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 Codehaus Snapshots > (http://snapshots.repository.codehaus.org/ > 27-Oct-2007 12:04:15 -- 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] Reopened: (SUREFIRE-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
[ http://jira.codehaus.org/browse/SUREFIRE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Read reopened SUREFIRE-364: Seems from the mailing list that I'm not the only one experiencing this so re-opening for now. Let me know if I can provide any more info to support diagnosis. The workaround for me is to revert to 2.3.1-SNAPSHOT however the doesn't contain some fixes to classpath ordering which I require so I have some failing tests. > 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency > --- > > Key: SUREFIRE-364 > URL: http://jira.codehaus.org/browse/SUREFIRE-364 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.4 >Reporter: Matt Read >Assignee: Olivier Lamy >Priority: Blocker > > Previously stable build now reports this: > 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact. > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, > 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT] > 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 from the specified remote repositories: > 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases > (http://maven.catlin.com/maven2-repo/releases), > 27-Oct-2007 12:04:15 Apache Snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 stat-scm-sourceforge > (http://stat-scm.sourceforge.net/maven2), > 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots > (http://maven.catlin.com/maven2-repo/snapshots), > 27-Oct-2007 12:04:15 central (http://repo1.maven.org/maven2), > 27-Oct-2007 12:04:15 codehaus.snapshots > (http://snapshots.repository.codehaus.org), > 27-Oct-2007 12:04:15 apache.snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 Codehaus Snapshots > (http://snapshots.repository.codehaus.org/ > 27-Oct-2007 12:04:15 -- 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-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
[ http://jira.codehaus.org/browse/SUREFIRE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111839 ] Brett Porter commented on SUREFIRE-364: --- the dependency is ok - but there are additional problems after the upgrade. > 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency > --- > > Key: SUREFIRE-364 > URL: http://jira.codehaus.org/browse/SUREFIRE-364 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.4 >Reporter: Matt Read >Assignee: Olivier Lamy >Priority: Blocker > > Previously stable build now reports this: > 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact. > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, > 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT] > 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 from the specified remote repositories: > 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases > (http://maven.catlin.com/maven2-repo/releases), > 27-Oct-2007 12:04:15 Apache Snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 stat-scm-sourceforge > (http://stat-scm.sourceforge.net/maven2), > 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots > (http://maven.catlin.com/maven2-repo/snapshots), > 27-Oct-2007 12:04:15 central (http://repo1.maven.org/maven2), > 27-Oct-2007 12:04:15 codehaus.snapshots > (http://snapshots.repository.codehaus.org), > 27-Oct-2007 12:04:15 apache.snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 Codehaus Snapshots > (http://snapshots.repository.codehaus.org/ > 27-Oct-2007 12:04:15 -- 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-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed SUREFIRE-298.
-
Assignee: Brett Porter
Resolution: Duplicate
Fix Version/s: (was: 2.4)
2.3.1
appears to be a duplicate
> Problem using -javaagent
>
>
> Key: SUREFIRE-298
> URL: http://jira.codehaus.org/browse/SUREFIRE-298
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Windows XP
>Reporter: Bård Dybwad Kristensen
>Assignee: Brett Porter
> Fix For: 2.3.1
>
>
> I try to run the JMockit framework in my tests to do some mocking of static
> classes.
> I supply the argLine arguments as follows (some spaces added to avoid
> smileys):
>
> -javaagent:D : \
> .m2\repository\jmockit\jmockit\0.83\jmockit-0.83.jar
> once
>
> This does not work. The problem is that the Mockit class is not able to find
> neither the class it is suppose to mock nor the class to use as a mock. I
> have made two small classes, Math and MockMath each with one similar method
> and one static String constant. My setup-method in the testclass is as
> follows:
> protected void setUp() throws Exception {
> super.setUp();
> System.out.println(Math.TEST);
> System.out.println(MockMath.TEST);
> Mockit.redefineMethods(Math.class, MockMath.class);
> }
> When I run this, the two System.out.printlns runs Ok, and prints what it
> should, but the Mockit class returns the following error:
> java.lang.RuntimeException: Failed to read class file for
> no.ergo.ec.vaktplan.MockMath
> at mockit.Mockit.readClassFile(Mockit.java:228)
> at mockit.Mockit.collectMockMethods(Mockit.java:191)
> at mockit.Mockit.redefineMethods(Mockit.java:176)
> at mockit.Mockit.redefineMethods(Mockit.java:162)
> at no.ergo.ec.vaktplan.TestMain.setUp(TestMain.java:12)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> Caused by: java.io.IOException: Class not found
> at org.objectweb.asm2.ClassReader.readClass(ClassReader.java:259)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:236)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:246)
> at mockit.Mockit.readClassFile(Mockit.java:225)
> It is not able to find the class, which was ok in the System.out run just
> before.
> If I do a mvn eclipse:eclipse and create an eclipse project, I can run the
> test class without any problems in Eclipse (with exactly tha same VM
> arguments as I use in the pom.xml)
> So I guess it is some issue with which classloader that loads the Mockit
> class when it is supplied as the instrumentation class via the -javaagent
> switch.
> Anybody experience any problems like this using the -javaagent switch?
> Any feedback would be greatly appreciated.
> regards,
> bdk
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administ
[jira] Closed: (MRM-511) Maven integration tests fail when using Archiva as a proxy
[ http://jira.codehaus.org/browse/MRM-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-511. Resolution: Won't Fix Fix Version/s: (was: 1.0-beta-3) the remaining ones turned out to be a problem with the tests themselves. IT 94 was likely fixed by the metadata changes in beta-3 > Maven integration tests fail when using Archiva as a proxy > -- > > Key: MRM-511 > URL: http://jira.codehaus.org/browse/MRM-511 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Brett Porter > > The following ITs pass without the proxy, but fail with it turned on: > 92 > 110 > I have not investigated if this is an Archiva problem or an IT problem yet. -- 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-366) Changes since 26.10.2007
Changes since 26.10.2007
Key: SUREFIRE-366
URL: http://jira.codehaus.org/browse/SUREFIRE-366
Project: Maven Surefire
Issue Type: Bug
Reporter: Alexander Filipchik
Priority: Blocker
I use OpenJPA and Maven in my project. Up to 27.10.2007 all tests have worked
fine.
Then something was changed (surefire or it's dependencies) - and now my simple
CRUD test cause OutOfMemory exception!
For enhancing i use ant call plugin:
Interesting, that now openjpa javaagent doesn't work (but it has worked in
Friday)
org.apache.maven.plugins
maven-surefire-plugin
once
-javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
true
Now it cause -
[INFO] Surefire report directory:
E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
orts
[INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter20526.jar
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/lang/exception/NestableRuntimeException
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
FATAL ERROR in native method: processing of -javaagent failed
at
org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
... 5 more
By the way - time of tests execution rises from one to another:
Running
ru.lanit.ps.registry.service.radministrativelevel.RAdministrativeLevelServiceTe
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.671 sec
Running ru.lanit.ps.registry.service.appeal.AppealServiceTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.749 sec
Running ru.lanit.ps.registry.service.address.AddressServiceTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.155 sec
Running ru.lanit.ps.registry.model.jibx.rpaymenttype.RPaymentTypeBindingTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.093 sec
Running ru.lanit.ps.registry.service.addresstype.RAddressTypeServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.64 sec
Running ru.lanit.ps.registry.service.pspassport.PsPassportTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.795 sec
Running ru.lanit.ps.registry.service.functionary.FunctionaryTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.058 sec
Running ru.lanit.ps.registry.service.paymenttype.PaymentTypeServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.995 sec
Running ru.lanit.ps.registry.model.jibx.roffdoctype.ROffDocTypeBindingTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.434 sec
Running ru.lanit.ps.registry.service.appealterm.AppealTermServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.558 sec
Running
ru.lanit.ps.registry.service.rplacesrequirements.RPlacesRequirementsServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.835 sec
Running
ru.lanit.ps.registry.service.ractivitydirection.RActivityDirectionServiceTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 25.942 sec <<<
FAILURE! - OutOfMem
All tests is very simple CRUD tests
If i configure as following:
org.apache.maven.plugins
maven-surefire-plugin
once
[jira] Updated: (MNGSITE-27) Create Maven Build Host guide.
[ http://jira.codehaus.org/browse/MNGSITE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Morgan updated MNGSITE-27: --- Attachment: maven-build-host-draft3.zip I have added a new section to the maven-build-host document that I have been working on. The new section is called "Restricting ViewVC Access". We always can't be open source :-( The section shows how to use viewvc in an authenticated way using your exsiting subversion authz and basic auth configuration. Download the draft3 zip file. Unzip it. cd in to the folder and use mvn site:run. Read the document at http://localhost:8080. > Create Maven Build Host guide. > -- > > Key: MNGSITE-27 > URL: http://jira.codehaus.org/browse/MNGSITE-27 > Project: Maven Project Web Site > Issue Type: Improvement > Environment: N/A >Reporter: Greg Morgan > Attachments: maven-build-host-draft1.zip, > maven-build-host-draft2.zip, maven-build-host-draft3.zip > > > I am putting Maven together in my head. I am working it out in how to > configure a Maven centric build host. Draft one is very rough. Major areas > of though and configuration have been sketched out. It may not be ready for > publication yet. To use: > Download draft > Crate maven site project. > copy unzipped files in mytestprog/src/site > cd mytestprog > mvn site:run -- 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-366) Changes since 26.10.2007
[
http://jira.codehaus.org/browse/SUREFIRE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111853
]
Brett Porter commented on SUREFIRE-366:
---
Alexander - is it possible you can use a previous version of the surefire
plugin?
eg:
2.2
> Changes since 26.10.2007
>
>
> Key: SUREFIRE-366
> URL: http://jira.codehaus.org/browse/SUREFIRE-366
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Alexander Filipchik
>Assignee: John Casey
>Priority: Blocker
>
> I use OpenJPA and Maven in my project. Up to 27.10.2007 all tests have worked
> fine.
> Then something was changed (surefire or it's dependencies) - and now my
> simple CRUD test cause OutOfMemory exception!
> For enhancing i use ant call plugin:
>
>
> classpathref="maven.compile.classpath"
>
> classname="org.apache.openjpa.ant.PCEnhancerTask"/>
> classpath="${project.basedir}/target/classes">
> dir="${project.basedir}/target/classes">
>
>
>
>
> Interesting, that now openjpa javaagent doesn't work (but it has worked in
> Friday)
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> once
>
> -javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
> true
>
>
> Now it cause -
> [INFO] Surefire report directory:
> E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
> orts
> [INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter20526.jar
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/commons/lang/exception/NestableRuntimeException
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> FATAL ERROR in native method: processing of -javaagent failed
> at
> org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
> ... 5 more
> By the way - time of tests execution rises from one to another:
> Running
> ru.lanit.ps.registry.service.radministrativelevel.RAdministrativeLevelServiceTe
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.671 sec
> Running ru.lanit.ps.registry.service.appeal.AppealServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.749 sec
> Running ru.lanit.ps.registry.service.address.AddressServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.155 sec
> Running ru.lanit.ps.registry.model.jibx.rpaymenttype.RPaymentTypeBindingTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.093 sec
> Running ru.lanit.ps.registry.service.addresstype.RAddressTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.64 sec
> Running ru.lanit.ps.registry.service.pspassport.PsPassportTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.795 sec
> Running ru.lanit.ps.registry.service.functionary.FunctionaryTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.058 sec
> Running ru.lanit.ps.registry.service.paymenttype.PaymentTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.995 sec
> Running ru.lanit.ps.registry.model.jibx.roffdoctype.ROffDocTypeBindingTest
> Tests run: 1, Failures: 0
[jira] Updated: (SUREFIRE-366) Out Of Memory exceptions in 2.4 SNAPSHOTs
[
http://jira.codehaus.org/browse/SUREFIRE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-366:
--
Summary: Out Of Memory exceptions in 2.4 SNAPSHOTs (was: Changes since
26.10.2007)
> Out Of Memory exceptions in 2.4 SNAPSHOTs
> -
>
> Key: SUREFIRE-366
> URL: http://jira.codehaus.org/browse/SUREFIRE-366
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexander Filipchik
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.4
>
>
> I use OpenJPA and Maven in my project. Up to 27.10.2007 all tests have worked
> fine.
> Then something was changed (surefire or it's dependencies) - and now my
> simple CRUD test cause OutOfMemory exception!
> For enhancing i use ant call plugin:
>
>
> classpathref="maven.compile.classpath"
>
> classname="org.apache.openjpa.ant.PCEnhancerTask"/>
> classpath="${project.basedir}/target/classes">
> dir="${project.basedir}/target/classes">
>
>
>
>
> Interesting, that now openjpa javaagent doesn't work (but it has worked in
> Friday)
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> once
>
> -javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
> true
>
>
> Now it cause -
> [INFO] Surefire report directory:
> E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
> orts
> [INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter20526.jar
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/commons/lang/exception/NestableRuntimeException
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> FATAL ERROR in native method: processing of -javaagent failed
> at
> org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
> ... 5 more
> By the way - time of tests execution rises from one to another:
> Running
> ru.lanit.ps.registry.service.radministrativelevel.RAdministrativeLevelServiceTe
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.671 sec
> Running ru.lanit.ps.registry.service.appeal.AppealServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.749 sec
> Running ru.lanit.ps.registry.service.address.AddressServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.155 sec
> Running ru.lanit.ps.registry.model.jibx.rpaymenttype.RPaymentTypeBindingTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.093 sec
> Running ru.lanit.ps.registry.service.addresstype.RAddressTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.64 sec
> Running ru.lanit.ps.registry.service.pspassport.PsPassportTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.795 sec
> Running ru.lanit.ps.registry.service.functionary.FunctionaryTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.058 sec
> Running ru.lanit.ps.registry.service.paymenttype.PaymentTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.995 sec
> Running ru.lanit.ps.registry.model.jibx.rof
[jira] Updated: (SUREFIRE-366) Out Of Memory exceptions in 2.4 SNAPSHOTs
[
http://jira.codehaus.org/browse/SUREFIRE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-366:
--
Affects Version/s: 2.4
Fix Version/s: 2.4
> Out Of Memory exceptions in 2.4 SNAPSHOTs
> -
>
> Key: SUREFIRE-366
> URL: http://jira.codehaus.org/browse/SUREFIRE-366
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexander Filipchik
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.4
>
>
> I use OpenJPA and Maven in my project. Up to 27.10.2007 all tests have worked
> fine.
> Then something was changed (surefire or it's dependencies) - and now my
> simple CRUD test cause OutOfMemory exception!
> For enhancing i use ant call plugin:
>
>
> classpathref="maven.compile.classpath"
>
> classname="org.apache.openjpa.ant.PCEnhancerTask"/>
> classpath="${project.basedir}/target/classes">
> dir="${project.basedir}/target/classes">
>
>
>
>
> Interesting, that now openjpa javaagent doesn't work (but it has worked in
> Friday)
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> once
>
> -javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
> true
>
>
> Now it cause -
> [INFO] Surefire report directory:
> E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
> orts
> [INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter20526.jar
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/commons/lang/exception/NestableRuntimeException
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> FATAL ERROR in native method: processing of -javaagent failed
> at
> org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
> ... 5 more
> By the way - time of tests execution rises from one to another:
> Running
> ru.lanit.ps.registry.service.radministrativelevel.RAdministrativeLevelServiceTe
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.671 sec
> Running ru.lanit.ps.registry.service.appeal.AppealServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.749 sec
> Running ru.lanit.ps.registry.service.address.AddressServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.155 sec
> Running ru.lanit.ps.registry.model.jibx.rpaymenttype.RPaymentTypeBindingTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.093 sec
> Running ru.lanit.ps.registry.service.addresstype.RAddressTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.64 sec
> Running ru.lanit.ps.registry.service.pspassport.PsPassportTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.795 sec
> Running ru.lanit.ps.registry.service.functionary.FunctionaryTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.058 sec
> Running ru.lanit.ps.registry.service.paymenttype.PaymentTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.995 sec
> Running ru.lanit.ps.registry.model.jibx.roffdoctype.ROffDocTypeBindingTest
> T
[jira] Created: (MNG-3262) Problem accessing dependency resource via reflection in maven 2 plugin
Problem accessing dependency resource via reflection in maven 2 plugin
--
Key: MNG-3262
URL: http://jira.codehaus.org/browse/MNG-3262
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.7
Reporter: Gary S. Weaver
I've written a Maven 2 mojo that is having trouble instantiating (via
reflection) a properties resource of dependency that is included as a
"compile"-scope dependency in the project (pom.xml) that is utilizing my plugin.
(Even though I need the plugin to access a dependency that is in "provided"
scope, for now I'm using compile scope since the maven documentation states
that @requiresDependencyResolution doesn't support provided scope.)
Here are the details:
1) I have the following dependency:
---start---
com.atlassian.confluence
confluence
2.6.0
compile
---end---
2) In the pom.xml of the project that utilizes my plugin, the mojo of the
plugin I wrote is configured with the execution:
---start---
get_ConfluenceActionSupport.properties
compile
extractProperties
com.atlassian.confluence.core.ConfluenceActionSupport.properties
target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties
---end---
3) In the Maven 2 mojo it calls the following code (just copied/pasted the
relevant portion):
---start---
// load properties with reflection and save to file
InputStream in = null;
OutputStream out = null;
boolean foundFile = false;
try {
String resource = cleanResourceName(fullyQualifiedProperties);
System.out.println("Getting " + resource);
in = getClass().getResourceAsStream (resource);
if (in != null)
{
Properties result = new Properties();
result.load (in); // Can throw IOException
out = new BufferedOutputStream(new
FileOutputStream(outputPathname));
result.store(out, "");
foundFile = true;
}
}
---end---
When executed, it can't find the properties file in the classloader. As you can
see from the following output, I'm putting the resource string together
correctly as
"/com/atlassian/confluence/core/ConfluenceActionSupport.properties" which if
you interrogate the above confluence dependency, you should be able to find.
---start---
[INFO] [i18nsanity-pt:extractProperties {execution:
get_ConfluenceActionSupport.properties}]
[INFO] Extracting properties file from classpath...
fullyQualifiedProperties=com.atlassian.confluence.core.ConfluenceActionSupport.properties
outputFile=/usr/svn/community/confluence/plugins/americanenglishlanguagepack/trunk/target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties
Getting /com/atlassian/confluence/core/ConfluenceActionSupport.properties
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed properties extraction!
Embedded error: Could not find properties file on classpath:
com.atlassian.confluence.core.ConfluenceActionSupport.properties
---end---
Thanks!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-184) Docbook issues
Docbook issues -- Key: DOXIA-184 URL: http://jira.codehaus.org/browse/DOXIA-184 Project: Maven Doxia Issue Type: Bug Components: Module - Docbook Simple Affects Versions: 1.0-alpha-9 Reporter: Lukas Theussl Fix For: 1.0-beta-1 The identity test currently reveals the following discrepancies: * head is emitted within body instead of before * no sectionTitle elements * figure- and table captions are emitted as sectionTitle5 * no tableRows element * no tableHeaderCell element * anchors are modified -- 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: (DOXIA-160) Book output in doc-book format is not well formed
[ http://jira.codehaus.org/browse/DOXIA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111879 ] Lukas Theussl commented on DOXIA-160: - Dave, we need to keep things apart. The reason for this issue is most likely in the docbook module, see DOXIA-184 for a list of known issues. We have to improve the quality of our Parsers/Sinks before we can expect them to be used seriously in applications like book. ad 1) not sure what you mean with configuration option, from the pom? In that case it should be injected via the doxia-maven-plugin. ad 2) I have no idea what the book() methods are used for, but since it's docbook module specific, they shouldn't do anything vital > Book output in doc-book format is not well formed > - > > Key: DOXIA-160 > URL: http://jira.codehaus.org/browse/DOXIA-160 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer > > I tried using the output from a book in doc-book to run it through a > postprocesing step with docbook and found that it barfed on the source > generated by doxia. Not surprising when you consider that it is not well > formed, e.g. it has two <<>> headers in it, and no root element: > +--- > > BarThis is bar > > > > SpamThis is spam > > > > +--- > When I changed it to this it worked better > +--- > "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd";> > > BarThis is bar > > > SpamThis is spam > > > > +--- -- 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: (DOXIA-166) Book output ignores book, chapter and section titles
[ http://jira.codehaus.org/browse/DOXIA-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111880 ] Lukas Theussl commented on DOXIA-166: - Can you attach a small test case? > Book output ignores book, chapter and section titles > > > Key: DOXIA-166 > URL: http://jira.codehaus.org/browse/DOXIA-166 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer > > Book output ignores book, chapter and section titles (for xhtml and doc-book > at least). For PDF the chapter titles are used but not the book or sections. > Maybe this is intentional (but then what are they there for in the book > model)? At least there should be some configuration to switch on/off titles? -- 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-3262) Problem accessing dependency resource via reflection in maven 2 plugin
[
http://jira.codehaus.org/browse/MNG-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary S. Weaver updated MNG-3262:
Attachment: trunk-exampleproject.tgz
trunk-i18nsanity-pt.tgz
Attached two maven2 projects and source:
* trunk-i18nsanity-pt.tgz - the plugin project
(net.sf.i18nsanity.pt.maven.plugin.PropertiesExtractorMojo is the plugin mojo
in question having this trouble)
* trunk-exampleproject.tgz - the project using the plugin that exhibits the
issue
Thanks for any help you can provide in figuring this out.
> Problem accessing dependency resource via reflection in maven 2 plugin
> --
>
> Key: MNG-3262
> URL: http://jira.codehaus.org/browse/MNG-3262
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.7
>Reporter: Gary S. Weaver
> Attachments: trunk-exampleproject.tgz, trunk-i18nsanity-pt.tgz
>
>
> I've written a Maven 2 mojo that is having trouble instantiating (via
> reflection) a properties resource of dependency that is included as a
> "compile"-scope dependency in the project (pom.xml) that is utilizing my
> plugin.
> (Even though I need the plugin to access a dependency that is in "provided"
> scope, for now I'm using compile scope since the maven documentation states
> that @requiresDependencyResolution doesn't support provided scope.)
> Here are the details:
> 1) I have the following dependency:
> ---start---
>
>
> com.atlassian.confluence
> confluence
> 2.6.0
> compile
>
>
> ---end---
> 2) In the pom.xml of the project that utilizes my plugin, the mojo of the
> plugin I wrote is configured with the execution:
> ---start---
>
> get_ConfluenceActionSupport.properties
> compile
>
> extractProperties
>
>
>
> com.atlassian.confluence.core.ConfluenceActionSupport.properties
>
> target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties
>
>
> ---end---
> 3) In the Maven 2 mojo it calls the following code (just copied/pasted the
> relevant portion):
> ---start---
> // load properties with reflection and save to file
> InputStream in = null;
> OutputStream out = null;
> boolean foundFile = false;
> try {
> String resource = cleanResourceName(fullyQualifiedProperties);
> System.out.println("Getting " + resource);
> in = getClass().getResourceAsStream (resource);
> if (in != null)
> {
> Properties result = new Properties();
> result.load (in); // Can throw IOException
> out = new BufferedOutputStream(new
> FileOutputStream(outputPathname));
> result.store(out, "");
> foundFile = true;
> }
> }
> ---end---
> When executed, it can't find the properties file in the classloader. As you
> can see from the following output, I'm putting the resource string together
> correctly as
> "/com/atlassian/confluence/core/ConfluenceActionSupport.properties" which if
> you interrogate the above confluence dependency, you should be able to find.
> ---start---
> [INFO] [i18nsanity-pt:extractProperties {execution:
> get_ConfluenceActionSupport.properties}]
> [INFO] Extracting properties file from classpath...
> fullyQualifiedProperties=com.atlassian.confluence.core.ConfluenceActionSupport.properties
>
> outputFile=/usr/svn/community/confluence/plugins/americanenglishlanguagepack/trunk/target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties
> Getting /com/atlassian/confluence/core/ConfluenceActionSupport.properties
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed properties extraction!
> Embedded error: Could not find properties file on classpath:
> com.atlassian.confluence.core.ConfluenceActionSupport.properties
> ---end---
> Thanks!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-160) Book output in doc-book format is not well formed
[ http://jira.codehaus.org/browse/DOXIA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111885 ] Dave Syer commented on DOXIA-160: - > The reason for this issue is most likely in the docbook module But DocbookRenderer is in the doxia-book project (not the Docbook module), so I think this issue is in the right place unless the renderers get factored out. > ad 1) not sure what you mean with configuration option, from the pom? In > that case it should be injected via the doxia-maven-plugin. How? As far as I can see, the doxia-maven-plugin only has configuration options for the book declaration, not for the renderers. I have tried asking this question in 4 different ways, now, in 4 different forums. If you know how to configure the DocbookRenderer from the plugin please show an example. > ad 2) I have no idea what the book() methods are used for, but since it's > docbook > module specific, they shouldn't do anything vital They are internal to DocbookRenderer (as I already said). Doesn't mean they don't do anything vital (otherwise why would they exist?). It was just a hint - the book() method is called in the wrong place. > Book output in doc-book format is not well formed > - > > Key: DOXIA-160 > URL: http://jira.codehaus.org/browse/DOXIA-160 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer > > I tried using the output from a book in doc-book to run it through a > postprocesing step with docbook and found that it barfed on the source > generated by doxia. Not surprising when you consider that it is not well > formed, e.g. it has two <<>> headers in it, and no root element: > +--- > > BarThis is bar > > > > SpamThis is spam > > > > +--- > When I changed it to this it worked better > +--- > "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd";> > > BarThis is bar > > > SpamThis is spam > > > > +--- -- 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: (DOXIA-166) Book output ignores book, chapter and section titles
[ http://jira.codehaus.org/browse/DOXIA-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-166: Attachment: docbook-test-patch.txt Patch to test case that demonstrates briefly the problem (docbook-test-patch). > Book output ignores book, chapter and section titles > > > Key: DOXIA-166 > URL: http://jira.codehaus.org/browse/DOXIA-166 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer > Attachments: docbook-test-patch.txt > > > Book output ignores book, chapter and section titles (for xhtml and doc-book > at least). For PDF the chapter titles are used but not the book or sections. > Maybe this is intentional (but then what are they there for in the book > model)? At least there should be some configuration to switch on/off titles? -- 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-357) Java language constraint is a poor criteria for surefire report generation
[ http://jira.codehaus.org/browse/SUREFIRE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111890 ] David Cardon commented on SUREFIRE-357: --- I'd be happy to, but I'm not exactly sure what the correct formatting is. Wouldn't I just copy and paste what I've given above into the patch file? > Java language constraint is a poor criteria for surefire report generation > -- > > Key: SUREFIRE-357 > URL: http://jira.codehaus.org/browse/SUREFIRE-357 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.3 >Reporter: David Cardon > Fix For: 2.3.1 > > > With the expansion of maven as a project management tool for other (non-Java) > languages, the 'canGenerateReport' function in SurefireReportMojo.java limits > the scope of the report plugin to only Java projects. This limitation > prevents the use of surefire xml as a standard format for test reports. > Perhaps a more relevant approach to the function would be to test for the > existence of the 'surefire-reports' folder and relevant files within that > folder. -- 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: (MEV-552) javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.jar is not correct
[ http://jira.codehaus.org/browse/MEV-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111893 ] Dan Tran commented on MEV-552: -- welcome to the club see MEV-498 > javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.jar is not correct > - > > Key: MEV-552 > URL: http://jira.codehaus.org/browse/MEV-552 > Project: Maven Evangelism > Issue Type: Bug > Components: Problem with Jar >Reporter: Daniel Kulp > > The jaxws-api jar is not the correct one. It is missing class files (like > MTOM.class) that exist in the correct version available at: > http://download.java.net/maven/1/javax.xml.ws/jars/ > (there is also a sources jar there that would be nice) > Our builds are failing if they have the central version already downloaded. > The two should definitely be in sync. -- 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-357) Java language constraint is a poor criteria for surefire report generation
[ http://jira.codehaus.org/browse/SUREFIRE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Cardon updated SUREFIRE-357: -- Attachment: patch.txt De-tabified version of the patch. > Java language constraint is a poor criteria for surefire report generation > -- > > Key: SUREFIRE-357 > URL: http://jira.codehaus.org/browse/SUREFIRE-357 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.3 >Reporter: David Cardon > Fix For: 2.3.1 > > Attachments: patch.txt > > > With the expansion of maven as a project management tool for other (non-Java) > languages, the 'canGenerateReport' function in SurefireReportMojo.java limits > the scope of the report plugin to only Java projects. This limitation > prevents the use of surefire xml as a standard format for test reports. > Perhaps a more relevant approach to the function would be to test for the > existence of the 'surefire-reports' folder and relevant files within that > folder. -- 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-552) javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.jar is not correct
[ http://jira.codehaus.org/browse/MEV-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-552. -- Assignee: Carlos Sanchez Resolution: Duplicate > javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.jar is not correct > - > > Key: MEV-552 > URL: http://jira.codehaus.org/browse/MEV-552 > Project: Maven Evangelism > Issue Type: Bug > Components: Problem with Jar >Reporter: Daniel Kulp >Assignee: Carlos Sanchez > > The jaxws-api jar is not the correct one. It is missing class files (like > MTOM.class) that exist in the correct version available at: > http://download.java.net/maven/1/javax.xml.ws/jars/ > (there is also a sources jar there that would be nice) > Our builds are failing if they have the central version already downloaded. > The two should definitely be in sync. -- 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-552) javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.jar is not correct
javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.jar is not correct - Key: MEV-552 URL: http://jira.codehaus.org/browse/MEV-552 Project: Maven Evangelism Issue Type: Bug Components: Problem with Jar Reporter: Daniel Kulp The jaxws-api jar is not the correct one. It is missing class files (like MTOM.class) that exist in the correct version available at: http://download.java.net/maven/1/javax.xml.ws/jars/ (there is also a sources jar there that would be nice) Our builds are failing if they have the central version already downloaded. The two should definitely be in sync. -- 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-1786) Upload fixed version of jaxws-api
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111900 ] Carlos Sanchez commented on MAVENUPLOAD-1786: - version still says 2.1 you have to remove repositories section are all dependencies already in central? > Upload fixed version of jaxws-api > - > > Key: MAVENUPLOAD-1786 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1786 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Kulp > > The 2.1 version in central is bogus. > The bundle jar above creates a 2.1-1 version that provides a correct 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: (MAVENUPLOAD-1785) Upload Joda-Time 1.5 (with -sources and -javadoc jars)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1785. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Joda-Time 1.5 (with -sources and -javadoc jars) > -- > > Key: MAVENUPLOAD-1785 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1785 > Project: maven-upload-requests > Issue Type: Task >Reporter: Stephen Colebourne >Assignee: Carlos Sanchez > > http://joda-time.sourceforge.net/joda-time-1.5-bundle.jar > > http://joda-time.sourceforge.net > http://joda-time.sourceforge.net/team-list.html > > Please upload joda-time 1.5 > *** This bundle also contains joda-time-1.5-sources.jar & > joda-time-1.5-javadoc.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: (MAVENUPLOAD-1784) Upload Unitils 1.0 rc 5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1784. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Unitils 1.0 rc 5 > --- > > Key: MAVENUPLOAD-1784 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1784 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tim Ducheyne >Assignee: Carlos Sanchez > > Could you please upload the unitils-1.0-rc-5 bundle? > Thank you, > Tim -- 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: (MAVENUPLOAD-1783) please upload jsdoc 1.3.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1783. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload jsdoc 1.3.3 > - > > Key: MAVENUPLOAD-1783 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1783 > Project: maven-upload-requests > Issue Type: Wish >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > Jsdoc is a documentation tool for javascript, inspired by javadoc. > This is a resources jar (no classes). -- 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: (MAVENUPLOAD-1779) please upload JsUnit 2.1.4 test runner
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1779. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload JsUnit 2.1.4 test runner > -- > > Key: MAVENUPLOAD-1779 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1779 > Project: maven-upload-requests > Issue Type: Wish >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > jsunit is a port of junit to javascript. > the test runner is the client part of the jsunit framework. This bundle is a > javascript archive of this runner, packaged as a jar for the (mojo) > javascript plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-498) javax.xml.ws:jaxws-api:2.1 is bad
[ http://jira.codehaus.org/browse/MEV-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111898 ] Daniel Kulp commented on MEV-498: - Created upload request for a 2.1-1 version. http://jira.codehaus.org/browse/MAVENUPLOAD-1786 > javax.xml.ws:jaxws-api:2.1 is bad > - > > Key: MEV-498 > URL: http://jira.codehaus.org/browse/MEV-498 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Dan Tran >Assignee: Carlos Sanchez > > Sun just released jaxws 2.1 and the jaxws-api available at repo1.maven.org is > not the same with the Sun's one (both pom and the jar ) > I am working jaxws-maven-plugin and the generate code crash due to missing > interfaces > We can either sync the sun version over, or remove it from repo1 to remove > confusion > Here is the link to java.net repo > https://maven-repository.dev.java.net/nonav/repository/com.sun.xml.ws/ -- 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-550) Missing castor version or incorrect groovy/openejb dependencies
[ http://jira.codehaus.org/browse/MEV-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-550. -- Assignee: Carlos Sanchez Resolution: Duplicate being fixed in MEV-549 > Missing castor version or incorrect groovy/openejb dependencies > --- > > Key: MEV-550 > URL: http://jira.codehaus.org/browse/MEV-550 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Nicolas Kyriazopoulos-Panagiotopoulos >Assignee: Carlos Sanchez > > We have a problem of dependencies: > [INFO] Path to dependency: > [INFO]1) [OUR PROJECT] > [INFO]2) groovy:groovy:jar:1.0 > [INFO]3) openejb:openejb-loader:jar:1.0 > [INFO]4) openejb:openejb-core:jar:1.0 > [INFO]5) castor:castor:jar:0.9.9.0-pre > The problem is new (we are using groovy for almost a year) . It seems that > someone very recently erased this version of the castor jar and grovy cannot > work without it (unless the problem is caused by newly changed poms). Finding > this particular version of castor on the web seems very difficult. > This is VERY URGENT: there is no newer stable version of groovy so we have > no alternative, and the problem makes new application deployments impossible > (unless we do kung fu with the downloaded poms to refer to other versions, > which is impractical and dangerous). > Thanks in advance! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1786) Upload fixed version of jaxws-api
Upload fixed version of jaxws-api - Key: MAVENUPLOAD-1786 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1786 Project: maven-upload-requests Issue Type: Task Reporter: Daniel Kulp The 2.1 version in central is bogus. The bundle jar above creates a 2.1-1 version that provides a correct 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] Commented: (MEV-549) Strange Groovy entries in the repository
[ http://jira.codehaus.org/browse/MEV-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111896 ] Carlos Sanchez commented on MEV-549: removed maven/groovy/jars/-0.2.jar The maven/ folder just redirects to maven2/ so I'm looking there and there are 1.1-beta-1 without jar 1.1-BETA-1 with jar which one should be changed? does the jar need to be copied ? > Strange Groovy entries in the repository > > > Key: MEV-549 > URL: http://jira.codehaus.org/browse/MEV-549 > Project: Maven Evangelism > Issue Type: Task > Components: Relocation >Reporter: Paul King > > Hi, I am trying to track down why some spurious entries are showing up for > Groovy. Please let me know if this is not the appropriate forum. > Groovy used to publish into the maven1 repo and there was some magic in place > that "republished" artifacts into the maven 2 repo. > Groovy now publishes into the maven2 repo and some magic "republishes" the > jars back into repo1. > Unfortunately, the old magic still seems to be in place and a spurious entry > appears (under the old groupId) in the maven 2 repo. > Does anyone know how to turn off the old magic? I guess then we need to clean > up the spurious artifacts but I can submit separate issue(s) for that if > needed. > Here is my understanding of the trail: > (1) Project publishes to http://repository.codehaus.org/org/codehaus/groovy/ > (2) Sync happens to copy artifacts to > http://repo1.maven.org/maven2/org/codehaus/groovy/ > (3) Magic happens here to copy artifacts back to maven 1 land ending up at > http://repo1.maven.org/maven/groovy/jars/ > This is actually broken in that it should be being copied to > http://repo1.maven.org/maven/org.codehaus.groovy/jars/ > and also the copying of the poms to http://repo1.maven.org/maven/groovy/poms > (which of course should also > be changed to http://repo1.maven.org/maven/org.codehaus.groovy/poms) has > stopped working at some point. > (4) Additional magic which should be turned off now occurs at this point and > copies the artifacts back to the maven 2 > repo. An example of this from 1.1-rc-1 (12 Oct 2007) can be found here: > http://repo1.maven.org/maven2/groovy/groovy-all/1.1-rc-1/ > This is in the wrong place given the groupId and doesn't contain a POM. > I am trying to track this down so I can request that step (4) be turned off. > Thanks, Paul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-357) Java language constraint is a poor criteria for surefire report generation
[ http://jira.codehaus.org/browse/SUREFIRE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111891 ] Brett Porter commented on SUREFIRE-357: --- yes, I was referring to avoiding the tabs though and using the 4 character indents :) > Java language constraint is a poor criteria for surefire report generation > -- > > Key: SUREFIRE-357 > URL: http://jira.codehaus.org/browse/SUREFIRE-357 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.3 >Reporter: David Cardon > Fix For: 2.3.1 > > > With the expansion of maven as a project management tool for other (non-Java) > languages, the 'canGenerateReport' function in SurefireReportMojo.java limits > the scope of the report plugin to only Java projects. This limitation > prevents the use of surefire xml as a standard format for test reports. > Perhaps a more relevant approach to the function would be to test for the > existence of the 'surefire-reports' folder and relevant files within that > folder. -- 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: (MAVENUPLOAD-1770) please upload Jetty 5.1.10
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1770. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload Jetty 5.1.10 > -- > > Key: MAVENUPLOAD-1770 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1770 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > jetty 5 is required by jsUnit, and no version is available on public repo > (for a strange reason, only 4.x and 6.x are deployed). > Thins bundle has been created from the distribution available at > ftp://ftp.mortbay.org/pub/jetty-5 -- 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: (MAVENUPLOAD-1777) please upload Log4Javascript
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1777. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload Log4Javascript > > > Key: MAVENUPLOAD-1777 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1777 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > Log4Javascript is a js librarie comparable to log4j in javascript development. > This bundle contains a javascript archive, created for the javascript maven > tools currently in mojo sandbox. -- 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-1786) Upload fixed version of jaxws-api
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111908 ] Daniel Kulp commented on MAVENUPLOAD-1786: -- Uploaded a new version with stuff fixed. Had to change to geronimo-specs version of jsr181 as I didn't want to try and figure out if BEA's license allows an upload or not. That said, the requirement is bogus as there are a LOT of artifacts synced to central that rely on stuff outside of central and thus have the repository entries. (tons of stuff that rely on incubator artifacts for example) > Upload fixed version of jaxws-api > - > > Key: MAVENUPLOAD-1786 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1786 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Kulp > > The 2.1 version in central is bogus. > The bundle jar above creates a 2.1-1 version that provides a correct 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] Commented: (MAVENUPLOAD-1786) Upload fixed version of jaxws-api
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111912 ] Dan Tran commented on MAVENUPLOAD-1786: --- please have say something about this special version 2.1.1 in the pom. Other wise, use will keep asking why. > Upload fixed version of jaxws-api > - > > Key: MAVENUPLOAD-1786 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1786 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Kulp > > The 2.1 version in central is bogus. > The bundle jar above creates a 2.1-1 version that provides a correct 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] Commented: (MAVENUPLOAD-1786) Upload fixed version of jaxws-api
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111914 ] Daniel Kulp commented on MAVENUPLOAD-1786: -- Done.Added a comment to the pom (with a link to MEV-498). > Upload fixed version of jaxws-api > - > > Key: MAVENUPLOAD-1786 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1786 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Kulp > > The 2.1 version in central is bogus. > The bundle jar above creates a 2.1-1 version that provides a correct 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] Commented: (MRAR-19) projects with packaging rar don't compile
[
http://jira.codehaus.org/browse/MRAR-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111917
]
Dennis Lundberg commented on MRAR-19:
-
I do not know the answer to this question.
Please ask about it on the users list.
> projects with packaging rar don't compile
> -
>
> Key: MRAR-19
> URL: http://jira.codehaus.org/browse/MRAR-19
> Project: Maven 2.x Rar Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: windows xp professional
>Reporter: Salvio Sergi
>Priority: Trivial
>
> In documentation (sub) projects it may be very useful to pack the generated
> site to an archive. I tried using rar and found this bug.
> Steps to reproduce
> * create a new (empty) project with the following pom.xml
> {code}
>
>
> 4.0.0
> sample
> sample
> rar
> 0.0.1
>
> {code}
> * running {{noformat}} mvn package I get the following error
> {noformat}
> [WARNING] Connector deployment descriptor:
> C:\projects\sample\target\sample-0.0.1\META-INF\ra.xml does not exist.
> [INFO] Could not find manifest file:
> C:\projects\sample\src\main\rar\META-INF\MANIFEST.MF - Generating one
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling RAR
> Embedded error: C:\projects\sample\target\sample-0.0.1 isn't a directory.
> {noformat}
> I would expect this to work similarly to the jar packaging type...
> *Workaround*: manually create a directory /target/sample-0.0.1 before running
> mvn package
--
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: (MRAR-19) projects with packaging rar don't compile
[
http://jira.codehaus.org/browse/MRAR-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MRAR-19.
---
Resolution: Won't Fix
> projects with packaging rar don't compile
> -
>
> Key: MRAR-19
> URL: http://jira.codehaus.org/browse/MRAR-19
> Project: Maven 2.x Rar Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: windows xp professional
>Reporter: Salvio Sergi
>Priority: Trivial
>
> In documentation (sub) projects it may be very useful to pack the generated
> site to an archive. I tried using rar and found this bug.
> Steps to reproduce
> * create a new (empty) project with the following pom.xml
> {code}
>
>
> 4.0.0
> sample
> sample
> rar
> 0.0.1
>
> {code}
> * running {{noformat}} mvn package I get the following error
> {noformat}
> [WARNING] Connector deployment descriptor:
> C:\projects\sample\target\sample-0.0.1\META-INF\ra.xml does not exist.
> [INFO] Could not find manifest file:
> C:\projects\sample\src\main\rar\META-INF\MANIFEST.MF - Generating one
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling RAR
> Embedded error: C:\projects\sample\target\sample-0.0.1 isn't a directory.
> {noformat}
> I would expect this to work similarly to the jar packaging type...
> *Workaround*: manually create a directory /target/sample-0.0.1 before running
> mvn package
--
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: (DOXIA-171) Confluence "quote" macro not recognised
[
http://jira.codehaus.org/browse/DOXIA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111922
]
Lukas Theussl commented on DOXIA-171:
-
Patch applied in svn, thanks!
For the {quote, tip, note, info} macros, I agree with your suggestion but how
would you tell them apart? Doxia doesn't handle in-line figures, so we can't
use the icons. But I don't think it's a big deal, I think you can go ahead with
it.
I don't see why i18n should be an issue. For a different language, you have to
provide a different source document anyway.
> Confluence "quote" macro not recognised
> ---
>
> Key: DOXIA-171
> URL: http://jira.codehaus.org/browse/DOXIA-171
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.0-alpha-8
>Reporter: Dave Syer
> Attachments: code-patch.txt, mylyn-context.zip
>
>
> The "quote" and "code" macros in Confluence should do something worthwhile in
> Doxia. They seem to only generate errors.
--
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: (MEV-549) Strange Groovy entries in the repository
[ http://jira.codehaus.org/browse/MEV-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111926 ] Paul King commented on MEV-549: --- 1.1-beta-1 was a change in decision about case in naming the release but 1.1-BETA-1 was already pushed to the repo so for repo stability we should just make both available. The jar can just be copied and renamed. Obviously the BETA-1 pom should have the uppercase artifactId inside it. Re: the comment in MEV-550: http://repo1.maven.org/maven2/groovy/groovy-all/1.0/groovy-all-1.0.pom still contains the unchanged reference to openejb http://dist.codehaus.org/groovy/poms/groovy-all-1.0.pom contains the exclusion of the problem castor dependency and points to the non-snapshot dependency. If that could be copied across, that would be great. Thanks, Paul. > Strange Groovy entries in the repository > > > Key: MEV-549 > URL: http://jira.codehaus.org/browse/MEV-549 > Project: Maven Evangelism > Issue Type: Task > Components: Relocation >Reporter: Paul King > > Hi, I am trying to track down why some spurious entries are showing up for > Groovy. Please let me know if this is not the appropriate forum. > Groovy used to publish into the maven1 repo and there was some magic in place > that "republished" artifacts into the maven 2 repo. > Groovy now publishes into the maven2 repo and some magic "republishes" the > jars back into repo1. > Unfortunately, the old magic still seems to be in place and a spurious entry > appears (under the old groupId) in the maven 2 repo. > Does anyone know how to turn off the old magic? I guess then we need to clean > up the spurious artifacts but I can submit separate issue(s) for that if > needed. > Here is my understanding of the trail: > (1) Project publishes to http://repository.codehaus.org/org/codehaus/groovy/ > (2) Sync happens to copy artifacts to > http://repo1.maven.org/maven2/org/codehaus/groovy/ > (3) Magic happens here to copy artifacts back to maven 1 land ending up at > http://repo1.maven.org/maven/groovy/jars/ > This is actually broken in that it should be being copied to > http://repo1.maven.org/maven/org.codehaus.groovy/jars/ > and also the copying of the poms to http://repo1.maven.org/maven/groovy/poms > (which of course should also > be changed to http://repo1.maven.org/maven/org.codehaus.groovy/poms) has > stopped working at some point. > (4) Additional magic which should be turned off now occurs at this point and > copies the artifacts back to the maven 2 > repo. An example of this from 1.1-rc-1 (12 Oct 2007) can be found here: > http://repo1.maven.org/maven2/groovy/groovy-all/1.1-rc-1/ > This is in the wrong place given the groupId and doesn't contain a POM. > I am trying to track this down so I can request that step (4) be turned off. > Thanks, Paul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-171) Confluence "quote" macro not recognised
[
http://jira.codehaus.org/browse/DOXIA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111927
]
Dave Syer commented on DOXIA-171:
-
The issue is that
{code}
{note}
A note in textile wiki.
{note}
{code}
would be rendered as
{code}
Note:A note in textile wiki.
{code}
So the text "Note:" is provided by Doxia - not in the language of the main
document. How can we know what the locle / appropriate bundle is at runtime?
> Confluence "quote" macro not recognised
> ---
>
> Key: DOXIA-171
> URL: http://jira.codehaus.org/browse/DOXIA-171
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.0-alpha-8
>Reporter: Dave Syer
> Attachments: code-patch.txt, mylyn-context.zip
>
>
> The "quote" and "code" macros in Confluence should do something worthwhile in
> Doxia. They seem to only generate errors.
--
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: (NMAVEN-89) Update documentation for Visual Studio
Update documentation for Visual Studio -- Key: NMAVEN-89 URL: http://jira.codehaus.org/browse/NMAVEN-89 Project: NMaven Issue Type: Improvement Reporter: Wendy Smoak Priority: Minor Some changes need to be made on this page: http://incubator.apache.org/nmaven/ide/visual-studio.html The Sample Generated Addin file should be updated to show the new location of the dll files in the 'gac' directory (they are no longer in the default Maven local repository.) Under 'Debugging' it should explain that the c:\tmp directory must exist before using the suggested 'devenv...' command, or that you should use an existing directory. I found that if the directory did not exist, no log file would be created. -- 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: (NMAVEN-90) Repository plugin export-rdf should log more info
Repository plugin export-rdf should log more info - Key: NMAVEN-90 URL: http://jira.codehaus.org/browse/NMAVEN-90 Project: NMaven Issue Type: Improvement Reporter: Wendy Smoak The 'export-rdf' goal should print the location of the rdf-repository-export.xml file. For example, the output of 'mvn install' shows exactly where to find the artifact that was created: [INFO] Installing c:\temp\myproject\target\myproject-1.0-SNAPSHOT.jar to C:\Documents and Settings\wsmoak\.m2\repository\com\aexp\examples\myproject\1.0-SNAPSHOT\myproject-1.0-SNAPSHOT.jar When the "mvn org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf " command completed successfully, I looked in the target directory for whatever it might have created. This page explains that the file lands in ~/.m2/uac/rdfRepository/rdf-repository-export.xml http://incubator.apache.org/nmaven/rdf-repository.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue
[ http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111929 ] Alfie Kirkpatrick commented on MNG-2277: I checked out this evening from https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x (identifies itself as version 2.0.8-SNAPSHOT) and I'm still seeing an error when running mvn generate-sources on my simple test project where child1 depends on child2 (with single parent project that includes both child1 and child2). > aggregating plugins in submodules of the reactor return all projects causing > a chicken/egg issue > > > Key: MNG-2277 > URL: http://jira.codehaus.org/browse/MNG-2277 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle, Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Brett Porter >Assignee: Brian Fox > Fix For: 2.0.8 > > > eg, assembly:attached > when this is put in maven-core, and a build is run from the root project with > a clean repo, it fails, as the original project sorter doesn't consider the > dependencies, building plugin-tools after maven-core. > However, hitting the aggregator when building maven-core then tries to > resolve all of the projects as dependencies. -- 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: (NMAVEN-91) Repository plugin export-rdf goal only works in a directory containing a pom
Repository plugin export-rdf goal only works in a directory containing a pom
Key: NMAVEN-91
URL: http://jira.codehaus.org/browse/NMAVEN-91
Project: NMaven
Issue Type: Bug
Reporter: Wendy Smoak
The "mvn org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf"
command explained on [1] apparently only works in a directory containing a
pom.xml file.
{noformat}
C:\Temp>mvn org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf
[INFO] -
---
[INFO] Building Maven Default Project
[INFO]task-segment:
[org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf]
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cannot execute mojo: export-rdf. 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: Mon Oct 29 14:39:38 MST 2007
[INFO] Final Memory: 1M/4M
[INFO]
{noformat}
I'm having trouble installing the Visual Studio addin. I'm not working with "a
project".
If this can't be changed, the documentation should be updated to explain the
issue and provide a simple pom.xml file that can be saved in the current
directory to allow the command to work.
[1] http://incubator.apache.org/nmaven/rdf-repository.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NMAVEN-91) Repository plugin export-rdf goal only works in a directory containing a pom
[
http://jira.codehaus.org/browse/NMAVEN-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111931
]
Shane Isbell commented on NMAVEN-91:
This is a bug/limitation with Maven, not NMaven. Maven plugins require a pom to
execute.
> Repository plugin export-rdf goal only works in a directory containing a pom
>
>
> Key: NMAVEN-91
> URL: http://jira.codehaus.org/browse/NMAVEN-91
> Project: NMaven
> Issue Type: Bug
>Reporter: Wendy Smoak
>
> The "mvn org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf"
> command explained on [1] apparently only works in a directory containing a
> pom.xml file.
> {noformat}
> C:\Temp>mvn org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf
> [INFO]
> -
> ---
> [INFO] Building Maven Default Project
> [INFO]task-segment:
> [org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf]
> [INFO]
>
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Cannot execute mojo: export-rdf. 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: Mon Oct 29 14:39:38 MST 2007
> [INFO] Final Memory: 1M/4M
> [INFO]
>
> {noformat}
> I'm having trouble installing the Visual Studio addin. I'm not working with
> "a project".
> If this can't be changed, the documentation should be updated to explain the
> issue and provide a simple pom.xml file that can be saved in the current
> directory to allow the command to work.
> [1] http://incubator.apache.org/nmaven/rdf-repository.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Deleted: (NMAVEN-90) Repository plugin export-rdf should log more info
[ http://jira.codehaus.org/browse/NMAVEN-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak deleted NMAVEN-90: -- > Repository plugin export-rdf should log more info > - > > Key: NMAVEN-90 > URL: http://jira.codehaus.org/browse/NMAVEN-90 > Project: NMaven > Issue Type: Improvement >Reporter: Wendy Smoak > > The 'export-rdf' goal should print the location of the > rdf-repository-export.xml file. > For example, the output of 'mvn install' shows exactly where to find the > artifact that was created: > [INFO] Installing c:\temp\myproject\target\myproject-1.0-SNAPSHOT.jar to > C:\Documents and > Settings\wsmoak\.m2\repository\com\aexp\examples\myproject\1.0-SNAPSHOT\myproject-1.0-SNAPSHOT.jar > When the "mvn > org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf " command > completed successfully, I looked in the target directory for whatever it > might have created. > This page explains that the file lands in > ~/.m2/uac/rdfRepository/rdf-repository-export.xml > http://incubator.apache.org/nmaven/rdf-repository.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3263) packaging type rar should not be allowed
packaging type rar should not be allowed - Key: MNG-3263 URL: http://jira.codehaus.org/browse/MNG-3263 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.7 Reporter: Salvio Sergi Priority: Trivial rar is a plugin and not a packaging type according to the first comment posted to this bug: http://jira.codehaus.org/browse/MRAR-19 -- 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: (DOXIA-171) Confluence "quote" macro not recognised
[
http://jira.codehaus.org/browse/DOXIA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111932
]
Lukas Theussl commented on DOXIA-171:
-
According to
http://confluence.atlassian.com/renderer/notationhelp.action?section=advanced
it is
{noformat}
{note:title=Be Careful}
The body of the note here..
{note}
{noformat}
so the title is provided in the source document. Or maybe I'm mixing something
up here?
> Confluence "quote" macro not recognised
> ---
>
> Key: DOXIA-171
> URL: http://jira.codehaus.org/browse/DOXIA-171
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.0-alpha-8
>Reporter: Dave Syer
> Attachments: code-patch.txt, mylyn-context.zip
>
>
> The "quote" and "code" macros in Confluence should do something worthwhile in
> Doxia. They seem to only generate errors.
--
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-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue
[ http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111934 ] Brian Fox commented on MNG-2277: Alfie, can you attach your sample project? > aggregating plugins in submodules of the reactor return all projects causing > a chicken/egg issue > > > Key: MNG-2277 > URL: http://jira.codehaus.org/browse/MNG-2277 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle, Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Brett Porter >Assignee: Brian Fox > Fix For: 2.0.8 > > > eg, assembly:attached > when this is put in maven-core, and a build is run from the root project with > a clean repo, it fails, as the original project sorter doesn't consider the > dependencies, building plugin-tools after maven-core. > However, hitting the aggregator when building maven-core then tries to > resolve all of the projects as dependencies. -- 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-3083) Ant needs to be upgraded to 1.7.0
[
http://jira.codehaus.org/browse/MNG-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3083.
-
Resolution: Won't Fix
can't think of what you want fixed - please reopen (or move to appropriate
project) if you are referring to one of the following:
- the maven tasks for ant (MANTTASKS)
- the maven ant plugin (MANT)
- the maven antrun plugin (you already filed that)
- the maven ant plugin tools (MPLUGIN)
> Ant needs to be upgraded to 1.7.0
> -
>
> Key: MNG-3083
> URL: http://jira.codehaus.org/browse/MNG-3083
> Project: Maven 2
> Issue Type: Bug
> Components: Ant tasks
>Reporter: Brian Topping
>Priority: Critical
>
> Moving an Ant 1.7.0 build to Maven is currently impossible because there are
> dependencies on 1.6.5 all around Maven and the groupId of Ant has changed
> from {{ant}} to {{org.apache.ant}}. This precludes upgrading the dependency
> through graph distance override.
> In order to fix this, dependencies on Ant 1.6.5 need to be upgraded to 1.7.0.
> Fixing MANTRUN-68 would be nice, but is not as big a deal because it can be
> rebuilt locally.
--
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-3153) Maven2 hangs at [INFO] Retrieving previous metadata from...
[ http://jira.codehaus.org/browse/MNG-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3153. - Resolution: Won't Fix please post this to the users list - you will need to provide the distributionManagement repository URL you are deploying to. It looks like scpexe, which may just be prompting for input. If you are able to narrow it down to something reproducible, feel free to reopen the issue. > Maven2 hangs at [INFO] Retrieving previous metadata from... > --- > > Key: MNG-3153 > URL: http://jira.codehaus.org/browse/MNG-3153 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.4, 2.0.7 >Reporter: Dominik Doll >Priority: Critical > > Every time when I upload a snapshot or a release version of my project to my > company repository it can occure that m2 hangs on one of the > [INFO] Retrieving previous metadata from SomeInternalRepositoryName > messages for hours. > It hangs not always on the same projects (it is a mulit-project) but every > time m2 shows "Retrieving previous metadata from SomeInternalRepositoryName" > it can hang ! > Is it possible that maven2 have problem with eventually high network traffic ? > I have tested it with Maven 2.0.4 and 2.0.7. > Here is a memory dump: > [INFO] Retrieving previous metadata from SomeInternalRepositoryName > 2007-08-16 16:24:51 > Full thread dump Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, > sharing): > "Thread-3" prio=6 tid=0x02f7d400 nid=0x944 runnable [0x0363f000..0x0363fa14] >java.lang.Thread.State: RUNNABLE > at java.io.FileInputStream.readBytes(Native Method) > at java.io.FileInputStream.read(FileInputStream.java:199) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > - locked <0x229f2110> (a java.io.InputStreamReader) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > - locked <0x229f2110> (a java.io.InputStreamReader) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at > org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:139) > "Thread-2" prio=6 tid=0x02f7d000 nid=0xb60 runnable [0x035ef000..0x035efa94] >java.lang.Thread.State: RUNNABLE > at java.io.FileInputStream.readBytes(Native Method) > at java.io.FileInputStream.read(FileInputStream.java:199) > at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) > at java.io.BufferedInputStream.read(BufferedInputStream.java:317) > - locked <0x229f37c0> (a java.io.BufferedInputStream) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > - locked <0x229f3220> (a java.io.InputStreamReader) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > - locked <0x229f3220> (a java.io.InputStreamReader) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at > org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:152) > "Low Memory Detector" daemon prio=6 tid=0x02af9c00 nid=0x5bc runnable > [0x..0x] >java.lang.Thread.State: RUNNABLE > "CompilerThread0" daemon prio=10 tid=0x02af8400 nid=0x794 waiting on > condition [0x..0x02daf698] >java.lang.Thread.State: RUNNABLE > "Attach Listener" daemon prio=10 tid=0x02af7000 nid=0xce0 runnable > [0x..0x] >java.lang.Thread.State: RUNNABLE > "Signal Dispatcher" daemon prio=10 tid=0x02af6400 nid=0xd7c waiting on > condition [0x..0x] >java.lang.Thread.State: RUNNABLE > "Finalizer" daemon prio=8 tid=0x02aee400 nid=0xc2c in Object.wait() > [0x02cbf000..0x02cbfa94] >java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x22e0d7e8> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) > - locked <0x22e0d7e8> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) > at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) > "Reference Handler" daemon prio=10 tid=0x02aed400 nid=0xe50 in Object.wait() > [0x02c6f000..0x02
[jira] Updated: (MNG-3078) artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but not saved to local repository
[ http://jira.codehaus.org/browse/MNG-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3078: -- Fix Version/s: 2.0.x this will warrant some investigation, as I actually use this in my own build without a problem (though I think that I may not have a classifier in all instances) > artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but > not saved to local repository > - > > Key: MNG-3078 > URL: http://jira.codehaus.org/browse/MNG-3078 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.6, 2.0.7 >Reporter: Peter Lynch >Priority: Critical > Fix For: 2.0.x > > > Using mvn deploy:deploy-file you can successfully upload a 'tar.gz' artifact > to a repository. > Example without classifier: > mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat > -Dversion=6.0.13 -Dpackaging=tar.gz -DrepositoryId=repo-central > -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ > -Dfile=apache-tomcat-6.0.13.tar.gz > Example with classifier > mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat > -Dversion=6.0.13 -Dpackaging=tar.gz -Dclassifier=bin > -DrepositoryId=repo-central > -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ > -Dfile=apache-tomcat-6.0.13.tar.gz > Once uploaded define a dependency in your pom to it. > Example without classifier > > pom > ... > > ... > > org.apache.tomcat > apache-tomcat > 6.0.13 > tar.gz > true > > ... > > ... > > Example with classifier > > pom > ... > > ... > > org.apache.tomcat > apache-tomcat > 6.0.13 > tar.gz > bin > true > > ... > > ... > > Now to reproduce the problem you could either do > mvn dependency:resolve > or > mvn assembly:assembly > (if the maven assembly plugin is configured with a dependency set that > unpacks this dependency for example) > > The reason I think this is a core bug and not an maven assembly plugin or > maven-dependency-plugin bug is because the problem happens in both of these > independent plugins. > When you run 'mvn dependency:resolve' you'll see that the dependency appears > downloaded but then the build fails with : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.tomcat > -DartifactId=apache-tomcat \ > -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz > -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=org.apache.tomcat > -DartifactId=apache-tomcat \ > -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz > -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.example:core:pom:1.0.0-A1-SNAPSHOT > 2) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 > -- > 1 required artifact is missing. > ... > ... and even stranger here is the log which proves the dependency was found > in the repo and downloaded, but NOT saved to local repository. > ... > [DEBUG] Trying repository repo-central > Downloading: > http://repo.example.com:4000/maven-repos/repo-central/org/apache/tomcat/apache-tomcat/6.0.13/apache-tomcat-6.0.13-bin.tar.gz > 5826K downloaded > [DEBUG] Unable to get resource > 'org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13' from repository > repo-central (http://repo.example.com:4000/maven-repos/repo-central) > [DEBUG] Unable to download the artifact from any repository > ..and YOU MAY GET FOOLED into thinking all is well. mvn deploy:deploy-file > also installs the same artifact into your local repo. So if you follow above > steps and don't get an error it is because the deploy-file goal installed it > in your local repo. However when someone else tries to use your project they > will get above error. > So, first delete from your local repo. example: > rm -rf ~/.m2/repository/org/apache/tomcat/apache-tomcat > and then try to execute mvn dependency:resolve and it should fail as > described. > ...and finally I'll mention that doing the same thing with a 'zip' > type/packaging there is NO PROBLEM. > Ultimately when using the maven assembly plugin I should be able to specify > any typ
[jira] Updated: (MNG-3133) DefaultModelInheritence::appendPath assumes it is operating on interpolated/literal paths
[
http://jira.codehaus.org/browse/MNG-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3133:
--
Fix Version/s: 2.1
> DefaultModelInheritence::appendPath assumes it is operating on
> interpolated/literal paths
> -
>
> Key: MNG-3133
> URL: http://jira.codehaus.org/browse/MNG-3133
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.7
>Reporter: John Allen
>Priority: Critical
> Fix For: 2.1
>
>
> Used by all the assembleXXXInheritance methods within
> assembleModelInheritance, the appendPath method assumes that its dealing with
> literal paths which is not a documented restriction. Thus having
> ${expressions} in any of the paths being operated on (e.g. project URL,
> distroManagement site, SCM, etc etc), the results will not be valid.
> This whole area of Maven's core requires a specification so it can be coded
> too and maintained.
--
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-3112) Maven2 issues with Filter
[ http://jira.codehaus.org/browse/MNG-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3112. - Assignee: Brett Porter Resolution: Duplicate > Maven2 issues with Filter > -- > > Key: MNG-3112 > URL: http://jira.codehaus.org/browse/MNG-3112 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: Deepal Jayasinghe >Assignee: Brett Porter >Priority: Critical > > Apache Axis2 moved to maven2 completely and now we have faced few issues with > maven2. Axis2 is a multi modules bit complex projects and we had no issues > with maven1 other than the performance. But once we moved to maven2 we > realized that we have issues with filters and we uses a number of filters as > well. Specially we have filters in the top most pom.xml and others extend > form that , once we change the filter value others get changed but the > uploaded one has the filter name not the value. > It will be great we can get a fix or path for this since this is bit critical > for us. We can edit them manually and do the release but that is not that > good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NMAVEN-92) Repository plugin export-rdf should log more info
Repository plugin export-rdf should log more info - Key: NMAVEN-92 URL: http://jira.codehaus.org/browse/NMAVEN-92 Project: NMaven Issue Type: Improvement Reporter: Wendy Smoak Priority: Minor The 'export-rdf' goal should print the location of the rdf-repository-export.xml file. For example, the output of 'mvn install' shows exactly where to find the artifact that was created: [INFO] Installing c:\temp\myproject\target\myproject-1.0-SNAPSHOT.jar to C:\Documents and Settings\wsmoak\.m2\repository\com\example\myproject\1.0-SNAPSHOT\myproject-1.0-SNAPSHOT.jar When the "mvn org.apache.maven.dotnet.plugins:maven-repository-plugin:export-rdf " command completed successfully, I looked in the target directory for whatever it might have created. This page explains that the file lands in ~/.m2/uac/rdfRepository/rdf-repository-export.xml http://incubator.apache.org/nmaven/rdf-repository.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3144) Snapshots not updated when using uniqueVersion false
[ http://jira.codehaus.org/browse/MNG-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111933 ] Brett Porter commented on MNG-3144: --- why does the metadata have a buildnumber and timestamp if uniqueVersion is false? mixing the two types of deployments will certainly cause problems. > Snapshots not updated when using uniqueVersion false > > > Key: MNG-3144 > URL: http://jira.codehaus.org/browse/MNG-3144 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.7 >Reporter: Nicky Sandhu >Priority: Critical > > The particular scenario here is > 1.) Deploy snapshot using uniqueVersion false in distribution management > 2.) Verify repository has latest snapshot and metadata is updated in build > number and timestamp > 3. ) Goto a developer's machine (not the same as from which it was deployed) > and do mvn -U or specify updates to be always in pom > 4.) Local cache shows the maven metadata xml file is updated but the snapshot > artifact (jar in this case) is not -- 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] Moved: (MPLUGIN-41) Problem during Ant Plugin development
[ http://jira.codehaus.org/browse/MPLUGIN-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-3100 to MPLUGIN-41: -- Affects Version/s: (was: Documentation Deficit) 2.3 Component/s: (was: Documentation: Guides) Key: MPLUGIN-41 (was: MNG-3100) Project: Maven 2.x Plugin Plugin (was: Maven 2) > Problem during Ant Plugin development > - > > Key: MPLUGIN-41 > URL: http://jira.codehaus.org/browse/MPLUGIN-41 > Project: Maven 2.x Plugin Tools > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Anton Ananich >Priority: Critical > > I'm investigating this manual about Developing Ant Plugins for Maven 2.x: > http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html > I try to create the easiest HelloWorld plugin. As described in this manual: > 1) I create Ant script > 2) I create mojo > 3) I create pom > 4) I build it and install (successfully) > And than I try to run it: > c:\> mvn org.myproject.plugins:hello-plugin:hello > Here is what I got: > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException >at > org.apache.maven.plugin.descriptor.PluginDescriptor.getMojo(PluginDescriptor.java:262) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1529) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:386) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:138) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:585) >at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Tue Jul 10 20:02:10 EEST 2007 > [INFO] Final Memory: 1M/2M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MPLUGIN-50) Special Runtime Plugin Dependencies
[ http://jira.codehaus.org/browse/MPLUGIN-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2512 to MPLUGIN-50: -- Description: (was: On ocassion a plugin may have dependencies upon non-java artifacts even though the plugin/Mojo is written in Java. For example the maven-exec-plugin could be extended to support execution of dotnet executables. It is assumed the dotnet executable (perhaps a code generator) will be executed by executing a system call. The Mojo should somehow be able to make maven aware of the dotnet executable (and it's transitive dependencies). This can be done today as long as the dotnet executable is a versioned dependency. On the other hand if the dotnet executable is a snapshot version found in a sister module (released/packaged together) , the only way to avoid problems is to be very careful of the ordering in the modules configuration of the top level pom. (Thats what I'm doing today). Chat log from #maven IRC channel [15:26] nawkboy: How far out is mvn 2.1? [15:26] jdcasey: nawkboy: :-) [15:26] jdcasey: ...get comfortable [15:27] jdcasey: we're still putting together the list of subjects we want to tackle, from a much larger list of possibilities [15:27] jdcasey: it's slow going, because many of us have less time to work on it than we'd like, unfortunately [15:27] nawkboy: Are you going to allow a plugin to inject dependencies in some fashion? [15:28] nawkboy: For example I have a mojo which runs a dotnet executable. [15:28] nawkboy: My mojo has to first download the dotnet executable from the repo (using the artifact resolver). [15:30] nawkboy: So although the mojo needs to execute a given artifact , the mojo code itself doesn't actually need the artifact to run. Its just the system call my mojo is making that needs the artifact resolved. [15:30] nawkboy: So in conclusion I have a Mojo which effectively has a dependency maven isn't aware of. [15:31] jdcasey: nawkboy: can you not use a plugin-level dependency in that case? [15:31] jdcasey: should be injected straight into the plugin container's classpath [15:31] jdcasey: is the app dependent on that artifact before or after the plugin runs? [15:31] nawkboy: If my mojo could somehow register this extra dependency things would be improved. [15:32] nawkboy: Well my plugin is java, but the executable I resolve and run is dotnet. The java based Mojo won't like having a dotnet dependency. [15:32] jdcasey: hmm [15:32] jdcasey: and the executable is not tailored to that particular app, right? [15:32] nawkboy: Another way to think about this is in terms of the maven-exec-plugin. [15:33] jdcasey: it's not really a project dependency, though, is it? [15:33] jdcasey: it's not used by any project code, right? [15:33] jdcasey: hmm [15:33] nawkboy: The fix I made http://jira.codehaus.org/browse/MEXEC-4 lets a csharp project use the maven-exec-plugin to start up a java based server. [15:34] jdcasey: well, I think a better solution in that case would be to provide better tools for resolving these things, or an annotation saying "I don't need this in my classpath, but get it anyway, and inject the path here" [15:34] nawkboy: But my fix only works nicely since the server I am starting is java based. If the server I wanted the maven-exec-plugin to run was written in say perl, I would have a smilar to problem to that described above. [15:34] nawkboy: bingo. I think you got it. [15:35] jdcasey: nawkboy: file a jira for that, if you would...in the MNG project [15:35] jdcasey: so we can track it. [15:35] jdcasey: that's a pretty new request, AFAIK [15:36] jdcasey: there are some folks who want to inject a new project-level dep because they're instrumenting the source/classes... [15:36] jdcasey: but IMO that's a wrong approach...but this is different [15:36] nawkboy: Potentially, a Mojo (say the maven-exec-plugin trying to start a perl based process) might only know what these sort of dependencies where based on the plugin's configuration. [15:37] nawkboy: where=were [15:39] nawkboy: MNG? Where is that? I'm on the codehaus JIRA, but don't see a project of MNG. [15:39] *** yuri has joined #maven. [15:39] jdcasey: hmm...ok, but it would be nice to have some plumbing for that, so we can accommodate it in things like a "go-offline" mojo [15:39] jdcasey: http://jira.codehaus.org/browse/MNG [15:40] nawkboy: What component should I place it under? [15:40] jdcasey: is there one for plugin tools? [15:40] jdcasey: or plugin management? [15:40] * jdcasey goes to look [15:40] nawkboy: Plugin API, Plugin Creation Tools, Plugin Requests, Plugins and Lifecycle [15:41] jdcasey: Plugins and Lifecycle and Plugin Creation Tools, I think...just use the CTL-click method :) [15:41] jdcasey: should get you close enough, anyway) Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s:
[jira] Moved: (MPLUGIN-55) Maven (plexus?) doesn't recognize Mojo parameter setters defined in a base class
[
http://jira.codehaus.org/browse/MPLUGIN-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MNG-1347 to MPLUGIN-55:
--
Affects Version/s: (was: 2.0)
Fix Version/s: (was: 2.x)
Component/s: (was: Plugin Creation Tools)
Key: MPLUGIN-55 (was: MNG-1347)
Project: Maven 2.x Plugin Tools (was: Maven 2)
> Maven (plexus?) doesn't recognize Mojo parameter setters defined in a base
> class
>
>
> Key: MPLUGIN-55
> URL: http://jira.codehaus.org/browse/MPLUGIN-55
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
>Reporter: David Jackman
>Priority: Minor
>
> Create a Mojo class that extends some base class that itself defines a
> parameter that uses a setter. Here's an example:
> public class Base extends AbstractMojo
> {
>/**
>* @parameter property="parameter"
>*/
>private String m_parameter;
>public void setParameter(String parameter)
>{
> m_parameter = parameter;
>}
> ...
> }
> /**
> * @goal mygoal
> */
> public class MyMojo extends Base
> {
> ...
> }
> Maven can build the plugin just fine, but when I attempt to execute the goal,
> I get an error:
> org.codehaus.plexus.component.configurator.ComponentConfigurationException:
> Cannot access method: com.example.MyMojo.setParameter( java.lang.Class ).
> If I move the setter to the goal class, it works just fine. Maven (plexus?)
> should be able to access the method from the base class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MPLUGIN-56) Inter-plugin Mojo inheritance
[ http://jira.codehaus.org/browse/MPLUGIN-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2789 to MPLUGIN-56: -- Fix Version/s: (was: 2.1) Component/s: (was: Plugin Creation Tools) Key: MPLUGIN-56 (was: MNG-2789) Project: Maven 2.x Plugin Tools (was: Maven 2) > Inter-plugin Mojo inheritance > - > > Key: MPLUGIN-56 > URL: http://jira.codehaus.org/browse/MPLUGIN-56 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement >Reporter: Kohsuke Kawaguchi > > It's often desirable to create a new mojo by extending an existing mojo and > changing its behavior. For example, one might imagine a NetBeans plugin > packager that extends from JarMojo and adds extra stuff into the jar. > Today, if I extends a mojo from another plugin, the plugin:descriptor goal > fails to create a proper META-INF/maven/plugin.xml --- it doesn't list any of > the injections that need to happen for the base class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
