Re: [VOTE] Should we respin CANCELLED releases with the same version number?

-1 (binding) Ralph On May 29, 2013, at 3:01 AM, Stephen Connolly wrote: > We have been using a policy of only making releases without skipping > version numbers, e.g. > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc > > Whereby if there is something wrong with the artifacts staged for release,

Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)

KEYS file - http://svn.apache.org/repos/asf/maven/project/KEYS svn tag - http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1 +1 on the release however it is odd that the Release Notes page is empty. Ralph On Jun 24, 2013, at 7:15 PM, sebb wrote: > On 25 June 2013 02:

Re: Release process updates

I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, sebb wrote:

Re: Release process updates

t; critical. Better to figure out how to support proper techniques now, rather > than wait until forced to. > > On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers > wrote: > >> I disagree that the revision is required. I know that the RM is going to >> recreate the tag with

Re: Release process updates

Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: > On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers > wrote: > >> Again I have to disagree. The release manager wil

Re: Release process updates

GA tag. > > On 25 June 2013 19:38, Ralph Goers wrote: >> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed >> release vote instead of deleting them. >> >> >> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: >> >>>

Re: Release process updates

Mirko > -- > Sent from my mobile > On Jun 27, 2013 4:42 PM, "sebb" wrote: > >> On 27 June 2013 15:05, Ralph Goers wrote: >>> I do not believe that can be done with the release plugins as the pom >> has to specify the same version as the tag. If you then r

Re: [VOTE] Retire maven-idea-plugin

+1 (binding) Ralph On Jul 19, 2013, at 10:01 AM, Dennis Lundberg wrote: > Hi > > It has been almost five years since I made the last release of > maven-idea-plugin. The features in IDEA to integrate Maven has been greatly > improved since then, making our own plugin obsolete. I therefor propose

Re: [VOTE] Retire Maven One Plugin

+1 Ralph On Jul 20, 2013, at 2:13 AM, Dennis Lundberg wrote: > Hi, > > Now that we have Maven 1 at End-Of-Life, I think it's time to retire > Maven One Plugin as well. It has been almost six years since the last > release. I therefor propose that we retire maven-one-plugin. > > http://maven.ap

Re: [VOTE] Retire Maven Model Converter

+1 Ralph On Jul 20, 2013, at 10:26 AM, Dennis Lundberg wrote: > Hi, > > The only consumer of Maven Model Converter we have left at the Apache > Maven project is Maven One Plugin. If the vote for the retirement of > Maven One Plugin succeeds we should also retire Maven Model Converter. > The las

Re: [VOTE] Release Maven 3.1.1

Sent from my iPad > On Sep 22, 2013, at 4:41 PM, sebb wrote: > >> On 22 September 2013 05:03, Jason van Zyl wrote: >> >>> On Sep 21, 2013, at 7:44 PM, sebb wrote: >>> On 22 September 2013 03:09, Jason van Zyl wrote: > On Sep 21, 2013, at 6:16 PM, sebb wrote: > > On 21 S

Re: APT vs Markdown formats for site docs

Log4j didn’t switch everything. A couple pages had to be left as Markdown for things AsciiDoc doesn’t support, although at the moment I don’t remember what those things were at the moment. Ralph > On Feb 1, 2021, at 6:30 AM, Gary Gregory wrote: > > FYI, over at Log4j, we switched to Asciidoc.

Re: [VOTE] Release Apache Maven version 3.8.0

If I were a user and expected the feature to be in 3.7.0 then I would certainly also expect it in 3.8.0. The only ways to avoid this are a) stay on 3.6.x.x until the feature is available, b) specifically say the promised features aren’t available yet. That said I’m +0 on the version numbering.

Re: Security/Versioning policy proposal

More than likely you will get whatever the next version number happens to be. I can’t think of a case where Maven needed to go back and patch a prior release. That could happen however, if Maven was modified to require Java 11 to run and a security fix had to be applied to the last version supp

Re: Security/Versioning policy proposal

you >> can require them from a project which does not offer them by themself). >> >> >> -- >> http://bernd.eckenfels.net >> >> Von: Ralph Goers >> Gesendet: Sunday, April 4, 2021 9:55:50 PM >> An: Maven Deve

Re: Security/Versioning policy proposal

