The jobs you suggested are a minimum (and "OK"). I really think we
should have a functioning windows build too... (I suspect we even have
1 or 2 committers that actually use windows now!)
I have no idea of what is actually wrong with the windows build. I
have a Mac Mini running windows functioning
The Aether milestones are based off mature Aether releases it just hasn't had a
non-incubation release at Eclipse. I don't see this as an issue.
But currently we're using M2 and I probably won't update to M3 until after the
3.1.1.
On Aug 19, 2013, at 4:43 AM, Stephane Nicoll wrote:
> Hi,
>
>
On Tue, Aug 20, 2013 at 3:15 PM, Jörg Schaible wrote:
>
> Can you also tell, why you really want to do this? If you really want
> "predictability", then use a shared parent, declare all involved
> dependencies there in a dependencyManagement section and declare your direct
> dependencies without a
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 while the plugin was in SNAPSHOT versio, I
just fixed
Hi Phillip,
Phillip Hellewell wrote:
> Hi all,
>
> I'd like to take a stab at adding support for Maven to be able to mediate
> dependency conflicts using "highest version" strategy rather than "nearest
> definition".
>
> I'll be happy if anyone can point me in the right direction on which
> sou
I think it's a good idea to move this page into the site, like /pom, /plugins,
/shared
the svnpubsub "externals" file is extpaths.txt [1]
"apache-resource-bundles" line in it should be replaced by one line per bundle
if you need help to configure svnpubsub on modules, just tell me and I'll have
On Tue, Aug 20, 2013 at 9:36 AM, Phillip Hellewell wrote:
> I believe the behavior needs to be defined in the parent
> pom, e.g., in a new tag called or something
> (help me think of a good name).
Besides "nearest" and "newest", we'll want a "fail" strategy, which
means fail the build on version
Hello Richard,
x-posted to dev, as the war-plugin is a core-plugin:
- IMO attaching would be the "wrong" term as it has another meaning.
- This is more of a "generated" jar (as generated sources, classes etc.)
- IMO packages should go in Maven modules of their own.
Regards Mirko
--
Sent from my
Thanks everyone for you help so far.
So would the crux of this be to create a VersionSelector class called
NewestVersionSelector, and then find the code where it is currently
hard-coded to use NearestVersionSelector and make it possible to use this
one instead?
Yeah, I'm also very concerned about
Hi Dennis,
I found this route:
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(File,
Artifact, ArtifactRepository, ArtifactRepository)
calls
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy(RepositorySystemSession,
DeployRequest)
calls
org.eclipse.aethe
What do you mean exactly?
Also what about the releasability question?
On Aug 20, 2013, at 7:45 AM, Dennis Lundberg wrote:
> Thanks for looking into this Jason.
>
> As someone who has tried to fix these builds, I think what we need is a
> platform independent way to set up and run the core ITs.
How many pages is it. Would it just be easier in the wiki?
On Aug 20, 2013, at 7:38 AM, Dennis Lundberg wrote:
> Anyone?
> Den 9 aug 2013 21:05 skrev "Dennis Lundberg" :
>
>> Hi,
>>
>> I'm trying to bring some order to apache-resource-bundles.
>>
>> A JIRA project has been created in the ASF
Thanks for looking into this Jason.
As someone who has tried to fix these builds, I think what we need is a
platform independent way to set up and run the core ITs. The best choice is
probably to use Ant.
Den 20 aug 2013 16:18 skrev "Jason van Zyl" :
Thanks for looking into this Jason.
As someone who has tried to fix these builds, I think what we need is a
platform independent way to set up and run the core ITs. The best choice is
probably to use Ant.
Den 20 aug 2013 16:18 skrev "Jason van Zyl" :
> I have separated them like the following to
Ping...
Den 13 aug 2013 21:32 skrev "Dennis Lundberg" :
> Hi,
>
> I'm looking at this issue, which is a Maven core issue:
> https://jira.codehaus.org/browse/MNG-5504
>
> There's a patch for the maven-2.2.x branch, which I have tweaked a bit and
> it works nicely.
>
> Since the same problem exists
Anyone?
Den 9 aug 2013 21:05 skrev "Dennis Lundberg" :
> Hi,
>
> I'm trying to bring some order to apache-resource-bundles.
>
> A JIRA project has been created in the ASF JIRA instance at
> https://issues.apache.org/jira/browse/MASFRES
>
> Now I want to publish the site. Current site is at
> http:
I have separated them like the following to delineate the stable builds that
are a reliable measure of the ITs working and things that have either been
failing for months, or things we can't reasonably maintain.
If these are working I consider Maven releasable:
https://builds.apache.org/view/M
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?
But in general I think we need to clean up the IT jobs:
https://builds.apache.org/view/M-R/view/Maven%20Core%20ITs/
Like the Wind
On 20 August 2013 23:13, Jason van Zyl wrote:
> I'm not sure what this "jdk-1.6-guice-from-google" build is but is referring
> to the 1.5-S of MRR which is not being used anymore. Is this job valid?
>
> https://builds.apache.org/job/core-integration-testing-maven-3-jdk-1.6-guice-from-google/4/con
I'm not sure what this "jdk-1.6-guice-from-google" build is but is referring to
the 1.5-S of MRR which is not being used anymore. Is this job valid?
https://builds.apache.org/job/core-integration-testing-maven-3-jdk-1.6-guice-from-google/4/consoleFull
Thanks,
Jason
Aether is incredibly flexible and can pretty much do anything. The class that
Olivier pointed you at is the where the Maven rules are encapsulated. The issue
is interoperability in the behaviour of a new Maven that may do something
different and versions of Maven that don't. Selecting the neares
Transitively it won't be propagated AFAIK. You want to reuse it by
inheritance (and from a Pom out of your current project) ?
I always used / saw such system dep usage in low level module. I don't
know how we could allow this but I already had such issue with the
java.home interpolation in the past
Hello Olivier,
If your project has a dependency on tools.jar, the artifact presumably need
that dependency to work.
Since the dependency is system scoped, Maven will not download it but look
it up locally.
Therefore, in case someone uses a JDK with different layout than your own,
the dependency wi
Hi,
I have an issue I don't know how to fix :-(
The goal is to have a dependency on tools.jar.
This activated by a profile
tools.jar
${java.home}/../lib/tools.jar
openjdk
tools
1.6
system
No this has moved here:
http://git.eclipse.org/c/aether/aether-core.git/tree/aether-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java
The issue will be to configure maven core to use your new implementation.
That's "hardcoded" currently here [1].
--
Olivier
The Maven team is pleased to announce the release of the Maven
Surefire Plugin, version 2.16
This release addresses some serious problems with character encodings in
the test report XML files and adds a new Parallel Computer implementation
to the JUnit 4.7+ provider, offering a bunch of new option
26 matches
Mail list logo
