these projects, including our
ambitious ideas for the next major version(s) of Maven itself.
To be able to gain more focus we need to criticize the current subprojects and
decide if it is worth maintaining.
The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
component that cou
ideas for the next major version(s) of Maven itself.
To be able to gain more focus we need to criticize the current subprojects and
decide if it is worth maintaining.
The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
component that could be used to easily resolve Maven pr
e huge amount of code to maintain we're
> > missing enough space to make real progress on all these projects,
> including
> > our ambitious ideas for the next major version(s) of Maven itself.
> > To be able to gain more focus we need to criticize the current
> subprojects
&
projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
>
sing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> The Maven Artifact Reso
+1
T
real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself. To be
> able to gain more focus we need to criticize the current subprojects and
> decide if it is worth maintaining.
>
> The Maven Artifact Resolution API (maven-artifac
n all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> The Maven Artifact Resolution API (maven-artifact-resolver) is a sh
n all these projects, including our
ambitious ideas for the next major version(s) of Maven itself.
To be able to gain more focus we need to criticize the current subprojects and
decide if it is worth maintaining.
The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
component
f.
To be able to gain more focus we need to criticize the current subprojects and
decide if it is worth maintaining.
The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
component that could be used to easily resolve Maven project dependencies. The
last (and only) released ve
Am 2013-12-10 01:56, schrieb Hervé BOUTEMY:
on my machine, build with Maven 3.1.1 works actually
old 2.4 m-pir-p is used, which doesn't use Aether, so it works both for Maven
3.0.x and 3.1.x
To test a skin, I suppose this old version is sufficient
do you have issues?
Yes, I do. Maven 3.1.1 an
on my machine, build with Maven 3.1.1 works actually
old 2.4 m-pir-p is used, which doesn't use Aether, so it works both for Maven
3.0.x and 3.1.x
To test a skin, I suppose this old version is sufficient
do you have issues?
Regards,
Hervé
Le mardi 10 décembre 2013 01:12:43 Michael-O a écrit :
Am 2013-12-10 00:54, schrieb Hervé BOUTEMY:
AFAIK, this is due to the fact that the skin uses itself, which is a good
thing to show the effective result for people wanting to use it, but it costs
this little problem: the most recent version is the version actually built,
not what is in local repo
AFAIK, this is due to the fact that the skin uses itself, which is a good
thing to show the effective result for people wanting to use it, but it costs
this little problem: the most recent version is the version actually built,
not what is in local repo (at least when working with SNAPSHOT)
so
Am 2013-12-09 22:23, schrieb Robert Scholte:
Have you tried to run it with an extra 'clean'? I've seen this a few
times and IIRC the clean helped.
No avail. Still the same error. If I leave out the profile reporting it
suddenly works.
Op Mon, 09 Dec 2013 20:47:20 +0100 schreef Michael-O <19
Have you tried to run it with an extra 'clean'? I've seen this a few times
and IIRC the clean helped.
Robert
Op Mon, 09 Dec 2013 20:47:20 +0100 schreef Michael-O <1983-01...@gmx.net>:
Hi,
during release preps of 1.3.1 I am constantly failing to build the with
Maven 3.1.1. I do "mvn -Prep
Hi,
during release preps of 1.3.1 I am constantly failing to build the with
Maven 3.1.1. I do "mvn -Preporting site" and it dies with
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
project maven-fluido-skin: Error during site generation:
On 10/08/2012, at 6:53 PM, "Mavroukakis, Ioannis"
wrote:
> Thanks Brett, will that also apply to what is retrieved from the remote repo?
Yes, that's the main purpose of the resolver - to find the right artifacts on a
list of remote repositories, and download them to the local repository (thou
Thanks Brett, will that also apply to what is retrieved from the remote repo?
-Original Message-
From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter
Sent: 10 August 2012 01:00
To: Maven Developers List
Subject: Re: VersionRange not used in artifact resolution?
On
On 10/08/2012, at 3:16 AM, "Mavroukakis, Ioannis"
wrote:
> Hello everyone,
>
> I'm worming my way slowly into the weird and wonderful world of maven plugin
> development, and I was having a play with some of the examples in the
> cookbook.
>
> My test artifact is version 12.8.14, the range
Hello everyone,
I'm worming my way slowly into the weird and wonderful world of maven plugin
development, and I was having a play with some of the examples in the cookbook.
My test artifact is version 12.8.14, the range starts at .14 and goes all the
way up to .20 and I have an Artifactory inst
ep coming across them at a later date searching for something
>> in the 2.x line.
>>
>> - Brett
>>
>> On 28/12/2009, at 8:11 AM, Jason van Zyl wrote:
>>
>>> Is anyone planning on actually doing any bug fixing in the 2.x artifact
>>> resolution c
lanning on actually doing any bug fixing in the 2.x artifact
>> resolution code?
>>
>> Lots of this stuff has been fixed in 3.x and I was just going to push any
>> bugs I saw in JIRA to 3.x and validate as fixed and for the ones that aren't
>> schedule th
n Zyl wrote:
> Is anyone planning on actually doing any bug fixing in the 2.x artifact
> resolution code?
>
> Lots of this stuff has been fixed in 3.x and I was just going to push any
> bugs I saw in JIRA to 3.x and validate as fixed and for the ones that aren't
> sched
Is anyone planning on actually doing any bug fixing in the 2.x artifact
resolution code?
Lots of this stuff has been fixed in 3.x and I was just going to push any bugs
I saw in JIRA to 3.x and validate as fixed and for the ones that aren't
schedule them to be fixed.
I don't thi
On 05/02/2009, at 7:28 PM, Brett Porter wrote:
Is there anything the clover2 plugin should be doing to ensure that
these modifications are made on the transitively resolved projects?
I'd have to dig a bit - it has been a while. I thought that the
project in a forked lifecycle was discarde
On 04/02/2009, at 11:51 AM, Nick Pellow wrote:
Hi Brett,
It's always hard to tell from the output - is the resources call in
the forked lifecycle or the main one afterwards? The latter would
not retain all the settings.
I'm not 100% certain, however it looks like the resources call is
Hi Brett,
It's always hard to tell from the output - is the resources call in
the forked lifecycle or the main one afterwards? The latter would
not retain all the settings.
I'm not 100% certain, however it looks like the resources call is
happening as part of the forked lifecycle[1].
The
There's a further resolution step. The resources:resources in question
is for the app, and has both:
[DEBUG] com.fidelity.shares:shares-app:jar:1.0-SNAPSHOT (selected for
null)
[DEBUG] com.fidelity.shares:shares-domain:jar:clover:1.0-
SNAPSHOT:compile (selected for compile)
and
[DEBUG]
You're right. the dependency artifacts are already transitive.
e.g. the -X output shows:
[DEBUG] [Clover] List of dependency artifacts after changes:
[DEBUG] [Clover] Artifact [com.fidelity.shares:shares-
domain:jar:clover:1.0-SNAPSHOT], scope = [compile]
[DEBUG] [Clover] List of artifac
The dependency artifacts should already be transitive. I'm not quite
sure how you are seeing the results you are. Have you tracked the
output of the swizzling process? Does -X show what is then fed into
the compiler plugin in the forked lifecycle?
- Brett
On 03/02/2009, at 3:26 PM, Nick Pe
Will the filtering be applied to the artifacts resolved by the maven-
compiler-plugin, and the maven-surefire-plugin?
My understanding is that:
1) the maven-clover2-plugin creates a classified artifact with the -
clover classifier. it also looks for -clover classified artifacts of
project dep
You can't modify the resolution, but you can filter the artifacts it
gets from the project. There are a few utility classes for that
(you'll see them used in the dependency plugin, assembly plugin for
example).
- Brett
On 03/02/2009, at 12:14 PM, Nick Pellow wrote:
Thanks for the clarifi
Thanks for the clarification, Brett.
What can the maven-clover2-plugin do to ensure that only classified
artifacts are resolved if they are available?
On 03/02/2009, at 9:17 AM, Brett Porter wrote:
Yes, that's expected - artifacts with a particular classifier are
considered different to ar
Yes, that's expected - artifacts with a particular classifier are
considered different to artifacts with a different or no classifier.
On 02/02/2009, at 5:44 PM, Nick Pellow wrote:
Hi,
The maven-clover2-plugin creates both a classified and a normal jar
artifact for each sub-module it build
Hi,
The maven-clover2-plugin creates both a classified and a normal jar
artifact for each sub-module it builds.
I have a problem, where I am seeing both a classified _and_ a non-
classified artifact being put on the classpath under certain
circumstances.
e..g
[INFO] Compiling 3 source file
>>> http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers
>>>
>>> And I know the plug points in Mercury provide by SAT4J deal with most of
>>> these but just trying to guide things into the same funnel.
>>>
>>> On 5-Aug-08, at 4:26 PM, Jason van
N/Mercury
and here's the nitty gritty:
http://docs.codehaus.org/display/MAVEN/SAT+Based+Dependency+Resolution
And a lot of this document should be reconciled as well:
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification
I think you and Oleg are most familiar
k at integrating
this, if applicable, into the Mercury write up?
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
--
the course of true love
ell:
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification
I think you and Oleg are most familiar with how you want this system
to be used insofar as conflict resolvers in particular and getting
those ideas aligned is important. It's also important to get the
general u
Jason van Zyl wrote:
>
>> Oleg,
>>
>> Not sure if you've seen this, but could you take a crack at integrating
>> this, if applicable, into the Mercury write up?
>>
>>
>> http://docs.codeh
4:26 PM, Jason van Zyl wrote:
Oleg,
Not sure if you've seen this, but could you take a crack at
integrating this, if applicable, into the Mercury write up?
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification
Thanks,
Oleg,
Not sure if you've seen this, but could you take a crack at
integrating this, if applicable, into the Mercury write up?
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification
Thanks,
Jason
--
Seems like a good idea to capture this as a 2.1 feature request,
write it up in the wiki and link in any related JIRA issues from all
the plugins and MNG itself so that it has a focal point. As we work
through things like the artifact mechanism it can be taken into
consideration.
That's i
This is an email about a class of bugs, discovered working with the
following general scenario:
I am building a standalone Java application.
maven-jar-plugin is configured with mainClass and addClasspath=true.
maven-assembly-plugin is configured with a to gather up
all the dependencies into a sin
Hi, i have to resolve the last version of an artifact given. For example, i
want to know which is the last version of log4j in my repository by a maven
plugin.
Is there any component that resolve it?
--
Lic Matias Urbieta
set the following property in pom file:
true
> Allow artifact resolution from workspace projects
> -
>
> Key: MNGECLIPSE-59
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-59
> Project: Maven 2.x Ext
lugin and a pom-server.xml. The
difference between the two is the pom.xml doesn't contain dependencies for the
projects that are in the eclipse workspace.
Is there a better solution?
> Allow artifact resolution from works
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=all ]
Eugene Kuleshov updated MNGECLIPSE-59:
--
Fix Version: 1.0.0
> Allow artifact resolution from workspace projects
> -
>
>
Allow artifact resolution from workspace projects
-
Key: MNGECLIPSE-59
URL: http://jira.codehaus.org/browse/MNGECLIPSE-59
Project: Maven 2.x Extension for Eclipse
Type: New Feature
Components: Dependency Resolver
runk/maven-site/src/site/apt/repositories-and-artifact-resolution-overview.apt
(with props)
Added:
maven/components/trunk/maven-site/src/site/apt/repositories-and-artifact-resolution-overview.apt
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-site/src/site/apt/repositories-and-arti
52 matches
Mail list logo
