The zone box seems to have globally run out of swap causing the Maven
and Myfaces continuum instances to both freak out with failed builds,
so I've turned ours off until whoever is pegging the box is taken
care of, then I'll bring them back up :)
- Brett
---
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
Because I considered it sorta experimental until I was able to verify
everything still worked and made the tests working. I didn't have it
fully working when I needed to stop and wanted to check in someplace
without essentially breaking the trunk.
-Original Message-
From: Dan Tran [mailto:
Since you know this code very well, why bother to branch it?
Just curious :-)
-D
On 1/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: brianf
Date: Mon Jan 29 20:02:17 2007
New Revision: 501305
URL: http://svn.apache.org/viewvc?view=rev&rev=501305
Log:
mdep-50: fixed unit tests
That would be nice! If the default set of plugins would only do work
if something really changed. Then one could hope that `mvn install`
would do a bunch of stuff, and if nothing changed the `mvn install`
again would complete much, much quicker. But more importantly
running `mvn deploy`
I can think of several use cases for this. The most obvious would be the
ability for jar to determine if compile or resources actually made any
changes and decide if repackaging is needed.
-Original Message-
From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
Sent: Monday, January 29, 2007
On 29 Jan 07, at 1:54 PM 29 Jan 07, Wendell Beckwith wrote:
I've read the doc and the irc and while I can see the benefit to a
shared
context, I'm curious as to whether the current pressing need is
coming more
from maven or the kepler project?
The drive for this is generally useful, but t
As for modding the build order, I'm still not sure that's possible (or
advisable, in the larger context)...currently, I've only used the
build-context concept in maven-core as mainly a read-only data structure,
after it's setup. Are you talking about the need to inject new projects to
an existing
OK, I can finally replicate it.
We are working on fixing it now - related to some recent appserver
fixes I believe.
It should be working fine when executed as mvn jetty:run
Andy
On 29 Jan 2007, at 20:11, Wendy Smoak wrote:
On 1/29/07, Andrew Williams <[EMAIL PROTECTED]> wrote:
Are you us
I was actually hoping that we could limit the downside of this through some
good design discussion. I like your idea of using some sort of
expression/container-wiring to access the shared context, though I'm not
sure how a plugin could "export" something into the shared context via
container wirin
Actually, to be perfectly honest, I haven't been actively involved with
Kepler for some time now. This proposal actually comes from a year of work
I've done for a client, where the use of a build-context-like structure has
allowed me to maintain separation of concerns between several different
plu
I have heard a lot of people ask for this kind of functionality on irc
for the last year+, and I myself have desired something similar a
couple of different times in the past.
being able to have and share state between two plugins is incredibly
useful, albeit a rather dangerous door to open up to
I've read the doc and the irc and while I can see the benefit to a shared
context, I'm curious as to whether the current pressing need is coming more
from maven or the kepler project? Doesn't matter either way just looking
for the origin of the pain. This proposal looks to satisfy some of the OS
For convenience, I'm inlining the document here. If anyone comments directly
in this thread, I'll try to keep the wiki page up to date. I'll also try to
copy over feedback on the wiki page here.
-j
=
1. Background A. Shared Context in Systems of Interchangeable Components
M
Hi everyone,
I wanted to propose a new feature for Maven 2.1 (trunk). I think quite a few
people have run into something like this before, but I've come across a need
to detect some advanced build configuration using plugins and/or custom
components at the beginning of the build, and use that det
On 1/29/07, Andrew Williams <[EMAIL PROTECTED]> wrote:
Are you using bretts latest changes for archiva to use the latest plexus
container?
I re-build at last changed revision 500951 (which includes brett's
plexus version number changes.)
Same thing, error 500 on any /repository url.
Here's a
How can I be removed from this mailing list?
Thanks,
On 1/29/07, nicolas de loof (JIRA) <[EMAIL PROTECTED]> wrote:
please upload Java 1.3 version of slf4j-1.2
---
Key: MAVENUPLOAD-1352
URL: http://jira.codehaus.org/brow
Hello all,
I am trying to write a provider for CCRC (ClearCase Remote Client) that uses
a pure Java API for ClearCase integration. How do I get started writing a
provider? I have a few of the methods such as Update and ChangeLog
implemented that work as stand-alone Mojo's and I am trying to a
On 1/28/07, Rahul Thakur <[EMAIL PROTECTED]> wrote:
Shouldn't the CI server take care of publishing if a build was
successful?
That would be nice. :)
I'm getting a test error that I don't have time to track down right
now, so I have not published the snapshots.
--
Wendy
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
For anyone who might be looking for a Maven solution for the Enterprise:
http://blogs.maven.org/jvanzyl/2007/01/29/1170060540361.html
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PR
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
+1 for both.
Emmanuel
Brett Porter a écrit :
Hi,
This is a dependency for upcoming plugin releases. The changes to each
are attached to this message - it shifts the release profile to the
maven POM, adds some developers, and removes the need for the plugin
surrogate parent.
SVN revision:
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
31 matches
Mail list logo
