Is anyone else seeing these?
[java] Failed tests:
[java]
testReportInvalidPluginForDirectInvocation
(org.apache.maven.error.ErrorReporterPointcutTest)
[java]
testReportDuplicateAttachmentException
(org.apache.maven.error.ErrorReporterPointcutTest)
I only get them throug
On 24-Feb-08, at 8:12 PM, Wendy Smoak wrote:
On Sun, Feb 24, 2008 at 9:04 PM, Jason van Zyl <[EMAIL PROTECTED]>
wrote:
The only thing I really liked was the link back to JIRA. So that's
cool if that's there. I think most people include that in the
announcement so it two clicks instead of one
On Sun, Feb 24, 2008 at 9:04 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> The only thing I really liked was the link back to JIRA. So that's
> cool if that's there. I think most people include that in the
> announcement so it two clicks instead of one which is not a big deal.
> But finding the
The only thing I really liked was the link back to JIRA. So that's
cool if that's there. I think most people include that in the
announcement so it two clicks instead of one which is not a big deal.
But finding the path back to JIRA is a nice feature.
On 24-Feb-08, at 7:38 PM, Wendy Smoak w
sounds like a good idea to me :)
On 25/02/2008, at 2:38 PM, Wendy Smoak wrote:
The release process has us sending an email to [EMAIL PROTECTED],
and updating two wiki pages [1] [2].
Since the ASF archives for the announcement list [3] include an Atom
feed [4], would it be possible to display t
The release process has us sending an email to [EMAIL PROTECTED],
and updating two wiki pages [1] [2].
Since the ASF archives for the announcement list [3] include an Atom
feed [4], would it be possible to display the date and subject from
the feed on the front page of the wiki, instead of manuall
On 25/02/2008, at 2:04 PM, Ralph Goers wrote:
Maybe that's because I didn't merge? Would merging from 2.0.x to
trunk work correctly? I guess it wouldn't have hurt to try.
Nah, it's just a convention we've used in the paste
On 25/02/2008, at 2:00 PM, Ralph Goers wrote:
If you really think
Maybe that's because I didn't merge? Would merging from 2.0.x to trunk
work correctly? I guess it wouldn't have hurt to try.
Brett Porter wrote:
sorry, I see the trunk commit now - just didn't have the normal
"merged from" notation. Same question applies for the reasoning :)
On 25/02/2008,
I did commit it to trunk. It just took me a while to do it as my
maven-artifact was seriously out of date and I was getting compile
errors in maven-project (and I had to go to work for the day) so it took
me a while to verify it.
If you really think this warrants a Jira issue I can create one.
Actually, I think this is a great idea. I'd love this for our sample
projects for the stuff I work on that we ship with the full kits.
There is no point to deploy them into the repositories as there is no
value in that at all. However, I'd like them built as part of the
build to make sur
I tested the plugin on a large project, checked the licenses.
I've identified two regressions that exist in both beta-1 and beta-2
(filed in JIRA, need to be scheduled). I'm also curious why there is
still an open issue for 2.2-beta-2 in JIRA? I don't see these as
blocking, just would like
Nicolas?
On 19/02/2008, at 7:30 AM, Brett Porter wrote:
Hi Nicolas,
Neat change - I like it.
I just wonder if ${mirrorOf} instead of {0} might be more intuitive?
Also - don't forget to merge your change to artifact/trunk!
Cheers,
Brett
On 19/02/2008, at 1:55 AM, [EMAIL PROTECTED] wrote:
sorry, I see the trunk commit now - just didn't have the normal
"merged from" notation. Same question applies for the reasoning :)
On 25/02/2008, at 9:10 AM, Brett Porter wrote:
Hi Ralph,
Not questioning this - but can you explain why and perhaps attach it
to a JIRA issue? Also, doesn't th
Hi Ralph,
Not questioning this - but can you explain why and perhaps attach it
to a JIRA issue? Also, doesn't this need to be merged to trunk?
- Brett
On 23/02/2008, at 1:22 AM, [EMAIL PROTECTED] wrote:
Author: rgoers
Date: Fri Feb 22 06:21:59 2008
New Revision: 630217
URL: http://svn.apa
On 24-Feb-08, at 12:19 PM, Carlos Sanchez wrote:
Is it possible to get a Mojo instance from the embedder ?
If you have the component in the classpath then yes, but Maven plugins
are special cases in that in Maven itself dynamically downloads the
plugin, makes it visible to the container
Is it possible to get a Mojo instance from the embedder ?
I started with
getPlexusContainer().lookup(org.apache.maven.plugin.Mojo.ROLE,"resources:resources")
and of course didnt work, I guess you'd need the embedder to process
the lifecycle first so the Mojos are available. Any hints?
--
I could
2008/2/24, Jason van Zyl <[EMAIL PROTECTED]>:
> Olivier,
>
> Please for the love of god, would you please be more careful. You're
> just ripping through all sorts of plugins making major behavioral
> changes in core fundamental plugins? How do you know changing the way
> properties are ordered
Vincent,
What's the use case for optional deployment?
On 24-Feb-08, at 11:34 AM, Olivier Lamy wrote:
Vincent Massol asked it for cargo build.
--
Olivier
2008/2/24, Jason van Zyl <[EMAIL PROTECTED]>:
On 24-Feb-08, at 10:57 AM, Olivier Lamy wrote:
My goal is only to help users which need s
Vincent Massol asked it for cargo build.
--
Olivier
2008/2/24, Jason van Zyl <[EMAIL PROTECTED]>:
>
> On 24-Feb-08, at 10:57 AM, Olivier Lamy wrote:
>
> > My goal is only to help users which need some features in maven.
> > But if you say/think the feature is bad : No problem I can revert the
On 24-Feb-08, at 10:57 AM, Olivier Lamy wrote:
My goal is only to help users which need some features in maven.
But if you say/think the feature is bad : No problem I can revert the
commit and mark the jira issue as won't fix.
What was the use case? I'm all for helping users, but generally t
On 24-Feb-08, at 10:35 AM, Olivier Lamy wrote:
Hi,
Just to be sure mavenSession.getExecutionProperties() should be use.
Yes, system properties are turned into execution properties in the CLI
and pushed into the session. So that from the embedder each invocation
can have it's own session a
My goal is only to help users which need some features in maven.
But if you say/think the feature is bad : No problem I can revert the
commit and mark the jira issue as won't fix.
--
Olivier
2008/2/24, Jason van Zyl <[EMAIL PROTECTED]>:
>
> On 22-Feb-08, at 2:57 PM, [EMAIL PROTECTED] wrote:
>
>
Olivier,
Please for the love of god, would you please be more careful. You're
just ripping through all sorts of plugins making major behavioral
changes in core fundamental plugins? How do you know changing the way
properties are ordered isn't going to affect someone relying on the
command
On 22-Feb-08, at 2:57 PM, [EMAIL PROTECTED] wrote:
Author: olamy
Date: Fri Feb 22 14:57:35 2008
New Revision: 630347
URL: http://svn.apache.org/viewvc?rev=630347&view=rev
Log:
[MDEPLOY-63] Allow disabling deployment for artifacts that should
not be deployed
What's the reasoning behind th
Hi,
Just to be sure mavenSession.getExecutionProperties() should be use.
Right ?
Thanks,
--
Olivier
2008/2/24, Jason van Zyl <[EMAIL PROTECTED]>:
>
> On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote:
>
> > I just hit the problem today with one of my colleague. Yes, System
> > props should defi
I corrected the page as Eugene doesn't like the m2eclipse being called
Tycho. Tycho is actually a set of Maven plugins written by Tom that
enable an OSGi toolchain that has been used in production for a long
time. I'll document that, but the eclipse integration itself is just
called m2eclip
+1.
--
Olivier
2008/2/24, Dennis Lundberg <[EMAIL PROTECTED]>:
> Hi
>
> To get the latest version of maven-source-plugin into our toolchain, I'd
> like to release maven parent pom r630638 as version 8. A site.xml has
> been added in this release.
>
> Source:
>
> https://svn.apache.org/viewv
Since the question of choosing an Eclipse Integration is often asked, I
just worked on the "Eclipse Integration" page from Maven Users Wiki:
http://docs.codehaus.org/display/MAVENUSER/Eclipse+Integration
I started a comparison matrix with basic project informations.
This Wiki is public: feel free
+1
On 24-Feb-08, at 9:19 AM, Dennis Lundberg wrote:
Hi
To get the latest version of maven-source-plugin into our toolchain,
I'd
like to release maven parent pom r630638 as version 8. A site.xml
has been added in this release.
Source:
https://svn.apache.org/viewvc/maven/pom/trunk/maven/po
Hi
To get the latest version of maven-source-plugin into our toolchain, I'd
like to release maven parent pom r630638 as version 8. A site.xml has
been added in this release.
Source:
https://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?r1=587312&r2=630638&diff_format=h
https://svn.apache
On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote:
I just hit the problem today with one of my colleague. Yes, System
props should definitely win.
You also must start thinking about how system properties make it into
the execution environment. System properties wreak havoc in the
embedder
I agree. We still have lots of users stuck on 2.0.5 due to various
issues in the newer versions. Once we've closed the gap, then supporting
all the way back to 2.0 is not as critical as it is now.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, February 22,
I just hit the problem today with one of my colleague. Yes, System
props should definitely win.
Thanks,
Stéphane
On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote:
> Now the question is "do we have to change this order ?".
> Have a look at MRESOURCES-39 [1].
>
> Users com
33 matches
Mail list logo
