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 version
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
+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:
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
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
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
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
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
Mark Lundquist wrote:
buildVersion
suffix-JIRA-1234/suffix
artifacts
artifactIdfoo/artifactId
artifactIdbar/artifactId
artifactIdbiff/artifactId
/artifact
/buildVersion
OK, having already dispensed w/ the prefix
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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`
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=revrev=501305
Log:
mdep-50: fixed unit tests
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
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
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
Christian Edward Gruber wrote:
Um, 1.0 to 1.1 seems like the right time to break an api if you are
going to eventually. Better if it were a 1.x to 2.x, but certainly it's
not a 1.0.12 to 1.0.13 situation. I think it woudl be hard to argue on
a purely needs basis. Apache as a whole is
Rahul Thakur wrote:
Trygve Laugstøl wrote:
Rahul Thakur wrote:
'int' ids are now converted to 'long' across the project and to
allow really large values. This should cater to scenarios where the
id generation could be started from an arbitrary large value.
Won't this break the API?
Yep,
Trygve Laugstøl wrote:
1.0 to a 1.1 is not the time when you break an API. You can add stuff
with minor released, but not break things. This is the versioning
conventions used for all Maven-related projects. Perhaps trunk should
be 2.0, but as long as it's 1.1 it can't break the API.
[snip]
Can you please come up with a realistic use case where IDs would start
on something other than 0 or 1? The database is controlled by
Continuum and is an internal thing which we have complete control over.
I don't have a specific use case for Continuum handy, but I guess
Continuum can
[snip]
Can you please come up with a realistic use case where IDs would start
on something other than 0 or 1? The database is controlled by
Continuum and is an internal thing which we have complete control over.
I don't have a specific use case for Continuum handy, but I guess
Continuum can
On 29 Jan 07, at 8:30 AM 29 Jan 07, [EMAIL PROTECTED] wrote:
Hello all,
I am trying to write a provider for CCRC (ClearCase Remote Client)
that uses a pure Java API for ClearCase integration.
Oh, that would be so awesome!
The closest thing we have would be two providers we have in the
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
38 matches
Mail list logo
