Got it! Thanks. The dependency without [] needs to exist, but may not end
up being used due to conflicts. Fair enough. :-)
On Sat, Aug 6, 2016 at 3:24 PM, Christian Schulte wrote:
> Am 08/06/16 um 05:15 schrieb Christian Schulte:
> > It just takes the highest version the version range resolver r
Am 08/06/16 um 05:15 schrieb Christian Schulte:
> It just takes the highest version the version range resolver returns and uses
> that or fails if nothing like that is available.
If using version range syntax.
-
To unsubscribe,
Am 08/06/16 um 02:04 schrieb Fred Cooke:
> A parent, I thought, used to be equivalent to [], ie, hard requirement. A
> dependency without [] is NOT a hard requirement, simply advisory. So yeah,
> they're different, or were. I wonder what semantics the ranged parents
> behaviour has for a simple bac
+1
Chas
> On Aug 5, 2016, at 7:37 AM, Christopher wrote:
>
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's st
A parent, I thought, used to be equivalent to [], ie, hard requirement. A
dependency without [] is NOT a hard requirement, simply advisory. So yeah,
they're different, or were. I wonder what semantics the ranged parents
behaviour has for a simple backward compatible (or not) plain version?
Implicit
On Fri, Aug 5, 2016 at 3:51 PM, Christopher wrote:
> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory
> wrote:
>
> > On Aug 5, 2016 7:41 AM, "Benson Margulies"
> wrote:
> > >
> > > On Fri, Aug 5, 2016 at 10:37 AM, Christopher
> > wrote:
> > > > I'm always in favor of adding skip properties. They a
What about putting the skip option into an abstract base plugin class? Just
thinking out loud
Sent from my iPhone
> On Aug 5, 2016, at 6:51 PM, Christopher wrote:
>
>> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory wrote:
>>
>>> On Aug 5, 2016 7:41 AM, "Benson Margulies" wrote:
>>>
>>> On Fr
On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory wrote:
> On Aug 5, 2016 7:41 AM, "Benson Margulies" wrote:
> >
> > On Fri, Aug 5, 2016 at 10:37 AM, Christopher
> wrote:
> > > I'm always in favor of adding skip properties. They are very useful for
> > > manipulating builds for debugging, running on
Sorry, I strongly disagree, dependency is not optional.
If there were not a valid, higher resolution path, the build would fail as well.
Regards,
Christophe
-Original Message-
From: Christian Schulte [mailto:c...@schulte.it]
Sent: Freitag, 5. August 2016 16:33
To: Maven Developers List
+1
On 5 August 2016 at 14:34, Tamás Cservenák wrote:
> ... Mercury
>
> On Thu, Aug 4, 2016 at 11:09 PM Jason van Zyl wrote:
>
> > When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and
> > Tycho. None of them very useful for people to understand what they
> actually
> > do.
Hi Herve
I have appended some things on this ticket. Please take a look.
I will have some more answers soon.
Thanks.
Regards,
Rajiv
> On 4 Aug 2016, at 22:50, herve.bout...@free.fr wrote:
>
> Hi,
>
> Please have a look at answers from Robert and myself on
> https://issues.apache.org/jira/br
On Aug 5, 2016 7:41 AM, "Benson Margulies" wrote:
>
> On Fri, Aug 5, 2016 at 10:37 AM, Christopher wrote:
> > I'm always in favor of adding skip properties. They are very useful for
> > manipulating builds for debugging, running on CI servers, controlling
> > executions in child poms, etc. Even i
On Fri, Aug 5, 2016 at 10:37 AM, Christopher wrote:
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's still possib
I'm always in favor of adding skip properties. They are very useful for
manipulating builds for debugging, running on CI servers, controlling
executions in child poms, etc. Even if it's not recommended to run
unattended, it's still possible, so a skip option is useful.
On Thu, Aug 4, 2016, 11:47 R
Am 08/05/16 um 16:10 schrieb Thiebaud, Christophe:
> ... oh ... I was 200% sure that parent did not allow a version range ...
Introduced in Maven 3.2.2. Broken since a few releases. Fixed in
3.4.0-SNAPSHOT.
>
> I tried, -> BUILD SUCCESS.
>
> Hourah, and thanks.
>
> Let see now if this option i
... oh ... I was 200% sure that parent did not allow a version range ...
I tried, -> BUILD SUCCESS.
Hourah, and thanks.
Let see now if this option is ok with our developers.
In any case, don't you think there is some valid reason to fill a jira entry ?
I mean, iterating over a set of possible
On Aug 5, 2016 2:56 AM, "Andreas Dangel" wrote:
>
> Hi all,
>
>
> I want to implement https://issues.apache.org/jira/browse/MPMD-220 -
> which is upgrading the m-pmd-p to use the latest PMD version.
>
> As of PMD 5.4.x, the minimum java runtime is 7, so I would upgrade the
> plugin accordingly.
>
... Mercury
On Thu, Aug 4, 2016 at 11:09 PM Jason van Zyl wrote:
> When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and
> Tycho. None of them very useful for people to understand what they actually
> do. I think I’m done with catchy names. I’m old.
>
>
AIR could be something Adobe might have a problem with ...
Chris
Von: Jörg Schaible
Gesendet: Freitag, 5. August 2016 14:54:29
An: dev@maven.apache.org
Betreff: Re: [DISCUSSION] finishing Aether import: help find a new name
Uwe Barthel wrote:
> Hi,
>
>> Eclips
Uwe Barthel wrote:
> Hi,
>
>> Eclipse owns the Aether name. We cannot use the name Aether.
>
> And the Eclipse Foundation doesn't like to provide that name to the ASF
> (only the name without the eclipse namespace)?
>
> Aethel means over the AIR.
>
> WDYT about org.Apache.maven.air: _A_rtifact
You maybe also could overcome this by using parent version ranges.
Am 08/05/16 um 13:27 schrieb Thiebaud, Christophe:
> Reading Aether documentation :
>
> https://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution
>
> looks that aether has been thought to manage this kind of issue:
>
> «
Am 08/05/16 um 13:27 schrieb Thiebaud, Christophe:
> Reading Aether documentation :
>
> https://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution
>
> looks that aether has been thought to manage this kind of issue:
>
> « For each direct dependency, a dependency selector is given a chance
Am 08/05/16 um 01:21 schrieb Gary Gregory:
> On Thu, Aug 4, 2016 at 3:24 PM, Christian Schulte wrote:
>
>> Am 08/05/16 um 00:15 schrieb Gary Gregory:
>>> But here you would just tell the manager: "I want to use Maven" as
>> opposed
>>> to "I want to use Ant and Ivy".
>>
>> So lets rename Maven. W
Reading Aether documentation :
https://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution
looks that aether has been thought to manage this kind of issue:
« For each direct dependency, a dependency selector is given a chance to
exclude the dependency from the graph »
Any hint if and how
Hi,
Eclipse owns the Aether name. We cannot use the name Aether.
And the Eclipse Foundation doesn't like to provide that name to the ASF
(only the name without the eclipse namespace)?
Aethel means over the AIR.
WDYT about org.Apache.maven.air: _A_rtifact _I_inqui_R_e. Inquire is more
gene
Hi all,
I want to implement https://issues.apache.org/jira/browse/MPMD-220 -
which is upgrading the m-pmd-p to use the latest PMD version.
As of PMD 5.4.x, the minimum java runtime is 7, so I would upgrade the
plugin accordingly.
m-pmd-p 3.6 would be the last version, that supports Java 6. From
yes, in the current case, this is an internal component name we're looking for:
end-users will not notice
Regards,
Hervé
- Mail original -
De: "Gary Gregory"
À: "Maven Developers List"
Envoyé: Vendredi 5 Août 2016 00:15:24
Objet: Re: [DISCUSSION] finishing Aether import: help find a n
Eclipse owns the Aether name. We cannot use the name Aether.
On 5 August 2016 at 05:14, Uwe Barthel wrote:
> Hi,
>
> I know Aether is one of the catchy non telling name.
> But, why not leave Aether with new Maven namespace like
> org.apache.maven.aether?
>
> -- barthel
>
>
>
Hi Rajiv,
I just had a look at my build. The version string comes from build.properties
in maven-core.jar:/org/apache/maven/messages/build.properties
As the values are updated by the resources plugin during the build, I would
imagine that they should be 3.4.0-SNAPSHOT or ${project.version} ..
29 matches
Mail list logo
