[jira] Created: (SCM-555) paths reported in svn-exe checkout do not match update command (always reports absolute)
paths reported in svn-exe checkout do not match update command (always reports absolute) Key: SCM-555 URL: http://jira.codehaus.org/browse/SCM-555 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.3 Environment: any Reporter: Andrew Williams Attachments: scm-relative.patch Paths listed by the update command are always absolute which is not the same behaviour as the update command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRESOURCES-110) escapeString is broken - break filtered output
[
http://jira.codehaus.org/browse/MRESOURCES-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201613#action_201613
]
Andrew Williams commented on MRESOURCES-110:
Yes, it strips the next character if the escapeString is not followed by a
filter character.
Very annoying!
> escapeString is broken - break filtered output
> --
>
> Key: MRESOURCES-110
> URL: http://jira.codehaus.org/browse/MRESOURCES-110
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4, 2.4.1
> Environment: Maven 2.0.9, WinXP
>Reporter: Marco Rothe
>Priority: Critical
>
> If the escapeString parameter is specified in plugin configuration this will
> break the filtered output.
> For example the configuration
>
>maven-resources-plugin
>2.4.1
>
> !
>
>
> an file to filter (an XML file)
>
>
>
>Why are my !\${\}\! static.content broken if the escapeString
> occure ?!?
>Content with replacement: ${replaceThis} !
>Content with escaped replacement: Do not !${replaceThis}
> !
>
> and a property
>
> I am the replacement
>
> from pom or profile.xml
> result in
>
>
>
>Why are my !${\}\!static.content broken if the escapeString
> occure ?!
>Content with replacement: I am the replacement !/broken-tag>
>Content with escaped replacement: Do not ${replaceThis}
> !/broken-tag>
>
> Note the broken comment and tags!
> If using Resources-Plugin 2.3 the output is like expected:
>
>
>
>Why are my !\${\}\! static.content broken if the escapeString
> occure ?!?
>Content with replacement: I am the replacement !
>Content with escaped replacement: Do not ${replaceThis}
> !
>
> Got even worse when using a complex escape string like
> static (I know it's a silly example ;)). The
> result is
>
>
>
>Why are my !\${\}\! staticcontent broken if the escapeSring
> occure ?!?
>Content with replacement: I am the replacement !
>Content with escapedreplacement: Do not !I am the replacement
> !
>
> Note the missing characters all over the file ... :-/
> So the actual state of the escapeString feature is unpredictable and nearly
> useless.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (WAGON-162) SCP deployment echos pasword
[ http://jira.codehaus.org/browse/WAGON-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134823#action_134823 ] Andrew Williams commented on WAGON-162: --- Yes, it echoes the characters you type to the console. > SCP deployment echos pasword > > > Key: WAGON-162 > URL: http://jira.codehaus.org/browse/WAGON-162 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: ubuntu linux >Reporter: Andrew Williams >Priority: Critical > Fix For: 1.x > > Attachments: patch > > > If you do not have keys set up and you upload via scp during a deploy phase > the password is echoed to the user. > very bad :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-208) change the default link from an anchor to a relative page in the apt format
[
http://jira.codehaus.org/browse/DOXIA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Williams updated DOXIA-208:
--
Description:
To be inline with wikis and other formats the APT link "MyLink" should be a
relative link whereas "#MyLink" would link to an anchor.
This is a deviation from the apt format, but would remove confusion for new
users and those working on supporting multiple formats.
Edit: this is an issue with the XHTML sink, not the apt parser - anything link
"MyLink" will be spat out as "#MyLink"
was:
To be inline with wikis and other formats the APT parser should recognise the
link "MyLink" as a relative link whereas "#MyLink" would link to an anchor.
This is a deviation from the apt format, but would remove confusion for new
users and those working on supporting multiple formats.
this changes the interpretation of {{Link}} and {{{Label} Link}} alone.
Component/s: (was: Module - Apt)
Module - Xhtml
> change the default link from an anchor to a relative page in the apt format
> ---
>
> Key: DOXIA-208
> URL: http://jira.codehaus.org/browse/DOXIA-208
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Xhtml
>Affects Versions: 1.0-alpha-10
>Reporter: Andrew Williams
>
> To be inline with wikis and other formats the APT link "MyLink" should be a
> relative link whereas "#MyLink" would link to an anchor.
> This is a deviation from the apt format, but would remove confusion for new
> users and those working on supporting multiple formats.
> Edit: this is an issue with the XHTML sink, not the apt parser - anything
> link "MyLink" will be spat out as "#MyLink"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-208) change the default link from an anchor to a relative page in the apt format
change the default link from an anchor to a relative page in the apt format
---
Key: DOXIA-208
URL: http://jira.codehaus.org/browse/DOXIA-208
Project: Maven Doxia
Issue Type: Improvement
Components: Module - Apt
Affects Versions: 1.0-alpha-10
Reporter: Andrew Williams
To be inline with wikis and other formats the APT parser should recognise the
link "MyLink" as a relative link whereas "#MyLink" would link to an anchor.
This is a deviation from the apt format, but would remove confusion for new
users and those working on supporting multiple formats.
this changes the interpretation of {{Link}} and {{{Label} Link}} alone.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (SCM-362) update command ignores date parameter
[ http://jira.codehaus.org/browse/SCM-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams updated SCM-362: Description: The AbstractManager has no support for calling update using the date parameter that the api advertises. This is ignored and a simple update with no date / version parameters is called instead. The providers have no way of accessing the Date parameter as it is dropped before they are called was: The api (and thus all providers) have no support for calling update using the date parameter that the api advertises. This is ignored and a simple update with no date / version parameters is called instead. > update command ignores date parameter > - > > Key: SCM-362 > URL: http://jira.codehaus.org/browse/SCM-362 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Affects Versions: 1.0 >Reporter: Andrew Williams >Priority: Blocker > > The AbstractManager has no support for calling update using the date > parameter that the api advertises. > This is ignored and a simple update with no date / version parameters is > called instead. > The providers have no way of accessing the Date parameter as it is dropped > before they are called -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SCM-362) update command ignores date parameter
update command ignores date parameter - Key: SCM-362 URL: http://jira.codehaus.org/browse/SCM-362 Project: Maven SCM Issue Type: Bug Components: maven-scm-api Affects Versions: 1.0 Reporter: Andrew Williams Priority: Blocker The api (and thus all providers) have no support for calling update using the date parameter that the api advertises. This is ignored and a simple update with no date / version parameters is called instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-489) Repositories are read only even for repository managers
[ http://jira.codehaus.org/browse/MRM-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106788 ] Andrew Williams commented on MRM-489: - I have tried to run litmus through the admin account and as a user with *all* roles and a mkcol at the root level fails. > Repositories are read only even for repository managers > --- > > Key: MRM-489 > URL: http://jira.codehaus.org/browse/MRM-489 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 > Environment: OSX >Reporter: Andrew Williams >Assignee: Joakim Erdfelt > > Both the OSX client and the litmus test suite report that the repositories > are read only and cannot be deployed to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-489) Repositories are read only even for repository managers
Repositories are read only even for repository managers --- Key: MRM-489 URL: http://jira.codehaus.org/browse/MRM-489 Project: Archiva Issue Type: Bug Components: WebDAV interface Affects Versions: 1.0-alpha-2 Environment: OSX Reporter: Andrew Williams Both the OSX client and the litmus test suite report that the repositories are read only and cannot be deployed to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2254) the encoding parameter in xml declaration of POM is ignored
[ http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105369 ] Andrew Williams commented on MNG-2254: -- Can you please clarify which patches apply and which do not > the encoding parameter in xml declaration of POM is ignored > > > Key: MNG-2254 > URL: http://jira.codehaus.org/browse/MNG-2254 > Project: Maven 2 > Issue Type: Bug > Components: POM::Encoding >Reporter: Naoki Nose >Assignee: Jason van Zyl > Fix For: 2.0.8 > > Attachments: DefaultMavenProjectBuilder.diff, MNG-2254-2.diff, > MNG-2254.diff, MNG-2254_artifact.diff, MNG-2254_components.diff, > modello-plugin-xpp3.diff > > > DefaultMavenProjectBuilder reads POM in system default character encoding, > and the encoding parameter in xml declartion is ignored. > to fix this problem, We should > - fix modello-plugin-xpp3 to use the xml parser which is able to handle the > encoding parameter properly > - regenerate maven-model using fixed modello-plugin-xpp3 > - fix DefaultMavenProjectBuilder to use regenerated maven-model properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSITE-239) encoding declaration in site.xml is ignored
[ http://jira.codehaus.org/browse/MSITE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams closed MSITE-239. - Resolution: Fixed Fixed but no new snapshot deployed, awaiting response from the site maintainers as before > encoding declaration in site.xml is ignored > --- > > Key: MSITE-239 > URL: http://jira.codehaus.org/browse/MSITE-239 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 >Reporter: Herve Boutemy > Fix For: 2.0-beta-6 > > Attachments: MSITE-239.diff, MSITE-239.tgz > > > when PLXUTILS-11 will be fixed, and XmlReader will be available, there won't > be any problem to fix this 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] Commented: (MASSEMBLY-231) Allow Assembly plugin to specify alternate DistributionManagement
[ http://jira.codehaus.org/browse/MASSEMBLY-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105344 ] Andrew Williams commented on MASSEMBLY-231: --- Indenting is broken in src/it/repositories/basic-repository-deploys-artifact-with-distribution-management/pom.xml at least > Allow Assembly plugin to specify alternate DistributionManagement > - > > Key: MASSEMBLY-231 > URL: http://jira.codehaus.org/browse/MASSEMBLY-231 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-2 >Reporter: James William Dumay > Attachments: maven-assembly-plugin.patch, maven-assembly-plugin.patch > > > The following patch allows the assembly plugin to specify alternate > repository locations for deployment of its attached artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3152) Change to plugin testing harness to allow the setting of ArtifactRepository on the ArtifactStub
[ http://jira.codehaus.org/browse/MNG-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams closed MNG-3152. Assignee: Andrew Williams Resolution: Fixed Fix Version/s: 2.0.8 > Change to plugin testing harness to allow the setting of ArtifactRepository > on the ArtifactStub > --- > > Key: MNG-3152 > URL: http://jira.codehaus.org/browse/MNG-3152 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.8 >Reporter: James William Dumay >Assignee: Andrew Williams > Fix For: 2.0.8 > > Attachments: maven-plugin-testing-harness.patch > > > Change to plugin testing harness to allow the setting of ArtifactRepository > on the ArtifactStub -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2142) Forcing execution of the post-integration-test phase
[ http://jira.codehaus.org/browse/MNG-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100850 ] Andrew Williams commented on MNG-2142: -- As I understand it the pre- and post- integration-test phases are for controlling the integration environment, so I think it is vital that the post is called even on failure. Is there a semantic already that assumes a post- running means success? perhaps pre- and post- whatever should always run for the phase then the lifecycle is defined as a list of phases (exclusing pre- and post-) each of which will invoke a pre- before and a post- after. I believe this would fix another bug I read, though I cannot remember which. > Forcing execution of the post-integration-test phase > > > Key: MNG-2142 > URL: http://jira.codehaus.org/browse/MNG-2142 > Project: Maven 2 > Issue Type: Improvement > Components: integration tests >Affects Versions: 2.0.3 >Reporter: Vincent Massol > Fix For: 2.1.x > > > The post-integration-test phase needs to always be called even in case of > tests failures in the integration-test phase. > For example when using Cargo the container may be left running if the > post-integration-test phase is not called... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2904) Misleading error message if profiles that are active by default do not have an ID
[ http://jira.codehaus.org/browse/MNG-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams updated MNG-2904: - Fix Version/s: 2.0.7 It seems that this is somehow due to the field which should be required not being verified when the ~/.m2/settings.xml is merged into the effective-pom. > Misleading error message if profiles that are active by default do not have > an ID > - > > Key: MNG-2904 > URL: http://jira.codehaus.org/browse/MNG-2904 > Project: Maven 2 > Issue Type: Improvement > Components: Errors >Affects Versions: 2.0.5 > Environment: Maven 2.0.x on Mac OSX Java 1.5.0_07 - happens on Java > 1.4.2 also >Reporter: Andrew Williams > Fix For: 2.0.7 > > > to reproduce edit your ~/.m2/settings.xml and add a new profile. > Mark it as active by default and make sure it has no ID. > The resulting stack is thus: > java.lang.ClassCastException: Settings.addActiveProfiles(string) parameter > must be instanceof java.lang.String > at > org.apache.maven.settings.Settings.addActiveProfile(Settings.java:91) > at > org.apache.maven.settings.DefaultMavenSettingsBuilder.activateDefaultProfiles(DefaultMavenSettingsBuilder.java:197) > at > org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:177) > at > org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:153) > at > org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:141) > at org.apache.maven.cli.MavenCli.buildSettings(MavenCli.java:315) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:176) > 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2904) Misleading error message if profiles that are active by default do not have an ID
Misleading error message if profiles that are active by default do not have an ID - Key: MNG-2904 URL: http://jira.codehaus.org/browse/MNG-2904 Project: Maven 2 Issue Type: Improvement Components: Errors Affects Versions: 2.0.5 Environment: Maven 2.0.x on Mac OSX Java 1.5.0_07 - happens on Java 1.4.2 also Reporter: Andrew Williams to reproduce edit your ~/.m2/settings.xml and add a new profile. Mark it as active by default and make sure it has no ID. The resulting stack is thus: java.lang.ClassCastException: Settings.addActiveProfiles(string) parameter must be instanceof java.lang.String at org.apache.maven.settings.Settings.addActiveProfile(Settings.java:91) at org.apache.maven.settings.DefaultMavenSettingsBuilder.activateDefaultProfiles(DefaultMavenSettingsBuilder.java:197) at org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:177) at org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:153) at org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:141) at org.apache.maven.cli.MavenCli.buildSettings(MavenCli.java:315) at org.apache.maven.cli.MavenCli.main(MavenCli.java:176) 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1958) we need a var that always points to the root direcotry in multi module builds
[
http://jira.codehaus.org/browse/MNG-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89790
]
Andrew Williams commented on MNG-1958:
--
Can one of the interested parties say why this is wanted?
Any information that modules want to share should be packaged in an artifact
and depended upon as any other dependency.
The very concept of a ${rootdir} breaks the reproducable nature of a maven
build. Variable variables like this should be avoided!
> we need a var that always points to the root direcotry in multi module builds
> -
>
> Key: MNG-1958
> URL: http://jira.codehaus.org/browse/MNG-1958
> Project: Maven 2
> Issue Type: Improvement
>Reporter: Mark Proctor
> Fix For: 2.1.x
>
>
> ${basedir} always points to the local module. There are cases, when having a
> local relative repository, when it would be usefull to have a var that always
> pointed to the root project, ${rootdir}.
> In such a case you may want to think of having the names ${rootdir}
> ${moduledir}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-1050) [2.0,) should not select 3.0 and above by default
[ http://jira.codehaus.org/browse/MNG-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams closed MNG-1050. Resolution: Won't Fix Agreed, this is the correct behaviour. Maven cannot assume that versions are incompatible, it uses flexible versions by default on purpose. The client is free to restrict the versions as Kenney stated if they do not wish to update to the latest version. If the maven versioning ranges are not operating correcty that is a seperate point. > [2.0,) should not select 3.0 and above by default > - > > Key: MNG-1050 > URL: http://jira.codehaus.org/browse/MNG-1050 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Brett Porter > Fix For: 2.1.x > > > I think that we need to assume major versions are incompatible as it is > easier to later state compatibility than fix it when broken. > This might just be a default compatibility scheme, but a project can define > its own (eg, compatible-since 2.1). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2205) "provided" scope dependencies must be transitive
[ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89787 ] Andrew Williams commented on MNG-2205: -- Your point may be correct, but your use case is wrong. if C wants to use Sybase JConnect then it must declare this as a dependency. A could at any time change it's dependencies and "break" this assumption of C's. It is wrong to use a dependency that you do not declare. > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: http://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 2.1.x > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1944) cyclic dependencies causes maven to not include all transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89786 ] Andrew Williams commented on MNG-1944: -- How is it possible for a cyclic dep. to be inserted into the repos, if it cannot be built? > cyclic dependencies causes maven to not include all transitive dependencies > --- > > Key: MNG-1944 > URL: http://jira.codehaus.org/browse/MNG-1944 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.1 >Reporter: Brian Fox >Priority: Critical > Fix For: 2.1.x > > > Try including dom4j 1.5.2 and see what dependencies are resolved. dom4j > depends on jaxen, which depends on dom4j. When maven sees the cyclic > dependency, it stops processing the jaxen dependency. This leaves everything > else jaxen depends on not included in the final artifact list. This is mvn -x > output: > dom4j:dom4j:jar:1.5.2 (selected for compile) > [DEBUG] stax:stax-api:jar:1.0 (selected for compile) > [DEBUG] pull-parser:pull-parser:jar:2 (selected for compile) > [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [DEBUG] msv:xsdlib:jar:20030807 (selected for compile) > [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile) > [DEBUG] dom4j:dom4j:jar:1.5.2 (removed - causes a cycle in the > graph) > [DEBUG] jaxen:jaxen:jar:1.1-beta-4 (selected for compile) > [DEBUG] msv:relaxngDatatype:jar:20030807 (selected for compile) > Notice that xerces and xom and everything else jaxen depends on isn't > included. > Taking dom4j out of the jaxen pom locally causes everything to be included: > [DEBUG] com.stchome.maven.mojo:helloUser:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] dom4j:dom4j:jar:1.5.2 (selected for compile) > [DEBUG] stax:stax-api:jar:1.0 (selected for compile) > [DEBUG] pull-parser:pull-parser:jar:2 (selected for compile) > [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [DEBUG] msv:xsdlib:jar:20030807 (selected for compile) > [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile) > [DEBUG] jaxen:jaxen:jar:1.1-beta-4 (selected for compile) > [DEBUG] jdom:jdom:jar:b10 (selected for compile) > [DEBUG] xom:xom:jar:1.0b3 (selected for compile) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (selected for compile) > [DEBUG] xerces:xercesImpl:jar:2.2.1 (selected for compile) > [DEBUG] xalan:xalan:jar:2.6.0 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [WARNING] > This artifact has been relocated to com.ibm.icu:icu4j:2.6.1. > [DEBUG] com.ibm.icu:icu4j:jar:2.6.1 (selected for compile) > [WARNING] > This artifact has been relocated to javax.servlet:servlet-api:2.4. > [DEBUG] javax.servlet:servlet-api:jar:2.4 (selected for compile) > [WARNING] > This artifact has been relocated to org.ccil.cowan.tagsoup:tagsoup:0.9.7. > [DEBUG] org.ccil.cowan.tagsoup:tagsoup:jar:0.9.7 (selected for > compile) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (removed - nearer found: 2.6.2) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.2 (selected for compile) > [DEBUG] xerces:xercesImpl:jar:2.2.1 (removed - nearer found: 2.6.2) > [DEBUG] xerces:xercesImpl:jar:2.6.2 (selected for compile) > [DEBUG] msv:relaxngDatatype:jar:20030807 (selected for compile) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2316) Add info to the poms for dependencies that implement an API or provide other dependencies
[ http://jira.codehaus.org/browse/MNG-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89785 ] Andrew Williams commented on MNG-2316: -- How would you be able to use such information if it was available? Perhaps your example is bad, but javax.mail is not just an API - it is an implementation, so including it on it's own is perfect;y valid, no extra implementation is needed. If there was a purely api jar and you implement it with another artifact how would we know about it? > Add info to the poms for dependencies that implement an API or provide other > dependencies > - > > Key: MNG-2316 > URL: http://jira.codehaus.org/browse/MNG-2316 > Project: Maven 2 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Carlos Sanchez >Priority: Critical > Fix For: 2.1.x > > > e.g. > geronimo implementation of javamail could say > > > javax.mail > mail > ... > > > spring.jar pom could say > > > org.springframework > spring-webmvc > ... > > > org.springframework > spring-context > ... > > ... > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-306) Managed dependencies in transient dependencies not correctly resolved
[ http://jira.codehaus.org/browse/SUREFIRE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams closed SUREFIRE-306. Resolution: Cannot Reproduce This looks like a not-a-bug, there was a bad pom in the chain pulling one of the artifacts down. > Managed dependencies in transient dependencies not correctly resolved > - > > Key: SUREFIRE-306 > URL: http://jira.codehaus.org/browse/SUREFIRE-306 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.3 > Environment: mvn 2.0.5 mvn 2.1-SNAPSHOT >Reporter: Andrew Williams > > This bug seems to be incredibly similar to MNG-115, but only occurs during > surefire tests. > To test I put a snapshot in the plexus.version in maven-components/pom.xml > and installed. > Then headed to maven-artifact and ran "mvn test -X" and watched as the > container-default version no longer matched the component-api (only > container-default is a direct dependency). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-306) Managed dependencies in transient dependencies not correctly resolved
Managed dependencies in transient dependencies not correctly resolved - Key: SUREFIRE-306 URL: http://jira.codehaus.org/browse/SUREFIRE-306 Project: Maven Surefire Issue Type: Bug Components: plugin Affects Versions: 2.3 Environment: mvn 2.0.5 mvn 2.1-SNAPSHOT Reporter: Andrew Williams This bug seems to be incredibly similar to MNG-115, but only occurs during surefire tests. To test I put a snapshot in the plexus.version in maven-components/pom.xml and installed. Then headed to maven-artifact and ran "mvn test -X" and watched as the container-default version no longer matched the component-api (only container-default is a direct dependency). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-115) versions of managed dependencies attached to transdeps are not resolved correctly
[ http://jira.codehaus.org/browse/MNG-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams closed MNG-115. --- Resolution: Fixed Sorry, not a re-open reason, will create a new related issue > versions of managed dependencies attached to transdeps are not resolved > correctly > - > > Key: MNG-115 > URL: http://jira.codehaus.org/browse/MNG-115 > Project: Maven 2 > Issue Type: Bug > Environment: all >Reporter: John Casey > Assigned To: John Casey >Priority: Critical > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > When resolving dependencies transitively, each dependency's POM is retrieved, > read, and parsed for its dependencies, and the cycle continues. Since we're > dealing with Model's here, and not MavenProject's, dependency management has > not taken place. This means the managed dependencies in that model will have > a version (and other info, potentially) which is null. This leads to a NPE in > the transdeps resolution process. > Proposal: Switch transitive resolution to use MavenProject rather than Model, > which will alleviate any problems with post-processing and inheritance > calculations on the Model. This will make inclusion of parent POM's easier > too, along with resolution of interpolated values within the POM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-115) versions of managed dependencies attached to transdeps are not resolved correctly
[ http://jira.codehaus.org/browse/MNG-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams reopened MNG-115: - This appears to still be problematic on trunk, but only when running surefire tests. perhaps someone can comment on this? there was a lot of "flux" with surefire recently. > versions of managed dependencies attached to transdeps are not resolved > correctly > - > > Key: MNG-115 > URL: http://jira.codehaus.org/browse/MNG-115 > Project: Maven 2 > Issue Type: Bug > Environment: all >Reporter: John Casey > Assigned To: John Casey >Priority: Critical > Fix For: 2.0-alpha-1 > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > When resolving dependencies transitively, each dependency's POM is retrieved, > read, and parsed for its dependencies, and the cycle continues. Since we're > dealing with Model's here, and not MavenProject's, dependency management has > not taken place. This means the managed dependencies in that model will have > a version (and other info, potentially) which is null. This leads to a NPE in > the transdeps resolution process. > Proposal: Switch transitive resolution to use MavenProject rather than Model, > which will alleviate any problems with post-processing and inheritance > calculations on the Model. This will make inclusion of parent POM's easier > too, along with resolution of interpolated values within the POM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MAVENENTERPRISE-4) Configure webdav repositories for public anon read or not, and for user dirs public or not
[
http://jira.codehaus.org/browse/MAVENENTERPRISE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Williams resolved MAVENENTERPRISE-4.
---
Assignee: Andrew Williams
Resolution: Fixed
this is now set in a config file at ${enterprise.dataDir}/config.xml which is
read at each boot
> Configure webdav repositories for public anon read or not, and for user dirs
> public or not
> --
>
> Key: MAVENENTERPRISE-4
> URL: http://jira.codehaus.org/browse/MAVENENTERPRISE-4
> Project: Maven Enterprise
> Issue Type: Improvement
>Affects Versions: 1.0-alpha-1
>Reporter: Jason van Zyl
> Assigned To: Andrew Williams
> Fix For: 1.0-alpha-1
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MAVENENTERPRISE-3) Polish up site deployment
[ http://jira.codehaus.org/browse/MAVENENTERPRISE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams resolved MAVENENTERPRISE-3. --- Resolution: Fixed now index.html redirections are in place I think this issue is done :) > Polish up site deployment > - > > Key: MAVENENTERPRISE-3 > URL: http://jira.codehaus.org/browse/MAVENENTERPRISE-3 > Project: Maven Enterprise > Issue Type: Improvement > Components: Site Deployment >Affects Versions: 1.0-alpha-1 >Reporter: Jason van Zyl > Assigned To: Andrew Williams > Fix For: 1.0-alpha-1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MAVENENTERPRISE-2) Data directory separation and configuration
[
http://jira.codehaus.org/browse/MAVENENTERPRISE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Williams resolved MAVENENTERPRISE-2.
---
Assignee: Andrew Williams
Resolution: Fixed
Done, this is now set in some profiles which allow a flexible setup.
The default datadir is target/plexus-app-runtime/data ( ${plexus.home}/data)
this can be overridden to any directory by passing
-Denterprise.dataDir=/my/data/directory
to mvn install.
running mvn install -Denterprise.install is designed to pick sensible defaults
for an installation
and for this property will set ${user.home}/.enterprise
> Data directory separation and configuration
> ---
>
> Key: MAVENENTERPRISE-2
> URL: http://jira.codehaus.org/browse/MAVENENTERPRISE-2
> Project: Maven Enterprise
> Issue Type: New Feature
>Affects Versions: 1.0-alpha-1
>Reporter: Jason van Zyl
> Assigned To: Andrew Williams
> Fix For: 1.0-alpha-1
>
>
> An admin might want a unified install where the datadir is contained within
> the distribution or stored externally for upgradability.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MAVENENTERPRISE-3) Polish up site deployment
[ http://jira.codehaus.org/browse/MAVENENTERPRISE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86447 ] Andrew Williams commented on MAVENENTERPRISE-3: --- This is now mostly done - but need to resolve directory listings to index.html if they exist instead of directory listings > Polish up site deployment > - > > Key: MAVENENTERPRISE-3 > URL: http://jira.codehaus.org/browse/MAVENENTERPRISE-3 > Project: Maven Enterprise > Issue Type: Improvement > Components: Site Deployment >Affects Versions: 1.0-alpha-1 >Reporter: Jason van Zyl > Fix For: 1.0-alpha-1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1101) Update continuum to the latest plexus appserver ( + container etc )
[ http://jira.codehaus.org/browse/CONTINUUM-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams closed CONTINUUM-1101. -- Resolution: Fixed Fix Version/s: 1.1 patch comitted by jason earlier today > Update continuum to the latest plexus appserver ( + container etc ) > --- > > Key: CONTINUUM-1101 > URL: http://jira.codehaus.org/browse/CONTINUUM-1101 > Project: Continuum > Issue Type: Improvement > Components: Core system >Affects Versions: 1.1 >Reporter: Andrew Williams > Assigned To: Jason van Zyl > Fix For: 1.1 > > Attachments: continuum-latest-appserver.patch, > continuum-latest-appserver.patch > > > The attached patch updates plexus-appserver and all related dependencies. > Tested and working here through the continuum-plexus-runtime -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-272) Server startup on jetty broken due to bug in plexus-xwork-integration (PLX-321)
[ http://jira.codehaus.org/browse/MRM-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams closed MRM-272. --- Assignee: Andrew Williams Resolution: Fixed Fix Version/s: 1.0 fixed in trunk of plexus, so should be cascaded to archiva too > Server startup on jetty broken due to bug in plexus-xwork-integration > (PLX-321) > --- > > Key: MRM-272 > URL: http://jira.codehaus.org/browse/MRM-272 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: WinXP SP2, JDK 1.6.0 >Reporter: Dirk Jablonski > Assigned To: Andrew Williams > Fix For: 1.0 > > > Due to a bug in plexus-xwork-integration (see > http://jira.codehaus.org/browse/PLX-321), web application is not available > because a VerifierError occurs, complaining about final method being > overridden. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-1101) Update continuum to the latest plexus appserver ( + container etc )
[ http://jira.codehaus.org/browse/CONTINUUM-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Williams updated CONTINUUM-1101: --- Attachment: continuum-latest-appserver.patch Another patch against the now current continuum trunk and some more up to date plexus artifacts > Update continuum to the latest plexus appserver ( + container etc ) > --- > > Key: CONTINUUM-1101 > URL: http://jira.codehaus.org/browse/CONTINUUM-1101 > Project: Continuum > Issue Type: Improvement > Components: Core system >Affects Versions: 1.1 >Reporter: Andrew Williams > Assigned To: Jason van Zyl > Attachments: continuum-latest-appserver.patch, > continuum-latest-appserver.patch > > > The attached patch updates plexus-appserver and all related dependencies. > Tested and working here through the continuum-plexus-runtime -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2732) Regression: new container unable to run release:prepare
[ http://jira.codehaus.org/browse/MNG-2732?page=all ] Andrew Williams closed MNG-2732. Resolution: Fixed Fix Version/s: 2.1-alpha-1 This issue is now fixed with the latest plexus and maven > Regression: new container unable to run release:prepare > --- > > Key: MNG-2732 > URL: http://jira.codehaus.org/browse/MNG-2732 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > I get this exception running mvn release:prepare -DdryRun=true on any project > (both with 2.0-beta-4 and 2.0-beta-5-SNAPSHOT of the release plugin): > [INFO] > > [INFO] Error for project: Maven Artifact (during release:prepare) > [INFO] > > [INFO] Internal error in the plugin manager executing goal > 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-5-SNAPSHOT:prepare': > Unable to find the mojo > 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-5-SNAPSHOT:prepare' > in the plugin 'org.apache.maven.plugins:maven-release-plugin' > org.apache.maven.plugins.release.scm.ScmRepositoryConfigurator > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the > plugin manager executing goal > 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-5-SNAPSHOT:prepare': > Unable to find the mojo > 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-5-SNAPSHOT:prepare' > in the plugin 'org.apache.maven.plugins:maven-release-plugin' > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:538) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:141) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:550) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:346) > 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the > mojo > 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-5-SNAPSHOT:prepare' > in the plugin 'org.apache.maven.plugins:maven-release-plugin' > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:534) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:413) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 17 more > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLookupException: > Unable to lookup component > 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-release-plugin:2.0-beta-5-SNAPSHOT:prepare', > it could not be started > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:107) > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:212) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:524) > ... 19 more > Caused by: > org.codehaus.plexus.component.repository.
[jira] Closed: (MNG-2731) Regression: new container handling cannot locate resources properly
[ http://jira.codehaus.org/browse/MNG-2731?page=all ] Andrew Williams closed MNG-2731. Resolution: Fixed Fix Version/s: 2.1-alpha-1 This issue is now fixed with the latest plexus and maven > Regression: new container handling cannot locate resources properly > --- > > Key: MNG-2731 > URL: http://jira.codehaus.org/browse/MNG-2731 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Assigned To: Jason van Zyl >Priority: Blocker > Fix For: 2.1-alpha-1 > > Attachments: doxia-site-renderer-MNG-2731.diff, > maven-project-info-reports-plugin-MNG-2731.diff > > > Run: mvn project-info-reports:scm on any Maven project. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Can't find bundle for base name project-info-report, locale en_AU > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: Can't find bundle for base name > project-info-report, locale en_AU > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:315) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:141) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:550) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:346) > 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: java.util.MissingResourceException: Can't find bundle for base > name project-info-report, locale en_AU > at > org.codehaus.plexus.i18n.DefaultI18N.cacheBundle(DefaultI18N.java:394) > at > org.codehaus.plexus.i18n.DefaultI18N.getBundle(DefaultI18N.java:157) > at > org.codehaus.plexus.i18n.DefaultI18N.getString(DefaultI18N.java:206) > at > org.apache.maven.report.projectinfo.ScmReport.getName(ScmReport.java:68) > at > org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute(AbstractProjectInfoReport.java:158) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:435) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311) > ... 11 more > This works in Maven 2.0.4/2.0.5-SNAPSHOT, but not on trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2351) mvn -X doesn't enable debugging
[ http://jira.codehaus.org/browse/MNG-2351?page=comments#action_85543 ]
Andrew Williams commented on MNG-2351:
--
Sorry this bug was actually just fixed today, by jdcasey
> mvn -X doesn't enable debugging
> ---
>
> Key: MNG-2351
> URL: http://jira.codehaus.org/browse/MNG-2351
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.1.x
>Reporter: Jerome Lacoste
> Fix For: 2.1
>
>
> mvn -X doesn't enable debugging
> If I add the following code to DefaultMaven.execute(...)
> public void execute( MavenExecutionRequest request )
> throws MavenExecutionException
> [...]
>
> loggerManager.setThreshold( request.getLoggingLevel() );
> // ADDED
> loggerManager.getLoggerForComponent( Maven.ROLE ).info( "XXX logging
> level " + request.getLoggingLevel());
> loggerManager.getLoggerForComponent( Maven.ROLE ).debug( "XXX logging
> level " + request.getLoggingLevel());
> System.err.println("XXX logging level " + request.getLoggingLevel());
> System.err.println("XXX show errors " + request.isShowErrors());
> System.err.println("XXX logger threshold " +
> loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
> // end of ADDED
> I get:
> [INFO] XXX logging level 0
> XXX logging level 0
> XXX show errors true
> XXX logger threshold 1
> Looks like something is wrong with regard to thresholds in the Maven.ROLE
> component.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2351) mvn -X doesn't enable debugging
[ http://jira.codehaus.org/browse/MNG-2351?page=all ]
Andrew Williams closed MNG-2351.
Assignee: (was: Andrew Williams)
Resolution: Fixed
Fix Version/s: (was: 2.1-alpha-1)
2.1
This was fixed in trunk a couple of days ago
> mvn -X doesn't enable debugging
> ---
>
> Key: MNG-2351
> URL: http://jira.codehaus.org/browse/MNG-2351
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.1.x
>Reporter: Jerome Lacoste
> Fix For: 2.1
>
>
> mvn -X doesn't enable debugging
> If I add the following code to DefaultMaven.execute(...)
> public void execute( MavenExecutionRequest request )
> throws MavenExecutionException
> [...]
>
> loggerManager.setThreshold( request.getLoggingLevel() );
> // ADDED
> loggerManager.getLoggerForComponent( Maven.ROLE ).info( "XXX logging
> level " + request.getLoggingLevel());
> loggerManager.getLoggerForComponent( Maven.ROLE ).debug( "XXX logging
> level " + request.getLoggingLevel());
> System.err.println("XXX logging level " + request.getLoggingLevel());
> System.err.println("XXX show errors " + request.isShowErrors());
> System.err.println("XXX logger threshold " +
> loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
> // end of ADDED
> I get:
> [INFO] XXX logging level 0
> XXX logging level 0
> XXX show errors true
> XXX logger threshold 1
> Looks like something is wrong with regard to thresholds in the Maven.ROLE
> component.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-264) Update archiva to latest plexus appserver ( + container etc)
[ http://jira.codehaus.org/browse/MRM-264?page=all ] Andrew Williams updated MRM-264: Attachment: archiva-latest-appserver.patch Updated patch to document the new URL on a plexus appserver > Update archiva to latest plexus appserver ( + container etc) > > > Key: MRM-264 > URL: http://jira.codehaus.org/browse/MRM-264 > Project: Archiva > Issue Type: Improvement > Components: system >Reporter: Andrew Williams > Assigned To: Jason van Zyl > Attachments: archiva-latest-appserver.patch, > archiva-latest-appserver.patch > > > The attached patch updates plexus-appserver and all related dependencies. > Tested and working here through the archiva-plexus-runtime. > I also altered the context path in archiva-plexus-application from '/' to > '/archiva' to be in-line with continuum. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-264) Update archiva to latest plexus appserver ( + container etc)
[ http://jira.codehaus.org/browse/MRM-264?page=all ] Andrew Williams updated MRM-264: Assignee: Jason van Zyl > Update archiva to latest plexus appserver ( + container etc) > > > Key: MRM-264 > URL: http://jira.codehaus.org/browse/MRM-264 > Project: Archiva > Issue Type: Improvement > Components: system >Reporter: Andrew Williams > Assigned To: Jason van Zyl > Attachments: archiva-latest-appserver.patch > > > The attached patch updates plexus-appserver and all related dependencies. > Tested and working here through the archiva-plexus-runtime. > I also altered the context path in archiva-plexus-application from '/' to > '/archiva' to be in-line with continuum. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-1101) Update continuum to the latest plexus appserver ( + container etc )
[ http://jira.codehaus.org/browse/CONTINUUM-1101?page=all ] Andrew Williams updated CONTINUUM-1101: --- Assignee: Jason van Zyl > Update continuum to the latest plexus appserver ( + container etc ) > --- > > Key: CONTINUUM-1101 > URL: http://jira.codehaus.org/browse/CONTINUUM-1101 > Project: Continuum > Issue Type: Improvement > Components: Core system >Affects Versions: 1.1 >Reporter: Andrew Williams > Assigned To: Jason van Zyl > Attachments: continuum-latest-appserver.patch > > > The attached patch updates plexus-appserver and all related dependencies. > Tested and working here through the continuum-plexus-runtime -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-264) Update archiva to latest plexus appserver ( + container etc)
Update archiva to latest plexus appserver ( + container etc) Key: MRM-264 URL: http://jira.codehaus.org/browse/MRM-264 Project: Archiva Issue Type: Improvement Components: system Reporter: Andrew Williams Attachments: archiva-latest-appserver.patch The attached patch updates plexus-appserver and all related dependencies. Tested and working here through the archiva-plexus-runtime. I also altered the context path in archiva-plexus-application from '/' to '/archiva' to be in-line with continuum. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1101) Update continuum to the latest plexus appserver ( + container etc )
Update continuum to the latest plexus appserver ( + container etc ) --- Key: CONTINUUM-1101 URL: http://jira.codehaus.org/browse/CONTINUUM-1101 Project: Continuum Issue Type: Improvement Components: Core system Affects Versions: 1.1 Reporter: Andrew Williams Attachments: continuum-latest-appserver.patch The attached patch updates plexus-appserver and all related dependencies. Tested and working here through the continuum-plexus-runtime -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSUREFIRE-169) resource not found through getResourceAsStream (works fine in Eclipse junit test runner)
[ http://jira.codehaus.org/browse/MSUREFIRE-169?page=comments#action_81683 ] Andrew Williams commented on MSUREFIRE-169: --- Whilst what you say is true I am not entirely certain it _should_ work The BytecodeClassLoader that you define does no lookups of it's own and does not delegate to a parent classloader. replacing the line "new BytecodeClassLoader()" in BytecodeClassLoaderTest to "getClass().getClassLoader()" (with the relevant field types changed) the tests wok. (If you get a null pointer exception then you need to make sure you do not force the use of getParent(), as getParent can return null quite validly) > resource not found through getResourceAsStream (works fine in Eclipse junit > test runner) > > > Key: MSUREFIRE-169 > URL: http://jira.codehaus.org/browse/MSUREFIRE-169 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Reporter: Valerio Schiavoni > Attachments: classloader-within-junittest.tgz > > > Running the attached test within eclipse, all tests pass. Running through mvn > test, there are 2 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] Updated: (MNG-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
[ http://jira.codehaus.org/browse/MNG-2678?page=all ] Andrew Williams updated MNG-2678: - Attachment: maven.new-latestplexus.patch Updated patch to upgrade to latest plexus/classworlds releases. These give us a stable bootstrap FINALLY! :) > Update maven embedder/core to use latest plexus and plexus-classworlds > -- > > Key: MNG-2678 > URL: http://jira.codehaus.org/browse/MNG-2678 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Andrew Williams > Attachments: latest-plexus.patch, latest-plexus2.patch, > latest-plexus3.patch, latest-plexus4.patch, maven.new-classworldsfix.patch, > maven.new-latestplexus.patch, maven.new-latestplexus.patch, > maven.new-scriptfixes.patch > > > This patch updates maven embedder and related core components to use the > latest plexus default-container and the classworlds now shipping inside the > plexus 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-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
[ http://jira.codehaus.org/browse/MNG-2678?page=all ] Andrew Williams updated MNG-2678: - Attachment: maven.new-scriptfixes.patch another patch for the scripts that start maven - pointing to the wrong mail class > Update maven embedder/core to use latest plexus and plexus-classworlds > -- > > Key: MNG-2678 > URL: http://jira.codehaus.org/browse/MNG-2678 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Andrew Williams > Attachments: latest-plexus.patch, latest-plexus2.patch, > latest-plexus3.patch, latest-plexus4.patch, maven.new-classworldsfix.patch, > maven.new-latestplexus.patch, maven.new-scriptfixes.patch > > > This patch updates maven embedder and related core components to use the > latest plexus default-container and the classworlds now shipping inside the > plexus 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-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
[ http://jira.codehaus.org/browse/MNG-2678?page=all ] Andrew Williams updated MNG-2678: - Attachment: maven.new-latestplexus.patch This patch updates maven.new to released classworlds and plexus > Update maven embedder/core to use latest plexus and plexus-classworlds > -- > > Key: MNG-2678 > URL: http://jira.codehaus.org/browse/MNG-2678 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Andrew Williams > Attachments: latest-plexus.patch, latest-plexus2.patch, > latest-plexus3.patch, latest-plexus4.patch, maven.new-classworldsfix.patch, > maven.new-latestplexus.patch > > > This patch updates maven embedder and related core components to use the > latest plexus default-container and the classworlds now shipping inside the > plexus 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-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
[ http://jira.codehaus.org/browse/MNG-2678?page=all ] Andrew Williams updated MNG-2678: - Attachment: maven.new-classworldsfix.patch This latest patch is against the maven.new branch and fixes broken imports related to the plexus-classworlds work > Update maven embedder/core to use latest plexus and plexus-classworlds > -- > > Key: MNG-2678 > URL: http://jira.codehaus.org/browse/MNG-2678 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Andrew Williams > Attachments: latest-plexus.patch, latest-plexus2.patch, > latest-plexus3.patch, latest-plexus4.patch, maven.new-classworldsfix.patch > > > This patch updates maven embedder and related core components to use the > latest plexus default-container and the classworlds now shipping inside the > plexus 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-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
[ http://jira.codehaus.org/browse/MNG-2678?page=all ] Andrew Williams updated MNG-2678: - Attachment: latest-plexus4.patch small updates on PluginDescriptor > Update maven embedder/core to use latest plexus and plexus-classworlds > -- > > Key: MNG-2678 > URL: http://jira.codehaus.org/browse/MNG-2678 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Andrew Williams > Attachments: latest-plexus.patch, latest-plexus2.patch, > latest-plexus3.patch, latest-plexus4.patch > > > This patch updates maven embedder and related core components to use the > latest plexus default-container and the classworlds now shipping inside the > plexus 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-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
[ http://jira.codehaus.org/browse/MNG-2678?page=all ] Andrew Williams updated MNG-2678: - Attachment: latest-plexus3.patch Jucier patch gets cutting edge classworlds and a little more success on the bootstrapping > Update maven embedder/core to use latest plexus and plexus-classworlds > -- > > Key: MNG-2678 > URL: http://jira.codehaus.org/browse/MNG-2678 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Andrew Williams > Attachments: latest-plexus.patch, latest-plexus2.patch, > latest-plexus3.patch > > > This patch updates maven embedder and related core components to use the > latest plexus default-container and the classworlds now shipping inside the > plexus 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-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
[ http://jira.codehaus.org/browse/MNG-2678?page=all ] Andrew Williams updated MNG-2678: - Attachment: latest-plexus2.patch updated patch to include maven-script, which is not in the parent pom > Update maven embedder/core to use latest plexus and plexus-classworlds > -- > > Key: MNG-2678 > URL: http://jira.codehaus.org/browse/MNG-2678 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Andrew Williams > Attachments: latest-plexus.patch, latest-plexus2.patch > > > This patch updates maven embedder and related core components to use the > latest plexus default-container and the classworlds now shipping inside the > plexus 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] Commented: (MNG-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
[ http://jira.codehaus.org/browse/MNG-2678?page=comments#action_80895 ] Andrew Williams commented on MNG-2678: -- I should say that this patch passes all tests including the core-integration-testing suite :) The only peculiarity that I can see is that for some reason the maven-core tests which pass from within the maven-core directory seeem to fail from the parent directory... > Update maven embedder/core to use latest plexus and plexus-classworlds > -- > > Key: MNG-2678 > URL: http://jira.codehaus.org/browse/MNG-2678 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Affects Versions: 2.0.5 >Reporter: Andrew Williams > Attachments: latest-plexus.patch > > > This patch updates maven embedder and related core components to use the > latest plexus default-container and the classworlds now shipping inside the > plexus 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] Created: (MNG-2678) Update maven embedder/core to use latest plexus and plexus-classworlds
Update maven embedder/core to use latest plexus and plexus-classworlds -- Key: MNG-2678 URL: http://jira.codehaus.org/browse/MNG-2678 Project: Maven 2 Issue Type: Improvement Components: Embedding Affects Versions: 2.0.5 Reporter: Andrew Williams Attachments: latest-plexus.patch This patch updates maven embedder and related core components to use the latest plexus default-container and the classworlds now shipping inside the plexus 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] Commented: (MNG-2351) mvn -X doesn't enable debugging
[ http://jira.codehaus.org/browse/MNG-2351?page=comments#action_77689 ]
Andrew Williams commented on MNG-2351:
--
as of today there is a setThresholds( int ) method on LoggerManager which can
be used to fix this issue.
Also the Logger has a setThreshold( int ), so you could
loggerManager.getLoggerForComponent( "blah" ).setThreshold( Logger.LEVEL_DEBUG )
> mvn -X doesn't enable debugging
> ---
>
> Key: MNG-2351
> URL: http://jira.codehaus.org/browse/MNG-2351
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.1
>Reporter: Jerome Lacoste
> Fix For: 2.0.5
>
>
> mvn -X doesn't enable debugging
> If I add the following code to DefaultMaven.execute(...)
> public void execute( MavenExecutionRequest request )
> throws MavenExecutionException
> [...]
>
> loggerManager.setThreshold( request.getLoggingLevel() );
> // ADDED
> loggerManager.getLoggerForComponent( Maven.ROLE ).info( "XXX logging
> level " + request.getLoggingLevel());
> loggerManager.getLoggerForComponent( Maven.ROLE ).debug( "XXX logging
> level " + request.getLoggingLevel());
> System.err.println("XXX logging level " + request.getLoggingLevel());
> System.err.println("XXX show errors " + request.isShowErrors());
> System.err.println("XXX logger threshold " +
> loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
> // end of ADDED
> I get:
> [INFO] XXX logging level 0
> XXX logging level 0
> XXX show errors true
> XXX logger threshold 1
> Looks like something is wrong with regard to thresholds in the Maven.ROLE
> component.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-21) Dependency on javax.mail should not be fixed on 1.3.2
[ http://jira.codehaus.org/browse/MCHANGES-21?page=comments#action_77639 ] Andrew Williams commented on MCHANGES-21: - Fixed in PLX-178 > Dependency on javax.mail should not be fixed on 1.3.2 > - > > Key: MCHANGES-21 > URL: http://jira.codehaus.org/browse/MCHANGES-21 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Environment: 2.0-beta-2-SNAPSHOT of the plugin, actually >Reporter: Grégory Joseph > Assigned To: fabrizio giustina > Fix For: 2.0-beta-2 > > > ... since javax.mail-1.3.2 is not available from sun anymore.. The dependency > should probably be [1.3,) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCLOVER-46) Coverage reports are incorrect for interface only modules.
[ http://jira.codehaus.org/browse/MCLOVER-46?page=comments#action_77021 ]
Andrew Williams commented on MCLOVER-46:
Now that maven-clover-plugin 2.3 has been released I crossed all my fingers,
but now we have a different error:
[ERROR] Total coverage of -100% did not meet target of 1%
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Build failed to meet Clover coverage targets
[INFO]
> Coverage reports are incorrect for interface only modules.
> ---
>
> Key: MCLOVER-46
> URL: http://jira.codehaus.org/browse/MCLOVER-46
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: ubuntu dapper drake. Maven 2.0, clover maven plugin 2.2
>Reporter: Meghan Claire Pike
> Assigned To: Vincent Massol
>
> Our projects require a coverage of at least 1% in order to force everyone to
> at least think about testing. Unfortunately for interface only packages, (due
> to seperation of concerns) clover just goes into a small spasm and dies. It's
> output is like this:
> Clover Version 1.3.12, built on February 08 2006
> loaded from:
> .m2/repository/com/cenqua/clover/clover/1.3.12/clover-1.3.12.jar
> Academic License registered to EDINA. This license of Clover is provided to
> support coursework at EDINA only.
> You have 29 day(s) before your Academic License expires.
> Updating database at 'target/clover/clover.db'
> Processing files at 1.4 source level.
> Instrumented 12 source files.
> ...
> [INFO] [clover:instrument {execution: default}]
> [INFO] [clover:check {execution: default}]
> [INFO] Checking for coverage of [1%] for database [target/clover/clover.db]
> WARN: No coverage data found for '/target/clover/clover.db'.
> [ERROR] Total coverage of did not meet target of 1%
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Build failed to meet Clover coverage targets
> it doesn't even output 0% or anything like that, which seems to me to be a
> bug. I think clover should maybe understand a little better that testing
> api's doesn't make sense, and is quite difficult to do. I don't have any
> testing classes whatsoever in the project, so it could be from that. But
> clover should have some ability not to enforce coverage on interfaces. (Or
> understand that they can't be tested except indirectly.)
> 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: (CONTINUUM-881) Multiple changesets can produce failure
[ http://jira.codehaus.org/browse/CONTINUUM-881?page=all ] Andrew Williams updated CONTINUUM-881: -- Attachment: ct38.patch newer patch - applies from continuum root :) (trunk) > Multiple changesets can produce failure > --- > > Key: CONTINUUM-881 > URL: http://jira.codehaus.org/browse/CONTINUUM-881 > Project: Continuum > Issue Type: Bug > Components: XMLRPC Interface >Affects Versions: 1.0.3 > Environment: Debian GNU Linux >Reporter: Andrew Williams >Priority: Minor > Attachments: ct38.patch, ct38.patch > > > There have been reports > (http://dev.rectang.com/projects/continutrac/ticket/38) that the author, > comment and revision fields are not always present so this patch was created > to work happily if this is the 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] Created: (CONTINUUM-881) Multiple changesets can produce failure
Multiple changesets can produce failure --- Key: CONTINUUM-881 URL: http://jira.codehaus.org/browse/CONTINUUM-881 Project: Continuum Issue Type: Bug Components: XMLRPC Interface Affects Versions: 1.0.3 Environment: Debian GNU Linux Reporter: Andrew Williams Priority: Minor Attachments: ct38.patch There have been reports (http://dev.rectang.com/projects/continutrac/ticket/38) that the author, comment and revision fields are not always present so this patch was created to work happily if this is the 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] Commented: (MAVENUPLOAD-1032) IRCLib from org.schwering
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1032?page=comments#action_72226 ] Andrew Williams commented on MAVENUPLOAD-1032: -- I have updated the pom in the bundle (new version at the same URL) org.schwering is correct, go to http://schwering.org/ and click on "~chs" - you will see IRCLib listed... > IRCLib from org.schwering > - > > Key: MAVENUPLOAD-1032 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1032 > Project: maven-upload-requests > Issue Type: Task >Reporter: Andrew Williams > > IRClib is a free Java implementation of the IRC protocol. > The upload is needed to support some new Plexus IRC features :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1032) IRCLib from org.schwering
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1032?page=comments#action_72220 ] Andrew Williams commented on MAVENUPLOAD-1032: -- OK, I see - suppose org.schwering is better. No, there are no dependencies. Do you need a new bundle for different groupId? > IRCLib from org.schwering > - > > Key: MAVENUPLOAD-1032 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1032 > Project: maven-upload-requests > Issue Type: Task >Reporter: Andrew Williams > > IRClib is a free Java implementation of the IRC protocol. > The upload is needed to support some new Plexus IRC features :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1032) IRCLib from org.schwering
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1032?page=comments#action_72181 ] Andrew Williams commented on MAVENUPLOAD-1032: -- Many apologies - I must have been very tired at the time the correct URL is: http://maven.rectang.com/irclib-1.04-bsd_uploadbundle.jar > IRCLib from org.schwering > - > > Key: MAVENUPLOAD-1032 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1032 > Project: maven-upload-requests > Issue Type: Task >Reporter: Andrew Williams > > IRClib is a free Java implementation of the IRC protocol. > The upload is needed to support some new Plexus IRC features :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1032) IRCLib from org.schwering
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1032?page=comments#action_72178 ] Andrew Williams commented on MAVENUPLOAD-1032: -- The pom.xml is insie the jar, as dictated by http://maven.apache.org/guides/mini/guide-ibiblio-upload.html > IRCLib from org.schwering > - > > Key: MAVENUPLOAD-1032 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1032 > Project: maven-upload-requests > Issue Type: Task >Reporter: Andrew Williams > > IRClib is a free Java implementation of the IRC protocol. > The upload is needed to support some new Plexus IRC features :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1032) IRCLib from org.schwering
IRCLib from org.schwering - Key: MAVENUPLOAD-1032 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1032 Project: maven-upload-requests Issue Type: Task Reporter: Andrew Williams IRClib is a free Java implementation of the IRC protocol. The upload is needed to support some new Plexus IRC features :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-753) buildNumber is incorrectly reported if a build fails after a build has suceedded
[ http://jira.codehaus.org/browse/CONTINUUM-753?page=comments#action_71778 ] Andrew Williams commented on CONTINUUM-753: --- any chance of getting this applied? > buildNumber is incorrectly reported if a build fails after a build has > suceedded > > > Key: CONTINUUM-753 > URL: http://jira.codehaus.org/browse/CONTINUUM-753 > Project: Continuum > Issue Type: Bug > Components: XMLRPC Interface >Affects Versions: 1.0.3 > Environment: debian linux / ubuntu linux >Reporter: Andrew Williams >Priority: Minor > Fix For: 1.1 > > Attachments: buildnumber.patch > > > If buildNumber is 0 then it is blanked by the python. > Unfortunately the buildNumber is reported as the last successful, so we need > to blank it if the build nwas not successful, not if the number is 0 > Attatched patch on continuum-core-it does just that -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-754) build details lists build numbers for build that have failed
[ http://jira.codehaus.org/browse/CONTINUUM-754?page=comments#action_71777 ] Andrew Williams commented on CONTINUUM-754: --- any chance on this getting applied? > build details lists build numbers for build that have failed > > > Key: CONTINUUM-754 > URL: http://jira.codehaus.org/browse/CONTINUUM-754 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0.3 > Environment: dbian linux / ubuntu linux >Reporter: Andrew Williams >Priority: Minor > Fix For: 1.1 > > Attachments: web-buildid.patch > > > The build list correctly omits the build number if a build has failed, but > the build details page lists the number of the last successful build instead > of omitting 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: (CONTINUUM-808) continuum-core-it does not use sever time zone
continuum-core-it does not use sever time zone -- Key: CONTINUUM-808 URL: http://jira.codehaus.org/browse/CONTINUUM-808 Project: Continuum Issue Type: Bug Environment: Debian Linux Reporter: Andrew Williams Attachments: it-localtime.patch Propagating a patch from continutrac whereby the times are in UTC rather than servers timezone. patch applies in the continuum-core-it directpry, on top of other patches I have submitted -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCLOVER-46) Coverage reports are incorrect for interface only modules.
[ http://jira.codehaus.org/browse/MCLOVER-46?page=comments#action_70596 ]
Andrew Williams commented on MCLOVER-46:
Assuming that by "Matthew" you meant me then I see, thanks for pointing this
out.
If there is no db then it should indeed ignore this and pass with a warning.
Assuming that this change will not allow projectst with no tests that _do_ need
some to pass ;)
Andrew
> Coverage reports are incorrect for interface only modules.
> ---
>
> Key: MCLOVER-46
> URL: http://jira.codehaus.org/browse/MCLOVER-46
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: ubuntu dapper drake. Maven 2.0, clover maven plugin 2.2
>Reporter: Meghan Claire Pike
> Assigned To: Vincent Massol
>
> Our projects require a coverage of at least 1% in order to force everyone to
> at least think about testing. Unfortunately for interface only packages, (due
> to seperation of concerns) clover just goes into a small spasm and dies. It's
> output is like this:
> Clover Version 1.3.12, built on February 08 2006
> loaded from:
> .m2/repository/com/cenqua/clover/clover/1.3.12/clover-1.3.12.jar
> Academic License registered to EDINA. This license of Clover is provided to
> support coursework at EDINA only.
> You have 29 day(s) before your Academic License expires.
> Updating database at 'target/clover/clover.db'
> Processing files at 1.4 source level.
> Instrumented 12 source files.
> ...
> [INFO] [clover:instrument {execution: default}]
> [INFO] [clover:check {execution: default}]
> [INFO] Checking for coverage of [1%] for database [target/clover/clover.db]
> WARN: No coverage data found for '/target/clover/clover.db'.
> [ERROR] Total coverage of did not meet target of 1%
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Build failed to meet Clover coverage targets
> it doesn't even output 0% or anything like that, which seems to me to be a
> bug. I think clover should maybe understand a little better that testing
> api's doesn't make sense, and is quite difficult to do. I don't have any
> testing classes whatsoever in the project, so it could be from that. But
> clover should have some ability not to enforce coverage on interfaces. (Or
> understand that they can't be tested except indirectly.)
> 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: (MCLOVER-46) Coverage reports are incorrect for interface only modules.
[ http://jira.codehaus.org/browse/MCLOVER-46?page=comments#action_70592 ]
Andrew Williams commented on MCLOVER-46:
Sorry - but I would have to disagree with the closure. It seems to me that the
line
"Total coverage of did not meet target of 1%"
contains a bug whether you agree with the requested change or not.
All code must have a coverage surely? if there are no tests for code that must
be tested then the coverage is "0%" not "".
I tend to agree here, that if the code requires no coverage then the absense of
testing seems to imply 100% not 0% and certainly not ""
The bug here is that if there were class in the code the coverage would be 0%
but with only interfaces it is broken.
> Coverage reports are incorrect for interface only modules.
> ---
>
> Key: MCLOVER-46
> URL: http://jira.codehaus.org/browse/MCLOVER-46
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: ubuntu dapper drake. Maven 2.0, clover maven plugin 2.2
>Reporter: Meghan Claire Pike
> Assigned To: Vincent Massol
>
> Our projects require a coverage of at least 1% in order to force everyone to
> at least think about testing. Unfortunately for interface only packages, (due
> to seperation of concerns) clover just goes into a small spasm and dies. It's
> output is like this:
> Clover Version 1.3.12, built on February 08 2006
> loaded from:
> .m2/repository/com/cenqua/clover/clover/1.3.12/clover-1.3.12.jar
> Academic License registered to EDINA. This license of Clover is provided to
> support coursework at EDINA only.
> You have 29 day(s) before your Academic License expires.
> Updating database at 'target/clover/clover.db'
> Processing files at 1.4 source level.
> Instrumented 12 source files.
> ...
> [INFO] [clover:instrument {execution: default}]
> [INFO] [clover:check {execution: default}]
> [INFO] Checking for coverage of [1%] for database [target/clover/clover.db]
> WARN: No coverage data found for '/target/clover/clover.db'.
> [ERROR] Total coverage of did not meet target of 1%
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Build failed to meet Clover coverage targets
> it doesn't even output 0% or anything like that, which seems to me to be a
> bug. I think clover should maybe understand a little better that testing
> api's doesn't make sense, and is quite difficult to do. I don't have any
> testing classes whatsoever in the project, so it could be from that. But
> clover should have some ability not to enforce coverage on interfaces. (Or
> understand that they can't be tested except indirectly.)
> 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: (MSITE-163) site modules menu does not inherit
site modules menu does not inherit -- Key: MSITE-163 URL: http://jira.codehaus.org/browse/MSITE-163 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: ubuntu linux / debian linux Reporter: Andrew Williams if I have a site.xml in a parent project that contains the line it is not inherited by child projects. works, as does parent. This happens when the parent project has no modules of its own. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2452) parameter parse error
parameter parse error - Key: MNG-2452 URL: http://jira.codehaus.org/browse/MNG-2452 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.3 Environment: ubuntu linux Reporter: Andrew Williams Priority: Minor typing "mvn -Uinstall" will result on a forced update and then an install phase. This is incorrect (if we wish to be compatible with GNU type arguments) it should force "mvn -U install". "-Uinstall" should imply 8 options, not 1 and the install command -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSITE-162) maven -N site does not generate index.html
[ http://jira.codehaus.org/browse/MSITE-162?page=comments#action_69949 ] Andrew Williams commented on MSITE-162: --- Sorry, I was not clear, here goes correcting that maven2 (yes, I know mvn, I just write maven out of habbit) this is a multi-module build built from the root. (that I did mean to write earlier, must have got distracted) > maven -N site does not generate index.html > -- > > Key: MSITE-162 > URL: http://jira.codehaus.org/browse/MSITE-162 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: solaris 8 >Reporter: Andrew Williams > Assigned To: Brett Porter > > when using maven -N (through continuum) I run the site goal (and site:deploy) > but it fails to generate index.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] Reopened: (MSITE-162) maven -N site does not generate index.html
[ http://jira.codehaus.org/browse/MSITE-162?page=all ] Andrew Williams reopened MSITE-162: --- This is _not_ related (as far as I can tell from the comments in the other bug) my default index.html is produced fine saying "there is no description..." UNLESS I run -N > maven -N site does not generate index.html > -- > > Key: MSITE-162 > URL: http://jira.codehaus.org/browse/MSITE-162 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: solaris 8 >Reporter: Andrew Williams > Assigned To: Brett Porter > > when using maven -N (through continuum) I run the site goal (and site:deploy) > but it fails to generate index.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] Closed: (MCLOVER-43) Clover reports fail the build on pom projects
[ http://jira.codehaus.org/browse/MCLOVER-43?page=all ] Andrew Williams closed MCLOVER-43: -- Resolution: Fixed Fix Version: 2.2 Apologies, I see this was fixed in 2.2, which we had not updateded too - everything is just jolly now :) > Clover reports fail the build on pom projects > - > > Key: MCLOVER-43 > URL: http://jira.codehaus.org/browse/MCLOVER-43 > Project: Maven 2.x Clover Plugin > Type: Bug > Environment: ubuntu linux > Reporter: Andrew Williams > Fix For: 2.2 > > > If your project is using "pom" packaging (or any part of it) clover reports > will cause the build to fail saying "Unable to load database at > some/path/clover.db". > This db clearly never gets generated, as there are no source 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] Created: (MPSITE-53) maven -N site does not generate index.html
maven -N site does not generate index.html -- Key: MPSITE-53 URL: http://jira.codehaus.org/browse/MPSITE-53 Project: maven-site-plugin Type: Bug Components: plugin Environment: solaris 8 Reporter: Andrew Williams when using maven -N (through continuum) I run the site goal (and site:deploy) but it fails to generate index.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: (MCLOVER-43) Clover reports fail the build on pom projects
Clover reports fail the build on pom projects - Key: MCLOVER-43 URL: http://jira.codehaus.org/browse/MCLOVER-43 Project: Maven 2.x Clover Plugin Type: Bug Environment: ubuntu linux Reporter: Andrew Williams If your project is using "pom" packaging (or any part of it) clover reports will cause the build to fail saying "Unable to load database at some/path/clover.db". This db clearly never gets generated, as there are no source 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: (MCLOVER-43) Clover reports fail the build on pom projects
[ http://jira.codehaus.org/browse/MCLOVER-43?page=comments#action_68987 ] Andrew Williams commented on MCLOVER-43: this can be tested easily by typing "mvn clover:check" in any pom packaged project > Clover reports fail the build on pom projects > - > > Key: MCLOVER-43 > URL: http://jira.codehaus.org/browse/MCLOVER-43 > Project: Maven 2.x Clover Plugin > Type: Bug > Environment: ubuntu linux > Reporter: Andrew Williams > > > If your project is using "pom" packaging (or any part of it) clover reports > will cause the build to fail saying "Unable to load database at > some/path/clover.db". > This db clearly never gets generated, as there are no source 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: (MNG-2416) site.xml is not properly inherited from the parent
[ http://jira.codehaus.org/browse/MNG-2416?page=comments#action_68876 ] Andrew Williams commented on MNG-2416: -- OK, so if I do an mvn install in the non-parent package then the mvn site works correctly from that point onwards > site.xml is not properly inherited from the parent > -- > > Key: MNG-2416 > URL: http://jira.codehaus.org/browse/MNG-2416 > Project: Maven 2 > Type: Bug > Components: Sites & Reporting > Environment: debian linux / ubuntu linux > Reporter: Andrew Williams > Priority: Critical > > > the site.xml is only inherited from ../pom.xml (or whatever your relative > path) but NOT from the declared > this is causing me a headache -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-754) build details lists build numbers for build that have failed
[ http://jira.codehaus.org/browse/CONTINUUM-754?page=all ] Andrew Williams updated CONTINUUM-754: -- Attachment: web-buildid.patch > build details lists build numbers for build that have failed > > > Key: CONTINUUM-754 > URL: http://jira.codehaus.org/browse/CONTINUUM-754 > Project: Continuum > Type: Bug > Components: Web interface > Versions: 1.0.3 > Environment: dbian linux / ubuntu linux > Reporter: Andrew Williams > Priority: Minor > Fix For: 1.1 > Attachments: web-buildid.patch > > > The build list correctly omits the build number if a build has failed, but > the build details page lists the number of the last successful build instead > of omitting 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: (MNG-2416) site.xml is not properly inherited from the parent
site.xml is not properly inherited from the parent -- Key: MNG-2416 URL: http://jira.codehaus.org/browse/MNG-2416 Project: Maven 2 Type: Bug Components: Sites & Reporting Environment: debian linux / ubuntu linux Reporter: Andrew Williams Priority: Critical the site.xml is only inherited from ../pom.xml (or whatever your relative path) but NOT from the declared this is causing me a headache -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-754) build details lists build numbers for build that have failed
build details lists build numbers for build that have failed Key: CONTINUUM-754 URL: http://jira.codehaus.org/browse/CONTINUUM-754 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Environment: dbian linux / ubuntu linux Reporter: Andrew Williams Priority: Minor Fix For: 1.1 The build list correctly omits the build number if a build has failed, but the build details page lists the number of the last successful build instead of omitting 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: (CONTINUUM-753) buildNumber is incorrectly reported if a build fails after a build has suceedded
buildNumber is incorrectly reported if a build fails after a build has suceedded Key: CONTINUUM-753 URL: http://jira.codehaus.org/browse/CONTINUUM-753 Project: Continuum Type: Bug Components: XMLRPC Interface Versions: 1.0.3 Environment: debian linux / ubuntu linux Reporter: Andrew Williams Priority: Minor Fix For: 1.1 Attachments: buildnumber.patch If buildNumber is 0 then it is blanked by the python. Unfortunately the buildNumber is reported as the last successful, so we need to blank it if the build nwas not successful, not if the number is 0 Attatched patch on continuum-core-it does just that -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2414) SCP deployment echos pasword
SCP deployment echos pasword Key: MNG-2414 URL: http://jira.codehaus.org/browse/MNG-2414 Project: Maven 2 Type: Bug Environment: ubuntu linux Reporter: Andrew Williams Priority: Critical If you do not have keys set up and you upload via scp during a deploy phase the password is echoed to the user. very bad :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-746) cannot add a project from an ssl server with invalid hostname in certificate
cannot add a project from an ssl server with invalid hostname in certificate Key: CONTINUUM-746 URL: http://jira.codehaus.org/browse/CONTINUUM-746 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Environment: debian linux / ubuntu linux Reporter: Andrew Williams Priority: Minor If the hostname in an ssl certificate used by an https server that is referenced in a URL is incorrect there is a large stack trace outputted and the error "The URL you provided doesn't exist" the trace is: jvm 1| java.io.IOException: HTTPS hostname wrong: should be jvm 1| at sun.net.www.protocol.https.HttpsClient.b(DashoA12275) jvm 1| at sun.net.www.protocol.https.HttpsClient.afterConnect(Dash 75) jvm 1| at sun.net.www.protocol.https.AbstractDelegateHttpsURLConne .connect(DashoA12275) jvm 1| at sun.net.www.protocol.http.HttpURLConnection.getInputStre tpURLConnection.java:626) jvm 1| at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInp eam(DashoA12275) jvm 1| at org.codehaus.plexus.formica.util.MungedHttpsURL.isValid( dHttpsURL.java:111) jvm 1| at org.codehaus.plexus.formica.validation.UrlSourceValidato idate(UrlSourceValidator.java:63) jvm 1| at org.codehaus.plexus.formica.DefaultFormManager.validateE ts(DefaultFormManager.java:195) jvm 1| at org.codehaus.plexus.formica.DefaultFormManager.validate( ltFormManager.java:124) jvm 1| at org.codehaus.plexus.formica.DefaultFormManager.validate( ltFormManager.java:114) jvm 1| at org.codehaus.plexus.formica.action.AbstractEntityAction. te(AbstractEntityAction.java:107) jvm 1| at org.codehaus.plexus.summit.pipeline.valve.ActionValve.in ActionValve.java:68) jvm 1| at org.codehaus.plexus.summit.pipeline.AbstractPipeline.inv bstractPipeline.java:70) jvm 1| at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) jvm 1| at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108 jvm 1| at javax.servlet.http.HttpServlet.service(HttpServlet.java: < rest omitted > suggest that this should be permitted with a warning or such notice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-745) Uploading pom file does not support projects with modules
Uploading pom file does not support projects with modules - Key: CONTINUUM-745 URL: http://jira.codehaus.org/browse/CONTINUUM-745 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Environment: debian linux / ubuntu linux Reporter: Andrew Williams Priority: Critical Uploaded pom files cannot contain sub modules. I see in issue CONTINUUM-425 that this is known, but it really should be possible to fix. Can we not just read the scm and download _before_ trying to read the child poms? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-735) XmlRpc does not expose getBuildOutput
[ http://jira.codehaus.org/browse/CONTINUUM-735?page=all ] Andrew Williams updated CONTINUUM-735: -- Attachment: all_changes.patch > XmlRpc does not expose getBuildOutput > - > > Key: CONTINUUM-735 > URL: http://jira.codehaus.org/browse/CONTINUUM-735 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Debian linux etc > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: DefaultContinuumXmlRpc_java.patch, all_changes.patch, > continuum_py-tidy.patch, continuum_py-tidy.patch, continuum_py.patch > > > the XmlRpc does not expose the rather useful getBuildOutput method. > The attatched patches against DefaultContinuumXmlRpc.java in comtinuum-xmlrpc > the module and continuum.py in the continuum-core-it module fixes this. > Both patches are against current svn (1.1-SNAPSHOT) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-735) XmlRpc does not expose getBuildOutput
[ http://jira.codehaus.org/browse/CONTINUUM-735?page=all ] Andrew Williams updated CONTINUUM-735: -- Attachment: continuum_py-tidy.patch > XmlRpc does not expose getBuildOutput > - > > Key: CONTINUUM-735 > URL: http://jira.codehaus.org/browse/CONTINUUM-735 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Debian linux etc > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: DefaultContinuumXmlRpc_java.patch, continuum_py-tidy.patch, > continuum_py-tidy.patch, continuum_py.patch > > > the XmlRpc does not expose the rather useful getBuildOutput method. > The attatched patches against DefaultContinuumXmlRpc.java in comtinuum-xmlrpc > the module and continuum.py in the continuum-core-it module fixes this. > Both patches are against current svn (1.1-SNAPSHOT) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-735) XmlRpc does not expose getBuildOutput
[ http://jira.codehaus.org/browse/CONTINUUM-735?page=comments#action_68200 ] Andrew Williams commented on CONTINUUM-735: --- by "this patch" I meant continuum_py-tidy.patch. It should be applied after continuum_py.patch > XmlRpc does not expose getBuildOutput > - > > Key: CONTINUUM-735 > URL: http://jira.codehaus.org/browse/CONTINUUM-735 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Debian linux etc > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: DefaultContinuumXmlRpc_java.patch, continuum_py-tidy.patch, > continuum_py.patch > > > the XmlRpc does not expose the rather useful getBuildOutput method. > The attatched patches against DefaultContinuumXmlRpc.java in comtinuum-xmlrpc > the module and continuum.py in the continuum-core-it module fixes this. > Both patches are against current svn (1.1-SNAPSHOT) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-735) XmlRpc does not expose getBuildOutput
[ http://jira.codehaus.org/browse/CONTINUUM-735?page=all ] Andrew Williams updated CONTINUUM-735: -- Attachment: continuum_py-tidy.patch > XmlRpc does not expose getBuildOutput > - > > Key: CONTINUUM-735 > URL: http://jira.codehaus.org/browse/CONTINUUM-735 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Debian linux etc > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: DefaultContinuumXmlRpc_java.patch, continuum_py-tidy.patch, > continuum_py.patch > > > the XmlRpc does not expose the rather useful getBuildOutput method. > The attatched patches against DefaultContinuumXmlRpc.java in comtinuum-xmlrpc > the module and continuum.py in the continuum-core-it module fixes this. > Both patches are against current svn (1.1-SNAPSHOT) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-735) XmlRpc does not expose getBuildOutput
XmlRpc does not expose getBuildOutput - Key: CONTINUUM-735 URL: http://jira.codehaus.org/browse/CONTINUUM-735 Project: Continuum Type: Improvement Components: XMLRPC Interface Environment: Debian linux etc Reporter: Andrew Williams Fix For: 1.1 Attachments: DefaultContinuumXmlRpc_java.patch, continuum_py.patch the XmlRpc does not expose the rather useful getBuildOutput method. The attatched patches against DefaultContinuumXmlRpc.java in comtinuum-xmlrpc the module and continuum.py in the continuum-core-it module fixes this. Both patches are against current svn (1.1-SNAPSHOT) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-732) Add dependencies to the python code in continuum-core-it
[ http://jira.codehaus.org/browse/CONTINUUM-732?page=all ] Andrew Williams updated CONTINUUM-732: -- Attachment: core-it.patch > Add dependencies to the python code in continuum-core-it > > > Key: CONTINUUM-732 > URL: http://jira.codehaus.org/browse/CONTINUUM-732 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Linux Debian, python 2.3 > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: DefaultContinuumXmlRpc_java.patch, > DefaultContinuumXmlRpc_java.patch, core-it.patch, core-it.patch, core-it.patch > > > The attatched patch fixes up continuum-core-it python code to work agains the > current (as of 1.0.3) version of the XMLRPC. > It adds dependency support. > The buldResults portion is commented out as it does not work now - I will fix > that next (needs work to the XMLRPC implementation first) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-732) Add dependencies to the python code in continuum-core-it
[ http://jira.codehaus.org/browse/CONTINUUM-732?page=all ] Andrew Williams updated CONTINUUM-732: -- Attachment: DefaultContinuumXmlRpc_java.patch > Add dependencies to the python code in continuum-core-it > > > Key: CONTINUUM-732 > URL: http://jira.codehaus.org/browse/CONTINUUM-732 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Linux Debian, python 2.3 > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: DefaultContinuumXmlRpc_java.patch, > DefaultContinuumXmlRpc_java.patch, core-it.patch, core-it.patch, core-it.patch > > > The attatched patch fixes up continuum-core-it python code to work agains the > current (as of 1.0.3) version of the XMLRPC. > It adds dependency support. > The buldResults portion is commented out as it does not work now - I will fix > that next (needs work to the XMLRPC implementation first) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-547) build results cannot be accessed from xmlrpc
[ http://jira.codehaus.org/browse/CONTINUUM-547?page=comments#action_67883 ] Andrew Williams commented on CONTINUUM-547: --- the patch to DefaultContinuumXmlRpc.java on http://jira.codehaus.org/browse/CONTINUUM-732 enables the method getBuildResultsForProject which summarises all build results. I plan to add another to get the details (changes, output etc) if this one gets accepted. Hope it helps > build results cannot be accessed from xmlrpc > > > Key: CONTINUUM-547 > URL: http://jira.codehaus.org/browse/CONTINUUM-547 > Project: Continuum > Type: Bug > Components: XMLRPC Interface > Reporter: Milos Kleint > > > calls to getProjects() or getProject(id) never return any build results... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-732) Add dependencies to the python code in continuum-core-it
[ http://jira.codehaus.org/browse/CONTINUUM-732?page=comments#action_67882 ] Andrew Williams commented on CONTINUUM-732: --- OK - so I just uploaded 2 more patches (the old core-it.patch is now out of date) this adds BuildResults listing to what we previously supported > Add dependencies to the python code in continuum-core-it > > > Key: CONTINUUM-732 > URL: http://jira.codehaus.org/browse/CONTINUUM-732 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Linux Debian, python 2.3 > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: DefaultContinuumXmlRpc_java.patch, core-it.patch, core-it.patch > > > The attatched patch fixes up continuum-core-it python code to work agains the > current (as of 1.0.3) version of the XMLRPC. > It adds dependency support. > The buldResults portion is commented out as it does not work now - I will fix > that next (needs work to the XMLRPC implementation first) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-732) Add dependencies to the python code in continuum-core-it
[ http://jira.codehaus.org/browse/CONTINUUM-732?page=all ] Andrew Williams updated CONTINUUM-732: -- Attachment: DefaultContinuumXmlRpc_java.patch > Add dependencies to the python code in continuum-core-it > > > Key: CONTINUUM-732 > URL: http://jira.codehaus.org/browse/CONTINUUM-732 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Linux Debian, python 2.3 > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: DefaultContinuumXmlRpc_java.patch, core-it.patch, core-it.patch > > > The attatched patch fixes up continuum-core-it python code to work agains the > current (as of 1.0.3) version of the XMLRPC. > It adds dependency support. > The buldResults portion is commented out as it does not work now - I will fix > that next (needs work to the XMLRPC implementation first) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-732) Add dependencies to the python code in continuum-core-it
[ http://jira.codehaus.org/browse/CONTINUUM-732?page=all ] Andrew Williams updated CONTINUUM-732: -- Attachment: core-it.patch > Add dependencies to the python code in continuum-core-it > > > Key: CONTINUUM-732 > URL: http://jira.codehaus.org/browse/CONTINUUM-732 > Project: Continuum > Type: Improvement > Components: XMLRPC Interface > Environment: Linux Debian, python 2.3 > Reporter: Andrew Williams > Fix For: 1.1 > Attachments: core-it.patch, core-it.patch > > > The attatched patch fixes up continuum-core-it python code to work agains the > current (as of 1.0.3) version of the XMLRPC. > It adds dependency support. > The buldResults portion is commented out as it does not work now - I will fix > that next (needs work to the XMLRPC implementation first) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-732) Add dependencies to the python code in continuum-core-it
Add dependencies to the python code in continuum-core-it Key: CONTINUUM-732 URL: http://jira.codehaus.org/browse/CONTINUUM-732 Project: Continuum Type: Improvement Components: XMLRPC Interface Environment: Linux Debian, python 2.3 Reporter: Andrew Williams Fix For: 1.0.3 Attachments: core-it.patch The attatched patch fixes up continuum-core-it python code to work agains the current (as of 1.0.3) version of the XMLRPC. It adds dependency support. The buldResults portion is commented out as it does not work now - I will fix that next (needs work to the XMLRPC implementation first) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-522) IRC support needed for IRC servers not supporting /privmsg
[ http://jira.codehaus.org/browse/CONTINUUM-522?page=comments#action_67816 ] Andrew Williams commented on CONTINUUM-522: --- I think this might be needed for freenode.net too, as I cannot get the bot to report to that network... > IRC support needed for IRC servers not supporting /privmsg > -- > > Key: CONTINUUM-522 > URL: http://jira.codehaus.org/browse/CONTINUUM-522 > Project: Continuum > Type: Improvement > Components: IRC Notifier > Versions: 1.0.2 > Environment: Linux > Reporter: Daniel Kulp > > > The IRC server we use in house does not support /privmsg for any non-operator > user. The IS folks are refusing to add any other operators for use by the > continuum builds. > It would be nice if we could configure the IRC notifier to do a normal: > /join #channel > and then a normal text message is sent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
