Re: Virtual versions
how often do you really change the enterprise pom though? On Wed, 18 Mar 2009 07:24:25 Timothy Reilly wrote: Hi Oleg, I just worked with a company converting 130+ projects from Ant to Maven. LATEST and RELEASE were invaluable. I do think there needs to be more thought around when they're allowed. No artifact's release pom should contain SNAPSHOT, LATEST or RELEASE anywhere. The later 2 should be extrapolated during the release build. But otherwise they're really important to me during development. Why wouldn't I want to point to parent pom version = RELEASE in my development poms? Or use the LATEST plugin until it breaks something in a non backward compatible way? Re-creating past releases and dependency trees it's a different story though. It's a lot to ask a build and deploy team to update 130+ projects whenever they release a new enterprise pom. What they'll do in practice is just change it and force it over the current version or worse avoid making changes that really should be done b/c it's too much hassle. -- Michael McCallum Enterprise Engineer mailto:gho...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposed change to handling of dependency version ranges
On Fri, 12 Dec 2008 09:59:33 Chris Maki wrote: When you say you get unstable builds you mean untested right? Because appropriate use of ranges will prevent you from assembling (war, ear, etc) artifacts that conflict. Ultimately the goal is stable software... right? In which case you want to use the version that you tested with for all the libraries that you depend upon. Best practice says you isolate components and change to reduce the risk. The simplest way of getting a consistent result with the scenario com.foo:my-artifact:jar:1.0:compile org.hibernate:hibernate:3.1.1:compile com.foo:another-artifact:2.0:compile org.hibernate:hibernate:3.1.3:compile is to factor out the hibernate dependency (I've excluded the transitions of hiberate composition here) com.foo:my-artifact:jar:1.1-SNAPSHOT:compile com.foo.composite:hibernate:[2,3):compile com.foo:another-artifact:[2,3):compile com.foo.composite:hibernate:[2,3):compile where com.foo.composite:hibernate is defined as com.foo.composite:hibernate:2.1 org.hibernate:hibernate:3.1.3:compile Now if all of your projects that use hibernate are defined in terms of this composite... then you KNOW which version of hibernate and all the associated libraries you are going to get. And you manage the lifecycle of the composite such that all minor releases don't break anything using it (easier to test with CI). The composite lifecycle does NOT need to match that of hibernate, so you can have different artifacts that use older versions and maven will tell you that you cannot package those two projects together. ~Michael -- Michael McCallum Enterprise Engineer mailto:gho...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Version range special cases?
On Sun, 16 Nov 2008 21:51:18 Dave Syer wrote: Hervé BOUTEMY wrote: [1] http://docs.codehaus.org/display/MAVEN/Versioning I didn't see any reference there to special qualifiers. But anyway, how does it make sense for [1.0.0,2.0.0) (with an *exclusive* upper bound of 2.0.0) to include anything from the 2.0.0. branch? I don't think users are going to expect to pick up pre-production versions of 2.0.0 if they use that as an upper exclusive bound. Its really really obvious but somewhat anoyying... 2-SNAPHOT == 2.0.0-SNAPSHOT 2.0.0 therefore ,2.0.0) is up to but not including 2.0.0 unfortunately including 2.0.0-SNAPSHOT but it makes sense, the only other option is to have a special case that not having a qualifier means 2.0.0-SNAPSHOT in a non-exclusive bound and thats just *arse* THE SOLUTION IS TO NEVER USE 2.0 just start at 2.1 and everything just works and makes sense... and why not use natural numbering anyway its more elegant... get rid of this odd development termininology of 0 versions. my 2c -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version range special cases?
On Mon, 17 Nov 2008 00:43:03 Dave Syer wrote: Michael McCallum-3 wrote: just start at 2.1 and everything just works and makes sense... Sorry, not to me, and not to anyone I know who uses version ranges. The works or make sense ;-) OSGi version conventions always used to annoy me. Now I've found something even worse. Why don't we just adopt the same rules - at least they are sane, and proven in production use? I used that approach with a rather transition team of consultants for production of 9 complex deliverables of over 150 artifacts. Worked fine for us. If 2.0.0 is the upper exclusive bound, I definitely do not want 2.0.0-* to be included. It's completely counter intuitive. Maybe I'm be a bit too pure with my math but when you say to but not include thats everything up to and not including... how is that not intuitive? In any case as long as [1,2) incluedes 1.1-SNAPSHOT and exlucdes 2.1-SNAPSHOT at the end of the day I will be happy... so I'll stop arguing btw: Gentoo linux solves this problem with slots [1] ... the 'pom' specifies a slot it belongs in e.g. 1, 2, 1.5 etc and things can depend on a particular slot. cheers [1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=1#doc_chap4 -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiler plugin: separate test compiler configuration
eclipse already blends test and compile scopes... if it plays havoc with your build just don't use the feature... On Mon, 20 Oct 2008 20:16:18 Daniel Le Berre wrote: Brian E. Fox a écrit : Milos, you can say that's eclipse's problem. But is't a majority of users, whether it's good or bad, we need to respect that use case. I think it should be allowed. Just because Eclipse can't do it doesn't mean maven shouldn't. It just means if you want to use eclipse and maven, then you can't use that feature. Maven shouldn't be limited to the least common denominator of all tools out there. I have the same feeling. Daniel -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.1.0-M1-RC16
On Tue, 09 Sep 2008 16:36:54 Paul Benedict wrote: John, Should MNG-3746 be revisited to not allow java.* properties to be overridden? I am concerned that while this is previous behavior, me too perhaps it is really allowing people to shoot themselves in the foot. I consider that Maven should error on such property names -- or at least be configured to have forbidden names. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: version LATEST merge with RELEASE
On Thu, 21 Aug 2008 10:47:04 Oleg Gusakov wrote: I cannot find use cases where asking for g:a:LATEST is different from g:a:RELEASE, so I merge these two in Mercury. Please comment in http://docs.codehaus.org/display/MAVEN/Mercury+Repository+Abstraction#Mercu ryRepositoryAbstraction-ArtifactVersionsspecialtreatment I'm confused... you are distriguishing between local and remote repositories when you've just abstracted the concept into a virtual reader... why? Why would you scan directories rather than read the metadata is that to support other tools that just dump jars? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
On Wed, 13 Aug 2008 20:52:31 Mark Hobson wrote: For example, say I need to fix a bug in Project A 3.0 that depends on Project B 2.0, amongst many other dependencies. I take A 3.0 and determine that the bug is in B 2.0, so I want to update the dependency of B in A to 2.1-SNAPSHOT. Assuming that this range was initially declared as B[2.0,3.0), using the repository approach I would just enable snapshot repositories for the range to resolve to my new work-in-progress B 2.1-SNAPSHOT. This works, but it would also open the gates for all other ranged dependencies to resolve to snapshots too, which I certainly don't want. Whereas if ranges behaved as I've described, then we would just update B to [2.0,2.1-SNAPSHOT) during development and then reinstate [2.0,3.0) once the fixed B 2.1 has been released. I wish you would stop pointing that out ;-). I only use snapshots in local and never deploy them... if someone wants trunk then they should build it themselves... if they want to try out the latest development then take the next major version of the project which most like is alpha/beta... Every approach that i have taken is engineered towards allowing rapid stable, reproducible change to the deliverables without too much overhead to the developers... I don't use deployed snapshots for the simple reasons that its too hard to back track... i want to very easily find out whats changed and whether rolling back or forward is the cheapest option... without tags aka releases there is just no easy way to do it... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
On Thu, 14 Aug 2008 00:09:59 Brian E. Fox wrote: I have to disagree here: developers should not care what repositories they have, or what dependency plugin shows them. They should, instead, simply say what they want - and get it. That is why, imho, the core, including dependency resolution, should be smarter :) I agree. The problem with excluding repos to try and influence your dependency resolution is that snapshots may already be in your local repo. Since it hits the local first, you can't effectively disable the snapshots at that point. the local repos should not be the cache of remote repos thats a design flaw... the local repo should be treated like all others... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
On Thu, 14 Aug 2008 02:03:36 Mark Hobson wrote: 2008/8/13 Oleg Gusakov [EMAIL PROTECTED]: Mark - this is the same if one excludes repositories and lives within pre-existing version set: like Maven having only local repo and OSGi having one OBR file. If we add a variable - repositories that constantly change, then we start wondering what to do and OSGi joins this discussion as soon as they add this feature. I'm not quite sure that I understand the scenario you're describing here? Aren't the repositories defined with the pom and so are constant? I define NO repositories in the pom... thats just a bit too chicken and egg... I define all my repositories in settings.xml -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include 2.1-alpha-1, etc Should most definitely not inlude 2.1-alpha-1 consider this scenario... module Z released as 2.X a dependent module Y specifies X [2,3) you now make a breaking change and release the alpha version of Z 3.0-alpha-1 and BAM module Y is using it when it explicitly said I only want major version 2 On Wed, 13 Aug 2008 12:51:17 Oleg Gusakov wrote: Working on Mercury I faced the necessity to use some standard definition of a version range, so I took OSGi definition: OSGi core specs 4.1, page 39 in April-2007 PDF available on OSGi site - http://osgi.org. Some interesting ramifications for Maven users: 1). Declaration 1.2.3 means any version X, greater or equal to 1.2.3: 1.2.3 = X. We are used to a soft version of that in Maven builds - version can be replaced by a more applicable dependency. But spec states ANY version: i.e. found in any scanned repository. i always use ranges to do otherwise IMO is just asking for trouble ;-) 2). I strongly feel that failing any explicit ranges, containing snapshots is a good thing. For instance, dependency declaration 1.2-SNAPSHOT is a range by definition, so I'd rather fail anything like [1.2-SNAPSHOT,2.0) or [1.0,1.2-SNAPSHOT) if you don't allow 1.2-SNAPSHOT how do you actually include them lets assume that 1-SNAPSHOT 1-alpha 1-beta 1 1.1 1.1.1 and i say [1,2) then -SNAPSHOT, alpha and beta will not match I always start my versions at 1.1, 2.1, 3.1 for the lower bound... otherwise you end up with not being able to use the first snapshot of a new major version in a range And I use the -! syntax for the upper bound which stops the next major versions first snapshot from creeping into a range for the previous major version Please comment if this does not sound natural or breaks some well-established usage patterns. Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
To be well rounded we should consider other approaches to dependencies its worth having a look at how gentoo does versioning with ranges and slots... http://www.gentoo.org/ http://devmanual.gentoo.org/general-concepts/dependencies/index.html http://devmanual.gentoo.org/general-concepts/slotting/index.html -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
On Wed, 13 Aug 2008 16:58:37 Oleg Gusakov wrote: 2). I strongly feel that failing any explicit ranges, containing snapshots is a good thing. For instance, dependency declaration 1.2-SNAPSHOT is a range by definition, so I'd rather fail anything like [1.2-SNAPSHOT,2.0) or [1.0,1.2-SNAPSHOT) if you don't allow 1.2-SNAPSHOT how do you actually include them lets assume that 1-SNAPSHOT 1-alpha 1-beta 1 1.1 1.1.1 and i say [1,2) then -SNAPSHOT, alpha and beta will not match alpha and beta will match, sn will not, because proposal is to treat them differently. alpha and beta are real releases, while sn is still wip. agreed they are real releases but how am i supposed to do automated integration testing trunk to trunk if I can't build a snapshot and push into a local repository and match it?... i would have to actually release the project in order to see if it breaks other things, and if it does its counter productive because i just broke everybody else whether or not i end up with snapshots should not be governed by the resolution mechanism but instead by what repositories i provide to it... if I don't want snapshots then there should be no snapshot repositories in the list to resolve from... and perhaps some form of enforcement... for example i use the enforcer plugin to make sure that no snapshots get into a project that is being released... i expect developers to use dependency:tree and dependency:resolve to know/check themselves first just in case enforce it with a tool -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
On Wed, 13 Aug 2008 16:35:38 Ralph Goers wrote: Michael McCallum wrote: To be well rounded we should consider other approaches to dependencies its worth having a look at how gentoo does versioning with ranges and slots... http://www.gentoo.org/ http://devmanual.gentoo.org/general-concepts/dependencies/index.html http://devmanual.gentoo.org/general-concepts/slotting/index.html Yes, but... What has really made Linux package management work is more than just versioning. not sure why you said but... i agree with everything you are saying... In your previous email you wrote - module Z released as 2.X a dependent module Y specifies X [2,3) you now make a breaking change and release the alpha version of Z 3.0-alpha-1 and BAM module Y is using it when it explicitly said I only want major version 2 This is exactly where I have a problem with the whole thing. You probably specified [2,3] under the assumption that all version 2 releases would be compatible. You probably also are assuming the version 3 isn't compatible with version 2. Either or both of these assumptions could be invalid. agreed, i have cooked my own slotting/provides by introducing my own packages that i depend upon which then transition to builds that are known to be compatible... you don't HAVE to have slots or requires/provides so i define but it could just as easily be the package maintainer that does an composite artifact... lets take spring as an example i know that there are three groups of compatible springs 1.2.X, [2.0, 2.5) and [2.5, 2.6) so i have three spring artifacts my.artifact.composite.spring-1.2.Y, my.artifact.composite.spring-2.0.Y and my.artifact.composite.spring-2.5.Y where Y is an incrementing revision number not related upstream each of these defines a specific range e.g. spring-core-[2.5,2.5.1] that fullfil the contract where i have projects that use the spring 2.5 compatible code they depend upon my.artifact.composite.spring-[2.5,2.6-!)... i can upgrade that composite to include a new spring release if I think its compatible... if spring were to release a 2.6 and i found it not compatible i would make a new composite now obviously there is overhead to this... and each company would need to make its own call...but i've found the overhead of extra artifacts with just dep lists very low... it can even include units tests with assumptions about the composed libraries to help with validating compatibility... hope that all makes sense i'm doing a presentation at a JUG in a few weeks so should have some pretty slides and examples of this soon... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
On Wed, 13 Aug 2008 17:42:17 Ralph Goers wrote: To be honest, even with this I'd still probably not use version ranges. But I sure would like for Maven to be able to fail the build because two artifacts need incompatible versions of the same thing. it does if you use version ranges and that is exactly why i use ranges... Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury Version Ranges
I have to disagree here: developers should not care what repositories they have, or what dependency plugin shows them. They should, instead, simply say what they want - and get it. That is why, imho, the core, including dependency resolution, should be smarter :) thats like saying i don't care what gas i put in my car it should just work... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM rewriting with DecentXML
On Tue, 05 Aug 2008 19:28:47 Aaron Digulla wrote: I mean, there was *no* XML parser which can do 100% round-tripping before DecentXML. It's just a non-issue for the XML guys. xom using xerces 2.6.7 was supposed to be able to do a complete round trip, have you disproved that? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM rewriting with DecentXML
there is already http://www.xom.nu/ that is worth considering... its goal is correctness and roundtripability ;-)... its mature and stable... i have used it and been very happy On Wed, 30 Jul 2008 19:34:53 Stephen Connolly wrote: On Wed, Jul 30, 2008 at 8:33 AM, Stephen Connolly [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2008 at 8:00 AM, Brett Porter [EMAIL PROTECTED] wrote: On 30/07/2008, at 4:52 PM, Aaron Digulla wrote: Quoting Brett Porter [EMAIL PROTECTED]: I've got some code ready for you to try: http://www.pdark.de/decentxml-1.0-SNAPSHOT-src.tar.gz wrong list? :) I've seen three Maven plugins which use their own code to manipulate POM and other XML files in projects, so I guess this is the right list to announce such a project. Sorry, it was missing the context so I thought you'd intended to send it to someone else. Part of it is that he wants this to be available for MOJO-1178... as the current pom rewriting is through semi-smart string replacement (in order to ensure that the formatting does not change) Which reminds me... can somebody have a look at MOJO-1178??? I'd like it if it could be hosted on mojo... if that is not something that people want I'll go look elsewhere but I'd appreciate knowing sooner rather than later -Stephen Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC2
I'm getting stack traces rather than the nice message when an artifact does not exist the repository... Downloading: http://mvn.somedomaindev.co.nz/central/nz/co/somedomain/nz.co.somedomain.parent/14-java4/nz.co.somedomain.parent-14-java4.pom org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate resource in repository at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:132) at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:474) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:363) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:318) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:200) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:557) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1393) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:822) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:507) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:199) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:578) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.io.FileNotFoundException: http://mvn.somedomaindev.co.nz/central/nz/co/somedomain/nz.co.somedomain.parent/14-java4/nz.co.somedomain.parent-14-java4.pom at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1239) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:115) -- Michael McCallum Development Lead somedomain Ltd cell: 021.576.907 msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] aim: gholamses http://www.somedomain.co.nz -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC2
On Thu, 24 Jul 2008 15:10:40 Michael McCallum wrote: I'm getting stack traces rather than the nice message when an artifact does not exist the repository... For regular maven user you could almost get away with this... but for newbies its will give them the willies and drive them away getting tonnes of stack traces during normal behaviour. In my case its a little worse 'cause I have 5 repositories... * local * overides * java.net (proxy cached) * restlet (proxy cached) * central mirror (proxy cached) so for each artifact thats new in the central repo i get 4 stack traces and then a downloading message... if no one goes DOH.. i know where that is i'll have a look at it later but i'm. Its only for the lightweight http wagon BTW... obvious in the stack trace me thinks ta -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do I go about contributing a plugin to mojo?
why not just specify the dependencies with version ranges, if you do there is no need to rewrite anything it just works... On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote: Oh... and if you want to prevent jumping too high in versions or too low, it supports adding a version specification to limit things. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release early, Release often
Now that each maven release locks down plugin versions and people are encouraged to do the same, plugins can be released more often with smaller features and one would hope that more people would pick them up and test them. Come core release time the plugins that are the most stable can be the ones that actually get pushed out, not necessarily the latest... Every now and again I find i need to patch a plugin, suprising not often which I think says a lot for the development of maven2 in general. There are certainly curly bits but I digress. I find that its quite difficult to actually get my own release of the head of a plugin because the deps are always a bit dodge with snapshots and version all over the place that may be public might need to be local or in some staging repository. So this is a request to get things cycling a bit more quickly. With the distributed CI that we have going on now... we should be able to stably release things in faster small increments without breaking things... except when we want to. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release early, Release often
On Mon, 14 Jul 2008 23:27:27 nicolas de loof wrote: I like the way Hudson does it's releases : there is a new version every month (and sometime every week) with one or two bu fixes and one new feature. This is a powerfull way to encourage users to provide patches, and to get feedback. yes me too Many maven plugins get fixes and features but stay in SNAPSHOT for months before some of us propose a new release. I think the main reason is the why? i mean why change it if you are not going to release it... i would figure that the trunk would nearly always never have changes... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing maven-filering?
On Tue, 15 Jul 2008 01:05:37 Stephane Nicoll wrote: Yep. WAR also has a couple of improvements and releasing it would be good. I have a patch for the war plugin that i was just working it adds support for the mapping to work for the jar of the classes as well (+1) for maven filtering p.s. I figured i should pull my finger out and patch something rather than just talking all the time, jon would be proud -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing for 2.0.10 RC1
On Sat, 12 Jul 2008 09:10:03 John Casey wrote: I think if we're going to try to take a hard line on maintaining a public API, then we need to define that API in a separate artifact that we can place strict limits on. thats a great idea -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
eclipse plugin and shared output directories
A long time back i discovered that if you have the same target output for eclipse and maven you end up with broken shit all over the place, intemittent errors. All really unpleasant. The default settings for eclipse:eclipse and eclipse:m2eclipse set the outputs to the same. Does this actually work for people? Maybe locking on windows actually make a positive impact finally? Thoughts anyone? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: initial comments on SAT solver document
On Mon, 23 Jun 2008 14:26:38 Michael McCallum wrote: have a meeting will explain in more detail later... have not forgotten just been really busy and want to give this a proper treatment... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: initial comments on SAT solver document
On Sun, 22 Jun 2008 18:16:37 Ralph Goers wrote: This is one of the problems that has bothered me for a while. It makes no sense for a project to say I'm compatible with 3.8.x. How in the world could they know that? The dependent project might release a new 3.8.x release that isn't compatible. Thus, for any kind of version range to have any meaning, projects must declare what prior versions they are compatible with using a declaration that isn't part of the current pom syntax. Then when a project specifies a dependency on 3.8.1 if there is a 3.8.2 that specifies it is compatible with any prior 3.8.x release it would be fine to use 3.8.2 in the project with the dependency. Without such a specification, in my opinion version ranges aren't particularly useful. I get around this by wrapping a well defined version around a strict range e.g. i have a special pom project that holds the version of spring that all my projects should use currently at 7.1 which says use 2.0.7 so all my projects use a range of dependency version[7,8-!)/version groupIdmy.domain.constraint/groupId artifactIdmy.domain.constraint.spring/artifactId /dependency and my.domain.constraint.spring is defined in brief as project ... ... dependency version[2.0.7]/version groupIdorg.springframework/groupId artifactIdcontext/artifactId /dependency ... /project the only overhead to this is a few extra artifacts with no code... hardly a major... there is also the added bonus that you have a convenient place to control exclusions like... commons-logging having read more of the thread... most of the apache projects are small and have fairly simple trees you can get away with locking vrsion down simply. In my case the trees are fairly horendous and using various pattern and refactoring techiniques was necessary to get clean consistent trees. It does mean that I encapsulate the the third party version as shown above and it also lets me guarantee that dependency graph produced by spring, hibernate, jmx, etc etc is the same when used in all my other projects. Each time there is a new release I can just do depedency:resolve and/or depedency:tree and make sure the trees look the same and then run tests on all my projects against the new version to ensure nothing breaks. If something does I can decide to bump the major version of the 'constraint' project or fix the problem in the broken project... i don't think that you can ever make a generic solution to this problem you always need a flexible solution close to home, because ultimately you need to manage when and where things change if you ever hope to produce stable software in a timely fashion. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: initial comments on SAT solver document
On Mon, 23 Jun 2008 11:20:40 Ralph Goers wrote: Why aren't you using dependencyManagement instead of the technique shown below? Good question, please refute/correct/flame if/where possible 1) there was no way to use dependencyManagement with deps when I adopted the technique. This works now with pom depedencies i think but I'm not certain it provides all the benefits. 2) because and i might be wrong but dependencyManagement messes with the version defined up the chain when what I want is a localised enforcement, its important to isolate the dependency and apply exclusions and version restrictions to guarantee that I get consistent resolution. 3) also because i actually use jars for the composites/constraints so that the poms and pom properties end up in my aggregations - they are single merged together... reasons are OT - so i can unravel what actually ended up in the jar if needed. 4) is it possible to use version ranges in dependencyManagement? I was thinking not but have not tried recently. Once you get a reasonable set of constrained external depdencies you naturally want to define them in terms of each other to reduce overhead and to ensure better consistency -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: initial comments on SAT solver document
On Mon, 23 Jun 2008 14:18:24 Ralph Goers wrote: 2) because and i might be wrong but dependencyManagement messes with the version defined up the chain when what I want is a localised enforcement, its important to isolate the dependency and apply exclusions and version restrictions to guarantee that I get consistent resolution. What do you mean up the chain? dependencyManagement should behave as if you specified the version wherever it is encountered in an actual dependency. So managed dependencies specified in one part of a dependency tree should only affect other parts of the tree in the same way they would with the fully specified dependency. thats my concern... As far as I know version ranges should work just fine. I haven't tried it because I don't use them. I don't know what you mean by defining dependencies in terms of each other. Do you mean versions 1.1-1.1.5 of Project A can use versions 1.0-1.x of Project B? This works until you start throwing in Project C, D, E, F, etc which also have dependencies. At some point understanding what is really compatible with what is extremely difficult. have a meeting will explain in more detail later... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MNG-624 automatic parent versioning
would it be possible to remove the default relative path... if people want it they can add it... ../pom.xml just seems very arbitrary maybe if you want group based parents it makes sense , i have found real power in using functional parents that define all the plugins for a particular type of project i.e. webapp, assembly, model, service etc otherwise you get heaps of projects with duplicated plugin configs and its hard to manage -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-grafo-plugin status
] [INFO] Total time: 4 seconds [INFO] Finished at: Thu Jun 05 16:10:09 CEST 2008 [INFO] Final Memory: 9M/16M ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency version conflict resolution
I concur with John, The key problem with plugable conflict resolution is that in my case I use hundreds of open source artifacts that all have interdepdencies that work based on the current maven conflict resolution model... If you make it pluggable where do you start and end with any strategy, how do you get a consistent and understandable resolution. One good library to bring up would be commons-logging, it ubiquitous many things depend on it. I exclude it because I prefer to use slf4j. If libraries I use have there own strategy could they then override my exclusion or force the tree to resolve such that my exclusions are in the wrong place. To me its like saying people should drive on any side of the road, depending on whats best for them. We don't do that we all drive on the same side of the road in any given country so that we can use the road safely with other users in a consistent manner. 2008/5/28 John Williams [EMAIL PROTECTED]: Brett, I'd be happy to work on implementing it, but I'm wary of the idea of pluggable strategies for something as fundamental as version conflict resolution. I agree that any new behavior needs to be switched on with a flag in the pom file in order to avoid breaking legacy builds, but beyond that I don't see much value in letting the user select a strategy. When is an alternate strategy appropriate, and how is a user supposed to make that decision? The sad fact is that pom files don't provide enough information to reliably resolve conflicting versions or detect when no resolution is possible. Any strategy is just a heuristic that will be wrong in some cases, so IMHO it's better to have a single strategy that's easy to understand and override when necessary than to have multiple strategies that all fail in different ways. jw On Wed, May 21, 2008 at 7:11 PM, Brett Porter [EMAIL PROTECTED] wrote: -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change to artifact version handling.
On Fri, 18 Apr 2008 04:11:19 Christian Edward Gruber wrote: Having said that, a simpler option would be to have - or . parsed as equivalent punctuation tokens, and have numerical ordering if it's convertable to a number or lexical ordering if not, on each item between the punctuations. so: I managed to miss this email in everthing else: JINX I opposed to Pluggable as that means custom and people making customs patterns is just going to wreck the possibility of being able to use the central repo. Every project and business will start doing there own thing. With the generic ordered components I think we can cover most of the bases without the need for pluggable. If anyone really really needs pluggable they can ship there own maven patch internally there is no need to make it too easy. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change to artifact version handling.
If we were to split the version string into components on - and . and _ and also split on transitions from number to letters then use the ordering rules at each component as defined here... Examples of version to components split 1.0 == 1, 0 1.0-beta1 == 1, 0, beta, 1 1-SNAPSHOT == 1, SNAPSHOT 2.3.4.5-r1 == 2, 3, 4, 5, r, 1 So each component could try a numeric compare if parsing as Integer works or string comparison otherwise. essentially this rule is applied to all components SNAPSHOT ALPHA BETA RC[a-zA-Z]* [0-9]* With exceptions for SNAPSHOT, BETA, ALPHA which can have special meaning and be less than anything in order. And the absense of an entry puts it above Its very similar to how things work now http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution This would seem to give a common sense interpretation of all versions This algorithm will work for ./commons-collections/commons-collections/2.0 ./commons-collections/commons-collections/2.1 ./commons-collections/commons-collections/3.0 ./commons-collections/commons-collections/3.1 ./commons-collections/commons-collections/3.2 ./commons-collections/commons-collections/2.1.1 ./commons-httpclient/commons-httpclient ./commons-httpclient/commons-httpclient/3.1 ./commons-httpclient/commons-httpclient/2.0.2 ./commons-httpclient/commons-httpclient/3.0.1 ./commons-httpclient/commons-httpclient/3.1-rc1 ./jaxen/jaxen/1.1.1 ./jaxen/jaxen/1.1-beta-6 ./jaxen/jaxen/1.1-beta-8 ./jaxen/jaxen/1.1-beta-9 ./jaxen/jaxen/1.0-FCS ./commons-io/commons-io ./commons-io/commons-io/1.2 ./commons-io/commons-io/1.3 ./commons-io/commons-io/1.4 ./commons-io/commons-io/1.3.1 ./geronimo-spec/geronimo-spec-jta/1.0-M1/ ./geronimo-spec/geronimo-spec-jta/1.0.1B-rc1/ ./geronimo-spec/geronimo-spec-jta/1.0.1B-rc2/ ./geronimo-spec/geronimo-spec-jta/1.0.1B-rc3/ ./geronimo-spec/geronimo-spec-jta/1.0.1B-rc4/ ./info/magnolia/magnolia-core/3.5.4 ./info/magnolia/magnolia-core/3.6-SNAPSHOT ./info/magnolia/magnolia-core/3.5.4.1-SNAPSHOT ./poi/poi/2.5.1 ./poi/poi/2.5.1-final-20040804 ./org/hibernate/hibernate/3.0.5 ./org/hibernate/hibernate/3.2.0.ga ./org/hibernate/hibernate/3.2.3.ga ./org/hibernate/hibernate/3.2.5.ga ./org/hibernate/hibernate/3.2.0.cr5 ./org/hibernate/hibernate-tools ./org/hibernate/hibernate-tools/3.2.0.beta9a ./org/hibernate/hibernate-annotations ./org/hibernate/hibernate-annotations/3.2.0.ga the .beta1 vs -beta1 example ./org/mortbay/jetty/servlet-api-2.5/6.1.3 ./org/mortbay/jetty/servlet-api-2.5/6.1.5 ./org/mortbay/jetty/servlet-api-2.5/6.0.0beta12 ./org/mortbay/jetty/servlet-api-2.5/6.1.1rc1 and even my favourite bug bear ./cglib/cglib/1.0/ ./cglib/cglib/2.0-rc2/ ./cglib/cglib/2.0.1/ ./cglib/cglib/2.0.2/ ./cglib/cglib/2.0beta2/ ./cglib/cglib/2.1/ ./cglib/cglib/2.1_2/ ./cglib/cglib/2.1_3/ ./cglib/cglib/rc2-1.0/ -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change to artifact version handling.
With two caveats... 1) A leading zero turns a number into a string (not a zero by itself) 2) How to you apply the -! rule that I use all the time which stops a match against -SNAPSHOT e.g. [2,3-!) will not match 3-SNAPSHOT. Perhaps say ! means ! and which means so that it can only match the following... [a-zA-Z]* [0-9]* You could also then say !alpha !beta !arbitrary !1 -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change to artifact version handling.
I know that maven2 is convention over anything else... a more general but consistent versioning scheme will help people transition, and help maven packages artifacts stay consistent with upstream sources. You could even have the release plugin map the version to the maven2 way with beta, alpha, rc and SNAPSHOT always with - prefixes in the repository. p.s. the three emails were intentional -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [regression] Cannot release plugins parent!
On Mon, 14 Apr 2008 05:53:50 David Jencks wrote: a. Put the parent pom somewhere else, like in plugins/trunk/plugin- parent. The pom in plugins/trunk would just have the modules element. I prefer (a) because then tagging the parent pom wont copy the entire set of plugins in a unreleased state into the svn tag for the released parent pom which in my view creates unnecessary confusion for anyone trying to understand what's going on in svn. Big fan of this... aggregation != inheritance -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Compiler plugin picks up source from jars in classpath
I found that one of my dependencies bundles some source in the jar... the compiler plugin compiles it and it ends up in my artifact. Has anyone see this before? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
Well ask us to do something rather than blabber on and we shut up... I lost two managers and a developer which has chewed up all my time... On Thu, 31 Jan 2008 02:14:59 Stephen Connolly wrote: IMHO I think a vote with the two positions clearly identified (perhaps with pros and cons for both if the pair of ye can agree on the pros and cons). (unless somebody else has a third position) -Stephen. On Jan 30, 2008 12:56 PM, Mark Hobson [EMAIL PROTECTED] wrote: On 30/01/2008, Mark Hobson [EMAIL PROTECTED] wrote: I don't think that linking this level of artifact resolution uncertainty to its source repository is a good idea. How version ranges are resolved should be completely deterministic and independent from where the artifact was actually downloaded from, otherwise we'll end up with no end of build reproducibility problems. In addition, the local repository would be exempt from these rules. This would require manually deleting artifacts from the local repo to ensure that certain versions weren't picked up; a maintenance nightmare I'm sure you'll agree. How's best to proceed with resolving this issue? Would voting make sense, or should the PMC lay down the intended direction? I'm not sure whether this thread needs to get any longer.. :) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
I am only speaking in regard to MNG-3092, there are several other related issues which I think all should be fixed Cons -- 1) Continuous integration of trunks I would like to be able to run the tests of all of my artifacts against a build of trunk of every other. How I currently achieve this... Use continuum with clean install and force a rebuild of every artifact on a regular basis. If MNG-3092 were to go ahead in order to include a snapshot in a build I would have to change the dep of each artifact to include a -SNAPSHOT in one of the bounds. 2) Using MNG-3092 is not the correct approach to exclude snapshots from releases. The enforcer plugin can detect and alert when a snapshot is resolved anywhere in the transitive tree. It would be nice to be able to bind this to a release Pros - 1) stops you getting inconsistent builds when you have a snapshot repository in your repository list that has artifacts matching a range 2) will stop (i think) dirty builds from snapshot metadata in the local repository. The local repository has multiple personality disorder. There is no way to enable disable the local metadata left in the local repository after a release or install. If the local repository cache was separate and the actual local repository (i.e. for installs) was a first order repo then this problem would go away On Thu, 31 Jan 2008 02:14:59 Stephen Connolly wrote: IMHO I think a vote with the two positions clearly identified (perhaps with pros and cons for both if the pair of ye can agree on the pros and cons). (unless somebody else has a third position) -Stephen. On Jan 30, 2008 12:56 PM, Mark Hobson [EMAIL PROTECTED] wrote: On 30/01/2008, Mark Hobson [EMAIL PROTECTED] wrote: I don't think that linking this level of artifact resolution uncertainty to its source repository is a good idea. How version ranges are resolved should be completely deterministic and independent from where the artifact was actually downloaded from, otherwise we'll end up with no end of build reproducibility problems. In addition, the local repository would be exempt from these rules. This would require manually deleting artifacts from the local repo to ensure that certain versions weren't picked up; a maintenance nightmare I'm sure you'll agree. How's best to proceed with resolving this issue? Would voting make sense, or should the PMC lay down the intended direction? I'm not sure whether this thread needs to get any longer.. :) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Attribute Based POM
From a commercial perspective... in an interview when I ask 'do you understand maven?' I want the prospective consultant/employee to say 'yes' and I want to know that that means they can grok poms... if you allow custom formats you just don't get that and we end up going the way of ant... big thumbs up for views like dependency:tree etc that make the pom human readable... which i think is most of the problem... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Attribute Based POM
sure but each project should not do that and using standard OO principles i can encapsulate it in reusable artifacts i average 5 deps per artifact and have (9 different) assemblies that result in about 84 jars each, with no dependency management sections and i have reproducible builds by factoring out common dependencies into reused artifacts I have isolated the efferent dependencies and stabilised them as a mental execise imagine that each class is a method and each artifact is a class, each group is a package, now refactor, you have read Martin Fowler of course... On Tue, 12 Feb 2008 13:17:09 Martijn Dashorst wrote: On 2/12/08, Michael McCallum [EMAIL PROTECTED] wrote: You can change the tool to make a bad pom look good but at the end of the day there is something wrong if your declared dependency list looks like that... How come? To get reproducible builds, you need to specify the versions of all your dependencies, including the transitive ones (e.g. to resolve version conflicts). This makes the list of dependencies huge. Martijn -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Attribute Based POM
IMO You can change the tool to make a bad pom look good but at the end of the day there is something wrong if your declared dependency list looks like that... Here are two different files for comparison (it halved the size): http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?content-type=text%2Fplainview=co http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplainview=co -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposal : make POM less verbose
the current pom structure is very easy to edit in many editors... attributes would make it a bit simpler in some circumstances but not necessarily more readable perhaps a pom to yaml printer plugin would help people to read it... I would say that people who really want to change it probably need to look at the way they are using poms in the first place, appropriate use of refactoring will help keep them clean and readable even in the current format On Mon, 11 Feb 2008 07:17:00 Jason van Zyl wrote: Also look here for previous discussions: http://docs.codehaus.org/display/MAVEN/Terse+POM+Syntax+-+Design+Discussion http://docs.codehaus.org/display/MAVEN/POM+Loading+and+Building You might want to start by looking at those and cleaning those up. Sifting out anything that's in JIRA. On 10-Feb-08, at 1:34 AM, nicolas de loof wrote: Hello, Maven detractors blam maven POM.xml to become huge XML files even for simple tasks. Considering the comparison with ant, the latest use XML attributes an few XML elements, making tasks declaration consise. Could we introduce a new XML schema (for maven 2.1) to support simple types elements as attributes, maybe using namespaces : project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo/groupId artifactIdmy-project/artifactId version1.0/version /project ... could be written : project modelVersion=4.0.0 groupId=org.codehaus.mojo artifactId=my-project version=1.0 /project We could use namespaces to avoid colision in maven schemas, and support a mix of elements and attributs : project m2:groupId=org.codehaus.mojo m2:artifactId=my-project m2:version=1.0 modelVersion4.0.0/modelVersion /project The previous examples are just to fix the principle. Declaring dependencies and plugins configuration could become really consice and enhance readability. Nico. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
On Thu, 31 Jan 2008 01:56:09 Mark Hobson wrote: On 30/01/2008, Mark Hobson [EMAIL PROTECTED] wrote: I don't think that linking this level of artifact resolution uncertainty to its source repository is a good idea. How version ranges are resolved should be completely deterministic and independent from where the artifact was actually downloaded from, otherwise we'll end up with no end of build reproducibility problems. fair enough In addition, the local repository would be exempt from these rules. I think the local repository should be treated just like any repo and separate from the cache of remote repositories... this is actually the cause of _many_ problems in thats its always included... This would require manually deleting artifacts from the local repo to ensure that certain versions weren't picked up; a maintenance nightmare I'm sure you'll agree. which is bloody annoying if I was able to configure my release profiles to not include the local repository that would be much better because I would only get released artifacts in remote repositories How's best to proceed with resolving this issue? Would voting make sense, or should the PMC lay down the intended direction? I'm not sure whether this thread needs to get any longer.. :) open to a vote Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
How about for MNG-3092 we make it configurable per repository whether the metadata resolution includes snapshots in ranges... you could even default to false to keep Dave and yourself happy and I can turn it on where i need it. I'm not certain if its possible but would perhaps be the most flexible compromise. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote: Hi Michael, There is another caveat in that it's all or nothing. Using a profile mechanism will switch all range dependencies into snapshot mode, when typically a developer only wishes to upgrade a couple. How could this be achieved using profiles? i can think of two ways off the top of my head * install on the specific project * selective repositories and profiles for different project groups The real question is what do you hope to achieve by enabling snapshots for a particular project or set of projects. Perhaps a change of direction in the discussion do you use multiple lines and merging to manage what your releases? I'm concerned that MNG-3092 is a one way street where better more flexible solutions could exist. But having said that if you did fix 3092 it would not adversely affect me right now. And if it does... well I'll figure something out. I can see the theoretical opposition to fixing MNG-3092, but since it's impractical and unworkable it seems merely academic. I'm open to At the moment I can do continuous integration in two ways * head to head (configure continuum deployment #1 to do clean install) * latest relevant release to latest relevant release - using version ranges (configure continuum deployment #2 do just do clean test) With mgn-3092 it will be impossible to take one artifact commit a change to the head and see if that breaks any of my other artifacts without changing poms. As the #1 won't pickup any changes because snapshot is not explicitly selected. suggestions if they still give the efficiency gains that working with version ranges will provide. I think people just overrate what snapshots provide... a non reproducible... non rollbackable... changes get pushed on me as a developer so i get broken when its incovenient to me... I work on the basic premise that the system should be in a state or releasability not development. Snapshots just bugger that up. And worse it makes people lazy. Its only a snapshot. Not using snapshots as a norm gives me more power to smack someone in the head - if you will excuse the metaphor - if they are not working responsibly. IMO if its not in source control it does not count, there is no trail, no guarantees, no possibility of generating diffs -Perhaps mercurial or svk could mitigate that to some extent - and chances are no recent backups. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
BTW if you want to _not_ include a snapshot on an open upper bound you can.. [1,2-!) which will not include 1.0-SNAPSHOT, 1-SNAPSHOT will include any version between 1 and 2 including any 1.2-SNAPSHOT or 1.4-SNAPSHOT will not include 2.0-SNAPSHOT or 2-SNAPSHOT On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote: Hi Michael, On 23/01/2008, Michael McCallum [EMAIL PROTECTED] wrote: Firstly IMHO of MNG-3092 is that is it not the right thing for maven in general. I believe with MNG-2994 and appropriate use of profiles to enable and disable snapshot repositories you can have everything that you want and still maintain the ability to allow any snapshot to be injected when desired. There is a little gem that i discovered - or maybe i just imagined it - the resolution tree is built from metadata, if you have no local metadata and MNG-2994 is fixed then you can control the resolution of any artifact by controlling its set of repositories - irrelevant of if a snapshot is cached in the local repo. There is one caveat: the local repository is a merging of two things... a local repository and a cache of remote repositories... which is unfortunate because that means deploy ends up installing local metadata and that results in my view of snapshots and other peoples views of snapshots being different. So the act of deploying or installing breaks the use of repository selection because local metadata is always used. Perhaps the 'local' repository metadata should be maskable as well. Strictly speaking there is no reason it should be treated differently. There is another caveat in that it's all or nothing. Using a profile mechanism will switch all range dependencies into snapshot mode, when typically a developer only wishes to upgrade a couple. How could this be achieved using profiles? I'm concerned that MNG-3092 is a one way street where better more flexible solutions could exist. But having said that if you did fix 3092 it would not adversely affect me right now. And if it does... well I'll figure something out. I can see the theoretical opposition to fixing MNG-3092, but since it's impractical and unworkable it seems merely academic. I'm open to suggestions if they still give the efficiency gains that working with version ranges will provide. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
so you are saying that A-2.0-SNAPSHOT uses B [1,2-!) and someone deploys B 1.4.1-SNAPSHOT and that overrides B 2.0-SNAPSHOT and B 1.4 or just that it overrides B1.4? Depends on your use case... as to how you would deal with that. And one of the reasons why I don't want mng-3092 because I can CI for this problem at the moment. digression well you do need to be careful but the same it true even if you have version ranges for releases... mvn depedency:resolve is your friend... when creating patched assemblies you need to confirm that any changes are ok... its not sufficient just to exclude snapshots... because any released version could also change the behaviour of the system... /digression On Thu, 24 Jan 2008 08:41:48 Stephen Connolly wrote: But that will bugger you up... You are working on the version 2 branch, there is no 2.0 released, only 2.0-SNAPSHOT... you don't care as it is still new and you are happy to use the last stable release, 1.4... Now there is some work that is needed for the 1.4 service pack, so 1.4.1-SNAPSHOT arrives and bang! you are scuppered On Jan 23, 2008 7:31 PM, Michael McCallum [EMAIL PROTECTED] wrote: BTW if you want to _not_ include a snapshot on an open upper bound you can.. [1,2-!) which will not include 1.0-SNAPSHOT, 1-SNAPSHOT will include any version between 1 and 2 including any 1.2-SNAPSHOT or 1.4-SNAPSHOT will not include 2.0-SNAPSHOT or 2-SNAPSHOT On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote: Hi Michael, On 23/01/2008, Michael McCallum [EMAIL PROTECTED] wrote: Firstly IMHO of MNG-3092 is that is it not the right thing for maven in general. I believe with MNG-2994 and appropriate use of profiles to enable and disable snapshot repositories you can have everything that you want and still maintain the ability to allow any snapshot to be injected when desired. There is a little gem that i discovered - or maybe i just imagined it - the resolution tree is built from metadata, if you have no local metadata and MNG-2994 is fixed then you can control the resolution of any artifact by controlling its set of repositories - irrelevant of if a snapshot is cached in the local repo. There is one caveat: the local repository is a merging of two things... a local repository and a cache of remote repositories... which is unfortunate because that means deploy ends up installing local metadata and that results in my view of snapshots and other peoples views of snapshots being different. So the act of deploying or installing breaks the use of repository selection because local metadata is always used. Perhaps the 'local' repository metadata should be maskable as well. Strictly speaking there is no reason it should be treated differently. There is another caveat in that it's all or nothing. Using a profile mechanism will switch all range dependencies into snapshot mode, when typically a developer only wishes to upgrade a couple. How could this be achieved using profiles? I'm concerned that MNG-3092 is a one way street where better more flexible solutions could exist. But having said that if you did fix 3092 it would not adversely affect me right now. And if it does... well I'll figure something out. I can see the theoretical opposition to fixing MNG-3092, but since it's impractical and unworkable it seems merely academic. I'm open to suggestions if they still give the efficiency gains that working with version ranges will provide. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
Firstly IMHO of MNG-3092 is that is it not the right thing for maven in general. I believe with MNG-2994 and appropriate use of profiles to enable and disable snapshot repositories you can have everything that you want and still maintain the ability to allow any snapshot to be injected when desired. There is a little gem that i discovered - or maybe i just imagined it - the resolution tree is built from metadata, if you have no local metadata and MNG-2994 is fixed then you can control the resolution of any artifact by controlling its set of repositories - irrelevant of if a snapshot is cached in the local repo. There is one caveat: the local repository is a merging of two things... a local repository and a cache of remote repositories... which is unfortunate because that means deploy ends up installing local metadata and that results in my view of snapshots and other peoples views of snapshots being different. So the act of deploying or installing breaks the use of repository selection because local metadata is always used. Perhaps the 'local' repository metadata should be maskable as well. Strictly speaking there is no reason it should be treated differently. I'm concerned that MNG-3092 is a one way street where better more flexible solutions could exist. But having said that if you did fix 3092 it would not adversely affect me right now. And if it does... well I'll figure something out. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.8 and release plugin bug status
i think you will find this is caused by broken metadata in third party projects which seems to change somewhat at random depedending on the project On Sat, 19 Jan 2008 15:23:44 dhoffer wrote: We are at a critical point with our usage of maven. We cannot update to 2.0.8 because 2.0.8 is broken with respect to the release plugin; RE MNG-3351 (no releases are possible if using version ranges). However we need to upgrade to 2.0.8 because we now have large projects that are tripping all over dependency/transitive/verson range bugs that reportedly have been fixed recently. Can someone comment on the status of MNG-3351? We are at a blocking point now where we cannot build anymore with maven. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release maven-shade-plugin 1.0-beta-1
I agree 100%, release often its the only way things really get used and tested in the wild... if people have problems they can alway roll back to the last release in the deps... On Fri, 18 Jan 2008 15:30:51 Brian E. Fox wrote: ... the people that need them. I'd rather see a release come out with the current fixes and then when MSHADE-9 is fixed, we do another release. At least then some people can use it rather than making everyone wait...and realistically doing the release doesn't preclude someone from fixing the issue in parallel so it shouldn't in theory delay the inevitable release with the MSHADE-9 fix in it. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
It's crazy that version ranges are still unusable in 2.0.8.. I disagree entirely. I use version ranges for a very complex Project... and it works very well * we have repeatable builds * we can mix and match snapshots during development if we need to * releases fail if you have snapshot deps even in ranges and transitions * this is all out of the box released maven core and plugins * have modules projects to test that the trunk of all projects builds and tests against the latest releases of all projects * have modules projects to test that the trunk of all projects builds and tests against the latest releases of all projects what more do you need? On Tue, 15 Jan 2008 06:41:42 Mark Hobson wrote: On 10/01/2008, Michael McCallum [EMAIL PROTECTED] wrote: another thought... by default you could not have snapshot repositories enabled and just enable them with a profile... that way all builds by default have no snapshots, you could even have separate profiles and snapshot repos for different departments to a allow more flexible integration Unfortunately this won't work either due to http://jira.codehaus.org/browse/MNG-2994 Both MNG-2994 and MNG-3092 need to be fixed before we can really start using version ranges as they were intended. I think we should just stick with the original design docs and apply the patch for MNG-3092. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots foot in mouth
On Tue, 15 Jan 2008 08:43:38 Michael McCallum wrote: It's crazy that version ranges are still unusable in 2.0.8.. * we can mix and match snapshots during development if we need to would not appear to work, i could swear i had this working in the last year... oh well, i can see how that would affect most projects -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
Back to the origin of the thread Version ranges with non-snapshot bounds can contain snapshot versions http://jira.codehaus.org/browse/MNG-3092 I feel that the current behaviour is correct and can be managed sufficiently by profiles. Let me render some scenarios... 1) You wish a release build with no snapshots which is the normal behaviour and so you just build the trunk of your artifact and it works... optionally the enforcer plugin can ensure that you are not including snapshot dependencies 2) You wish a dev build with all snapshots enabled so you enable a project configured in your settings.xml that exposes you snapshot repositories Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994 first 3) You wish a dev build but with only a single snapshot... build the project you wish a snapshot of into your local repo... build as in #1 If we were to fix MNG-3092 then 2 would not be possible... as you would have to go and edit all your poms to enable snapshots... i have well over 100 artifacts and many dependencies that exist in 40 or more projects... it seems to be that decent continuous integration would not be possible if you fix MNG-3092 Can we start a vote for this issue here I guess the same rules as releases would apply. 72 hours only pmc votes are binding. etc etc -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
another thought... by default you could not have snapshot repositories enabled and just enable them with a profile... that way all builds by default have no snapshots, you could even have separate profiles and snapshot repos for different departments to a allow more flexible integration -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin repositories (was: svn commit: r609772)
On Thu, 10 Jan 2008 04:21:32 John Casey wrote: After talking this over some more with Brian Fox, I'm convinced that this approach of segregating plugin and project repositories will result in a large amount of duplication of effort for ~90% of projects, since so many project-dependency repositories also host plugins. This is especially true as the community migrates to a more general use of proxies. So, this would tend to support my original changes, where all artifacts are drawn from the repositories list, even for plugin resolution. To keep Maven from resolving snapshot versions of plugins in this new setup, it would be great if we could add two new flags to the repository syntax: - dependencies (true|false) - plugins (true|false) there is no need for a change... deploy plugins to their own repo and disable snapshots on that repository definition... you could have a profile to enable if you want to pick up the snapshot plugin repo for testing... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin repositories (was: svn commit: r609772)
On Thu, 10 Jan 2008 11:56:34 Brian E. Fox wrote: there is no need for a change... I disagree. The current 2.0.x method of having separate config is just a major pita. Most people have them mixed (including us-Maven) and it means you almost always have to duplicate all your repos in both lists. This provides a simple way to minimize the config and have sensible defaults for the 99% of people that don't separate them. sorry wasn't trying to make that point, let me try that again... So, this would tend to support my original changes, where all artifacts are drawn from the repositories list, even for plugin resolution. To keep Maven from resolving snapshot versions of plugins in this new setup, it would be great if we could add two new flags to the repository syntax: - dependencies (true|false) - plugins (true|false) i don't think the plugins true|false is necessary you can use profiles and separate repositories to force it if you really want to -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
All fair comments. We don't release documentation for each release. site-deploys are independent. And we have perhaps fewer people. But at the same time I would never want another department to break my build by deploying a snapshot I'm not ready for. Quite possibly we could make more use of snapshots. Did we not start this whole discussion because you wanted artifact resolution to not work transparently with snapshots? i.e. you have to explicitly mention snapshots in the ranges as defined the original maven2 dependency spec. BTW snapshots are not filtered/faulted by the release plugin when defined in ranges, it would appear to work on the defined not resolved dependencies... you have to use the enforcer plugin which works on the resolved tree. cheers -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
IMHO, I think our approach excels in making sure this doesn't happen. First and foremost, if this version range issue can be fixed, snapshots will never be considered valid unless explicitly asked for. Therefore snapshot deploys will never be a problem for me. Currently I can't even release because snapshots are not filtered out. the enforcer plugin definitely fixes this and the generateReleasePoms=true ensures that the build from tag uses the same clean deps as when tagging -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote: IMHO, I think our approach excels in making sure this doesn't happen. First and foremost, if this version range issue can be fixed, snapshots will never be considered valid unless explicitly asked for. Therefore snapshot deploys will never be a problem for me. Currently I can't even release because snapshots are not filtered out. the enforcer plugin definitely fixes this and the generateReleasePoms=true ensures that the build from tag uses the same clean deps as when tagging sorry lets you get errors if you try to release with snapshots... this is how i configured it... it pays to do a clean test enabling the profile first otherwise it fails on perform rather than tag... there may be a better way that this though profile idenforce-no-snapshots/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId executions execution idenforce-no-snapshots/id phasevalidate/phase goals goalenforce/goal /goals configuration rules noSnapshots message No snapshots allowed in releases it breaks build reproducibility. /message /noSnapshots /rules searchTransitivetrue/searchTransitive failtrue/fail /configuration /execution /executions /plugin /plugins /build /profile -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
We just avoid that being an issue in three ways... 1) I slap anyone around who deploys a snapshot to a remote repository unless they have a _very_ good excuse. My method is to increment the major version if there is a breaking change and release early to avoid the need for snapshots. Ideally the repository would support sufficient metadata to tag releases as broken... but we get by for now. 2) enforcer plugin to stop releases having snapshots in them 3) all our versions are X.Y you only ever get X.Y.Z when you have patched a change to a library deployed into production On Tue, 08 Jan 2008 07:13:42 dhoffer wrote: Which maven release/build is this in? Based on my understanding I don't think this is sufficient to resolve this issue. It needs to exclude 1.0.4-SNAPSHOT as well, let me try to explain. If I specify a version range of [1.0,2.0) for a dependency, what I am saying is that I will accept any RELEASED version from 1.0 (inclusive) to 2.0 (exclusive). I am not saying I want any SNAPSHOTS to be allowed. The only time a SNAPSHOT should be allowed is when it is specified by an inclusive version range boundary. Michael McCallum-3 wrote: you can specify a range [1.0,1.1-!) which will stop 1.1-SNAPSHOT from being included, this wont stop 1.0.4-SNAPSHOT but i think thats valid anyway... On Sun, 06 Jan 2008 14:39:37 dhoffer wrote: What is the status of this? This issue is very serious (highest priority) for us; every time we update maven we have to apply a patch to fix this else releases fail. Can we come to some conclusion on how to fix this? -Dave mihobson wrote: Hi, Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was contrary to the 2.0 design docs: http://jira.codehaus.org/browse/MNG-3092 Brett, Kenney and myself had a brief discussion on IRC about this: Kenney says that the behaviour is theoretically correct (which it is), although I feel it goes against the practical usage described in the docs. The two main choices I can see are: 1) We stick to the design docs and disallow snapshots in ranges when they aren't an explicit boundary, as per the MNG-3092 patch. 2) We reconsider the design docs and leave range resolution behaving as it is, then use profiles to enable or disable snapshot repositories at build time. Any thoughts? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
On Tue, 08 Jan 2008 14:25:06 dhoffer wrote: Regarding 1: Well that's not normal maven operation. You apparently have created a 'work-around' that works for you...I prefer to fix the bug so it works as it is specified. There are lots of reasons to deploy snapshots. Normal maven behavior is that everything, in development, is always a snapshot. You have to deploy these so they can be used by others; now we do keep these on a separate repo, never mixed with releases. Perhaps the implementor realised the spec wasn't right and failed to update the docs... Anyway to snapshots, well the pom thats in the trunk of any artifact has a snapshot version but anything that i share with other developers has a release version. Each of our artifacts that in active development will get released at least once a day. The main reason being that i should not go messing with other developers environments unless I am confident that all the tests pass and the code works the same or better than before. I want a tool than gives me the power to define exactly what I am deploying and allow me to easily develop that and patch it if necessary. We are working with over 11 projects composed of 130 or so artifacts. It all works very well without snapshots being deployed. We do of course make use of snapshots in our local repositories though. Once of my major beefs about snapshots being deployed is that you get to a point where you want to make Release and have to unroll and whole tangle of transitive snapshots. We make at least one Release everyday and really need a fully consistent ready to deploy tree of artifacts. We mark the completion of a task as the release of the artifact... so if you have developers willy nilly deploying snapshots as a single developer i cannot easily mark the end of my work without rolling up other peoples as well. The simplest solution is to require by process that people release things regularly. And use metadata - or otherwise -to manage horribly broken artifacts, which very rarely happen with decent tests. Consider one of my least favourite quotes But it worked yesterday! For stable artifacts the rate of commits/checkin to releases is close to 1:1. For developing artifacts its much higher. In any case My vote would be for maintaining the current behaviour and allowing an option to change it at runtime or on the command line. You run the risk of breaking builds otherwise. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
you can specify a range [1.0,1.1-!) which will stop 1.1-SNAPSHOT from being included, this wont stop 1.0.4-SNAPSHOT but i think thats valid anyway... On Sun, 06 Jan 2008 14:39:37 dhoffer wrote: What is the status of this? This issue is very serious (highest priority) for us; every time we update maven we have to apply a patch to fix this else releases fail. Can we come to some conclusion on how to fix this? -Dave mihobson wrote: Hi, Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was contrary to the 2.0 design docs: http://jira.codehaus.org/browse/MNG-3092 Brett, Kenney and myself had a brief discussion on IRC about this: Kenney says that the behaviour is theoretically correct (which it is), although I feel it goes against the practical usage described in the docs. The two main choices I can see are: 1) We stick to the design docs and disallow snapshots in ranges when they aren't an explicit boundary, as per the MNG-3092 patch. 2) We reconsider the design docs and leave range resolution behaving as it is, then use profiles to enable or disable snapshot repositories at build time. Any thoughts? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Surefire 2.3.1
On Thu, 13 Dec 2007 05:59:18 Benjamin Bentmann wrote: Mauro Talevi wrote: firstly, nothing prevents us from releasing a 2.3.2 right after a 2.3.1. If an ordinary user may disturb: I really appreciate Mauro's attitude. For my taste, there could be more maintenance releases. Please consider that not all Maven users can/want to build plugins from source just to get a snapshot with a long awaited bugfix. Furthermore, a shorter release cycle will produce more release artifacts, giving users more possibilities to hack their POM if they find the latest release not usuable. Benjamin Bentmann i second that -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surefire 2.4 is coming
worked for me but i had to use maven-shade trunk to build surefire-api successfully NOTE: i built on java6... java4 failed on the junit4 support On Tue, 11 Dec 2007 14:18:51 Dan Tran wrote: No problem found in my build using 2.4 SNAPSHOT, good work. But I can't put it on production build thou. We test with latest snapshot from time to time. Thanks for putting all hard works. -D On Dec 10, 2007 4:50 PM, Dan Fabulich [EMAIL PROTECTED] wrote: Dan Tran wrote: Can I assume you already have the latest 1.4 snapshot at Apache's snapshot repository? Yes, maven-surefire-plugin-2.4-20071210.231259-19 is latest right now. (Its various other dependencies like surefire-api, surefire-booter, etc. are all deployed at the same time.) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including managed dependencies
On Tuesday 18 September 2007 19:40, 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. i came to a similar conclusion I use composite dependencies to wrap significat groups of 3rd party libraries in known good sets, standard depedency managements takes care of the rest... heavy use of ranges [1,2), [2,3) make life very simple in this regard What people are looking for is a single source of truth for versioning that is external to their projects, as heretical as that may sound, it is a practical truth. Where I am there are a set of people here through through the use of a build grid who determine what works then the developers are pretty much unaware what versions of artifacts they actually use. They may need new functionality and know what artifacts to use but they don't see the versioning. to some degree i agree but there is a big difference between spring 1 and spring 2 or hibernate 2 and hibernate 3 or even better example jaxb and jaxb2 I don't care about minor version only the feature version, i use composites as mentioned above to say a consistent set of libraries for using hibernate is this, lets call it composite.hibernate-1.X to get support for hibernate in project i depend apon the composite with a range [1,2) when i need to introduce a new set of hibernate functionality or a new set of libraries which will break things i bump to 2.X trying to bring two trees together with different major version will fail however i can easily release small updates composite.hibernate-1.2, 1.3 etc etc that will just work across all projects and deliverables What is needed is a version provider or a version catalog. What I'm trying to do with 2.1 in my current situation is to utilize and existing set of dependency information. In my case I cannot take the version information from anywhere as the designers of the original system won't let this change and after much debate as to where this version information should live I finally agreed with them. i can see the attraction... but nothing is reproducible... and how can you release and patch things if it not reproducible... i released version please look in catalog to env A... I think what large enterprises are looking for is a single source of truth for the versions, and how to deal with conflicts for a particular set of releases. So effectively what my POMs look are that they have no depMan sections, and no versions of anything are specified in the POM. Not even for the project itself as this is a particular problem for large clearcase-centric shops where the version of an artifact is defined by the clearcase label. So while your method works and may be good for 2.0.7 what are we ultimately creating? A depMan section is a localized version catalog. I think this could be implemented such that the default provider is the current depMan section but allow for things what I'm currently attempt which is vastly more appealing to my current client because every last piece of version information sits in one single file. how can it be one file... is there only one service? one deliverable and no shared depedencies? Surely its a tree at least Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Idea of a new parameter for the DEPLOY plugin
I would recommend changing your poms to avoid the situation where expansion on
install/deploy is required for things to work.
By containing variables I assume you mean expression expantion. So all the
properties should be expanded? I think that makes some sense but it affects
the ability to compose poms by inheritance.
For example I define the path for tags of my projects using ${pom.name} in the
parent pom so that my tag directory looks like this...
/tags/projectname/1.0
/tags/projectname/1.1
/tags/projectname/1.2
...
If that was resolved in the parent pom on deploy or install then everything
would end up tagged as
/tags/{parentname}/1.0
I notice that many people migrating projects over from ant tend to
parameterise their depedencies and IMO even worse use a parent to define the
versions of the depedencies. This leads to all sorts of problems in earlier
versions of maven 2.0.7 esp when running on jdks 5, not sure why the
sematics change on the different vms I think the default ordering of some
core collections changes.
I use some simple rules to keep consistent dependency hierachies
* dependecy ranges
* composition of dependencies
* don't deploy snapshots
* release early release often
* parent poms are not modules projects
and that works very well for a team of 10 with over 65 maven projects.
It helps to use webdav for deployment and http for repositories and set update
never for a proxy cached version of the main repos for improving the speed of
releases.
cheers
Michael
On Wednesday 22 August 2007 03:22, Brian E. Fox wrote:
If this is done (not sure I'm convinced) I think this also needs to be
handled in a way for Install also. Otherwise the pom in your local repo
won't match what ultimately gets deployed. This could cause lots of
headaches.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 21, 2007 4:12 AM
To: dev@maven.apache.org
Subject: Idea of a new parameter for the DEPLOY plugin
Hi All,
When using Maven in my job, I'm encountering a problem of deployed POM
which still contain variables. I would like to deploy POM whith the valued
variables.
I've looked at the deploy plugin source code, and I've understand that the
deployed POM was the file POM on the disk.
But, it could be interesting to introduce a new parameter (not mandatory)
named deployValuedPom to the deploy plugin. This parameter will be a
boolean flag to decide either to deploy the file POM on the disk
(parameter=false, the default value), either the valued POM (explicit
parameter=true). So the new feature won't have impact on existing projects.
What do you think about this new feature?
I could give a first version of the source code modification if the idea is
correct.
Thanks.
Cyril
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
