Ralph Goers wrote:
export MAVEN_OPTS=-Dmaven.repo.local=$PWD/.mvn
Mark Lundquist wrote:
So my argument is that my expectation that builds would be
self-contained was reasonable. And in fact, separate builds on
separate machines *are* (by default) self-contained! I am arguing
that it *
Mark Lundquist wrote:
no, of course not... nevertheless, SNAPSHOT is only meaningful in
relation to a remote repository, right?
I don't really understand why you'd say that. It indicates that this is
an unreleased version. Whether it is in your local repository or a
remote repository doesn't
Hi Ralph,
Ralph Goers wrote:
Mark Lundquist wrote:
IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local
repositories. That's not in view here.
Huh? SNAPSHOT identifies an artifact as not-released. There is no
requirement that it ever be published to a remote reposito
Mark Lundquist wrote:
IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local
repositories. That's not in view here.
Huh? SNAPSHOT identifies an artifact as not-released. There is no
requirement that it ever be published to a remote repository. In our
environment we have our
So you want to alter the versions that you rely on without altering the pom?
surely that breaks the idea of repeatable builds?
Andy
Mark Lundquist wrote:
Andrew Williams wrote:
have you tried referring to a snapshot build using it's full build
identifier (date etc)?
that has worked for me in
Andrew Williams wrote:
have you tried referring to a snapshot build using it's full build
identifier (date etc)?
that has worked for me in some situations in the past.
"Referring to"?
No touching the pom, that's my requirement :-)
I'm looking for a solution, not a kludge that might help in
Ralph Goers wrote:
Mark Lundquist wrote:
It's not. Did you read the scenario from my original post? I don't
think SNAPSHOT is even in view here.
Yes, I read it.
IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local
repositories. That's not in view here.
Do you th
Mark Lundquist wrote:
-JIRA-1234
foo
bar
biff
OK, having already dispensed w/ the "prefix" idea in favor of an
across-the-board build-specific private version ID, we can simplify this
some more... there's no
Mark Lundquist wrote:
It's not. Did you read the scenario from my original post? I don't
think SNAPSHOT is even in view here.
Yes, I read it.
Do you think it's currently possible to build two different instances
of a project (e.g. one w/ local modifications and one without) on the
same m
late last night I, Mark Lundquist wrote:
thinking about it some more, maybe the version to use should be
specified as a suffix to be applied to whatever the model-determined
artifact ID would otherwise be. That's the only reasonable way to be
able to apply this to an aggregate of modules inst
have you tried referring to a snapshot build using it's full build
identifier (date etc)?
that has worked for me in some situations in the past.
Andy
Mark Lundquist wrote:
Hi Ralph, fancy meeting you here :-)...
Ralph Goers wrote:
I have one issue with this.
Typically, at least in the envir
Hi Ralph, fancy meeting you here :-)...
Ralph Goers wrote:
I have one issue with this.
Typically, at least in the environment I work in (which uses Maven 1),
the version would be something like 1.0.1 only when that version had
been released. When doing any modifications the version should bec
I have one issue with this.
Typically, at least in the environment I work in (which uses Maven 1),
the version would be something like 1.0.1 only when that version had
been released. When doing any modifications the version should become
1.0.2-SNAPSHOT until the next release is performed. You
Patrick Schneider wrote:
On 1/28/07, Mark Lundquist <[EMAIL PROTECTED]> wrote:
[..snip]
To pull this off, I need to be able to say "in this working area, module
M builds version V (some local custom version name), *and* all other
modules that depend on P must resolve that dependency to versi
Forgive me if this is obvious, but in your description here...
"in this working area, module M builds version V (some local custom version
name), *and* all other modules that depend on P must resolve that dependency
to version V"
...what is P?
On 1/28/07, Mark Lundquist <[EMAIL PROTECTED]> wro
Hi, I think I've identified a need for a new (hopefully minor) Maven
feature that I'd like to discuss. I've failed to find any solution with
the current feature set (but please let me know if I'm wrong about that!
:-), and although I'm new to the internals of Maven I'd be happy to
contribute
16 matches
Mail list logo
