Hi Lóránt,
However, requiring each project to do this is rather error prone, so I'd
like to define a pattern in the company parent POM, and have all
projects
automatically derive their location from there.
This doesn't work. If I set a location in our top-level POM to, say,
Hey,
Thanks for the example. This is quite similar to what I'm trying to do. But
if I do it like this, Maven will deploy my site under:
scp://.../${parent.groupId}/${parent.artifactId}/${parent.version}/../../../${project.groupId}/${project.artifactId}/${project.version}/${project.artifactId}/
Hi,
I just noticed that when I do mvn site on my project, that Maven tries to
download the site.xml for its parent project:
[INFO] Parent project loaded from repository:
com.topdesk:tis-parent:pom:3.2-SNAPSHOT
Downloading:
Using Maven 3?
See
http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Site_descriptor_attachment
HTH,
-Lukas
On 08/19/2011 12:21 PM, Lóránt Pintér wrote:
Hi,
I just noticed that when I do mvn site on my project, that Maven tries to
download the site.xml for its parent
Thank you, that solved my problem.
Lorant
On Fri, Aug 19, 2011 at 12:27, Lukas Theussl ltheu...@apache.org wrote:
Using Maven 3?
See http://maven.apache.org/**plugins/maven-site-plugin/**
Hi,
Thanks for the example. This is quite similar to what I'm trying to do.
But
if I do it like this, Maven will deploy my site under:
scp://.../${parent.groupId}/${parent.artifactId}/$
{parent.version}/../../../${project.groupId}/${project.artifactId}/$
Hi,
Thanks but I'm not sure it goes really far from generating checksum of a
unique file, and my problem is more how to generate checksums of inner
content of tar.gz or zip archive ... And where to locate this in maven
life-cycle.
I had this idea, but I'm not sure on feasibility, implemented in
We recently encountered a strange Maven build error and the root cause turned
out to be that the com.sun.jersey:jersey-project:1.1.4:pom artifact differs on
Maven Central and java.net. In particular, on java.net
It may also be worthwhile to note that this artifact was recently (I think
Aug.16) pushed to central.
-Original Message-
From: Blaney, Kyle (Kyle) [mailto:kbla...@avaya.com]
Sent: Friday, August 19, 2011 10:19 AM
To: users@maven.apache.org
Subject:
My build broke this morning due to a bad checksum. It looks like somebody
added .sha1 hashes to this old artifact this morning and the one on the .jar
file is wrong.
http://repo1.maven.org/maven2/javax/xml/bind/jaxb-api/2.1/
That file has 2edb9610deb9527fce7a196e951296f8aacc4bda but the
Hi,
I think only way for me to USE apache-maven-2.0.11 version. Which supports
Java 1.4.2 Version.
As my issue is my project is using RT.JAR and TOOLS.JAR which compiler can't
change it unless and untill i project MAVEN with JDK 1.4.2 version and this
version supports JDK 1.4.2 so i have to
That file has 2edb9610deb9527fce7a196e951296f8aacc4bda but the correct hash
is d68570e722cffe2000358ce9c661a0b0bf1ebe11.
Can someone please fix this?
Issues like this should be filed in JIRA...
https://issues.sonatype.org/browse/MVNCENTRAL
Wayne
Issues with Central should be filed in JIRA:
https://issues.sonatype.org/browse/MVNCENTRAL
Wayne
On Fri, Aug 19, 2011 at 9:27 AM, Thiessen, Todd (Todd)
tthies...@avaya.com wrote:
It may also be worthwhile to note that this artifact was recently (I think
Aug.16) pushed to central.
What is the failure that you're seeing here? The changes look
appropriate since the contents of maven/1 and maven/2 are now in
Central, so removing those repo declarations should have no effect.
On Fri, Aug 19, 2011 at 10:18 AM, Blaney, Kyle (Kyle) kbla...@avaya.com wrote:
We recently
Wayne,
I don't know enough to say which artifact is correct - the one on Maven Central
or the one on java.net. Therefore, I don't feel comfortable raising a defect
against either. Perhaps I'll try one of the Jersey mailing lists
(http://java.net/projects/jersey/lists) and see what they
Brian,
The following build failure occurs when a project specifies a direct dependency
on com.sun.jersey.contribs:jersey-spring:1.1.4:jar:
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
This is even stranger. That jar is/has been in central:
http://search.maven.org/#artifactdetails|org.springframework|spring|2.5.6|jar
The changes to the jersey pom shouldn't have affected this at all.
On Fri, Aug 19, 2011 at 1:26 PM, Blaney, Kyle (Kyle) kbla...@avaya.com wrote:
Brian,
The
Brian,
Agreed - I don't understand why the workaround fixes the problem or why the
jersey pom affects the problem.
Does Maven use a slightly different algorithm to resolve where to download a
direct versus transitive dependency?
Kyle
-Original Message-
From: Brian Fox
I realize that not having the repo section defined shouldn't be causing a
problem (we have been scratching our heads over that one for a couple of days).
But the two poms that Kyle referenced have the same GAV, both released, yet
have different contents. I thought that was a big no no in the
Todd,
The artifact that Maven fails to download is not the one that's different
between Maven Central and java.net. Rather, it's a parent pom of the original
artifact that differs. It all starts with the
com.sun.jersey.contribs:jersey-spring:1.1.4:jar artifact, which depends on
Thanks for clarifying. Hopefully we can get some advice here wrt the policies
regarding different artifacts with the same GAV.
-Original Message-
From: Blaney, Kyle (Kyle) [mailto:kbla...@avaya.com]
Sent: Friday, August 19, 2011 4:30 PM
To: Maven Users List
Subject: RE:
The Maven team is pleased to announce the release of the parent POMs for Maven
projects: version 21 for Maven parent, version 22 for Maven Plugins parent and
version 17 for Maven Shared Components parent.
http://maven.apache.org/pom/maven/
http://maven.apache.org/pom/maven-plugins/
On Fri, Aug 19, 2011 at 4:35 PM, Thiessen, Todd (Todd)
tthies...@avaya.com wrote:
Thanks for clarifying. Hopefully we can get some advice here wrt the policies
regarding different artifacts with the same GAV.
This is a very rare circumstance. What happened was we merged java.net
with Central.
23 matches
Mail list logo
