Re: Issue with 3.8.2 and support status of 3.6.3, 3.5.X, 3.3.X and .3.2.X

> do exactly what you need, out of the box? > > But in general, I am completely aligned with Karl, try latest (as you > noticed, soon 3.8.3) > > HTH > Tamas > > > > On Fri, Oct 1, 2021 at 12:41 AM Fred Cooke wrote: > > > Hey Karl, > > > > Thank

Re: Issue with 3.8.2 and support status of 3.6.3, 3.5.X, 3.3.X and .3.2.X

Karl Heinz Marbaise wrote: > Hi, > > On 30.09.21 15:49, Fred Cooke wrote: > > Hi all, > > > > We've hit an issue with maven 3.8.2 which a lot of our clients use on > macs > > through Brew and although brew supports the latest 3.8, 3.5, 3.3, 3.2 > > v

Issue with 3.8.2 and support status of 3.6.3, 3.5.X, 3.3.X and .3.2.X

Hi all, We've hit an issue with maven 3.8.2 which a lot of our clients use on macs through Brew and although brew supports the latest 3.8, 3.5, 3.3, 3.2 versions it does not support 3.8.1 which doesn't have the regression and does not have 3.6 which was also fine for our purposes. I'm not sure

Re: Issues to be done for Maven Core 4.0.0-alpha-1?