it upfront. >>> >>> So proposal can be: >>> >>> [Experimental policy until June 2022] >>> 1. We maintain two major releases, ie 3.x and 4.x as of today (no minor >> in >>> particular, just the highest one) >>> 2. We maintain versio

JPMS compile problems

I am trying to convert Log4j 2 to be fully modularized and am running into problems with Log4j-core. First, I have hit a couple of nasty bugs when compiling on MacOS that are reflected in https://issues.apache.org/jira/browse/MCOMPILER-461

Re: JPMS compile problems

Thanks Christian, Thanks to either a good night’s sleep or reading the messages in this thread I realized deleting the module-info.class file generated to create the test jar might fix the problem. It did. After deleting it the compiler only used the class path to run the annotation processor an

JPMS, Maven and test jars

I have recently had quite an adventure modifying several of Log4j’s Maven modules to implement JPMS on our master branch. It was quite an adventure due to a few issues: 1. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826. This bug has been fixed in Java 17 but Log4j uses Ja

Re: JPMS, Maven and test jars

Sorry for posting again. I really need to proof-read better. Please ignore the prior email. I have recently had quite an adventure modifying several of Log4j’s Maven modules to implement JPMS on our master branch. It was an adventure due to a few issues: 1. https://bugs.java.com/bugdatabase/vi

Re: JPMS, Maven and test jars

ting > module, but to me for a good reason. > > Even with your very small reduction of steps to simplify the process, it > doesn't fit in the default lifecycle unless you write you introduce a new > lifecycle-binding or write a new extension. > > Robert > > On

Re: JPMS, Maven and test jars

e main source before it will allow the unit tests to include one. > > This will also help your IDE recognize the code. > And as this is a common pattern, it will also help other coders to > more easily recognize the structure of your project. Yes, this will obviously make the IDE happie

Re: JPMS, Maven and test jars

> On Jun 22, 2021, at 1:19 PM, Elliotte Rusty Harold wrote: > > On Tue, Jun 22, 2021 at 7:32 PM Gary Gregory wrote: > >> In addition, how is one supposed to test package private code if a test jar >> tests a main jar where all packages are now different? > > Some projects adhere to strictly

Re: JPMS, Maven and test jars

Gary, the test jar doesn’t perform tests. It provides test utility classes like LoggerContextRule. > On Jun 22, 2021, at 12:31 PM, Gary Gregory wrote: > > It feels to me like JPMS just plainly breaks the informal industry standard > of the Maven project layout we have all been using for a mil

Re: JPMS, Maven and test jars

derstand recursion, we must first understand recursion. > > > On Tue, Jun 22, 2021 at 7:02 AM Ralph Goers > wrote: > >> Sorry for posting again. I really need to proof-read better. Please ignore >> the prior email. >> >> I have recently had quite an

Re: JPMS, Maven and test jars

> On Jun 22, 2021, at 11:16 AM, Robert Scholte wrote: > > If I understand correctly you want both log4j-core main classes and test > classes be distributed as modularized jars. > To me with JPMS you should move the modularized test-classes to a separate > Maven module as a first citizen arti

Re: JPMS, Maven and test jars

