Re: MNG-5799

- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5799

Am 03/01/16 um 20:47 schrieb Robert Scholte: > If many projects suddenly break we should really decide if this is worth > implementing or that we need to teach our users to RTFM ;) That's not documented anywhere. People order the plugin declarations intuitively. Current behaviour is the result

MNG-5799

Before doing anything about it, I'd like to ask here first. Is the Maven 2 behaviour really what should be retained? I would need to revert some "regression" commits making Maven 3 behave the same way Maven 2 did. People are reporting the Maven 2 behaviour as being broken independently. I would

maven-3.3-release-status-test-windows

Can someone take a look at the setup of the 'maven-3.3-release-status-test-windows' [1] jenkins build job please. It fails with the following message since nearly weeks. We also have had users report that error message. I would like to know if there is an issue with the 'mvn.bat' script I fail to

Re: Please review Re: maven git commit: [MNG-5984] Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml

Am 02/26/16 um 12:04 schrieb Arnaud Héritier: > Hi Christian, > > Isn't it possible to add some tests here ? > Also something I'm not sure to understand in the case is if the user has > another profile activated > AFAIR activeByDefault activates a profile only if no profile is manually >

Re: Julia Antonova is out of office.

Must have been really busy the last years not leaving the office. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

MNG-5959 - Different wording, same use case. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

Am 01/29/16 um 11:50 schrieb Robert Scholte: Hi, What interested me is that is seems to be the intention to NOT manage the optional flag.[1] It's one of those issues flagged a regression in Maven 3 which hasn't been. Maven 2 just did not have support for it. It got removed for Maven 3.0 in

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