> - improved commandline options when working with multimodule projects. > - jansi based console output improvements > > This is just a short summary of the release[1], but it should give you an > idea why this version should be called Maven 4. > > thanks, > Robert > > [

Re: Issues to be done for Maven Core 4.0.0-alpha-1?

Is there somewhere where I can read about the rationale behind the first major version bump since I learned M2 15 years ago and what's changed in a positive but breaking fashion that warranted that bump? Just the 4 sounds exciting without any context. I hope the context lives up to it, but 3 has

Re: IRC: still being used?

Yeah, it still gets a bit of traffic. On Tue, 31 Mar 2020 at 00:43, Elliotte Rusty Harold wrote: > A lot of our docs and READMEs talk about the IRC channel. E.g. > > #Maven IRC channel on freenode.org > > Is this still in use? Or should I remove this from the docs where I > find it and perhaps

Re: IRC Chat

The process is done through IRC, there will be a help page on freenode somewhere, search register or similar. You connect with desired nickname, and then send commands to nickserv to sort it out. On 18 August 2018 at 04:47, Christian Stein wrote: > On Fri, Aug 17, 2018 at 2:41 PM Fred Co

Re: IRC Chat

Yes, create an account, spam attack = +r set on most channels and registration required to enter. Hope that helps. On 18 August 2018 at 00:37, Christian Stein wrote: > Hi Maven-Devs, > > tried to join #maven-dev via http://webchat.freenode.net but it > does not work like it used to do. I guess,

Re: [ANN] Apache Maven 3.5.3 Released

3.5.3 as per subject and list or 3.5.2 as per opening sentence? Guessing the former. On 9 March 2018 at 01:31, Stephen Connolly wrote: > The Apache Maven team is pleased to announce the release of the Apache > Maven 3.5.2 > > You can download the appropriate sources etc.

Re: Allowed characters in GAV and how/where to sanitize?

Looks like I'm just plain wrong (and happy about it). I'm not sure where that memory came from. Perhaps maven 2 some time ago, though it felt fresh in my mind. Apologies for the noise! :-( On 11 January 2018 at 11:22, Hervé BOUTEMY wrote: > Le mercredi 10 janvier 2018,

Re: Allowed characters in GAV and how/where to sanitize?

Re versions, I know the background on it, but it annoys me that maven can't handle 4 part versions, 1.2.3.4 as sometimes it's handy to do a patch level that deep. Lots of messed up software in the world :-) Format should be N[.N as many times as needed][optional hyphen and qualifier of some sort]

Re: Building a Java9 project just using JDK9

I'll throw my 2c in here, too: Java 9 runtime forces me to rewrite parts of my application because non-root thread priority control is no longer available. Plenty of people have relied on lines like this to achieve their desired behaviour: java -jar -Xms128m -Xmx1024m

Re: No helping on the 3.5.0 release checklist...

017 at 22:10, Fred Cooke <fred.co...@gmail.com> wrote: > > > Thanks for all of your hard work on this, much appreciated! > > > > A little feedback for 3.5.1 (not helping with 3.5.0): checksums for the > > binaries too, not just the source. > > > > >

Re: No helping on the 3.5.0 release checklist...

Thanks for all of your hard work on this, much appreciated! A little feedback for 3.5.1 (not helping with 3.5.0): checksums for the binaries too, not just the source. That's it. :-) On 8 April 2017 at 09:05, Stephen Connolly wrote: > 24. Publish the website

Re: [VOTE] Release Apache Maven 3.5.0

+1 non binding, built my main app without drama, and the rest of my personal projects are simpler On 5 April 2017 at 09:37, Tibor Digana wrote: > +1 (binding) > > On Tue, Apr 4, 2017 at 12:14 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > Hi, > >

Re: [DISCUSS] How to work with branches

and a wise thing to do in a dynamic code base. On 20 March 2017 at 20:15, Stephen Connolly <stephen.alan.conno...@gmail.com > wrote: > On Mon 20 Mar 2017 at 00:44, Fred Cooke <fred.co...@gmail.com> wrote: > > > Sounds like the solution is for people to use a different r

Re: [DISCUSS] How to work with branches

rubbish. A merge, or a rebase, is a human operation, even when the tool can do it "cleanly"/automatically. To ignore this is to introduce subtle issues and breakages. On 20 March 2017 at 10:20, Stephen Connolly <stephen.alan.conno...@gmail.com > wrote: > On Sun 19 Mar 2017 at 20:05,

Re: [DISCUSS] How to work with branches

No need to cherry-pick, that should be a rare operation. Clean up the branch and prepare it for a fast forward with high quality commits, then just push it when it's ready and passes scrutiny and tests. +1 on ugly masters. Last time I looked at the docker project the displayed history showed 15

Re: [DISCUSS] How to work with branches

How are branches noisy? Promiscuous automated emails or some such? Surely you don't need to look at all branches unless you've been asked to pre-review something prior to fast-forward? Just the ones you're interested in? Naming scheme sounds sensible, however unless everyone is constantly

Re: [VOTE] Revert Surefire and commit to branches

o pure git revert is fine. > > On Wed, Jan 18, 2017 at 6:01 AM, Fred Cooke <fred.co...@gmail.com> wrote: > > > By revert do you mean reset --hard or keep the full history and rest the > > contents then re commit and verify with a diff to that hash? > > >

Re: [VOTE] Revert Surefire and commit to branches

By revert do you mean reset --hard or keep the full history and rest the contents then re commit and verify with a diff to that hash? Or did you mean revert, each commit, in reverse order, back to that base? On Wed, Jan 18, 2017 at 5:43 PM, Tibor Digana wrote: > Hi, >

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

t; once your push has succeeded > > > > git push origin :BRANCH > > > > > > On 16 January 2017 at 08:51, Christian Schulte <c...@schulte.it> wrote: > > > >> Am 16.01.2017 um 09:00 schrieb Fred Cooke: > >> > No, not correct in my books. >

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

January 2017 at 08:51, Christian Schulte <c...@schulte.it> wrote: > > > Am 16.01.2017 um 09:00 schrieb Fred Cooke: > > > No, not correct in my books. > > > > > > git checkout BRANCH # Assuming it's local already > > > git fetch upstream # risk

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

is not what I thought, then I back it out again. Though that's yet to happen, so I'll save the key strokes and use my alias "git force". On Mon, Jan 16, 2017 at 9:51 PM, Christian Schulte <c...@schulte.it> wrote: > Am 16.01.2017 um 09:00 schrieb Fred Cooke: > > No

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

verifying no one has pushed to it # create pull request/email someone/communicate your intention to have it merged ^ correct in my books, others may differ. On Mon, Jan 16, 2017 at 8:52 PM, Christian Schulte <c...@schulte.it> wrote: > Am 16.01.2017 um 08:27 schrieb Fred Cooke: &

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

Rebase is the only clean way forward for small projects in which people step on each others toes. Merge commits are difficult to comprehend for some developers, leading to errors. Avoiding them is beneficial. On Mon, Jan 16, 2017 at 8:23 PM, Hervé BOUTEMY wrote: > do we

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Christian, some (potentially unwelcome) advice: Learn to use rebase, learn to fetch, never pull, and review your changes in their new context before pushing them. Whether you take the advice, or not, this is how I ensure that my changes are clean and focused and coherent, every time. Pull is a

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

Commons lang could commit to providing patch releases/bug fixes in a maintenance series of the existing line for that purpose. Then it'd be totally fine to do whatever they liked in the new version with major incremented. On Mon, Sep 26, 2016 at 3:20 AM, Robert Scholte

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Yes, presumably to be consumed in another build, right? :-) On Tue, Aug 30, 2016 at 10:45 AM, Christian Schulte <c...@schulte.it> wrote: > Am 08/30/16 um 00:33 schrieb Fred Cooke: > > I fail to see how any such flattening can do away with interpolation. > Your > > typica

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

