RE: Maven is in no danger of being replaced :-)
Jason, thank you for that concise information. It would be great if you could also publish a quarterly sampled line graph on the same stats, so one could easily identify and trends in this. :-) Regards Markus From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Donnerstag, 27. September 2012 20:03 To: Maven Users List Subject: Maven is in no danger of being replaced :-) I was curious to see what the breakdown is of Maven, Ivy and Gradle use so I took the block of traffic from last week and filtered down the unique IPs per tool across its versions. If you want to take a look at the data pulled you can see it here: https://gist.github.com/3794963 I used easily identifiable user agents. As Dan Kulp pointed out in IRC many versions of Maven 2.0.x are not accounted for because we never specified a user agent. So if anything, Maven's portion of the pie is bigger. Older versions of Gradle used Ivy, and older versions of Ivy also didn't identify itself correctly. Let's just say it all comes out in the wash and this is what we're left with. This is only traffic against Maven Central so it's hard to tell what's behind repository managers. But I think this is fairly representative. So as far as I can tell empirically from data gathered from the logs in Maven Central, Maven is in no danger of being replaced anytime soon. I believe that the Aether Ant tasks will ultimately replace Ivy in Ant builds, and Gradle has been around for 5 years (give or take) and it's not really making much of a dent. 0952.png Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
How to generate an announcement from GitHub with Changes plugin?
Hi, Is it possible somehow to generate an announcement from GitHub with Changes plugin. Or is there an other way? Rgds, Markku - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version ranges not working
I thought about mathematical ranges as well, and the outcome for me personally that a strict mathematical time vector interpretation makes no sense for maven. You have a library in version 1.7.0 which fits your project. Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary incompatible change. But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. Also: for most dependencies you only like to get released versions via your version range. But as I read here some use this internally as well and like to get SNAPSHOTS resolved. What about simply writing up what people like to have and then implement a new mechanism? I could even think about regexp based versioning... LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Users List users@maven.apache.org Cc: Sent: Saturday, September 29, 2012 5:06 AM Subject: Re: Version ranges not working yes, https://jira.codehaus.org/browse/MNG-3092 is still here I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do so, it's not a *range* any more but a range + a filter (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english) and actual discussion helps me dig into other ideas that could be useful: IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and beta too, no? But I'm not sure about the use case (and Guide to using version ranges still needs to be written: https://jira.codehaus.org/browse/MNG-1368) I understand that when a library is at 1.9 and someone needs old 1.8-, he implictely wants releases, not alpha nor SNAPSHOTS But if 1.8 is still not out, and there is still work on 1.7.x, we need to accept *latest* 1.7.x whatever its maturity level is Really , excluding version from a mathematical range is another operation that needs some specification and probably something more expressive than [min,max] Regards, Hervé Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit : I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. However one of the problems is that since this issue was never fixed...and sadly seems never will be...we had to abandon the use of version ranges. I do not agree they are a bad idea. I think they could have been a very useful feature if implemented as originally proposed. (The fundamental problem was that they did not exclude SNAPSHOTS as originally intended/stated.) Effectively we had to work around the lack of version ranges by just building against SNAPSHOTS instead (I'm talking about internal code here). So effectively the SNAPSHOT became our version range. One of the problems of this approach is now I have to toggle between going offline/online if I don't want to accept new updates since it will be changing on a regular basis. Using version ranges would have been a more elegant solution as it would give me more control over what versions I depend on during development. Because it wasn't fixed and we had to do the workaround I have not been close to this issue anymore...its been like 5 years or more. But the short answer is it should be fixed and it can/could be useful as some have indicated in this discussion. -Dave On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 28/09/2012 3:17 AM, Jesse Long wrote: Without version ranges, how do I write a library that works with SLF4J version 1.5.*, but does not work with SLF4J 1.6.*? Do I depend on, say, version 1.5.11? Then when a user depends on my library, and on slf4j-api directly, specifying slf4j-api version 1.6.0 in his pom, Maven will link in 1.6.0. So that is pretty useless to me. If I find a way to enforce version 1.5.11. Then I am loosing the ability to upgrade to any future version 1.5.*. I am not sure how version ranges will help you in this case. Your mythical user is overriding your version 1.5.* with 1.6.* so he will be in trouble using your library regardless of what you put in your dependency. If your library is clearly documented as not being compatible with versions after 1.5.*, then the user is responsible for making sure that nothing brings in a later version of slf4j. You had better write a big note about your restriction since most of us will just put an exclusion on your transitive dependency for slf4j and run with the version that we want. There are not many good libraries that are not upwards compatible and it is generally safe to run with the latest version of everything. The good library authors will change the artifact name if the new version is not capable of supporting code written for the previous version. I have yet to see a good case for version ranges and it
Re: Maven is in no danger of being replaced :-)
Surely Tesla's going to revolutionise the world and take over? :-) Are there any -SNAPSHOT dists anywhere at all? On 28/09/2012, at 6:03 AM, Jason van Zyl ja...@tesla.io wrote: I was curious to see what the breakdown is of Maven, Ivy and Gradle use so I took the block of traffic from last week and filtered down the unique IPs per tool across its versions.
Re: Version ranges not working
Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit : I thought about mathematical ranges as well, and the outcome for me personally that a strict mathematical time vector interpretation makes no sense for maven. You have a library in version 1.7.0 which fits your project. Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary incompatible change. But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. Also: for most dependencies you only like to get released versions via your version range. But as I read here some use this internally as well and like to get SNAPSHOTS resolved. a range tells about a constraint then choosing a precise version between the multiple choices that match constraints is not about the range but about what is usually called conflict resolution This term is ok when it's about changing preferred version (ie when versions are not defined as range but as simple version, which means preferred version) but that term doesn't show that when it's about ranges, it's not about conflict but about choosing one version between the multiple valid choices: do you prefer the most recent? even if it is a snapshot or an alpha? or if the most recent is an alpha, you prefer to stick with stable version? IMHO, during development, you can want to test latest alpha SNAPSHOT, but when doing a release, you'll prefer stable versions What about simply writing up what people like to have and then implement a new mechanism? I could even think about regexp based versioning... sure, there is something to create here, but IMHO not into version ranges: into conflict resolution specification and switch (with CLI or IDE) LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Users List users@maven.apache.org Cc: Sent: Saturday, September 29, 2012 5:06 AM Subject: Re: Version ranges not working yes, https://jira.codehaus.org/browse/MNG-3092 is still here I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do so, it's not a *range* any more but a range + a filter (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english) and actual discussion helps me dig into other ideas that could be useful: IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and beta too, no? But I'm not sure about the use case (and Guide to using version ranges still needs to be written: https://jira.codehaus.org/browse/MNG-1368) I understand that when a library is at 1.9 and someone needs old 1.8-, he implictely wants releases, not alpha nor SNAPSHOTS But if 1.8 is still not out, and there is still work on 1.7.x, we need to accept *latest* 1.7.x whatever its maturity level is Really , excluding version from a mathematical range is another operation that needs some specification and probably something more expressive than [min,max] Regards, Hervé Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit : I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. However one of the problems is that since this issue was never fixed...and sadly seems never will be...we had to abandon the use of version ranges. I do not agree they are a bad idea. I think they could have been a very useful feature if implemented as originally proposed. (The fundamental problem was that they did not exclude SNAPSHOTS as originally intended/stated.) Effectively we had to work around the lack of version ranges by just building against SNAPSHOTS instead (I'm talking about internal code here). So effectively the SNAPSHOT became our version range. One of the problems of this approach is now I have to toggle between going offline/online if I don't want to accept new updates since it will be changing on a regular basis. Using version ranges would have been a more elegant solution as it would give me more control over what versions I depend on during development. Because it wasn't fixed and we had to do the workaround I have not been close to this issue anymore...its been like 5 years or more. But the short answer is it should be fixed and it can/could be useful as some have indicated in this discussion. -Dave On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 28/09/2012 3:17 AM, Jesse Long wrote: Without version ranges, how do I write a library that works with SLF4J version 1.5.*, but does not work with SLF4J 1.6.*? Do I depend on, say, version 1.5.11? Then when a user depends on my library, and on slf4j-api directly, specifying slf4j-api version 1.6.0 in his pom, Maven will link in 1.6.0. So that is pretty useless to
Re: Version ranges not working
The issue I see is that there is a difference with ranges between build time and run time. In general at build time you want the lowest version in the range (assuming the api is versions correctly) to ensure you are compatible with the smallest set of api method signatures. At run time you want the highest as it has the most big fixes in theory. At test time you ideally want every version. But that matrixes out to an impossible combinatorial. On Saturday, 29 September 2012, Hervé BOUTEMY wrote: Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit : I thought about mathematical ranges as well, and the outcome for me personally that a strict mathematical time vector interpretation makes no sense for maven. You have a library in version 1.7.0 which fits your project. Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary incompatible change. But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. Also: for most dependencies you only like to get released versions via your version range. But as I read here some use this internally as well and like to get SNAPSHOTS resolved. a range tells about a constraint then choosing a precise version between the multiple choices that match constraints is not about the range but about what is usually called conflict resolution This term is ok when it's about changing preferred version (ie when versions are not defined as range but as simple version, which means preferred version) but that term doesn't show that when it's about ranges, it's not about conflict but about choosing one version between the multiple valid choices: do you prefer the most recent? even if it is a snapshot or an alpha? or if the most recent is an alpha, you prefer to stick with stable version? IMHO, during development, you can want to test latest alpha SNAPSHOT, but when doing a release, you'll prefer stable versions What about simply writing up what people like to have and then implement a new mechanism? I could even think about regexp based versioning... sure, there is something to create here, but IMHO not into version ranges: into conflict resolution specification and switch (with CLI or IDE) LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Users List users@maven.apache.org Cc: Sent: Saturday, September 29, 2012 5:06 AM Subject: Re: Version ranges not working yes, https://jira.codehaus.org/browse/MNG-3092 is still here I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do so, it's not a *range* any more but a range + a filter (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english) and actual discussion helps me dig into other ideas that could be useful: IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and beta too, no? But I'm not sure about the use case (and Guide to using version ranges still needs to be written: https://jira.codehaus.org/browse/MNG-1368) I understand that when a library is at 1.9 and someone needs old 1.8-, he implictely wants releases, not alpha nor SNAPSHOTS But if 1.8 is still not out, and there is still work on 1.7.x, we need to accept *latest* 1.7.x whatever its maturity level is Really , excluding version from a mathematical range is another operation that needs some specification and probably something more expressive than [min,max] Regards, Hervé Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit : I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. However one of the problems is that since this issue was never fixed...and sadly seems never will be...we had to abandon the use of version ranges. I do not agree they are a bad idea. I think they could have been a very useful feature if implemented as originally proposed. (The fundamental problem was that they did not exclude SNAPSHOTS as originally intended/stated.) Effectively we had to work around the lack of version ranges by just building against SNAPSHOTS instead (I'm talking about internal code here). So effectively the SNAPSHOT became our version range. One of the problems of this approach is now I have to toggle between going offline/online if I don't want to accept new updates since it will be changing on a regular basis. Using version ranges would have been a more elegant solution as it would give me more control over what versions I depend on during development. Because it wasn't fixed and we had to do the workaround I have not been close to this issue anymore...its been like 5 years or more. But the short answer is it should be fixed and it can/could be
Re: Maven is in no danger of being replaced :-)
Markus, I started from a place where the user agent ids stabilized. A huge swath of Maven 2.0.x usage is missing because the user agent isn't easily identified, as is the case with Ivy and Gradle in the past. I posit that if I actually went back and pulled out all the commons-http-client user agents and used the same ratios as the chart shows Maven would probably be closer to 85%. Someone asked for past stats so I'm going to go back and do another sampling. Definitely going forward this is easy to do as the user agents are accurate if we normalize to the initial set used in the first report then we have a decent baseline. I'm not worried about the missing block of Maven 2.0.x users because as they move forward to a version of Maven that is identifiable they will come back into play. On Sep 29, 2012, at 3:52 AM, Markus KARG mar...@headcrashing.eu wrote: Jason, thank you for that concise information. It would be great if you could also publish a quarterly sampled line graph on the same stats, so one could easily identify and trends in this. :-) Regards Markus From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Donnerstag, 27. September 2012 20:03 To: Maven Users List Subject: Maven is in no danger of being replaced :-) I was curious to see what the breakdown is of Maven, Ivy and Gradle use so I took the block of traffic from last week and filtered down the unique IPs per tool across its versions. If you want to take a look at the data pulled you can see it here: https://gist.github.com/3794963 I used easily identifiable user agents. As Dan Kulp pointed out in IRC many versions of Maven 2.0.x are not accounted for because we never specified a user agent. So if anything, Maven's portion of the pie is bigger. Older versions of Gradle used Ivy, and older versions of Ivy also didn't identify itself correctly. Let's just say it all comes out in the wash and this is what we're left with. This is only traffic against Maven Central so it's hard to tell what's behind repository managers. But I think this is fairly representative. So as far as I can tell empirically from data gathered from the logs in Maven Central, Maven is in no danger of being replaced anytime soon. I believe that the Aether Ant tasks will ultimately replace Ivy in Ant builds, and Gradle has been around for 5 years (give or take) and it's not really making much of a dent. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: Maven is in no danger of being replaced :-)
Only a small part of Tesla is the build tool, and they are all just JARs you stick in a normal Maven installation. Most of what Tesla is is the integration of all the tools across the delivery chain. The Maven extensions are really not terribly exciting. The shell, however, is pretty cool :-) I'll probably show it to a few more people at JavaOne but I'm more interested in it being useful, well documented and having a decent website before I release it. I'd hoped to have it in a state ready for public consumption at JavaOne but it's not and I don't really care about trying to get things done for conferences anymore. On Sep 29, 2012, at 6:51 AM, Mark Derricutt m...@talios.com wrote: Surely Tesla's going to revolutionise the world and take over? :-) Are there any -SNAPSHOT dists anywhere at all? On 28/09/2012, at 6:03 AM, Jason van Zyl ja...@tesla.io wrote: I was curious to see what the breakdown is of Maven, Ivy and Gradle use so I took the block of traffic from last week and filtered down the unique IPs per tool across its versions. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: Version ranges not working
yes, that's my point: ranges are the same, but version to choose are different the solution won't come from ranges tweak but conflict resolution improvements Le samedi 29 septembre 2012 17:31:29 Stephen Connolly a écrit : The issue I see is that there is a difference with ranges between build time and run time. In general at build time you want the lowest version in the range (assuming the api is versions correctly) to ensure you are compatible with the smallest set of api method signatures. At run time you want the highest as it has the most big fixes in theory. At test time you ideally want every version. But that matrixes out to an impossible combinatorial. On Saturday, 29 September 2012, Hervé BOUTEMY wrote: Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit : I thought about mathematical ranges as well, and the outcome for me personally that a strict mathematical time vector interpretation makes no sense for maven. You have a library in version 1.7.0 which fits your project. Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary incompatible change. But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. Also: for most dependencies you only like to get released versions via your version range. But as I read here some use this internally as well and like to get SNAPSHOTS resolved. a range tells about a constraint then choosing a precise version between the multiple choices that match constraints is not about the range but about what is usually called conflict resolution This term is ok when it's about changing preferred version (ie when versions are not defined as range but as simple version, which means preferred version) but that term doesn't show that when it's about ranges, it's not about conflict but about choosing one version between the multiple valid choices: do you prefer the most recent? even if it is a snapshot or an alpha? or if the most recent is an alpha, you prefer to stick with stable version? IMHO, during development, you can want to test latest alpha SNAPSHOT, but when doing a release, you'll prefer stable versions What about simply writing up what people like to have and then implement a new mechanism? I could even think about regexp based versioning... sure, there is something to create here, but IMHO not into version ranges: into conflict resolution specification and switch (with CLI or IDE) LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Users List users@maven.apache.org Cc: Sent: Saturday, September 29, 2012 5:06 AM Subject: Re: Version ranges not working yes, https://jira.codehaus.org/browse/MNG-3092 is still here I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do so, it's not a *range* any more but a range + a filter (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english) and actual discussion helps me dig into other ideas that could be useful: IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and beta too, no? But I'm not sure about the use case (and Guide to using version ranges still needs to be written: https://jira.codehaus.org/browse/MNG-1368) I understand that when a library is at 1.9 and someone needs old 1.8-, he implictely wants releases, not alpha nor SNAPSHOTS But if 1.8 is still not out, and there is still work on 1.7.x, we need to accept *latest* 1.7.x whatever its maturity level is Really , excluding version from a mathematical range is another operation that needs some specification and probably something more expressive than [min,max] Regards, Hervé Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit : I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. However one of the problems is that since this issue was never fixed...and sadly seems never will be...we had to abandon the use of version ranges. I do not agree they are a bad idea. I think they could have been a very useful feature if implemented as originally proposed. (The fundamental problem was that they did not exclude SNAPSHOTS as originally intended/stated.) Effectively we had to work around the lack of version ranges by just building against SNAPSHOTS instead (I'm talking about internal code here). So effectively the SNAPSHOT became our version range. One of the problems of this approach is now I have to toggle between going offline/online if
Re: Version ranges not working
On Sep 29, 2012, at 12:31 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The issue I see is that there is a difference with ranges between build time and run time. Bingo. And this is what confuses a lot of people especially if they come from OSGi where the target platform against which they compile is really a runtime notion. But I believe this is a completely flawed approach. Igor and I have had so many conversations about this. In general at build time you want the lowest version in the range (assuming the api is versions correctly) to ensure you are compatible with the smallest set of api method signatures. At build time you build against _one_ version. You may want it to be the lowest, or some other criterion, but you build against a very specific version. No in their right might is going to let the system just resolve any implementation from any source. Never, ever going to happen and the conflation of these things specifically in Maven was just an oversight in what we actually allow. I think Ralph got it mostly right in how dependencyManagement works because in practice most of the time you want to severely limit what gets chosen. Where the current system breaks down is the combination of many subsystems but that's another story and if you're dealing with one application all the time it works great. You compile against something very specific. At runtime however you may let the system roam somewhat in order to update without rebuilding the whole system for performance problems, security fixes or what have you. Allowing ranges in the POM for compilation I believe is a mistake for the most part. Maven conflates the compile time and runtime where compile time is king, and OSGi conflates compile time and runtime where runtime is king. Both have problems. A QA person cannot validate a range in practice, they can however validate a concrete set of components and given proper retention policies on repositories, proper management of configurations of the various systems the result is reproducible. This things was built, I tested this thing and it runs as expected so I'm shipping this thing which consists of a known set of artifacts. On top of that you can reason about what might be acceptable changes. But again in practice who is going to let a runtime system just go grab some shit and update itself. Probably no one. Really you find you need to make a change, you introduce a new artifact and test it again. I really don't think anyone really allows a runtime to update itself without strict constraints. There are distinct cases as well. If you're a SaaS you likely don't give a crap and you just rebuild everything and deploy it again, or you take a diff of the artifacts of one build to the next and send instructions to a node and change it to mirror the new version, or use a git repo and just update it. The case of Eclipse is different in that you want people to be able to update to newer versions. But we build m2e with very specific versions of bundles and then use ranges so that people with existing installations and use new things. But the Eclipse repository for a release is extremely constrained from version to version. Everyone builds against the same thing building up to a release and we put ranges in manifests so people can update, but compile time is for the most part very specific. At any rate, I believe the specification of what you compile with versus what you may potentially want to run with should be separated. Maven and OSGi get this wrong from my perspective. And it seems to me in the wild more people do OSGi with Maven so this muddies the water even further (the maven-bundle-plugin is the most used plugin outside of the core maven plugins). At run time you want the highest as it has the most big fixes in theory. Right, in theory you would like to leave the runtime intact for as long as possible absorbing changes without rebuilding if possible. But I'm not sure this is really done. At the most advanced development shops I've been in there are radical simplifications like just rebuild and redeploy the whole thing because Maven, along with everything else can result in problems primarily from configuration differences, retention policies on repositories but it's enough to cause problems that prevent predictable re-deploys. So they rebuild and redeploy the whole thing. At test time you ideally want every version. But that matrixes out to an impossible combinatorial. I think you create them when necessary and they are specific and you test that and validate it. No one in practice tests all combinations as it's likely many of them are not used so why expend the resources to try them. On Saturday, 29 September 2012, Hervé BOUTEMY wrote: Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit : I thought about mathematical ranges as well, and the outcome for me personally that a strict mathematical
Re: Version ranges not working
Wait, You're suggesting we starting encoding VERSION NUMBERING into the artefact NAME now? Isn't that just as bad, if not worse than the abuse of classifiers we already see out there? We have the exact same issue being discussed here, and also as mentioned by others use OSGi. One of the key things to think of in all these situations to also let your artefacts work FOR you. 1) Separate out APIs from implementations - two artefacts 2) Users depend ONLY on API - NEVER implementations - mock those implementations for testing, or have a third fake/test impl. 3) Use composite artefacts for grouping common dependencies - a POM only artefact with dependencies, i.e. a testing pom that deps on testng, fest-assert etc. etc. 4) Often its only really the packaging/distribution that really needs the range to be resolved so maybe we should enhance the assembly plugin, or some other new packaging plugin. On 29/09/2012, at 8:21 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Not acceptable. If a developer is not going to provide upward compatibility, then they should change the Artifact id to be sure that no one gets hurt because of the laziness or lack of thoughtfulness or just plain bad design of the older version. Major versions are not incompatible in most libraries. Hibernate is a good example where the developers realized that version 3 was completely different from versions. If they wanted to have reasonably method names without the danger of people getting hurt by trying to run code written to version 2 specs against version 3, they had to rename the artifacts.
Re: Version ranges not working
This idea would require a POM change, but similar to repository definitions having the option of declaring release or snapshot's being enabled, maybe something similar could be provided for dependencies. Or, with modifying the POM itself, we could extend the capability of the classifier attribute to somehow express NO CLASSIFIER which would exclude -SNAPSHOT, -alpha etc. etc. Maybe classifier/ or classifier/classifier could handle that, which is different to it being absent. This does beg the question of weather -SNAPSHOT is or is not a classifier or not - having -SNAPSHOT just be a magically part of the version and not a classifier has always been a bug bear, esp. with timestamp'd SNAPSHOTs breaking the 1-1 mapping of direction/filenames On 29/09/2012, at 3:06 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do so, it's not a *range* any more but a range + a filter (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english)
Re: Version ranges not working
+1 - we've mentioned this on the IA podcast a few times in the past - compile against the lower bound, run against the upper bound. How to express that however On 30/09/2012, at 5:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: In general at build time you want the lowest version in the range (assuming the api is versions correctly) to ensure you are compatible with the smallest set of api method signatures.
Re: How to generate an announcement from GitHub with Changes plugin?
Hi Support for a report based on issues at GitHub was added in the latest version. There is no support for announcements yet. It should be relatively easy to do though, now that the code to fetch issues from the GitHub issue tracker is in place. Patches are welcome. Have a look in AnnouncementMojo how it has been implemented for JIRA and Trac. On 2012-09-29 10:22, Markku Saarela wrote: Hi, Is it possible somehow to generate an announcement from GitHub with Changes plugin. Or is there an other way? Rgds, Markku - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version ranges not working
I agree with Richard, as they exist now in maven version ranges can be used very effectively. I'm happy to post example projects if you want to know how to do it. If you want 'repeatability' then ranges might not be for you but if you want determinism and releasability then ranges are for you. Its just a matter of having good process and leveraging the tools to there greatest effect, rather than trying to make the tool perfect. On Sat, Sep 29, 2012 at 11:16 AM, Richard Vowles rich...@bluetrainsoftware.com wrote: You may then be surprised to know that there are many of us for whom version ranges in Maven work perfectly. Ideally Maven could be more clever and understand that [1.6.2] is already on the local system and the metadata checking for ranges doesn't need to be re-fetched, but that is merely an optimisation. SNAPSHOTS work perfectly, ranges work perfectly, and SemVer is a silly waste of space. Richard On Sat, Sep 29, 2012 at 2:07 AM, David Hoffer dhoff...@gmail.com wrote: I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. -- --- Richard Vowles, Grails, Groovy, Java Consistency is the last refuge of the unimaginative - Oscar Wilde ph: +64275467747, linkedin, twitter:richardvowles get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh podcast: http://www.illegalargument.com
RFE: dependency:get plugin should support version rangers
It'd be nice to be able to download the latest version of an artifact with the dependency plugin (eg. for use in a deployment script) using the same mechanism Maven itself uses, i.e., dependency ranges. Unfortunately, the dependency plugin does the wrong thing with them: $ mvn dependency:get \ -Dtransitive=false \ -DgroupId=com.example \ -DartifactId=example \ -Dversion='[1,]' \ -Ddest=example-LATEST.jar complains that it couldn't find an artifact whose literal version was [1,]. Totally a wouldn't it be nice if request, -o - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version ranges not working
I - almost - disagree completely, I've successfully used ranges on seven
separate commercial projects. A mix of sizes from corporate to startup.
If you care at all about agility being explicit everyone is very
cumbersome, the fundamental aspect is determinism - meaning that its
obvious WHY it behaves the way it does, once you understand how maven
implements ranges its very easy to use to them to great effect.
Having said that using ranges can be dangerous hence the composition
pattern mentioned in my previous email.
When you say nail down your version do you use [1.7.1] or 1.7.1?
On Fri, Sep 28, 2012 at 11:20 AM, Baptiste MATHUS m...@batmat.net wrote:
+1.
Version ranges are basically just a bad practice in my experience. I mostly
don't see any interest apart from being able to see a normally passing
build suddenly going rogue because you somehow had a dependency update
somewhere in the dependency tree. (I wrote something similar in that
comment
http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
)
So, please, Maven users, don't use them. It's like having scripts inside
your pom.xml, it might seem sexy and powerful, but it's dangerous.
Nail down a version, and upgrade explicitly when you need to and/or are
ready to. You'll be very happy that way and your build'll stay green.
Cheers
2012/9/28 Stephen Connolly stephen.alan.conno...@gmail.com
Well that is a recipe for disaster. rules only make sense within the
scope
of the artifacts they apply to.
This is kind of why version ranges are next to useless from a practical
PoV
anyway
On 27 September 2012 23:05, Paul French paul.fre...@kirona.com wrote:
I would only want the same version rules applied to all artifacts, not
on
a per artifact basis, that would be a nightmare! I understand that
people
who produce artifacts have their own versioning rules. However we can
take
that into account in our version ranging.
Usually for 3rd party artifacts we have a very narrow version range
since
we cannot trust the producer of that artifact not to break their
current
API in later versions unless they support semantic versioning.
On 27/09/2012 22:29, Stephen Connolly wrote:
when is that class applied?
each dependency would have its own comparator, as each dependency has
its
own versioning rules.
and then don't start on epoch's (i.e. where the versioning rules
change
from under your feet mid sequence
It's tempting... but dangerous... the closest I have come up with is
the
rulesets hack from versions-maven-plugin @ mojo... but even that has
issues... hence why I haven't pushed it further.
-Stephen
On 27 September 2012 22:19, Paul French paul.fre...@kirona.com
wrote:
Okay I see the problem.
How about allowing a user to plugin a Version class that implements
Comparator
class MavenVersion implements ComparableMavenVersion
{
public int compareTo(MavenVersion o)
{
// your implementation
}
}
Then we can all do whatever we need.
On 27/09/2012 21:40, Hervé BOUTEMY wrote:
I understand that many people get caught
But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?
The actual semantic is pure mathematical range, including or
excluding
an
extreme
since 1.8-alpha1.8-beta-1.8-rc1.8-SNAPSHOT1.8, it's pure
math
IMHO, anything that doesn't conform mathematical range will have
some
unexpected behaviour sometime
Yes, people need to learn that they usually want
[1.7,1.8-alpha-SNAPSHOT)
if
they want to be precise. Or approximations: [1.7,1.8-a),
[1.7,1.7.999]
Or we need to create another notation and define its semantics
precisely
Regards,
Hervé
Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
+1
I agree with Jesse.
A version range like [1.7,1.8) should exclude any artifact that
starts
with 1.8
Then maven (or aether) would respect semantic versioning rules.
We use version ranges/semantic versioning and API analysis to
ensure
our
artifacts are versioned correctly. Sometimes we get caught out by
what
Jesse outlined below.
On 27/09/2012 15:51, Stephen Connolly wrote:
On 27 September 2012 14:41, Jesse Long j...@unknown.za.net
wrote:
Dear Maven Community,
I am writing to beg you to fix the problems with the version
ranges
in
Maven 3.0.5, specifically regarding the defining compatible
version
ranges.
I am using Maven 3.0.4. I have a simple project that depends on
org.slf4j:slf4j-api version 1.5.*. I define my compatibility
range
as
[1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
define
the
version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
version
1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but
Re: Version ranges not working
For a practical solution... I just stopped using 0's in versions.. maven interprets 1.8 as 1.8.0 then [1.7,1.8) will never match 1.8.1-SNAPSHOT invariably you don't actually want a third parties release to affect you build because what they consider and breaking change might not be for you therefore you need your own lifecyle for the external dependency. I use composition poms for slf4j it looks like this... http://search.maven.org/remotecontent?filepath=net/stickycode/composite/sticky-composite-logging-api/2.1/sticky-composite-logging-api-2.1.pom All my projects depend on the composite at [2,3) and as I control the lifecycle it always works. I can upgrade the version across all my projects with a new release of the composite. You may note the two point version... personally I don't bother with the patch version, two points is enough, if you break it change the major version and if you don't change the minor. my 2c Michael
Re: RFE: dependency:get plugin should support version rangers
On Sat, Sep 29, 2012 at 1:30 AM, Owen Jacobson owen.jacob...@grimoire.ca wrote: It'd be nice to be able to download the latest version of an artifact with the dependency plugin (eg. for use in a deployment script) using the same mechanism Maven itself uses, i.e., dependency ranges. Unfortunately, the dependency plugin does the wrong thing with them: $ mvn dependency:get \ -Dtransitive=false \ -DgroupId=com.example \ -DartifactId=example \ -Dversion='[1,]' \ -Ddest=example-LATEST.jar complains that it couldn't find an artifact whose literal version was [1,]. Totally a wouldn't it be nice if request, Does http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html have the same problem? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version ranges not working
The composite pattern also makes exclusion very easy.
On Sep 30, 2012 3:35 PM, Michael McCallum mich...@stickycode.net wrote:
I - almost - disagree completely, I've successfully used ranges on seven
separate commercial projects. A mix of sizes from corporate to startup.
If you care at all about agility being explicit everyone is very
cumbersome, the fundamental aspect is determinism - meaning that its
obvious WHY it behaves the way it does, once you understand how maven
implements ranges its very easy to use to them to great effect.
Having said that using ranges can be dangerous hence the composition
pattern mentioned in my previous email.
When you say nail down your version do you use [1.7.1] or 1.7.1?
On Fri, Sep 28, 2012 at 11:20 AM, Baptiste MATHUS m...@batmat.net wrote:
+1.
Version ranges are basically just a bad practice in my experience. I
mostly
don't see any interest apart from being able to see a normally passing
build suddenly going rogue because you somehow had a dependency update
somewhere in the dependency tree. (I wrote something similar in that
comment
http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
)
So, please, Maven users, don't use them. It's like having scripts inside
your pom.xml, it might seem sexy and powerful, but it's dangerous.
Nail down a version, and upgrade explicitly when you need to and/or are
ready to. You'll be very happy that way and your build'll stay green.
Cheers
2012/9/28 Stephen Connolly stephen.alan.conno...@gmail.com
Well that is a recipe for disaster. rules only make sense within the
scope
of the artifacts they apply to.
This is kind of why version ranges are next to useless from a practical
PoV
anyway
On 27 September 2012 23:05, Paul French paul.fre...@kirona.com
wrote:
I would only want the same version rules applied to all artifacts,
not
on
a per artifact basis, that would be a nightmare! I understand that
people
who produce artifacts have their own versioning rules. However we can
take
that into account in our version ranging.
Usually for 3rd party artifacts we have a very narrow version range
since
we cannot trust the producer of that artifact not to break their
current
API in later versions unless they support semantic versioning.
On 27/09/2012 22:29, Stephen Connolly wrote:
when is that class applied?
each dependency would have its own comparator, as each dependency
has
its
own versioning rules.
and then don't start on epoch's (i.e. where the versioning rules
change
from under your feet mid sequence
It's tempting... but dangerous... the closest I have come up with is
the
rulesets hack from versions-maven-plugin @ mojo... but even that has
issues... hence why I haven't pushed it further.
-Stephen
On 27 September 2012 22:19, Paul French paul.fre...@kirona.com
wrote:
Okay I see the problem.
How about allowing a user to plugin a Version class that implements
Comparator
class MavenVersion implements ComparableMavenVersion
{
public int compareTo(MavenVersion o)
{
// your implementation
}
}
Then we can all do whatever we need.
On 27/09/2012 21:40, Hervé BOUTEMY wrote:
I understand that many people get caught
But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?
The actual semantic is pure mathematical range, including or
excluding
an
extreme
since 1.8-alpha1.8-beta-1.8-rc1.8-SNAPSHOT1.8, it's pure
math
IMHO, anything that doesn't conform mathematical range will have
some
unexpected behaviour sometime
Yes, people need to learn that they usually want
[1.7,1.8-alpha-SNAPSHOT)
if
they want to be precise. Or approximations: [1.7,1.8-a),
[1.7,1.7.999]
Or we need to create another notation and define its semantics
precisely
Regards,
Hervé
Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
+1
I agree with Jesse.
A version range like [1.7,1.8) should exclude any artifact that
starts
with 1.8
Then maven (or aether) would respect semantic versioning rules.
We use version ranges/semantic versioning and API analysis to
ensure
our
artifacts are versioned correctly. Sometimes we get caught out by
what
Jesse outlined below.
On 27/09/2012 15:51, Stephen Connolly wrote:
On 27 September 2012 14:41, Jesse Long j...@unknown.za.net
wrote:
Dear Maven Community,
I am writing to beg you to fix the problems with the version
ranges
in
Maven 3.0.5, specifically regarding the defining compatible
version
ranges.
I am using Maven 3.0.4. I have a simple project that depends on
Re: How to generate an announcement from GitHub with Changes plugin?
Hi, Thanks, i'll look those. Markku On 09/30/2012 12:06 AM, Dennis Lundberg wrote: Hi Support for a report based on issues at GitHub was added in the latest version. There is no support for announcements yet. It should be relatively easy to do though, now that the code to fetch issues from the GitHub issue tracker is in place. Patches are welcome. Have a look in AnnouncementMojo how it has been implemented for JIRA and Trac. On 2012-09-29 10:22, Markku Saarela wrote: Hi, Is it possible somehow to generate an announcement from GitHub with Changes plugin. Or is there an other way? Rgds, Markku - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
