Here's one:
https://github.com/hcguersoy/nexus-maven-plugin
I works but has been discontinued now in favor of a Jenkins plugin.
Reinhard
Am 10.07.2014 01:15, schrieb Dan Tran:
any one? :-) or it is just me having a need for this?
Thanks
-D
On Tue, Jul 8, 2014 at 10:24 AM, Dan Tran wrote
f he
would have patched an official release.
/Anders
On 13 February 2013 14:54, Reinhard Nägele <
reinhard.naeg...@mgm-tp.com
wrote:
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a
third-party
depend
e, we need a temporary solution.
Reinhard
Am 11.02.2013 15:27, schrieb Ron Wheeler:
Why not just load these stray orphans into your MRM once and then
treat them and normal dependencies.
Ron
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
Hello,
A couple of years ago I used a plugin execution i
Hello,
A couple of years ago I used a plugin execution in the validate phase to
bootstrap jars that were not available on Maven Central as suggested in
[1]. I needed to do the same thing again today but noticed that this
approach does not seem to work any more with Maven 3. Right after
runnin
HOT.
The plugin calls into the maven resolution logic so this is core maven
behavior.
In 2.2, resolution from the reactor was introduced for these goals,
previously they would always go to the repository, this could be why
you see a change in the new version.
On Fri, Jul 15, 2011 at 5:28 AM, Reinhar
Hi all,
We use the dependency plugin's goal "copy-dependencies" in several
projects. For snapshot dependencies, it would copy unique snapshot jars
until version 2.1. Since version 2.2, the behavior has changed in that
now timestamped snapshots are copied.
I could not find this change anywher
the patch.
http://jira.codehaus.org/browse/SUREFIRE
Kristian
Den 14.02.2011 12:42, skrev Reinhard Nägele:
Thanks, Kristian, for the hint. I commented out the line as you
suggested. This fixed the problem. Surefire still builds successfully
and all test run. I think it does not make sense anywa
dependency escaping the confinement of the isolated
classloader in surefire.
Most of this code is >5 years old and I really doubt if anyone
remembers why ;)
But we might get lucky, anyone know ?
Kristian
Den 14.02.2011 08:43, skrev Reinhard Nägele:
Hello,
We have a project that uses Gu
Kristian
Den 14.02.2011 08:43, skrev Reinhard Nägele:
Hello,
We have a project that uses Guice 3 and TestNG for unit tests. TestNG
now has support for Guice (which we don't use). The problem is that
TestNG uses Guice 2. Surefire puts TestNG and its dependencies
(including Guice 2) first
Hello,
We have a project that uses Guice 3 and TestNG for unit tests. TestNG
now has support for Guice (which we don't use). The problem is that
TestNG uses Guice 2. Surefire puts TestNG and its dependencies
(including Guice 2) first in the classpath. This makes our tests fail
because we use
Hello,
I just added filtering to a web project as follows:
org.apache.maven.plugins
maven-war-plugin
src/main/webapp/WEB-INF
web.xml
WEB-INF
true
process. So, your problem might be specific to the
profiles.xml which I have never used.
Reinhard
Reinhard Nägele schrieb:
There is a Jira ticket for this problem, which I provided a patch for
quite a while ago.
http://jira.codehaus.org/browse/MRELEASE-415
It'd be nice if the issue coul
There is a Jira ticket for this problem, which I provided a patch for
quite a while ago.
http://jira.codehaus.org/browse/MRELEASE-415
It'd be nice if the issue could get some attention by the developers.
Reinhard
Eugeny N Dzhurinsky schrieb:
Hello there!
I am facing some strange problem wi
vocaro.com]
Sent: Tuesday, June 09, 2009 9:51 AM
To: Maven Users List
Subject: Re: wagon:upload fails only with release:perform
On Jun 9, 2009, at 3:26 AM, Reinhard Nägele wrote:
> Have you tried to create an execution for the wagon plugin that is
> bound to the install phase inste
Have you tried to create an execution for the wagon plugin that is bound
to the install phase instead of adding the wagon:upload to the release
plugin goals?
Reinhard
Trevor Harmon schrieb:
Hi,
I'm using release:perform, and it works perfectly in the standard
configuration. But now I'm try
I just found the following issue which could be related:
http://jira.codehaus.org/browse/MNG-3579
Reinhard
Reinhard Nägele schrieb:
Hello,
I guess I spotted a bug in Maven 2.1.0. In a pom, which is intended to
be used as a parent pom, we have the following profile. The profile is
used to
Hello,
I guess I spotted a bug in Maven 2.1.0. In a pom, which is intended to
be used as a parent pom, we have the following profile. The profile is
used to copy artifacts to Luntbuild's publish directory.
luntbuild
maven-dependency-plugin
cop
Hello,
This morning, I updated our Nexus version from 1.3.1.1 to 1.3.2. After
that my builds did not run because they failed to download snapshot
dependencies from a hosted repository. As yesterday everything was still
fine, I suspected a regression in Nexus, went back to 1.3.1.1, but the
pro
Luntbuild sets the system property "artifactsDir" which you can use. Add
the following property to your pom:
${project.build.directory}
Add the following to your surefire plugin configuration:
${artifactsDir}/surefire-reports
For a multi-module project you could do:
${artifactsDir}/surefire-rep
I don't have a solution to your problem, but I would advice against
putting the real version number instead of ${project.version}. It is
good practice to avoid such redundancy using ${project.version}, even
though the release plugin can deal with explicit versions. Using
${project.version} is a
Why did you configure connection and developerConnection differently? I
guess they should both point to the trunk. The changelog plugin by
default uses "connection."
Reinhard
huser schrieb:
Any ideas anyone ? The code is under "trunk". How/Where can I change the path
for Maven to look at the
s added to the repository.
>
> I'd call this a bug/defect. I guess I have two tasks, now.
> 1) Figure out how to get done what I need to get done.
> 2) Create a sample project and file it with a JIRA.
>
> Thanks for the input,
> Dave
>
>
> Reinhard Nägele wrote:
>
I had kind of the same problem this week with our custom release plugin. It
works similar to the Maven release plugin in that it adds the active profiles
to the forked Maven process. Actually, I had taken this code from the Release
plugin.
The Release plugin gets the profile as follows:
List p
thing,
perhaps some test dependency you have slightly changed and is influencing the
dependency tree as seen by it.
-Original Message-
From: Reinhard Nägele [mailto:reinhard.naeg...@mgm-tp.com]
Sent: Monday, February 09, 2009 2:41 AM
To: users@maven.apache.org
Subject: Resolved Ve
Hello,
We have a multi-module project which transitively uses Commons Logging. We do
not use it directly ourselves and so did not explicitly declare it as a
dependency. So far, this has not been a problem. But for some reason, something
must have changed over the weekend. I started our applicat
Users List
Subject: RE: Repo1 Mirrors not Updated
We push daily to a few mirrors, other mirrors are pulling from some other
locations. Which mirror are you trying to use?
-Original Message-
From: Reinhard Nägele [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 2:56 AM
To: users
Hi,
I was just trying to set up a new Wicket application using
wicket-archetype-quickstart. I tried versions 1.3.5 and 1.4-rc1. Both failed. I
then checked repo1 and did find the archetype artifacts. Then I figured we were
using a repo1 mirror. I checked there and noticed that both, 1.3.5 and 1
Hi,
The latest beta (2.0-beta-6) of the Release plugin caused different problem
here, so we went back to using 2.0-beta-5, which works fine.
Problem 1:
We use Java 5 including features such as generics etc. In our super pom, the
compile plugin is configured to use 1.5 source and target. Howeve
Thanks for the hint. However, this should not justify the problem. No matter,
whether I set this to true or false, the classpath in a manifest should be set
accordingly.
Reinhard
-Original Message-
From: Jörg Schaible [mailto:[EMAIL PROTECTED]
Sent: Freitag, 23. März 2007 09:42
To: Ma
I've seen this problem too a while ago. This is indeed very strange. It looks
like a bug to me. We do not package snapshots, so it does not concern me at the
moment, but I'm still curious to see an answer here.
Reinhard
-Original Message-
From: Tim Cederman [mailto:[EMAIL PROTECTED]
S
om sits you can run:
mvn deploy:deploy-file -DrepositoryId=artifactoryServer -Durl=dav:http://...
-Dfile=.. -DgroupId=... -DartifactId=... -Dversion=... -Dtype=...
-Dclassifier=...
Hope it helps.
On 3/6/07, Reinhard Nägele <[EMAIL PROTECTED]> wrote:
>
>
> This looks quite interesting, and I started
This looks quite interesting, and I started to play around with it. The biggest
problem is the poor documentation. With Jetty, you can quickly start it out of
the box. Accessing the Web interface, you are then stuck with the login screen
because the default credentials are not documented anywh
I don't think it is a good idea to deploy artifacts which are not available on
the Web to your local repository. You should really set up a separate one for
those. The local repository is nothing you should actively manage, and you
should be able to delete it any time. The extra repository would
Hi,
We use the release plugin in various projects without problems. I understand
that a release cannot be performed when the project has snapshot dependencies,
which makes sense.
We have always been able to release project that use snapshot versions of
plugins. However, with the war plugin thi
Just read the error message, and you'll know. You are trying to install a jar
file from its location in the local repository to your local repository. This
doesn't make sense.
Reinhard
-Original Message-
From: serafettin senturk [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 20. Dezember 2
35 matches
Mail list logo