Hi,
Looking at the code, there is really a one-to-one implicit mapping between the
repository id and the server id used to look-up authentication information.
Maven adds to a DefaultAuthenticationSelector the server id [1] as key of a map
Id -> authentication info [2]. Then, a possible
Hi,
It sounds like the simplest answer would be to use the
maven-assembly-plugin and generate the JAR in the
generate-test-resources phase. You can configure the plugin not to
attach the artifact with false.
Then, still in the generate-test-resources phase, you bind an execution
of
Hi,
You should be able to get only the project compiled classes with
project.getBuild().getOutputDirectory(). Internally, this is what
getCompileClasspathElements does. For the test classpath, you have the
similar project.getBuild().getTestOutputDirectory().
With those two folders, you can
Maven will consider 2.0-alpha-1 to be before 2.0-SNAPSHOT. This is
documented in ComparableVersion:
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html.
Guillaume
Le 23/09/2016 à 18:49, Robert Patrick a écrit :
I was not
Hi,
The error you have is "... was cached in the local repository,
resolution will not be reattempted until the update interval of
Proper-Resolution has elapsed or updates are forced". The typical
resolution to this is to force Maven to update releases and snapshots
with the -U parameter. On
Hi,
Your previous error was about the snapshot policy, which the -U flag has
definitely solved. If you still hit an issue, it has to be a different
error, can you show what it is?
Guillaume
Le 18/10/2016 à 16:19, Gopal a écrit :
Hi:
I have cleaned out the repository, used the -U option and
Hi,
It sounds like you're looking for the parse-version goal of the
build-helper-maven-plugin:
http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html.
It can decompose the project version into several Maven properties.
There is an example of usage here
If you're inside a Maven plugin, you can get a ProjectBuildingRequest
with the session.
https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getProjectBuildingRequest()
The shared ArtifactResolver from maven-artifact-transfer should resolve
Hi,
platform!all
means that the profile will be active when the system property
"platform" is not defined, or is defined with a value different than
"all". Put another way, it is always active unless "platform" is equal
to "all". This explains your observations, where both platform-reactor
Hi,
Profile activation is documented here
http://maven.apache.org/guides/introduction/introduction-to-profiles.html,
there is a section about the different types of activation.
is also mentioned.
I'm not sure which part of activeByDefault you are refering to, could
you clarify that?
(AttachArtifactTask.java:80)
Am 01.06.2017 19:17 schrieb "Guillaume Boué" <gb...@apache.org>:
It's currently in Apache snapshot repository located at
https://repository.apache.org/content/repositories/snapshots. You can add
this repository as a plugin repository to your settings or
Hi,
I looked into this issue and committed a fix for it. The core problem
was that the 'attachartifact' task launched from the external Ant build
was working from a clone of the Maven project, instead of the project
itself. Can you try the latest 3.0.0-SNAPSHOT and report back?
Le
/repositories/snapshots/
true
Le 01/06/2017 à 16:25, Jürgen Weber a écrit :
There is no 3.0.0-SNAPSHOT of maven-antrun-plugin, is it?
org/apache/maven/ant/tasks/AttachArtifactTask.class is in
maven-antrun-plugin-1.8.jar
Am 31.05.2017 19:57 schrieb "Guillaume Boué
You could also upgrade the maven-war-plugin to version 3.1.0 or newer:
it will automatically detect if you're using Servlet 3.0, in which case
it won't require a web.xml file to be present.
Le 16/02/2018 à 17:21, Karen Goh a écrit :
I managed to get the error away by adding
false
cos I am
14 matches
Mail list logo
