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
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
making
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:
I'll
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
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=725604view=rev
Log:
Thanks to Ben - fixed MERCURY-40
Not a big deal but could you follow our conventions about commit message [1]?
Thanks
Vincent
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
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 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:
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 my
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å·¥å
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
--
-
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
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 badly.
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 idea
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
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 attached
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
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=725604view=rev
Log:
Thanks to Ben - fixed MERCURY-40
Not a big deal but could you follow our conventions about
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
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 list of
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.
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
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
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
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 the lifecycle
On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox bri...@reply.infinity.nu 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
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
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 chrism...@mac.com
Hi Everyone
In the spirit of full-disclosure, I work with Ian at Overstock.com, but I
wanted to chime in on this discussion
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 java
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 issue.The
On Fri, Dec 12, 2008 at 7:45 AM, Stephen Connolly
stephen.alan.conno...@gmail.com 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.
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,
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 and
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
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
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
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
Sent from my iPhone
On Dec 12, 2008, at 7:02 AM, Brett Porter br...@apache.org 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
On Dec 11, 2008, at 7:48 PM, Shane Isbell shane.isb...@gmail.com
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
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
oleg.subscripti...@gmail.com wrote:
6 votes casted
[+1] 6: 4 binding, 2 non-binding
[-1]
[0]
I released Mercury 1.0.0-alpha-2, site at
Hi Paul,
2008/12/10 Paul Spencer [EMAIL PROTECTED]:
Vincent,
The project doxia-test-docs should contain the documents and the document
should be maintained in the projects source repository so they can be
release by the project, i.e. mvn release... The version of this project
It is exactly
Vincent Siveton wrote:
Any comments are welcome!
Building the whole Doxia trunk takes only ~1 min for me, fine work IMHO
Vincent :-) !
Benjamin
44 matches
Mail list logo