> On Jun 22, 2021, at 2:29 PM, Andres Almiray wrote: > > Ralph, > > Once you move test code to their own Maven module they become a top level > module, that is, they have a life of their own as any other top level module. > > In contrast -tests jars are not top level, but a “variant” (that’

Re: JPMS data as first-class citizen of the POM

My 2 cents. I’ve spent many, many hours trying to make Log4j 2 JPMS compatible. It is still nowhere near done. While JPMS sounds simple the side effects it has permeate everything. If you were to look at the Log4j 2 master branch right now it is a complete mess. Adding Java 9 support was bad en

Re: Maven Dependency Plugin - Log4j vulnerabilities

This appears to be plugin dependencies though, not project dependencies. The issue should really be raised with whatever plugin is causing it to be used. My recollection is that Maven itself hasn’t used Log4j in quite some time for logging. Ralph > On Mar 3, 2022, at 8:21 AM, Gary Gregory wr

Re: Change of Chair

Thanks for all you’ve done as chair Robert. It has been much appreciated. Congrats Karl! Ralph > On Apr 21, 2022, at 4:57 PM, Robert Scholte wrote: > > Hi all, > > as of now, Karl Heinz is the new chairman of the Apache Maven project. > I've done it for quite some time with a lot of pleasure

Re: Question - JDK Minimum of future Apache Maven 4.0.0

Some statistics below. I think you are being very optimistic about how fast people will adopt JDK 17. If it follows the trends for Java 8 and 11 I would put money on betting it won’t be the predominant version until the next LTS is released. https://adoptium.net/support and https://aws.amazon.

Re: Question - JDK Minimum of future Apache Maven 4.0.0

> On Jul 25, 2022, at 12:34 PM, Michael Osipov wrote: > > Am 2022-07-25 um 21:31 schrieb Ralph Goers: >> So my vote would be +1 for Maven 4 requiring Java 17 under the condition >> that Maven 3 continues to get new releases. > > This will not happen with me, only

Re: Logging in Maven Plugins - Bridging

> On Nov 5, 2022, at 6:08 AM, Elliotte Rusty Harold wrote: > > After log4shell last year, I no longer have any patience for third > party logging libraries, full stop. > > IMO logging should be done through java.util.logging, nothing else. > This is fully functional since Java 1.4 twenty year

Re: Logging in Maven Plugins - Bridging

ote: > > On 6/11/2022 at 8:31:45 PM, Ralph Goers wrote: > >> I can absolutely guarantee you that if Google is actually using JUL that >> they >> have written plenty of their own code on top of it since JUL is woefully >> incomplete. > > > Google came up with

Re: New logo?

I like the owl, but why not just make the body a solid color? To me it now looks like one of those fancy “haircuts’ people get where they have something shaved into their head. Ralph > On Nov 20, 2014, at 2:43 AM, Stephen Connolly > wrote: > > Stop calling Couché-tard "shotgun owl"! > > Do

Re: [DISCUSS] Adopt Mr Couché-Tard as our mascot, change the logo font to Alte Haas Grotesk, change the colour letter to "v"

Why does the owl need chest hair? (or whatever the oval patch is supposed to represent). Ralph > On Nov 23, 2014, at 2:59 PM, Stephen Connolly > wrote: > > On 23 November 2014 at 02:53, Hervé BOUTEMY > wrote: > >> Le samedi 22 novembre 2014 19:22:29 Benson Marg

Re: [VOTE] Change project logo and adopt owl as mascot

-1 - only because a) I don’t understand the purpose of what is going on on the bird’s chest and b) I love the idea of putting the bird in a sweater with the letter “M” on it. Ralph > On Nov 25, 2014, at 5:05 AM, Andreas Gudian wrote: > > +1 > > Am Dienstag, 25. November 2014 schrieb Stephen

Re: [DISCUSS] Design by committee

> On Nov 25, 2014, at 8:14 AM, Stephen Connolly > wrote: > > On 25 November 2014 at 14:31, Ralph Goers > wrote: > >> -1 - only because a) I don’t understand the purpose of what is going on on >> the bird’s chest and > > > http

Re: [VOTE] Maven 3.3.1 Release

+1. Release looks good to me. Ralph > On Mar 13, 2015, at 6:08 PM, Paul Benedict wrote: > > There are about ten unresolved issues that need to be kicked out of this > version. > On Mar 13, 2015 7:14 PM, "Jason van Zyl" wrote: > >> Great, thanks for testing! >> >> jvz >> >>> On Mar 13, 2015

Re: [VOTE] Release Apache Maven Fluido Skin Version 1.4

See the section right above - http://www.apache.org/foundation/voting.html#ReleaseVotes . Notice the bold sentence that says release votes cannot be vetoed. You can vote -1 on a release, but that is not a veto. If someone has a conce

Re: logging during multithreaded builds

If you use the SLF4J MDC - which is supported by Logback, Log4j 1.x and 2.x - you can include anything stored in the MDC on every line of log output. Just use %X to include all MDC items or %MDC{key} to include the specific key. This would require storing the value(s) at the beginning of every

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

+1 Ralph > On Feb 27, 2017, at 11:51 AM, Stephen Connolly > wrote: > > Any more PMC members care to vote? > > -- Forwarded message - > From: Stephen Connolly > > Date: Mon 27 Feb 2017 at 14:42 > Subject: Re: [VOTE] Release Apache Maven

Maven plugin fails when a class compiled for Java 9 is present in a jar running in Java 8.

