On Wed, Aug 21, 2013 at 11:28 AM, Robert Scholte rfscho...@apache.org wrote:
The problem with newest is that it can *never* be overridden by the active
project, for whatever reason.
Instead of newest I'd prefer to use the RequireUpperBoundDependencies
Enforcer Rule[1] which give you the same
On Wed, Aug 21, 2013 at 11:34 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
IIUC Baptiste point, the question is not about exceptionally forcing to the
old release when 2 versions are in conflict, but to choose the newer one of
the two proposed versions vs using the newest in the repository (=
On Wed, Aug 21, 2013 at 8:21 PM, Mark Derricutt m...@talios.com wrote:
On 22/08/2013, at 4:37 AM, Phillip Hellewell ssh...@gmail.com wrote:
My idea to solve this was to add support for a
forcevertrue/forcever in the dependency declaration. Thoughts?
I didn't think we could change the POM
Beware the changing of the pom schema is a thorny subject... at present
we are still stuck trying to decide how to evolve to the next schema
(whatever that is) without breaking *everything*
On 22 August 2013 16:54, Phillip Hellewell ssh...@gmail.com wrote:
On Wed, Aug 21, 2013 at 8:21 PM,
grhhh
same with:
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-20
00:51:28+1100)
Maven home: /Users/olamy/softs/maven/apache-maven-3.0.5
Java version: 1.6.0_51, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale:
On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Beware the changing of the pom schema is a thorny subject... at present
we are still stuck trying to decide how to evolve to the next schema
(whatever that is) without breaking *everything*
How does
On 23/08/2013, at 2:52 PM, Phillip Hellewell ssh...@gmail.com wrote:
On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Beware the changing of the pom schema is a thorny subject... at present
we are still stuck trying to decide how to evolve to the
On Aug 21, 2013 7:00 AM, Olivier Lamy ol...@apache.org wrote:
On 21 August 2013 00:08, Jason van Zyl ja...@tesla.io wrote:
Doesn't answer the question whether the job is valid. It's referencing
incorrect plugins and why would you consume the latest version of Guice and
not through Sisu?
Should maven not have a Concept to support multiple schema versions?
Am 23.08.2013 um 05:08 schrieb Mark Derricutt m...@talios.com:
On 23/08/2013, at 2:52 PM, Phillip Hellewell ssh...@gmail.com wrote:
On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
As one of the main downstream users of Sisu would you prefer it to declare
a provided scope dependency to (sisu-)guice rather than the current compile
scope dependency?
Making it provided should make it easier to swap in alternative versions
while still documenting the dependency - and avoid lots
On Aug 22, 2013, at 8:57 PM, Stuart McCulloch mccu...@gmail.com wrote:
As one of the main downstream users of Sisu would you prefer it to declare
a provided scope dependency to (sisu-)guice rather than the current compile
scope dependency?
Not really.
Making it provided should make it
On 23/08/2013, at 3:50 PM, Domi d...@fortysix.ch wrote:
Should maven not have a Concept to support multiple schema versions?
In theory it does, by way of the DTD declaration, you can specify which DTD
you're currently using, but support for that POM version would mandate a
minimum version of
I believe Stuart just want to ease life of users consuming maven artifatcs
but prefer google guice rather than a fork ( preventing them having to
write too many exclusions xml elements and avoid having twice guice as a
dependency).
I think it's a good idea and doesn't prevent us using the version
13 matches
Mail list logo
