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
with.
Like if 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
dependency
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
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
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, Reinhard Nägele
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 anywhere
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 in the classpath. This makes our
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 Guice
.
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 anyways to have
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:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
webResources
webResource
directorysrc/main/webapp/WEB-INF/directory
includes
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 could get
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
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
]
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 instead of adding
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
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.
profile
idluntbuild/id
build
plugins
plugin
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
Luntbuild sets the system property artifactsDir which you can use. Add
the following property to your pom:
artifactsDir${project.build.directory}/artifactsDir
Add the following to your surefire plugin configuration:
reportsDirectory${artifactsDir}/surefire-reports/reportsDirectory
For a
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
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
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
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
,
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 Version
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
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
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.
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]
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:
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
where this pom 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
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
33 matches
Mail list logo