Can someone please take a look at this? MNG-5227 is already checked in (with IT) and I would not want to revert it. It is triggering a bug in Aether I just reported and provided a patch for. How to procceed? Am 01/28/16 um 17:37 schrieb Christian Schulte (JIRA): [ https

Re: maven git commit: [MNG-5607] Don't use M2_HOME anymore in mvn shell/batch file anymore

Am 27.01.2016 um 11:02 schrieb Arnaud Héritier: -1 See https://issues.apache.org/jira/browse/MNG-5607 Ok to introduce MVN_HOME with M2_HOME value as default when defined (and then remove M2_HOME in Maven 4) But replacing M2_HOME by MVN_HOME in 3.4 seems to be a risky change for our ecosystem

Re: core-integration-testing-maven-3-jdk-1.7 - Build # 1687 - Still Failing

um 08:43 schrieb Christian Schulte: Hi, can someone take a look at that build node, please. Jenkins is currently sending out emails about failing ITs not failing locally here. I think the root cause for this is the following exception right at the start of the ITs. Setting -Djava.io.tmpdir

Re: core-integration-testing-maven-3-jdk-1.7 - Build # 1687 - Still Failing

Hi, can someone take a look at that build node, please. Jenkins is currently sending out emails about failing ITs not failing locally here. I think the root cause for this is the following exception right at the start of the ITs. Setting -Djava.io.tmpdir to point to somewhere inside the

Re: svn commit: r1719483 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/markup/ doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-core/src/main/java/org/apa

Am 12/12/15 um 11:20 schrieb Hervé BOUTEMY: is an API change in Doxia Sink API really necessary to add this HTML-specific feature (in very specific context)? Not really that HTML-specific any more. I just renamed the method from 'ssi' to 'directive' locally. Because whatever how the method

Re: svn commit: r1719483 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/markup/ doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-core/src/main/java/org/apa

Am 12/12/15 um 11:52 schrieb Hervé BOUTEMY: what means "a directive" in markdown? fml? confluence? LaTex? xdoc? I know "directive" word is more generic than "ssi", but the only useful case I know is when generated html is put on a web server that supports such directives then just handling this

Re: svn commit: r1719483 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/markup/ doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-core/src/main/java/org/apa

Am 12/11/15 um 20:18 schrieb Robert Scholte: Hi Christian, first of all: welcome! about this commit: It took a while before I understood the term 'ssi'. ssi is an abbreviation, not that clear and IMHO it suggest that this page includes dynamic content fro a server, making this content dynamic

Re: Reproducibility versus ranges

Am 26.10.2015 um 15:54 schrieb Benson Margulies: Am I missing something? Could it be that the release process somehow resolves the ranges and writes them into the poms? This is what 'mvn release:prepare-with-pom' would do. Regards, -- Christian

Re: [VOTE] Release Apache Maven JavaDoc Plugin version 2.10.2

What about http://jira.codehaus.org/browse/MJAVADOC-414 http://jira.codehaus.org/browse/MJAVADOC-418 ? It's a regression introduced in 2.10 and stopping people from upgrading. I doubt someone needing the fix to http://jira.codehaus.org/browse/MJAVADOC-365 will upgrade due to that issue.

Re: [VOTE] Maven 3.2.4 Release

Maybe consider upgrading to Aether '1.0.1.v2014' ? Am 12/13/14 um 00:38 schrieb Igor Fedorenko: Unfortunately, I have to take this back. The changes to toolchain broke Tycho and, short of using reflection, I don't see how to make Tycho work with maven 3.2.4 and earlier versions of Maven.

Re: Maven plugin naming pattern

Am 10/10/14 14:00, schrieb Karl Heinz Marbaise: Hi, On 10/10/14 1:25 PM, Michael Osipov wrote: They should rename going forward. At some point (probably we could do so now) we will turn on enforcement in the maven-plugin-plugin. This will of course piss of a lot of people. Wouldn't it?

How to deploy to a stock WebDAV enabled Apache httpd without modifying Maven installation ?

Subject says it all. Deployment fails PUTting to non-existent directories with HTTP 409. Is it correct that deploying to a WebDAV enabled Apache httpd can only be done by updating the local Maven installation adding support for WebDAV like $ ls -lah lib/ext/ total 1492 drwxr-xr-x 2 schulte

Re: Potential depMgt import bug was Re: [ANN] Apache Maven 3.2.2 Release

Am 17.07.2014 04:07, schrieb Timothy Astle: I believe I hit the same problem. This only surfaced after moving to 3.2.2. My project might not be as large as Arnaud's, but it's closed source. I'm definitely willing to help debug the issue if needed. Did you try executing 'mvn -U' already ?

Re: Potential depMgt import bug was Re: [ANN] Apache Maven 3.2.2 Release

Am 17.07.2014 11:46, schrieb Arnaud Héritier: if projectA imports projectB which imports projectC then maven doesn't try to download projectC pom with 3.2.2 I will report a new issue because I'm not sure that it is related (but probably) to MNG-5663 http://jira.codehaus.org/browse/MNG-5663 I'll

Re: Potential depMgt import bug was Re: [ANN] Apache Maven 3.2.2 Release

Am 17.07.2014 12:57, schrieb Arnaud Héritier: On Thu, Jul 17, 2014 at 12:41 PM, Christian Schulte c...@schulte.it wrote: Am 17.07.2014 11:46, schrieb Arnaud Héritier: if projectA imports projectB which imports projectC then maven doesn't try to download projectC pom with 3.2.2 I will report

Re: POM 5.0 and Maven.next idea - re: repository's

Am 06/26/14 17:18, schrieb Stephen Connolly: And the staleness is another killer on the: oh why don't we use DNS records to resolve the repository because what if foobar.org do not renew their domain, now all the org.foobar artifacts will just drop off the net and we have no means to inject a

Re: Topics for Maven Development Hangout

Am 06/19/14 17:51, schrieb Tamás Cservenák: I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have

Re: [GitHub] maven pull request: [MNG-2199] Version ranges not supported for pa...

Am 06/14/14 08:39, schrieb Hervé BOUTEMY: this is one of the problems when using version ranges, tied to reproducibility and definition of the algorithm for Maven to choose one version in the range adapted to the actual context. It's not only about version ranges. It seems inconsistent to

Re: [GitHub] maven pull request: [MNG-2199] Version ranges not supported for pa...

Am 06/14/14 04:50, schrieb talios: Github user talios commented on the pull request: https://github.com/apache/maven/pull/21#issuecomment-46076519 Interesting about the version range changes in aether there - whilst the [2.2.*] range is nice, that doesn't offer SNAPSHOT

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

Why Java 6 ? Seriously. It does not add any value to Maven compared to Java 5. Java 7 is what provides new APIs Maven could benefit from. Why give up on Java 5 in favour of Java 6 ? -- Christian - To unsubscribe, e-mail:

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

Am 07/24/13 03:10, schrieb jieryn: Greetings, On Tue, Jul 23, 2013 at 8:59 PM, Christian Schulte c...@schulte.it wrote: Why Java 6 ? Seriously. It does not add any value to Maven compared to Java 5. Java 7 is what provides new APIs Maven could benefit from. Why give up on Java 5 in favour

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

Am 07/24/13 04:00, schrieb jieryn: Move forward or die. If you are stuck on 1.5, you can continue to use a full stack that is already supported. I am so sick of hearing people complain that they will be broken if a JDK migration to a newer version is undertaken. No, you are not broken, you

Re: Fwd: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]

