Our experience in geronimo has always been that maven does not support this,
and I thought for maven 3 it was announced that it never ever would.
We have a proflie to build up through the plugin, then you can do the full
build.
Releasing is a pain as you have to do the manual profile build with
I would like to dynamically determine the currently executing goal from a
MOJO.
I attempted this using reflection but the new annotations are not available
at runtime.
All other solutions I have seen appear to require access to the executing
MOJO's groupId and artifactId.
Anyone have a solution?
+1 for 3.1
On 10 September 2012 21:19, Dennis Lundberg wrote:
> +1 for 3.1
>
> On 2012-09-07 22:19, Anders Hammar wrote:
> > I know. But there wasn't much visible change in v3.0 either. And I'm
> > thinking that it would be easier to communicate a dependency on Maven
> > 3.1+ than 3.0.5+ if some
Interesting… I wonder how I've managed to do CXF releases for all these years
then. :-)
Seriously, for CXF <=2.5.x, I use Maven 2.2.1 and it "just works". Parts of
the build certainly do use the plugins that are built as part of the reactor.
That said, we use "install" as the default targe
Hi
I've been working my way towards a release of the Changes Plugin. Now
I'm all done. Unless someone has anything really urgent I'll start the
release process soon.
There are other projects depending on a release because of
http://jira.codehaus.org/browse/MCHANGES-285
--
Dennis Lundberg
-
+1 for 3.1
On 2012-09-07 22:19, Anders Hammar wrote:
> I know. But there wasn't much visible change in v3.0 either. And I'm
> thinking that it would be easier to communicate a dependency on Maven
> 3.1+ than 3.0.5+ if some component utilizes the JSR330 support.
>
> Version numbers are cheap. Why
Perso due to this change I'm more for a 3.1 (it's just a matter of
jiras bulk change :-) )
2012/9/9 Robert Scholte :
> It looks to me the changes fit more a 3.0.5
>
> I always had in mind, that with the 3.1 we would make the pom-parser more
> strict meaning:
> - don't warn but fail for plugins wit
On Mon, Sep 10, 2012 at 3:25 PM, Olivier Lamy wrote:
> Did you apply exactly pom sample from
> http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html
Sadly, I did not. I thought I did, but I was wrong. Now I'm fine.
> ?
>
> 2012/9/10 Benson Margulies :
>> My plu
Did you apply exactly pom sample from
http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html
?
2012/9/10 Benson Margulies :
> My plugin has an @Mojo on itself. I'm so far failing to figure out
> what I'm missing.
>
> INFO] --- maven-plugin-plugin:3.1:descriptor (d
My plugin has an @Mojo on itself. I'm so far failing to figure out
what I'm missing.
INFO] --- maven-plugin-plugin:3.1:descriptor (default-descriptor) @
r4dws-client-codegen-maven-plugin ---
...
[INFO]
[INFO] BUILD FAILURE
[I
I'm fairly sure this didn't work in Maven 2.x. It was one of the
unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround
would be to use an older released version of the plugin. Don't think
running a build twice is/was a workable workaround as I can't see how
that would work in a relea
On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies wrote:
> On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp wrote:
> >
> > On Sep 10, 2012, at 11:14 AM, Benson Margulies
> wrote:
> >
> >> In Maven 2.x, the following was true; the reactor could not apply a
> >> plugin it had just built. So, if a par
On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp wrote:
>
> On Sep 10, 2012, at 11:14 AM, Benson Margulies wrote:
>
>> In Maven 2.x, the following was true; the reactor could not apply a
>> plugin it had just built. So, if a particular problem required a
>> plugin (e.g., for generating code), the pl
On Sep 10, 2012, at 8:04 AM, Benson Margulies wrote:
> There are people who embed Maven, and they are likely to find it
> congenial that they can make it talk to the logging framework of their
> choice by dropping in slf4j-X as needed. For the ordinary
> command-line, Jason and I and others think
On Sep 10, 2012, at 11:14 AM, Benson Margulies wrote:
> In Maven 2.x, the following was true; the reactor could not apply a
> plugin it had just built. So, if a particular problem required a
> plugin (e.g., for generating code), the plugin has to be an
> independent project that is built in adva
In Maven 2.x, the following was true; the reactor could not apply a
plugin it had just built. So, if a particular problem required a
plugin (e.g., for generating code), the plugin has to be an
independent project that is built in advance. Is this still true in
3.x?
On a related front, have any rea
There are people who embed Maven, and they are likely to find it
congenial that they can make it talk to the logging framework of their
choice by dropping in slf4j-X as needed. For the ordinary
command-line, Jason and I and others think that we just pick a
backend, put the appropriate jar into M2_H
Yep lots of people mess this up big time... I should know having ended up
writing my own logging adapter at one point in time...
The only api that came close to offering all the required features was
slf4j... And the missing features were in my view less optimal and largely
driven by the telecoms
Hi Simone,
I will try to have a look if you create a JIRA with a test project that
I can play with. No promises though, my velocity skills are quite rusty
by now...
-Lukas
Simone Tripodi wrote:
> Hi all guys,
>
> I invested some time on trying the upgrade and I miserably failed :(
>
> The fa
wait men,
we speak about maven right? how often do you configure your logs to be
"verbose"?
it is often simply [level] - message
other usages are "advanced" (an user will never activate it - i agree when
you dev you can but dev are not targeted users IMO?)
so for such a simple need whatever fra
Hi,
Except someone complains I will start release of
maven-scm-publish-plugin tomorrow.
2012/9/5 Olivier Lamy :
> Hi Folks,
> First reminder, moving site and distribution to svnpubsub is mandatory
> for the end of the year (the good is dist and sync are very very fast
> opposite to the current rsy
Sorry - I should have added - "unless your facade uses LocationAwareLogger
instead of the normal Logger".
Ralph
On Sep 10, 2012, at 9:21 AM, Ralph Goers wrote:
>
> On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote:
>
>>
>>> Absolutely. In light of commit r1380105, the next step is for you
>>>
On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote:
>
>> Absolutely. In light of commit r1380105, the next step is for you
>> (Maven folks) to formulate a policy for swapping out logging
>> back-ends.
>
> Well that is what this is all about. And we have this solution available in
> Maven since
Hi all guys,
I invested some time on trying the upgrade and I miserably failed :(
The fact is that I didn't get explicit warnings/errors, the macro was
simply ignored and rendered as #evaluate String, with arguments.
Can someone please, with more doxia background, help me on give a try?
Many th
Mark, I hope I did not convey the wrong message in my previous
email. Commit r1380105 provides a backward compatible way for existing
Maven plug-ins to continue using org.codehaus.plexus.Logger. The said
Plexus logger would delegate to org.slf4j.Logger to perform actual
logging. By "a policy for
> Absolutely. In light of commit r1380105, the next step is for you
> (Maven folks) to formulate a policy for swapping out logging
> back-ends.
Well that is what this is all about. And we have this solution available in
Maven since 2004. There is already a logging facade which is widely used:
On Sep 9, 2012 8:08:34 pm, Ralh Goers wrote:
> First, I also would recommend moving from plexus logging to SLF4J.
Cool.
> Mark's concerns with incompatibilities only come about with the log4j
> bridge if you are trying to use APis that the SLF4J bridge hasn't
> implemented. Something being use
> But it would be nice to allow the end user the ability to swap out the
> logging implementation if they want.
Yes, that would be very good. I know there's been questions on the
mailing list how to tweak the logging (don't remember exactly what the
wanted to do). So having something that would m
Le 9 sept. 2012 15:44, "Jason van Zyl" a écrit :
>
> I noted in the issue where the tool is and there's a standard Maven
plugin page there. Probably as well documented as how to do it with Plexus
:-)
>
For sure and I agree on that :-) (as responsible of that fact too :-) )
But as we always have t
29 matches
Mail list logo
