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
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:
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
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
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.
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
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
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 :-)
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
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
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
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
+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
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
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.
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
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
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
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.
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
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
21 matches
Mail list logo