Perhaps we are at the point where we should start breaking builds rather than just giving a stern warning... certainly the warning has been there for long enough MNG-3762 Say there is a maven-whatever-plugin available in central which needs to be renamed to whatever-maven-plugin. Is there a

Re: Fwd: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]

Am 06/18/13 17:32, schrieb Stephen Connolly: relocation pom will not work for plugins... (we maybe should look into that though) Simplest is just to move to the new ID and tell your users to change... that's what jetty did Ok. Thanks for clarifying. -- Christian

Re: A very interesting performance regression in 3.1 embedded mode

Am 12/12/12 08:23, schrieb Milos Kleint: how much memory will be freed by the soft reference? if it's not a big chunk, most likely not worth it, soft references are released only when your VM is really, really in trouble. by the time it gets released, you've been slowed down by repeatedly

Re: A very interesting performance regression in 3.1 embedded mode

Am 12/09/12 22:58, schrieb Kristian Rosenvold: Anyone else have any ideas about eviction strategies ? Without having looked at the code. GC driven by using soft references. -- Christian - To unsubscribe, e-mail:

Re: [VOTE] Maven 3.1.0

Please do not update the site plugin to 3.2. See http://jira.codehaus.org/browse/MSITE-665. -- Christian Am 12/04/12 05:10, schrieb Jason van Zyl: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging

Re: 3.1.0 decision making

Am 12/01/12 19:03, schrieb Hervé BOUTEMY: Le samedi 1 décembre 2012 18:52:51 Dennis Lundberg a écrit : I would -1 any suggestion to start using the beta moniker again, at least for the changes made this far. I completely agree would it be more a milestone, to show the stable but work in

Re: To RC or not RC

Am 11/25/12 20:42, schrieb Jason van Zyl: I wish RCs were useful, but I don't believe anyone really looks or takes the time to even try anything until it's actually released. It's not hard to make RCs. So if folks want them, not a problem, I can roll an RC. Anyone have an opinion?

Re: To RC or not RC

Am 11/26/12 00:49, schrieb Jason van Zyl: It's easy enough to not push the tag, or blow it away. So I'll just stage it again. All I am saying is that this https://github.com/apache/maven-3/tree/maven-3.1.0 tag will be incorrect, if you ever need to re-create another 3.1.0 tag in subsversion

Re: Tentative release planning for 3.1.x

Am 11/11/12 05:58, schrieb Jason van Zyl: I have more cycles now, so I'd like to propose a tentative release schedule for the core and get some changes pushed out. 3.1.0 Release I'd like to finish the following and then do a 3.1.0 release. I don't think these changes should be conflated

Re: [VOTE] Release Maven Dependency Tree 2.0 + Maven Project Info Reports Plugin 2.5 + Maven Dependency Plugin 2.5

Am 07/31/12 07:21, schrieb Hervé BOUTEMY: please open a Jira issue with traces of the problem Done. MDEP-363. Thanks, -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:

Re: [VOTE] Release Maven Dependency Tree 2.0 + Maven Project Info Reports Plugin 2.5 + Maven Dependency Plugin 2.5

-1 (unbinding) The dependency plugin still contains 'System.out.println' statements. Am 07/30/12 22:50, schrieb Hervé BOUTEMY: Hi, We solved 2 + 7 + 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14540

Re: Depending on Artifacts not in central