I have a plugin that uses a jar that doesn’t have any Maven plugin annotations in it but does have classes compiled for Java 9 in it that are only used when executing on Java 9. Loading of the plugin is failing because the annotation scanner can’t read the class. What do I need to do to prevent

Re: Maven plugin fails when a class compiled for Java 9 is present in a jar running in Java 8.

support toolchains so it can’t be used to compile) and then call the jar plugin. The maven-bundle-plugin doesn’t support multi-release jars so it has to be called before the java9 classes are created. Ralph > On Jun 15, 2017, at 4:42 PM, Ralph Goers wrote: > > I have a plugin that uses a

Re: Maven plugin fails when a class compiled for Java 9 is present in a jar running in Java 8.

I spoke too soon. It appears my java9 classes are not being found in the multi-release jar so I still don’t know if it fixes the problem with the scanner. Ralph > On Jun 15, 2017, at 8:28 PM, Ralph Goers wrote: > > FWIW, building the jar as a multi-release jar did fix this pro

Re: Log4j Warning

Jason, I really don’t care which logging framework Maven uses. There isn’t going to be much difference between Logback and Log4j 2 in a batch process like Maven, although asynchronous loggers might speed up larger builds somewhat. However, these comparisons are still incorrect. Log4j is using t

Re: Log4j Warning

He claims that Log4j 2 isn’t popular enough. The real reason, as you probably know, is that Jason seriously dislikes me, although he would never actually say that as his reason. Ralph > On Jan 7, 2016, at 10:56 AM, Jason van Zyl wrote: > > >> On Jan 7, 2016, at 11:43 AM, Arnaud Héritier wr

Re: Log4j Warning

I apologize for this email. It was not meant for this list. Ralph > On Jan 7, 2016, at 11:47 AM, Ralph Goers wrote: > > He claims that Log4j 2 isn’t popular enough. The real reason, as you > probably know, is that Jason seriously dislikes me, although he would never > actua

Re: Log4j Warning

with that. > > Reasonable? > >> On Jan 7, 2016, at 1:47 PM, Ralph Goers wrote: >> >> He claims that Log4j 2 isn’t popular enough. The real reason, as you >> probably know, is that Jason seriously dislikes me, although he would never >> actually say t

[Discuss] [VOTE] Retire Maven Ant Tasks

Where is the doc for Maven for Maven? I didn’t see anything on the maven plugins page or via a Google search. Ralph > On May 15, 2016, at 4:24 PM, Michael Osipov wrote: > > Hi, > > this component hasn't been touched for years effectively and we rely now on > Maven for Maven (dog food). Addit

Re: [VOTE] Retire Maven Ant Tasks

+1 Ralph > On May 15, 2016, at 4:24 PM, Michael Osipov wrote: > > Hi, > > this component hasn't been touched for years effectively and we rely now on > Maven for Maven (dog food). Additionally, Ant build support has already been > removed from Maven. This relic shouldn't be used with Maven 3

Re: [Discuss] [VOTE] Retire Maven Ant Tasks

Thanks. That is perfect. Ralph > On May 16, 2016, at 9:25 AM, Michael Osipov wrote: > > Am 2016-05-16 um 15:58 schrieb Ralph Goers: >> Where is the doc for Maven for Maven? I didn’t see anything on the maven >> plugins page or via a Google search. > > There is htt

Re: 3.4.0 SNAPSHOT breaks Log4j build

This is an interesting situation. The classes that use Jackson are all considered optional in Log4j, so having optional set to true is indeed what is desired. However, we require those dependencies to compile and to run the unit tests. With scope set to test I would expect that the non-test cla

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Actually, for me the ideal would be a command line switch that could re-enable the feature that was deprecated. Then you don’t really have to wait a release, so long as it is documented. This makes sure user’s are aware since they have to take a minor action to continue to make things work. Ral

Re: [DISCUSSION] finishing Aether import: help find a new name

I much prefer MARS, especially if you can come up with corresponding wordplay for VENUS… ;-) Seriously, the overlap with Java ARchive is bound to be confusing, and might even make people think that the component has something to do with them. Ralph > On Aug 3, 2016, at 4:29 PM, Christian S

Re: Adding extra "scope" type metadata to dependencies?

Extending the pom.xml has been discussed for years. Unfortunately, it validates the XSD, so when the pom is extended with new attributes older versions of Maven will fail. This is the main reason why import scope was introduced rather than using a new element. There were many discussions about