I fail to see how any such flattening can do away with interpolation. Your typical nonlib project has say 5-100 deps, each of which would have a flat tree that needs to be compared with and resolved against the others. I can see it speeding things up due to having all of the information for just

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

forget about non-central deployments. I suppose if there's a way to always deploy pom.xml.build through some plugin or configuration or some such, then that's fine with me. On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > Le mercredi 24 août 2016 18:41:59 F

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

thought deeply about it aside from reading this thread. On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit : > > That should have separation between builder Pom and consumer Pom. For > > pa

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

That should have separation between builder Pom and consumer Pom. For packaging=pom we deploy the builder Pom using classifier=build *for all other packaging a we do not deploy the builder Pom*. I don't like the sound of this. The deployed artefacts should include the exact POM in use to build

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Someone nailed it when they said it'd be two big decisions, one for JRE one for MVN. But here's the reality: People are just going to grab and use "the latest", whatever it is. What does that mean? We'll probably start seeing dependencies we can't consume, but want to, and otherwise could. A

Re: slf4j runtime dependency for plugin

Something doesn't have to be in Java to be universal (as SLF4J really is), and conversely, something being in Java doesn't make the world instantly catch up (eg YodaTime vs J8+). Adding the nop logger as a dep seems like the wrong thing to do and will (IIRC) cause a warning/error at runtime if

Re: slf4j runtime dependency for plugin

Clearly it's going to matter to him if Maven fails to provide and it doesn't work. Some sort of dependency isolation not right somewhere? Something seems to be going on. You're right, but he's seeing behaviour that indicates something is amiss. On Mon, Aug 15, 2016 at 6:37 PM, Michael Osipov

Re: Git Commit log with wrong encoding

The solution is to not push directly, and to seek peer review even if you're the king of the hill. Once pushed to a public upstream a commit should pretty much never be touched. What was the impact of the encoding being wrong? I haven't yet understood the actual problem. On Sun, Aug 7, 2016 at

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

Got it! Thanks. The dependency without [] needs to exist, but may not end up being used due to conflicts. Fair enough. :-) On Sat, Aug 6, 2016 at 3:24 PM, Christian Schulte wrote: > Am 08/06/16 um 05:15 schrieb Christian Schulte: > > It just takes the highest version the

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

A parent, I thought, used to be equivalent to [], ie, hard requirement. A dependency without [] is NOT a hard requirement, simply advisory. So yeah, they're different, or were. I wonder what semantics the ranged parents behaviour has for a simple backward compatible (or not) plain version?

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

I'm surprised the transitive dependency to that parent succeeds, unless it's ranged. For the others, in order to determine the dependency tree, and thus any transitive dependencies, and so on, the entire pom needs to be present. A parent is part of that. If the parent is of a fixed version (all

Re: Strange GIT

I take that back. In a single blow, you changed the entire file! Why? Because since that file was created on Christmas eve 2015, it has had broken line endings. Fix up the line endings and move on. On Mon, May 30, 2016 at 4:20 PM, Fred Cooke <fred.co...@gmail.com> wrote: > I cloned it,

Re: Strange GIT

I cloned it, assuming you're talking about the linked hash, which is the tip/head of master, then the diff shown is correct, you moved the package declaration around under the auspices of "investigating". Your change must be in an earlier commit. I looked at a few, but gave up. On Mon, May 30,

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

"You can run maven with Java 8 right now, so it is not a change in any way for those users." This equates to ruling out developers who are forced to use older JDKs/JREs if you look at it the other way. "I agree that jumping to Java 8 would be unwise. I think we can wait until 4.x. Don’t get me

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

My 2c: Our shop has all of the infrastructure on Ubuntu (for better or worse) and no LTS Ubuntu version exists with Java 8. So for now we (and anyone else using Ubuntu) are stuck with a few options: 1) stay with 12.04/14.04 and J7 2) backport J8 to 14.04 and/or use a PPA 3) use a non-LTS stable

