Cool, I'll flip trunk to use it so we're another step closer to the
alpha-1.
Sent from my iPhone
On Dec 12, 2008, at 7:02 AM, Oleg Gusakov
wrote:
6 votes casted
[+1] 6: 4 binding, 2 non-binding
[-1]
[0]
I released Mercury 1.0.0-alpha-2, site at http://maven.apache.org/mercury
Thanks,
On Dec 11, 2008, at 7:48 PM, "Shane Isbell"
wrote:
The idea here is not to do away with modelVersion, but rather to add
an
additional parameter, similar to modelGroupId.
Something that I think would be useful is a language/platform element.
Then it's purely additions to the POM. If y
Sent from my iPhone
On Dec 12, 2008, at 7:02 AM, Brett Porter wrote:
Hi,
I was looking at applying the patch for this one, but wasn't happy
with it and looked for a better solution, which I'm also not happy
with :)
Basically, in the reactor target/classes is always used as the
class
I made a first working snapshot of the Mercury ant tasks available at
http://people.apache.org/~ogusakov/repos/test/org/apache/maven/mercury/mercury-ant-tasks/1.0-alpha-1-SNAPSHOT/mercury-ant-tasks-1.0-alpha-1-20081211-all.jar
Just put this jar into ~/.ant/lib and use
http://people.apache.org
6 votes casted
[+1] 6: 4 binding, 2 non-binding
[-1]
[0]
I released Mercury 1.0.0-alpha-2, site at http://maven.apache.org/mercury
Thanks,
Oleg
Oleg Gusakov wrote:
Dear All,
This is the first release of Mercury with all major [mercury]
functionality enabled: repository access + dependency r
Hi,
I was looking at applying the patch for this one, but wasn't happy
with it and looked for a better solution, which I'm also not happy
with :)
Basically, in the reactor target/classes is always used as the
classpath for projects referring to dependencies inside the reactor
because of
Issue Subscription
Filter: Design & Best Practices (28 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
I agree with this. But even with managed dependencies there are still
problems. Even though you have dictated the version you really have no
idea if it is compatible with the version needed by the artifact
trying to use it.
I have been advocating for some time that 3.0 support "requires" an
On 12/12/2008, at 6:55 AM, Barrie Treloar wrote:
See http://jira.codehaus.org/browse/MECLIPSE-37
There doesn't seem to be anything on the mailing lists to help with
this problem.
This is an interesting problem.
I don't see any way to fix this other than changing Maven itself,
unfortunately,
On Fri, Dec 12, 2008 at 7:45 AM, Stephen Connolly
wrote:
> H you've just given me an idea for a mojo for the
> versions-maven-plugin
As Stephen points out in the JIRA, the correct way is to add a
dependencyManagement section.
Dependencies need to be MANAGED.
Someone needs to take this own
On Thursday 11 December 2008 4:26:42 pm Lilianne E. Blaze wrote:
> Daniel Kulp wrote:
> > Could you try unzipping the shaded jar and then using "jar cf" to create
> > a new jar using the same contents and seeing if that helps?
>
> Thanks.
> It seems it doesn't help.
OK. Then that's not the issu
Daniel Kulp wrote:
> Could you try unzipping the shaded jar and then using "jar cf" to create a
> new jar using the same contents and seeing if that helps?
Thanks.
It seems it doesn't help.
>
> At one point, shade wasn't sticking directory entries into the jar properly
> which worked fine for
H you've just given me an idea for a mojo for the
versions-maven-plugin
http://jira.codehaus.org/browse/MVERSIONS-16
2008/12/11 Chris Maki
> Hi Everyone
>
> In the spirit of full-disclosure, I work with Ian at Overstock.com, but I
> wanted to chime in on this discussion because of issu
Hi Everyone
In the spirit of full-disclosure, I work with Ian at Overstock.com,
but I wanted to chime in on this discussion because of issues I've
had with various projects.
Given this scenario:
com.foo:my-artifact:jar:1.0:compile
org.hibernate:hibernate:3.1.1:compile
com.foo:anothe
On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox wrote:
> I think most of these ideas are already covered in the lifecycle
> proposal out there that john wrote.
Can you paste the link in please?
-
To unsubscribe, e-mail: dev-unsubs
>> See http://jira.codehaus.org/browse/MECLIPSE-37
>> There doesn't seem to be anything on the mailing lists to help with
>> this problem.
>>
>
> This is an interesting problem.
>
> I don't see any way to fix this other than changing Maven itself,
> unfortunately, but I think Arnaud's idea about th
The idea here is not to do away with modelVersion, but rather to add an
additional parameter, similar to modelGroupId.
I found a post by Bryon here talking about the extensibility:
http://freedomandbeer.com/posts/extensible-xml-with-xml-namespaces-and-relaxng
If it is possible to grab out extensi
On 11-Dec-08, at 6:48 PM, Shane Isbell wrote:
I'm encountering an issue with Byldan (.NET version of Maven) and
since this
is a general problem, I thought I'd raise it here on the list. I
need to
extend the pom model to include information like the key token id of
the
.NET assembly. Using
I'm encountering an issue with Byldan (.NET version of Maven) and since this
is a general problem, I thought I'd raise it here on the list. I need to
extend the pom model to include information like the key token id of the
.NET assembly. Using the modelVersion element of the pom isn't appropriate
t
>will the plugin versions in the super pom be updated for 2.0.10 or will
>the defaults used in 2.0.9 be kept ?
Thanks for bringing that up. I think we adjusted them when the original
2.0.10 started but it's been a while and we should re-eval before making
the final build.
---
Brian E. Fox schrieb:
> Hello,
> This RC fixes the SCP wagon problem identified in RC2 (MNG-3717). We
> have reverted the 2.0.x branch back to use wagon beta-2 where it was
> historically for stability. Users that require fixes for wagon beta-3+
> should use 2.1.0-M1 instead.
>
>
> Here's the lis
I think most of these ideas are already covered in the lifecycle
proposal out there that john wrote.
-Original Message-
From: Brett Porter [mailto:br...@apache.org]
Sent: Thursday, December 11, 2008 11:02 AM
To: Maven Developers List
Subject: Re: What will replace the @aggregator MOJO con
Vincent Siveton wrote:
Hi,
2008/12/11 <[EMAIL PROTECTED]>:
Author: ogusakov
Date: Wed Dec 10 23:23:19 2008
New Revision: 725604
URL: http://svn.apache.org/viewvc?rev=725604&view=rev
Log:
Thanks to Ben - fixed MERCURY-40
Not a big deal but could you follow our conventions about com
On 12/12/2008, at 3:10 AM, De Smet Ringo wrote:
Brett,
-Original Message-
From: Brett Porter
Ok, I see what you mean. You illustrated the property in the
project which should not work. But from settings.xml and the
command line it should.
Unfortunately, it doesn't, or again I'm mis
Brett,
> -Original Message-
> From: Brett Porter
>
> Ok, I see what you mean. You illustrated the property in the
> project which should not work. But from settings.xml and the
> command line it should.
Unfortunately, it doesn't, or again I'm misinterpreting you. :-)
The three attac
On 07/12/2008, at 2:06 AM, Brian E. Fox wrote:
Yes it's binding the aggregator with @execute to a lifecycle that is
the
problem. There's nothing wrong with aggregators that are meant to
perform
some action from the CLI. The trouble is that everyone ends up
making two
goals, one @aggregator
baerrach wrote:
>
> See http://jira.codehaus.org/browse/MECLIPSE-37
> There doesn't seem to be anything on the mailing lists to help with
> this problem.
>
This is an interesting problem.
I don't see any way to fix this other than changing Maven itself,
unfortunately, but I think Arnaud's id
Could you try unzipping the shaded jar and then using "jar cf" to create a
new jar using the same contents and seeing if that helps?
At one point, shade wasn't sticking directory entries into the jar properly
which worked fine for "java" and "javac" and such, but it confused winzip
really bad
On 12/12/2008, at 12:39 AM, De Smet Ringo wrote:
The value is overridden for the project
under build, but not for the transitive dependencies. Are you
surprised
that I find this an inconsistent result? :-)
Ok, I see what you mean. You illustrated the property in the project
which should
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Maven Wiki" for change
notification.
The following page has been changed by Iacob:
http://wiki.apache.org/maven/Chinese_Maven_In_Five_Minutes
--
-
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Maven Wiki" for change
notification.
The following page has been changed by Iacob:
http://wiki.apache.org/maven/Chinese_Maven_In_Five_Minutes
--
-
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Maven Wiki" for change
notification.
The following page has been changed by Iacob:
http://wiki.apache.org/maven/Chinese_Maven_In_Five_Minutes
New page:
Mavenäºåéå
¥é¨
å®è£
Mavenæ¯ä¸æ¬¾Javaå·¥å
·ï¼å¦æè¦è¿è
Brett,
> -Original Message-
> From: Brett Porter
>
> It looks like the intended behaviour to me, the same as if
> you pulled the properties out of the profile. Properties are
> not transitively applied.
Can you give me some more background on the why of this decision. If you
re-read m
I hadn't read your replay before I sent the mail to the maven dev
list. I will take it up with the portal developers.
Thanks,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Thu, Dec 11, 2008 at 1:23 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
>
On 11/12/2008, at 11:54 PM, De Smet Ringo wrote:
[INFO] The following files have been resolved:
[INFO]be.atriso.test:a:pom:1.0-SNAPSHOT:compile
[INFO]junit:junit:jar:3.8.1:compile
Is this a bug, or is this intended behaviour?
It looks like the intended behaviour to me, the same as i
Hello,
As a followup on my original mail, I also started debugging the Maven
internals. I came to the conclusion that properties defined in profiles, are
not injected into the Maven model of transitive dependencies, just before the
interpolation is executed.
Attached you can find 2 POM files t
Hi,
2008/12/11 <[EMAIL PROTECTED]>:
> Author: ogusakov
> Date: Wed Dec 10 23:23:19 2008
> New Revision: 725604
>
> URL: http://svn.apache.org/viewvc?rev=725604&view=rev
> Log:
> Thanks to Ben - fixed MERCURY-40
Not a big deal but could you follow our conventions about commit message [1]?
Thanks
Nick,
I meant that you should send this to the portal team so that they can
correct:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/portals/bridges/portals-bridges-common/1.0.4/
BTW, you should check if Artifactory has an option to fix checksums on
the fly for you, it
It seems that the SHA1 checksums of
org.apache.portals.bridges:portals-bridges-commons:1.0.4 [1] are wrong
on Central. Can this be repaired?
Downloading:
http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.pom
2K downloaded
[W
if the project in question is opened (or otherwise known), all queries
are redirected to it. That way you get the correct error badges in
project B when you change classses in project A..
Milos
On Thu, Dec 11, 2008 at 9:30 AM, Lilianne E. Blaze
<[EMAIL PROTECTED]> wrote:
> Milos Kleint wrote:
>>
Milos Kleint wrote:
> I'll look into it when I get back from vacation (Jan 2009).
> Right now it seems to be an issue with the fact that the shaded jar
> belongs to a project that doens't provide the source for the binaries
> contained. That's sort of a concept in netbeans project system, so
> maki
I'll look into it when I get back from vacation (Jan 2009).
Right now it seems to be an issue with the fact that the shaded jar
belongs to a project that doens't provide the source for the binaries
contained. That's sort of a concept in netbeans project system, so
making it work will probably invol
42 matches
Mail list logo