Re: And while I'm on the subject of logging

Might I suggest that you are never going to make everyone happy. That is why Logging frameworks such as Log4j support using Logger names, Log Levels, and Markers as basic ways of categorizing log events. With those you can continue to log events but filter them down to just what the user wants.

Re: RPMs for Maven 3?

On Mar 20, 2012, at 5:23 PM, Stephen Connolly wrote: > > Actually -1 votes don't count. You cannot veto releases, you only > need 3 x +1... so we could have 3 x +1 and 21 x -1 and the release > manager is still allowed to proceed with the release! [It would be bad > form to proceed from my PoV,

Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or

First, I also would recommend moving from plexus logging to SLF4J. Mark's concerns with incompatibilities only come about with the log4j bridge if you are trying to use APis that the SLF4J bridge hasn't implemented. Something being used in a plugin really shouldn't be using those. Although C

Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or

On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote: > >> Absolutely. In light of commit r1380105, the next step is for you >> (Maven folks) to formulate a policy for swapping out logging >> back-ends. > > Well that is what this is all about. And we have this solution available in > Maven since

Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or

Sorry - I should have added - "unless your facade uses LocationAwareLogger instead of the normal Logger". Ralph On Sep 10, 2012, at 9:21 AM, Ralph Goers wrote: > > On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote: > >> >>> Absolutely. In light of commit

Re: Aether 0.9.0.M1

On Oct 6, 2012, at 4:23 AM, Hervé BOUTEMY wrote: > Aether 0.9.0.M1 is now in central [1] > and Benjamin did the upgrade on his own Maven 3 branch [2] > > Question: do we need a formal vote for the upgrade of this dependency? No. > Any objection to do the upgrade without vote, given it's just a

Re: [VOTE] Release Maven PDF Plugin Version 1.2

+1 Ralph On Nov 5, 2012, at 2:40 PM, Benson Margulies wrote: > To: "Maven Developers List" > Subject: [VOTE] Release Maven XXX Plugin version Y.Z > > Hi, > > We solved 15 > issues:http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11932&version=16050 > > There are still a couple of

Re: Logback in Maven Core

I checked out Maven and used its build as a comparison. First, I ran the log4j 2 build and it was taking around 59 seconds. I then changed the log4j2.xml to remove the colors. I then got an average time for Log4j 2 of 54.76s and for Logback I get an average of 55.225s. I consider these diff

Re: Logback in Maven Core

Oh - FWIW I'm running on OSX 10.7.5 with a 2.5 GHz Intel Core i7 with 16GB of memory. Ralph On Dec 12, 2012, at 12:27 AM, Ralph Goers wrote: > I checked out Maven and used its build as a comparison. First, I ran the > log4j 2 build and it was taking around 59 seconds. I then

Re: [VOTE] formally end support for Maven 1

+1 Ralph On Mar 2, 2013, at 7:18 AM, Benson Margulies wrote: > Based on the sentiment on the discussion thread, I call a formal vote > to end support for Maven 1.x. This is a vote to: > > 1: Remove maven 1 release materials from the primary distribution > area, leaving them only on the archive

Re: [VOTE] Commit Access for Hervé Boutemy

+1 Ralph -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 6:44 PM To: Maven Developers List Subject: [VOTE] Commit Access for Hervé Boutemy Hi, Hervé has been submitting patches on the Maven Ant Tasks for a long time, done lots of f

Including managed dependencies

I met with a group of maven users from several business units of my company last week. The single largest pain point is still with regard to dependency management. Despite the changes Patrick and I introduced in MNG-1577 they are still having difficulties primarily because it is impractical or

Re: Including managed dependencies

Jason van Zyl wrote: I have been doing some similar work for a project with 1000+ projects across 60 branches and I have come to the conclusion that dependency management via inheritance is ineffective in many cases. Especially for enterprise wide endeavors. What people are looking for is

trunk build

I made a small change to Artifact which is used in maven-project. I then checked out trunks on another machine and the build failed. When I manually build artifact first it builds fine. I suspect this is because artifact was recently split out but was not added as a module to the main project?

Re: trunk build

Jason van Zyl wrote: maven-artifact lives here: http://svn.apache.org/repos/asf/maven/artifact/trunk/ It is used by maven-project here: http://svn.apache.org/repos/asf/maven/components/trunk/maven-project/ And maven-artifact in its new separated location is referenced in the POM of maven-pr