Unreadable dependency resolution/collection failure messages

Compare this original version: [ERROR] Failed to execute goal on project emerge-monolithic-services: Could not resolve dependencies for project nz.co.company.emerge:emerge-monolithic-services:jar:40.166-SNAPSHOT: Failed to collect dependencies for

Re: Reproducibility versus ranges

of potential issue too there) > > On Monday 26 October 2015, Fred Cooke <fred.co...@gmail.com> wrote: > > > In our case, we don't want the original range back exactly, we want the > > current version of that, ie, higher lower bound to currently released > > thin

Re: Reproducibility versus ranges

e no poms with ranges to > depend on. > > Am Tue, 27 Oct 2015 14:03:01 +1300 > schrieb Fred Cooke <fred.co...@gmail.com>: > > > False, you've locked to a specific version of a thing which depends on > > ranges. This does not lock down those ranges, as it doesn't have > &g

Re: Reproducibility versus ranges

In our case, we don't want the original range back exactly, we want the current version of that, ie, higher lower bound to currently released things. Do not forget the transient ranges that need to be locked in our modified pom, either. Without this any tooling would be severely limited in use.

Re: Reproducibility versus ranges

nges on release your dependencies will also have no > ranges and you do not need to lock them down transitively. > > BTW: I really think tis is a topic for the maven-user list. > > Gruss > Bernd > > Am Tue, 27 > Oct 2015 11:21:09 +1300 schrieb Fred Cooke <fred.co...

Re: Reproducibility versus ranges

There is a plugin by a friend of a friend (don't ask me what it's called) that writes out a de-ranged pom.xml as part of the build, in the event that you need to reproduce a build, eg, branching from a tag for a production fix, you swap in the tag, drop in the pom, make the change down stream as

Re: number of bugs in maven-release-plugin

Some of the issues are mine. I'm pretty sure that at some point I realised that to get it working properly for my use case would require forking it to a privately released version. I guess now that it's mostly or all in git, that's feasible. The conflicting requirements across SCMs, the highly

Re: number of bugs in maven-release-plugin

Benson, I'm curious as to what you did, and also how it broke both for Git users and other users. Any links/refs/bugs/emails/etc to read? Was it just a case of leveraging features only available in very new versions? A data point if so: This sid laptop 2.1.3 My wheezy server 1.7.10.4 Work ucuntu

Re: IRC rooms @codehaus

Not that I know of, you seem to be in the right one. :-) On Sat, Jun 13, 2015 at 10:23 PM, Robert Scholte rfscho...@apache.org wrote: It seems less crowded on the IRC @ FreeNode (Europe) compared to IRC @ codehaus. Did I miss some rooms? Robert Op Mon, 11 May 2015 18:16:52 +0200 schreef

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 3.3.3

-14574303 explain the issue better? On 5 June 2015 at 11:05, Fred Cooke fred.co...@gmail.com wrote: Your tar file is polluted with ._ stuff that ends up laying around the place. Aside from that: 3.1.1 succeeds. 3.3.3 fails The description of what is wrong/your expectation could

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 3.3.3

Your tar file is polluted with ._ stuff that ends up laying around the place. Aside from that: 3.1.1 succeeds. 3.3.3 fails The description of what is wrong/your expectation could be better. I guess I would expect it to fail, but fail because relative path POM version doesn't match that

Re: Full migration to Git

+1, SVN fans should not be involved in these decisions at all, they'll just get it totally wrong. On Mon, Jun 1, 2015 at 8:08 PM, Arnaud Héritier aherit...@gmail.com wrote: For me it should be one per plugin, shared component. Everything which has its own release lifecycle must have its own

Re: Full migration to Git