Arnaud HERITIER schrieb: For the repository constraint I agree.But what can we recommend to jboss and others company which have this need to be a good maven citizen ? I'll have the same issue soon with my company exoplatform. We are interested to deploy nexus and push some of our artifacts in

Regarding MSANDBOX-46

Hi, a few weeks ago I contributed a maven-jarsigner-plugin which got committed to the maven sandbox. That plugin is meant to become the successor for the maven-jar-plugin:sign goal which does not support signing sources jar, javadoc jar or any other java capable artifact attached to a project. I

Re: proposal for cleaning up 2.x series releases / trees

Paul Benedict schrieb: My preference is to release 2.0.11 as it is now (37 issues fixed). The remaining issues should move to 2.2.1. If critical bugs remain in 2.0.x, then build build a 2.0.12 issue list as people require it. - Paul +1 2.0.x is the last JDK 1.4 release. Users of the GPG

Re: [VOTE] Maven 2.2.0 (Second Attempt)

John Casey schrieb: Hi, I'm opening a new vote for Maven 2.2.0 after closing: http://jira.codehaus.org/browse/MNG-4169 http://jira.codehaus.org/browse/MNG-4207 All URLs below have been updated where appropriate. --- This version displays log4j:WARN No appenders could be

Re: [VOTE] Maven 2.2.0 (Second Attempt)

John Casey schrieb: This would be because of the recent addition of log4j, which is now shaded into the Maven binary (bundled with a changed package structure to keep it out of the way of plugins' own log4j dependencies). httpclient is using log4j because it's available, but log4j doesn't

Re: Progress on support for large projects

Ralph Goers schrieb: They just shouldn't change things significantly without good arguments. Which are only the ones you agree with? I am really just trying to warn you about doing something dangerous. Mixing release versions with snapshot versions. The release plugin takes care of this -

Re: Progress on support for large projects

Ralph Goers schrieb: On May 13, 2009, at 5:09 PM, Christian Schulte wrote: Ralph Goers schrieb: So the tree really looks like: +tags +root-1.0 (trunk revision 1) +A(1.0) +B(1.0) +root-1.1 (trunk revision 2) +A(1.0) +B(1.1) +root-1.2 (trunk revision 3

Re: Progress on support for large projects

Joerg Hohwiller schrieb: Hi Christian, My question may have sounded rhetorically but I really meant that. You could of course manage commit rights with subversion so that whenever someone mistakenly would try to commit to that release version on trunk, subversion could simply disallow that.

Re: Progress on support for large projects

Ralph Goers schrieb: On May 12, 2009, at 9:30 PM, Christian Schulte wrote: Ralph Goers schrieb: Imagine that you could get a pom.xml for all of Apache Commons that contained the dependency management for it. Every time a commons project released a new Commons bill of materials would go

Re: Progress on support for large projects

Ralph Goers schrieb: So the tree really looks like: +tags +root-1.0 (trunk revision 1) +A(1.0) +B(1.0) +root-1.1 (trunk revision 2) +A(1.0) +B(1.1) +root-1.2 (trunk revision 3) +A(1.0) +B(1.2) /trunk at revision 4 +root(1.2-SNAPSHOT)

Re: Progress on support for large projects

Ralph Goers schrieb: On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by

Re: Progress on support for large projects

Ralph Goers schrieb: Imagine that you could get a pom.xml for all of Apache Commons that contained the dependency management for it. Every time a commons project released a new Commons bill of materials would go with it. a) You want all the projects to be part of the build to be sure

Re: [VOTE] Release Maven Remote Resources Plugin 1.1

Jason van Zyl schrieb: Hi, I just want to release this to fix the coupling of the exception to the maven-reporting-api which happened by mistake. Staging repo: https://repository.apache.org/content/repositories/maven-staging-002 Guide to testing staged releases:

Re: [VOTE] Release Maven Remote Resources Plugin 1.1

Jason van Zyl schrieb: I didn't see a test so no. I don't have time to write a test. Ok. I'll try to prepare some tests next week. Just in case I disturbed the vote. +1 Since the modello model version will have to be increased, maybe don't name that release 1.1 since that would also be the

Re: Version comparison rules

Stephen Connolly schrieb: What I'm thinking is that if we had some metadata associated with the groupId, it could specify what the version comparison rule is for that groupId (and all it's child groupIds)... It would be very cool to have some general purpose grouplevel metadata! Various things