site build

I made some changes to the dependency management documentation and checked them in. I tried to rebuild the site but the upload failed with permission problems. It appears that my id is not a member of the maven group on people.apache.org. Who has the correct permissions to fix that? Ralph -

Re: svn commit: r578553 - in /maven: artifact/trunk/src/main/java/org/apache/maven/artifact/ components/trunk/maven-project/src/main/java/org/apache/maven/project/ components/trunk/maven-project/src/t

Jason van Zyl wrote: On 23 Sep 07, at 12:20 AM 23 Sep 07, [EMAIL PROTECTED] wrote: Author: rgoers Date: Sun Sep 23 00:20:24 2007 New Revision: 578553 URL: http://svn.apache.org/viewvc?rev=578553&view=rev Log: Allow the managed dependencies of projects to be imported into the managed dependen

Re: svn commit: r578553 - in /maven: artifact/trunk/src/main/java/org/apache/maven/artifact/ components/trunk/maven-project/src/main/java/org/apache/maven/project/ components/trunk/mave

Jason van Zyl said: > > On 24 Sep 07, at 9:23 AM 24 Sep 07, Mark Hobson wrote: > >> Okay, but I do think a feature branch is the best for prototyping new >> features - it stops blocking the developer and doesn't cause >> unnecessary problems for others. Do we really need to merge it into >> 2.0.x?

Re: svn commit: r578553 - in /maven: artifact/trunk/src/main/java/org/apache/maven/artifact/ components/trunk/maven-project/src/main/java/org/apache/maven/project/ components/trunk/ma

OK. My mistake for not making it clear where I wanted to add this. I'll try to revert this tonight (I'm in California). I'll look at the other options you've presented for moving this forward. I should make it clear that I'm not just doing this for my employer (if I was I'd be doing the work on

jira

I created an issue in Jira but it seems I can't assign it to myself. Can someone with permission grant me rights to do that? Thanks, Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROT

Wiki authorization

I do not seem to have authorization to edit http://docs.codehaus.org/display/MAVEN/All+Proposals. Can someone fix that? Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wiki authorization

Is there a reason I can't see an edit tab on this page? Can someone please fix that? Ralph Ralph Goers wrote: I do not seem to have authorization to edit http://docs.codehaus.org/display/MAVEN/All+Proposals. Can someone fix that?

Re: Wiki authorization

ralphgoers Jason van Zyl wrote: On 11 Oct 07, at 7:03 PM 11 Oct 07, Ralph Goers wrote: Is there a reason I can't see an edit tab on this page? Can someone please fix that? This is the second time I've tried and the user browser is so abysmal I can't find your user a

Re: Wiki authorization

Jason van Zyl wrote: Should be good now. Thanks Jason, but I still don't see an Edit tab on that page. Am I doing something wrong? Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL

Re: [codehaus-confluence] Maven: Importing Managed Dependencies (Comment Added)

I don't know that confluence was designed for debates so I am posting this here. Mark, while I appreciate your feedback I have to take issue with the -1. In all the groups that I work with that use Maven every single one of the Configuration Management teams that manages the projects requires

RE: [codehaus-confluence] Maven: Importing Managed Dependencies (Comment Added)

to change it to do that or to use a property to control the behavior. This is all that I am aware of. Ralph Brian E. Fox said: > I need to think about this some more, but at first blush it could be > useful. I need to think about any possible side effects. > > -Original Messa

MNG-3220

I've created http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies. I'd appreciate feedback on this or its related Jira issue at http://jira.codehaus.org/browse/MNG-3220. This has become a serious roadblock in our use of Maven and I would like to resolve it. Ralph --

Re: Modifying deploy plugin to prevent deployment of existing versions

Jason van Zyl wrote: I've been working on some release/deployment tools lately for a client and I modified their deployments so that you could not accidentally release the same version of an artifact more then once. I can stop this on the server side only when running a repository manager, bu

Re: ApacheCon/OSSummit roll call!

I'll be at ApacheCon. Ralph Brett Porter wrote: I know several folks are presenting and will definitely be there, but I thought it might be good to send a shout out and see who is coming along? Hopefully we'll get some opportunities for getting together around the hackathon/code-a-ramas. I'

Re: Article on Maven Usage