Git can generate normal patches that you can simply apply and commit after testing. Or you could have a Git-SVN repo of your own setup, fetch the git commits, cherry pick hem into your SVN based tree, and dcommit them back up. I use Git-SVN every day at work. It's either that or kill myself as SVN

Re: Full migration to Git

Yep, that's getting pretty deep! If the clone(s where's the s?) has been done poorly (monolithically or otherwise brokenly) then the only sensible option is to do it again. The right approach is the slow one, per slice, otherwise the tags don't make sense. Trying to do this after the fact from

Re: Releasing entire maven-shared as a single release ?

+1 from me, too! Well said. On Sun, May 31, 2015 at 6:09 AM, Michael Osipov micha...@apache.org wrote: Am 2015-05-30 um 17:17 schrieb Jason van Zyl: If they have truly separate development cycles, then I think it best to try and move toward meaningful (semantic) versioning for each

Re: IRC rooms @codehaus

Yes, been lurking there for years anyway, and it's usually bigger, but the topic needs to be updated to not say go to codehaus irc, last time I looked, anyway. On Mon, May 11, 2015 at 8:41 AM, Robert Scholte codeh...@sourcegrounds.com wrote: Hi, Up until now the official IRC rooms were #maven

Re: Jekyll experiment

Well, if you created it, then a personal thank you from me for that. I would never use it for normal web stuff, but for the autogenerated stuff like PMD, checkstyle, findbugs, cross ref code, javadocs, etc etc it's GREAT at release time to give you a reference of what was. Or during dev, when one

Re: [DISCUSS] To SemVer or not to SemVer, that is the question

within their context, you're doing well. For example, your long lived release branches. On Mon, Feb 23, 2015 at 5:09 PM, Chris Graham chrisgw...@gmail.com wrote: On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke fred.co...@gmail.com wrote: I'd also love to hear that no one is trying to release 200

Re: [DISCUSS] To SemVer or not to SemVer, that is the question

It's worth pointing out that if you just run the two part version in the first place you are doing the same thing. IE, internally maven's versions are always x.y.z even if you only specify x.y thus if you have 2.6 and you're doing SemVer (2+, 1 sucked), then it'll behave correctly. Add the patches

Re: Releases, Continuous Delivery and the Future

