I'm willing to take a crack at this, but I'm not really sure what
changes are required to implement this.
Rick
Jason Dillon wrote:
Short of getting Maven to actually fix this problem...
Can we try to work around this by having the yoko introduce a version
property, and use ${version} where
org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-M2-SNAPSHOT
Short of getting Maven to actually fix this problem...
Can we try to work around this by having the yoko introduce a version
property, and use ${version} where its using ${project.version} now?
I know its not ideal, but this might allow G 1.2 builds
org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-M2-SNAPSHOT
Short of getting Maven to actually fix this problem...
Can we try to work around this by having the yoko introduce a version
property, and use ${version} where its using ${project.version} now?
I know its not ideal, but this might
Attached is a small patch which defines a 'version' property, and
then uses ${version} everywhere that ${project.version} was used before.
version.patch
Description: Binary data
I'm not 100% sure this will fix the problem, but I hope that it will.
I've tested this builds fine off of rev#
FYI, looks like we are back in business... I can build again with
artifacts you deployed using the version patch.
We still need to get Maven fixed so this is not needed, but at least
we can build again.
Thanks :-)
--jason
On Feb 8, 2007, at 1:53 AM, Rick McGuire wrote:
I'm willing to
Notice the strange message:
1) org.apache.geronimo.configs:client-corba-yoko:car:1.2-SNAPSHOT
2) org.apache.yoko:yoko-rmi-impl:jar:1.0-incubating-M2-SNAPSHOT
3) org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-
M2-20070206.145504-10
The version changes from a SNAPSHOT to a
Weird... I think I must have checked yoko-rmi, not yoko-rmi-spec, as
I do see plenty of 1.0-incubating-M2-SNAPSHOT artifacts in here:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
yoko/yoko-rmi-spec/1.0-incubating-M2-SNAPSHOT/
Erg... wtf... how can we fix this?
Offhand I'd guess this is related to the problem we had with the
openejb container pom recently haven't kept up with whether the
maven guys have done anything about it.
Has everyone voted for
http://jira.codehaus.org/browse/MNG-2796
?
thanks
david jencks
On Feb 6, 2007, at 6:22
On Feb 6, 2007, at 6:38 PM, David Jencks wrote:
Offhand I'd guess this is related to the problem we had with the
openejb container pom recently haven't kept up with whether the
maven guys have done anything about it.
Has everyone voted for
http://jira.codehaus.org/browse/MNG-2796
I put a watch on it before, just voted... will comment on it
shortly... though my wii is calling to me ;-)
--jason
On Feb 6, 2007, at 6:38 PM, David Jencks wrote:
Offhand I'd guess this is related to the problem we had with the
openejb container pom recently haven't kept up with
On Feb 6, 2007, at 6:44 PM, David Blevins wrote:
On Feb 6, 2007, at 6:38 PM, David Jencks wrote:
Offhand I'd guess this is related to the problem we had with the
openejb container pom recently haven't kept up with whether
the maven guys have done anything about it.
Has everyone
So, does the yoko project need to be updated to use a ${version}
property to prevent the timestamp-build from getting used in
dependency elements?
I remember you updated openejb, but I'm not sure about any of the
other projects we are using snapshot versions for...
--jason
On Feb 6,
I had to build yoko :(
-dain
On Feb 6, 2007, at 6:22 PM, Jason Dillon wrote:
Weird... I think I must have checked yoko-rmi, not yoko-rmi-spec,
as I do see plenty of 1.0-incubating-M2-SNAPSHOT artifacts in here:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
We need to fix our tools. There is no way we can go to every project
and say use our custom geronimo ${version} property instead of the
standard ${pom.version}, oh and by the way you can't use maven
release tools anymore.
-dain
On Feb 6, 2007, at 6:57 PM, Jason Dillon wrote:
So, does
:-(
I'm fine to either always build a set of external components (maybe
just openejb, tranql, yoko), or always rely on the dependencies
deployed to a remote repo... but switching between the two isn't
really a viable option from a build automation standpoint.
I don't think this is
I agree... just its not really been that easy to get some of these
problems in maven fixed and get a new release out, so we have been
forced to dance around the problem.
Its been months now since we have this staged build to get around
problems loading a maven extension which gets built in
Maybe we need to bribe the Maven team with beer or something...
--jason
On Feb 6, 2007, at 7:17 PM, Dain Sundstrom wrote:
We need to fix our tools. There is no way we can go to every
project and say use our custom geronimo ${version} property
instead of the standard ${pom.version}, oh
Does anyone know if it is a recommended practice to use a pom as a
dependency?
Thanks
Anita
--- David Blevins [EMAIL PROTECTED] wrote:
On Feb 6, 2007, at 6:38 PM, David Jencks wrote:
Offhand I'd guess this is related to the problem we had with the
openejb container pom
Not sure I understand the question.
If you have a jar module which depends on another pom module, while
valid, the jar module does not get any of the dependencies
transitively from the pom module, nor does it ensure that any of the
pom module's children build before the jar module is
19 matches
Mail list logo
