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 w
On 23/08/2013, at 3:50 PM, Domi 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 Maven for the bu
On Aug 22, 2013, at 8:57 PM, Stuart McCulloch 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 easier to swap
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
Should maven not have a Concept to support multiple schema versions?
Am 23.08.2013 um 05:08 schrieb Mark Derricutt :
> On 23/08/2013, at 2:52 PM, Phillip Hellewell wrote:
>
>> On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
>> wrote:
>>> Beware the changing of the pom schema is a thorn
On Aug 21, 2013 7:00 AM, "Olivier Lamy" wrote:
>
> On 21 August 2013 00:08, Jason van Zyl 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?
> >
> Branch has been started w
On 23/08/2013, at 2:52 PM, Phillip Hellewell wrote:
> On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
> 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 b
On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
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 the addition of a new optional
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: en
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 wrote:
> On Wed, Aug 21, 2013 at 8:21 PM, Mark Derricutt
On Wed, Aug 21, 2013 at 8:21 PM, Mark Derricutt wrote:
> On 22/08/2013, at 4:37 AM, Phillip Hellewell wrote:
>
>> My idea to solve this was to add support for a
>> true in the declaration. Thoughts?
>
> I didn't think we could change the POM schema? Not without some epic major
> reasoning ( an
On Wed, Aug 21, 2013 at 11:34 AM, Hervé BOUTEMY 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 (= the latest)
> be
On Wed, Aug 21, 2013 at 11:28 AM, Robert Scholte 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 result (otherwise
13 matches
Mail list logo