As Brett said this is kind of tough. I work for a large company and if I had to guess I'd say that the 100 maven users number is being met. But that is on lots of projects across a fairly large company. Many of these projects are dependent on each other but are only tied to each other through

Re: Using a graph to resolve dependencies

Are there specific examples to illustrate how this works? i.e. are there unit tests for it? Obviously I'm definitely interested in this. Ralph Jason van Zyl wrote: Mark, Ralph, You'll probably be interested in the artifact graph code that went in as the conflict resolution and dependency ma

Re: [vote] Nicolas de Loof as a committer

+1 Ralph Brett Porter wrote: I'd like to call a vote for Nicolas de Loof as a committer, based primarily on his work for Archiva, but also from being active in the general Maven community for quite some time. He has been relentlessly testing and identifying issues and providing patches recentl

Re: User license acceptance db+plugin thingy for Maven

Interesting idea, but wouldn't it make more sense to have a separate plugin that only makes you accept the license when you download the artifact from the remote repository? If I'm not using a repository manager and am downloading from from maven.org that might be nice. Once it is an internal r

Re: maven.test.skip.exec

If you have a super pom that all your projects inherit from then this solution is workable. You probably want one so that your organization can configure things like the enforcer plugin to make sure all your projects follow the same rules. But if you can't do that then this solution doesn't wor

Re: possible performance bottleneck in current trunk

If I can get some time I might look at it as well. This wouldn't necessarily be a bad thing if it can tell you all of the errors after preparing the projects. Milos Kleint wrote: The build doesn't fail fast now in some cases. It will prepare all the 20 project's lifecycles, perform dependency

Re: Plugin Versions in the Super pom

In my world I require a reproduceable build. Typically, that means a specific release would have to be built using a specific version of Maven. Any attempt to build it at a later time would need to still use that release. This isn't just because of default versions of plugins but because the

Re: proposal : make POM less verbose

Tim O'Brien wrote: People will use whatever implementation they feel like using. I'd propose that you start by shipping Maven with two: 1. Classic - the way it works now 2. Reduced XML - the thing that Nicolas proposed If someone wants to ship an implementation that understands something

Re: proposal : make POM less verbose

I think you are missing my point. I have no problem with allowing a more compact XML using attributes instead of elements. But the minute you allow the parser to be pluggable you allow folks to start inventing their own POM syntax. I would find that situation completely unacceptable. I don't ca

Re: An Attribute Based POM

Actually, there wasn't a single dependency in that pom. Those were all managed dependency declarations. I'm not surprised to see something like that, however it would really be better if it was: artifactId="bill-of-materials" version="1.1-SNAPSHOT" type="pom"/> instead of

Re: [vote] Benjamin Bentmann as Maven committer

+1 Ralph Lukas Theussl wrote: I'd like to propose giving commit access to Benjamin. During the last few months, he has provided patches in so many areas of Maven that I can't list them all here (various plugins, surefire, doxia,...), including documentation and translations, and he has not

Re: svn commit: r630217 - /maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/project/DefaultMavenProjectBuilder.java

I did commit it to trunk. It just took me a while to do it as my maven-artifact was seriously out of date and I was getting compile errors in maven-project (and I had to go to work for the day) so it took me a while to verify it. If you really think this warrants a Jira issue I can create one.

Re: svn commit: r630217 - /maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/project/DefaultMavenProjectBuilder.java

Maybe that's because I didn't merge? Would merging from 2.0.x to trunk work correctly? I guess it wouldn't have hurt to try. Brett Porter wrote: sorry, I see the trunk commit now - just didn't have the normal "merged from" notation. Same question applies for the reasoning :) On 25/02/2008,

Re: Documentation for import scope

I checked it in before so it is still in SVN. I just have to put that version back on top. Where do the release notes go? Ralph Brett Porter wrote: I think this is mostly for Ralph... I wasn't able to find any documentation for the import scope in the site. I was wondering if you could add a

Re: Documentation for import scope

http://marc.info/?l=turbine-maven-dev&m=119061621617466&w=2 http://marc.info/?l=turbine-maven-dev&m=119061621501107&w=2 These were reverted. I just need to get it back and make some minor updates. Ralph Brett Porter wrote: On 29/02/2008, at 11:22 AM, Ralph Goers wrote:

  1   2   3   4   5   >