Thank /***, finally some movement in the right direction! :-D Please also try to remember that EVERY single one of your users is a *developer* and should comprehend that a version is an arbitrary label on a piece of software to be used to uniquely identify it. If not, they should be educated.

Re: Releases, Continuous Delivery and the Future

sorts of contortions to collect all the various snapshot versions for a release to mimc something like CD but it's certainly not ideal. On Dec 14, 2014, at 8:44 PM, Fred Cooke fred.co...@gmail.com wrote: Thank /***, finally some movement in the right direction! :-D Please also try

Re: Git Push Summary

There will still be a copy around, get hold of the original and push it back up. Hooks should be setup to prevent tag deletion... On Tue, Sep 16, 2014 at 8:40 AM, Robert Scholte rfscho...@apache.org wrote: Ouch?! Op Mon, 15 Sep 2014 03:44:29 +0200 schreef ol...@apache.org: Repository:

Re: Maven 1.x cleanup

Leave SVN alone, it's only a matter of time before it's permanently retired in it's entirety, right? On Tue, Jul 29, 2014 at 12:58 PM, Brett Porter br...@apache.org wrote: Hi, About a year ago, the EOL banner was added for Maven 1.x. Today I saw there was a still a maven-1.x link in the

Re: Operating system requirement

A minimum is just that, a minimum! My repo is 600 meg, but I have a stack of *dependencies* in there... A minimum should not include *user* dependency guesswork, it should only include what a default hello-world project with NO deps outside the default near-empty pom produces when run through most

Re: Convert everything to Git

The entire SCM interface is very SVN-centric IMO. I raised a number of git related m-rel-p issues some time ago, but have been busy moving countries and more in the mean time. I doubt there has been progress on them, though. One pretty much required a core change to Maven (perhaps something for

Re: Convert everything to Git

+extension +groupIdorg.apache.maven.wagon/groupId +artifactIdwagon-ssh-external/artifactId +version${extension.version.wagon}/version +/extension It was SSH settings that were not being respected. Things like ports and ssh

Re: Towards faster releases

these things. Fred. On Wed, Feb 19, 2014 at 10:46 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 18 February 2014 22:49, Fred Cooke fred.co...@gmail.com wrote: Perhaps a stupid question, however if no change goes in, and it kicks off and gives the same gold star as the previous

Re: Towards faster releases

to shake :-) On Thu, Feb 20, 2014 at 12:00 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 19 February 2014 10:13, Fred Cooke fred.co...@gmail.com wrote: You missed the point. No-change commits include: - Clean up white space - Fix some comments in the code base

Re: Towards faster releases

Perhaps a stupid question, however if no change goes in, and it kicks off and gives the same gold star as the previous week, then there's no point to releasing it, because it's the same thing, what takes care of this? Just the human going well, actually there were no commits, so this email is

Re: Convert everything to Git

[1] https://git-wip-us.apache.org/repos/asf Le vendredi 14 février 2014 20:23:34 Fred Cooke a écrit : I have my private git repo setup in a nested way. No reason you couldn't do that the same for this. baseurl/org/apache/mvn/core/componentA.git etc

Re: Convert everything to Git

Great posts, Jason! There are so many reasons to dump SVN, but controlled branch sharing and personal work flow are big ones for me, too. I have a dozen or more local branches of my project, too, and like you, I rebase against what I publish until they're ready, then publish them, and rebase the

Re: Convert everything to Git

I have my private git repo setup in a nested way. No reason you couldn't do that the same for this. baseurl/org/apache/mvn/core/componentA.git etc. Unsure if this addresses your concerns or not, but it's certainly neat and tidy at the server end, and the user can duplicate the path structure

Re: Convert everything to Git

I like you more and more! :-) On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl ja...@tesla.io wrote: Can we start the process of converting everything to Git. I don't really see any benefit in using Subversion any longer. If so then we should just get together for a day and convert them and

Re: Convert everything to Git

The SVN repo should probably be retained anyway, just in RO format, and with a new URL that indicates it shouldn't be used. You can try to retain all history, but it's never quite in the same form, really. Perhaps no one cares, though? +1 for decompose into individual repos. Fred. PS, perhaps

Re: [VOTE] Apache Maven SCM 1.9

+1 list looks good. Beware of jgit and symlinks, though, you can end up with a lot of disk and cpu churn because of it if not careful. On Thu, Oct 24, 2013 at 5:35 AM, Olivier Lamy ol...@apache.org wrote: Hi, We fixed 9 issues. The new feature is the jgit provider (based on jgit). Details:

Re: Maven Core moving to 1.6

+1 too, 1.5 is dead for me. On Mon, Oct 7, 2013 at 8:12 PM, Dennis Lundberg dennisl.apa...@gmail.comwrote: +1 to 1.6 for 3.2 On Sat, Oct 5, 2013 at 5:03 AM, Jason van Zyl ja...@tesla.io wrote: Given the vote we had about releases after September does anyone mind if I update the

Re: [ANN] Maven 3.1.1 Release

Congratulations, Jason! :-) On Fri, Oct 4, 2013 at 10:56 PM, Jason van Zyl ja...@tesla.io wrote: Hi! The Apache Maven Team is pleased to announce the release of 3.1.1 The release notes can be found here: http://maven.apache.org/docs/3.1.1/release-notes.html The release can be downloaded

Re: [VOTE] Release Maven 3.1.1

+1 even if I'm late to the epic party. Love the sebbaliser, great work, and sense of humour, Jason! Dislike his lack of enthusiasm for the name. I'd have bragged about it for years if you'd called it the fredaliser :-) Unfortunately I am too busy to continue nagging. Good on sebb for picking up

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

Version ranges are extremely useful for this case: lib 0.2.4 0.3.0 non inclusive where lib has a guaranteed stable API with only non-breaking bug fixes and additions. There are other uses, too. I sincerely hope it's never dropped or broken. On Mon, Sep 16, 2013 at 10:09 AM, Stephen Connolly

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

Fair call. On Mon, Sep 16, 2013 at 1:39 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 16 September 2013 12:26, Fred Cooke fred.co...@gmail.com wrote: Version ranges are extremely useful for this case: lib 0.2.4 0.3.0 non inclusive where lib has a guaranteed stable API

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

releases. For now, I'd prefer reusing versions and no gaps. I don't mind deleting tags, otherwise I'd prefer the usage of RCx during votes. Robert Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke fred.co...@gmail.com: Last time someone asked this I went straight to central and found

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

Sep 2013 02:05:55 +0200 schreef Fred Cooke fred.co...@gmail.com: Last time someone asked this I went straight to central and found two examples. There are plenty out there. I'm not doing it again, you're more than capable. Also note, it's not much different to go from 3.1.2 to 3.1.4

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

Sent from my iPhone On 15 Sep 2013, at 12:30, Fred Cooke fred.co...@gmail.com wrote: Exactly! :-) On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: But you asked the wrong jump then. It would be 3.0.5 to 4.0.4... There's no way

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

You're in Git now. You don't *have* to push your tag and release commits up to the public world until AFTER you've checked they're OK. Or by failed release do you mean voted down? They could live on branches until set in stone, then merge --ff-only into master at that point, if so. On Sat, Sep

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

sept. 2013 à 19:30, Fred Cooke fred.co...@gmail.com a écrit : You're in Git now. You don't *have* to push your tag and release commits up to the public world until AFTER you've checked they're OK. Or by failed release do you mean voted down? They could live on branches until set

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

hardware without forcing people to use another repo hosting. LieGrue, strub - Original Message - From: Fred Cooke fred.co...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Saturday, 14 September 2013, 20:48 Subject: Re: Leaving Maven Core POMs

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

on dedicated branches. - Arnaud Le 14 sept. 2013 à 19:30, Fred Cooke fred.co...@gmail.com a écrit : You're in Git now. You don't *have* to push your tag and release commits up to the public world until AFTER you've checked they're OK. Or by failed release do you mean

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

maintained manually. LieGrue, strub - Original Message - From: Fred Cooke fred.co...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Saturday, 14 September 2013, 21:51 Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT I agree on skipping

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

. Otherwise the release notes would be broken - or would need to get maintained manually. LieGrue, strub - Original Message - From: Fred Cooke fred.co...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Saturday, 14 September 2013, 21:51

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

of the project unless there is a compelling reason to do otherwise. On Sep 14, 2013, at 7:48 PM, Fred Cooke fred.co...@gmail.com wrote: Jason, PLEASE understand that you do NOT have a single user. Not even one. Nada. Zilch. You have developers. Developers, by definition, are not *completely

Re: What is the correct Git SCM URL for a branch?

I understood that the purpose of the SCM *URL* was to be able to *use* it with a tool (where browser != tool), as such, there is only one correct URL, the rest are paths for browsing on a file system or web-front end. I did this knowing it would fail to illustrate the point:

Re: What is the correct Git SCM URL for a branch?

24, 2013 at 5:08 PM, Baptiste Mathus m...@batmat.net wrote: See http://maven.apache.org/pom.html#SCM Hervé is talking about xpath:/SCM/url which is indeed a scm web ui and said (developer)Connection would be discussed in another thread. Cheers Le 24 août 2013 16:57, Fred Cooke fred.co

Re: [VOTE] Release Apache Maven Model Converter version 2.3

Dennis, I've been using (and mostly loving) the release plugin/process for the better part of a decade and certainly claim to understand it well. I don't see how my knowledge of that (or Sebb's perceived lack of knowledge of that) is in any way relevant. The release plugin means it's harder to do

Re: [VOTE] Release Apache Maven Model Converter version 2.3

Dennis, of course source bundles will contain URLs and hashes and revisions and so forth, and the chance of those being mismatched is approximately zero. That's not the point. The point (for me, at least) is what did you INTEND to release, and does THAT match what is actually found in the bundle

Re: [VOTE] Release Apache Maven Model Converter version 2.3

. On Sat, Aug 17, 2013 at 12:00 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That sounds like you are looking for the SHA1 sum of the source bundle to be included in the vote email. Which would seem perfectly reasonable to me. On 16 August 2013 12:31, Fred Cooke fred.co

Re: [VOTE] Release Apache Maven Model Converter version 2.3

Dennis, effectively what is required is a statement like this: I believe that I've released XYZ binaries from ABC sources (tarball + N patches, SCM, whatever) with enough info to exactly identify what XYZ and ABC are (checksums, URLs, revisions, etc) without guessing and duplicated

  1   2   >