Joachim, a possible solution would be to front the external non-Maven repo
with a repo manager transforming it into a true Maven repo. As a Nexus (one
of the repo managers out there) user I know you can do that via
implementing a virtual repo plugin, but I would expect you can do similar
things wit
Am 30.01.2013 00:22, schrieb Stephen Connolly:
On 29 January 2013 22:22, Joachim Durchholz wrote:
Am 29.01.2013 21:09, schrieb Stephen Connolly:
On Tuesday, 29 January 2013, Joachim Durchholz wrote:
Am 29.01.2013 19:42, schrieb Anders Hammar:
The right/correct solution here is to se
In that case, you will simply have to tell them where to get the files
and tell them that they have to be uploaded into their Maven repo with
the same GAV that you used in your POM.
No one would have trouble with these instructions.
Uh... there are a lot of people who're comfortable with an IDE
Am 30.01.2013 09:13, schrieb Anders Hammar:
Joachim, a possible solution would be to front the external non-Maven repo
with a repo manager transforming it into a true Maven repo.
Sounds complicated.
I.e. not doable unless you know all aspects that need to be considered,
hence probably far out
On 30 January 2013 08:30, Joachim Durchholz wrote:
> Am 30.01.2013 00:22, schrieb Stephen Connolly:
>
> On 29 January 2013 22:22, Joachim Durchholz wrote:
>>
>> Am 29.01.2013 21:09, schrieb Stephen Connolly:
>>>
>>> On Tuesday, 29 January 2013, Joachim Durchholz wrote:
>>>
Am 29.
> However, I'm eager to hear arguments that may falsify my view. I'd be all
> for it to see how this use case (import available from an external, stable
> download site) can be properly integrated into a Maven workflow.
..
> So I'm arguing for some mechanism to record in a pom:
> - the coor
You are arguing with the guys who wrote Maven and are responsible for
maintaining it.
They are giving you good advice about how to use it properly.
Why not try it their way for a week and see if it solves your problems.
Stephen has tried to give you concrete reasons why your way will lead to
a
I don't know all commands by heart :-).
And it also depends a bit on your project.
should be something like:
mvn release:branch -DbranchName=thatNewBranchYouWereDreamingAbout
But fortunately, the doc is quite complete:
http://maven.apache.org/maven-release/maven-release-plugin/branch-mojo.html
Bu
On 30/01/2013 3:58 AM, Joachim Durchholz wrote:
In that case, you will simply have to tell them where to get the files
and tell them that they have to be uploaded into their Maven repo with
the same GAV that you used in your POM.
No one would have trouble with these instructions.
Uh... there a
This is the type of thing I've been hoping for. We are still in the same boat
so to speak. Has your Legal department allowed you to release this?
Thanks,
Rob
-Original Message-
From: Ansgar Konermann [mailto:ansgar.konerm...@googlemail.com]
Sent: Friday, May 25, 2012 4:14 PM
To: users@m
When I run mvn clean, and look at the reactor order, it lists the build order
for the modules in that particular project. That list does not include other
projects for which the target project is dependent upon.
For example:
Project A
---> module A
---> module B
---> module C
Project B
---> mo
Thanks Wayne. I looked at it shortly after you sent the e-mail, but it did not
appear to offer what I needed.
-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com]
Sent: Friday, May 25, 2012 10:22 PM
To: Maven Users List
Subject: Re: Plugin to determine release order for multipl
Hi,
I understand you have two different multimodules projects.
But those projects have actually dependencies with each other. In short,
"circular".
If so, it won't work with Maven.
The "Maven way" here is: if those projects actually have modules that are
so intricate, then you somehow have the sa
Hi everyone,
First of all, thanks for the great discussion, everyone!
Stephen: I really appreciate you taking the time to lay out your solution
with download-single. That is quite slick!
Joachim: Thanks for being tenacious about getting your questions answered
with a real technical discussion.
Am 30.01.2013 10:20, schrieb Stephen Connolly:
Now that's just crazy, who would roll back an SVN repo and overwrite a
revision past?
I'd download from http://repo/tags/1.3.2. And if that's borked, the
maintainer will provide http://repo/tags/1.3.3 and I'll update the pom to
download from there.
Actually... if I may. I might be able to end this a little easier by
providing some information which I think has been left out of the
conversation so far.
The newest release of Nexus does have something to help you in pinpointing
a particular revision. Granted, you will need to do a little wor
Am 30.01.2013 21:45, schrieb Lyons, Roy:
Actually... if I may. I might be able to end this a little easier by
providing some information which I think has been left out of the
conversation so far.
Thanks, that's very much appreciated.
Nexus now comes with a functionality of metadata. You c
Hi,
Historically we've had a lot of trouble getting our developers to adhere to our
company's stated best practices. For example, we want all projects to depend
upon the latest version of other projects (unless they have a valid reason not
to). Typically our developers will only update the depe
Is these the droids you are looking for?
http://mojo.codehaus.org/versions-maven-plugin/examples/advancing-dependenc
y-versions.html
http://mojo.codehaus.org/versions-maven-plugin/examples/update-parent.html
Thanks,
Roy Lyons
Senior Configuration Engineer
On 1/30/13 3:12 PM, "Pimentel, Ro
On 30/01/2013 3:18 PM, Joachim Durchholz wrote:
Am 30.01.2013 10:20, schrieb Stephen Connolly:
Now that's just crazy, who would roll back an SVN repo and overwrite a
revision past?
I'd download from http://repo/tags/1.3.2. And if that's borked, the
maintainer will provide http://repo/tags/1.3.3
Am 30.01.2013 16:14, schrieb Ron Wheeler:
You are arguing with the guys who wrote Maven and are responsible for
maintaining it.
Should I stand in awe from that?
I doubt it.
I have seen many holes punched into authority figures.
In one instance, I was the one who did the punching.
Besides, I h
On 30/01/2013 4:54 PM, Joachim Durchholz wrote:
Am 30.01.2013 16:14, schrieb Ron Wheeler:
You are arguing with the guys who wrote Maven and are responsible for
maintaining it.
Should I stand in awe from that?
I doubt it.
I have seen many holes punched into authority figures.
In one instance,
There are two ways to look at this:
1. Maven is what it is, how do I achieve my end goal as close as is
practicable to the maven best practices
2. Maven sucks, and here is how it should do things differently.
We appreciate both types of viewpoint, but keep in mind that it has taken
*over a year*
23 matches
Mail list logo