Re: Version comparison rules

Christian Schulte schrieb: Stephen Connolly schrieb: What I'm thinking is that if we had some metadata associated with the groupId, it could specify what the version comparison rule is for that groupId (and all it's child groupIds)... It would be very cool to have some general purpose

Re: [2.0.10 RC] please test

Brian E. Fox schrieb: Hello, This RC fixes the SCP wagon problem identified in RC2 (MNG-3717). We have reverted the 2.0.x branch back to use wagon beta-2 where it was historically for stability. Users that require fixes for wagon beta-3+ should use 2.1.0-M1 instead. Here's the list of

Re: Proposed change to handling of dependency version ranges

Ian Robertson schrieb: I would propose that the semantics change to Of the overlapping ranges, the *lowest* soft requirement is the version to be used. Consequently, new releases of a project would not change builds of other projects depending on it (assuming that version numbers

Re: Default plugin execution id

Stephen Connolly wrote: Christian, Please do not take offense, but I think that you do not understand what is being discussed/proposed. Here is my understanding: Maven has the concept of a lifecycle. Each lifecycle consists of a sequence of phases. When you invoke Maven with a specific

Re: Default plugin execution id

Brian E. Fox wrote: I think we've gone way off the rails here. I see there's a proposal but haven't reviewed it yet. The first portion of this discussion was rather small in scope: Currently default executions of plugins have a null id. The null is used to indicate the default config for a

Re: Default plugin execution id

Benjamin Bentmann wrote: Christian Schulte wrote: Not having specified an execution id does not necessarily mean someone did not care about it. It means someone explicitly referred to the default execution. I disagree with this interpretation, mainly because I am not aware of any docs

Re: Default plugin execution id

Stephen Connolly wrote: AFAIK, The execution id refers only to a specific plugin, and each execution can only match a specific phase... so I don't see the need to tie the execution to a goal name, neither to the plugin name... What I see as bind important is if the plugin is bound to

Re: Default plugin execution id

Jason van Zyl wrote: I don't think anyone is generally going to type: default-execution-id It says what it is and if someone happens to look at the effective POM they will understand. It's also unlikely someone would actually use that in their own POMs. Although not an apache

Re: Default plugin execution id

Benjamin Bentmann wrote: However, given that POM snippets without execution id like execution phasefoo/phase goals goalrun/goal /goals /execution might not be uncommon, i.e. where one doesn't care about the execution id and simply relies on the

Re: Default plugin execution id

Brian E. Fox wrote: Definitely 2.1 and that way if there is a conflict, it's part of moving forward. Is there a name besides default that might be less likely to conflict? org.apache.maven/2.1 ? -- Christian - To

Re: Default plugin execution id

Brett Porter wrote: How about #groupId:artifactId:sequenceNumber. It would be unique to the POM. xs:element name=id minOccurs=0 type=xs:string default=default ^ xs:annotation xs:documentation

Re: Releasing Maven 2.0.5

On Do, November 2, 2006 15:09, Mike Perham wrote: MNG-2340 and MNG-1577 are both on my must fix list before release. I still need to test the latest patch for 1577. mike What about MNG-2646 ? I opened it just yesterday. The attached patch needs an expert's review, of course, but fixes the

[Fwd: [m2] Howto custom CharsetProvider implementations ?]

Hi, I am forwarding this to the dev mailing list since I got no answer on the users list. Any ideas or workarounds highly appreciated. Ursprüngliche Nachricht - Betreff: [m2] Howto custom CharsetProvider implementations ? Von: Christian

Re: [Fwd: [m2] Howto custom CharsetProvider implementations ?]

On Mo, März 6, 2006 15:41, Brett Porter wrote: Christian Schulte wrote: Hi, I am forwarding this to the dev mailing list since I got no answer on the users list. Generally better to just send a gentle reminder in reply on the users list. Any ideas or workarounds highly appreciated

[jira] Created: (MNG-2002) The mvn.bat Script does not return the error-code of Maven

Environment: Windows XP Reporter: Christian Schulte Priority: Blocker The mvn.bat Script does not return with an error-code if Maven failed. The scipt only returns error-codes for problems with the environment. If Maven fails the Script does not propagate Maven's error code back

[jira] Closed: (MNG-1805) src/main/resources/org/apache/maven/plugin/checkstyle/images/rss.png missing leading to a NPE

[ http://jira.codehaus.org/browse/MNG-1805?page=all ] Christian Schulte closed MNG-1805: -- Resolution: Duplicate Fix Version: (was: 2.0.2) src/main/resources/org/apache/maven/plugin/checkstyle/images/rss.png missing leading to a NPE

[jira] Created: (MPCHECKSTYLE-48) rss.png resource missing in repository leading to a NPE

rss.png resource missing in repository leading to a NPE --- Key: MPCHECKSTYLE-48 URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-48 Project: maven-checkstyle-plugin Type: Bug Reporter: Christian Schulte

[jira] Created: (MNG-1805) src/main/resources/org/apache/maven/plugin/checkstyle/images/rss.png missing leading to a NPE

Type: Bug Components: maven-checkstyle-plugin Versions: 2.0.1 Reporter: Christian Schulte Priority: Blocker Fix For: 2.0.1 During updating the plugin someone forgot to also add the relevant resources. Since src/main/resources/org/apache/maven/plugin/checkstyle/images

[jira] Created: (MNG-1807) PMD report needs to support file encodings (patch included)

: 2.0.1 Reporter: Christian Schulte Priority: Trivial Fix For: 2.0.1 Attachments: patch I need the PMD plugin to support reading files with an encoding different from the default platform encoding. The attached patch adds a parameter encoding which takes the name of the encoding

[jira] Created: (MNG-1808) checkstyle plugin should skip generating reports if no sources exist (patch included)

: Improvement Components: maven-checkstyle-plugin Versions: 2.0.1 Reporter: Christian Schulte Priority: Trivial Fix For: 2.0.1 Attachments: patch In order to be able to configure the checkstyle plugin in the root pom of a multi-module build the plugin should not throw an exception

[jira] Commented: (MNG-1263) Multiproject Release: No check in

[ http://jira.codehaus.org/browse/MNG-1263?page=comments#action_51812 ] Christian Schulte commented on MNG-1263: This is not only a problem of the release plugin its also a problem with inheritance in Maven 2 in general. Its completely ignoring

[jira] Closed: (CONTINUUM-462) Relative path not honoured in cvs commands for flat project layout

[ http://jira.codehaus.org/browse/CONTINUUM-462?page=all ] Christian Schulte closed CONTINUUM-462: --- Resolution: Duplicate see comment in MNG-1263 Relative path not honoured in cvs commands for flat project layout

[jira] Commented: (MNG-1263) Multiproject Release: No check in

[ http://jira.codehaus.org/browse/MNG-1263?page=comments#action_51814 ] Christian Schulte commented on MNG-1263: see also CONTINUUM-462 Multiproject Release: No check in - Key: MNG-1263 URL

[jira] Created: (CONTINUUM-462) Relative path not honoured in cvs commands for flat project layout

Environment: affects all environments Reporter: Christian Schulte Continuum does not implement the flat project layout as described at http://maven.apache.org/guides/mini/guide-ide-eclipse.html at the end of the site correctly. The checkout via ViewCVS does work but during building continuum

[jira] Commented: (MNG-1313) maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider

[ http://jira.codehaus.org/browse/MNG-1313?page=comments#action_50074 ] Christian Schulte commented on MNG-1313: If the surefire-plugin would contain the boot classpath this would not lead to ClassLoader.getSystemClassLoader(), as used in the JDK

[jira] Reopened: (MNG-1313) maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider

[ http://jira.codehaus.org/browse/MNG-1313?page=all ] Christian Schulte reopened MNG-1313: maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider

[jira] Created: (MNG-1313) maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider

://jira.codehaus.org/browse/MNG-1313 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0 Environment: All Reporter: Christian Schulte Priority: Blocker maven-surefire-plugin cannot run a jUnit test for a custom charset provider specified

<    2   3   4   5   6   7