Since Maven 3.1.0 SLF4J is included with the distribution. The Mojo logger is
baked in but you can use SLF4J is you prefer.
On Feb 2, 2015, at 6:58 PM, Lennart Jörelid wrote:
> From which version of the Maven-Plugin-API are we using SLF4J Loggers,
> Jason?
> In the 2.2.1 plugin API, the Abstrac
>From which version of the Maven-Plugin-API are we using SLF4J Loggers,
Jason?
In the 2.2.1 plugin API, the AbstractMojo contains an
org.apache.maven.plugin.logging.Log.
I presume that this is changed in a later version of the plugin API, right?
public abstract class AbstractMojo
implements M
On Feb 2, 2015, at 6:44 PM, Lennart Jörelid wrote:
> Implying that Maven should simply use SJF4J instead of the Maven logging, I
> take it?
Maven does use SLF4J now. We use the slf4j-simple implementation by default. If
there are many libraries that use JUL then SLF4J provides a standard funne
Implying that Maven should simply use SJF4J instead of the Maven logging, I
take it?
And - yes - that would be a simpler approach.
(Or at least an approach where one would not need to wrap/convert loggers
to loggers in a custom manner over and over ... ).
2015-02-02 17:02 GMT+01:00 Jason van Zyl
+1
On 1 February 2015 at 06:05, Michael Osipov wrote:
> Hi,
>
> We solved 15 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11140&version=20775
>
> There are still a couple of issues left in JIRA:
> https://jira.codehaus.org/browse/MPMD-186?jql=project%20%3D%20MPMD%20AN
-1 for both archetype and stage plugin.
Maybe I will have a look to fix issues if enough spare time..
I don't understand such rush... AFAIK we are not a company with some budget
and who need to justify a ratio between number of bugs and time spent on
projects.
On 2 February 2015 at 20:23, Michael
+1
Regards,
Hervé
Le samedi 31 janvier 2015 20:05:51 Michael Osipov a écrit :
> Hi,
>
> We solved 15 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140&version=20
> 775
>
> There are still a couple of issues left in JIRA:
> https://jira.codehaus.org/browse/MPMD-186?jql
To be exact, DefaultMavenProjectBuilder goes to extra trouble to end
up with a 'dynamic' version of the Build, not the resolved version,
and this test needs the resolved one.
On Mon, Feb 2, 2015 at 12:19 PM, Benson Margulies wrote:
> Somewhere between 2.0 and 2.2, MavenProjectBuilder changed to b
Github user cushon closed the pull request at:
https://github.com/apache/maven-plugins/pull/43
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature i
Great, Daniel, I thought I'm the only one thinking that way... ;-)
2015-02-02 19:38 GMT+01:00 Daniel Kulp :
>
> I’m -1 to retiring the maven-eclipse-plugin until the m2e stuff is at a
> state where it can be as flexible and useful as the maven-eclipse-plugin.
> Trying to bring a large complex pr
I'm pretty sure I might be bashed for writing this, but what the heck... ;-)
I do still see some need for the maven-eclipse-plugin.
To be perfectly clear, I agree that m2e is by far superior in many ways,
not only tech-wise, but also conceptionally.
Still, at work we had to migrate from m2e to m
I’m -1 to retiring the maven-eclipse-plugin until the m2e stuff is at a state
where it can be as flexible and useful as the maven-eclipse-plugin. Trying to
bring a large complex project like CXF into eclipse with m2e is PAINFUL and
doesn’t even result in fully configured and ready workspace.
Somewhere between 2.0 and 2.2, MavenProjectBuilder changed to build
projects with property references in them. For example,
.getBuild().getDirectory():
${project.basedir}/target
There are tests in archetype that are pretty confused by this. Can
someone remind me of how to obtain an interpolated v
Should you really be using the JVM of maven to run these tools?
I would argue no. You should be forking the toolchains specified JVM and
using that forked JVM to do the work. If you do it that way you can
completely control what logging those forked JVMs uses and route it to the
Maven logger of ch
Would it be easier if we just packaged jul-over-slf4j in the distribution to
cover these cases?
On Feb 2, 2015, at 10:07 AM, Lennart Jörelid wrote:
> Hello all,
>
> I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
> encountered a (presumably) common problem. The plugin dele
On Monday, 2 February 2015 at 14:43, Benson Margulies wrote:
> I'm attempting to pull archetype up to 2.2.1. I seem to have found a
> disagreement between 2.2.1 of maven-artifact-manager and some version
> of some part of plexus.
>
> Is this a familiar story to anyone; is there, for example, some
Hello all,
I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of its
work to the JDK-distributed tools XJC and SchemaGen. These two tools use
JUL for logging; and their respective outputs should be emitted onto
So all is well with 1.0-alpha-9-stable-1, of plexus-container-default,
but nothing newer! I suppose that I should keep that dependency for
the release at the 2.2.1 level, and then reconsider things.
On Mon, Feb 2, 2015 at 9:43 AM, Benson Margulies wrote:
> I'm attempting to pull archetype up to
I'm attempting to pull archetype up to 2.2.1. I seem to have found a
disagreement between 2.2.1 of maven-artifact-manager and some version
of some part of plexus.
Is this a familiar story to anyone; is there, for example, some plexus
piece I need a different version of?
DefaultArtifactTransfomati
Sounds good to me. I especially like the Maven 3.0 (not 3.0.5) requirement.
/Anders
On Mon, Feb 2, 2015 at 12:42 PM, Karl Heinz Marbaise
wrote:
> Hi,
>
> after some discussions at FOSDEM with Hervé, Kristian and Robert in
> Brussels i will summarize some ideas we would like to share here:
>
> M
Just to be perfectly clear:
I am volunteering to include archetype in the herd.
I have submitted INFRA-9100 to move it to git.
I have assigned http://jira.codehaus.org/browse/ARCHETYPE-471 to myself.
So no need to send any email announcing its demise.
---
Hi,
the plan was to release from almost all the plugins to make a last
releases which has Maven 2.2.1 minimum and JDK 5 min.
Furthermore I'm working on several of those plugins:
maven-docck-plugin,
maven-doap-plugin
maven-repository-plugin
maven-stage-plugin
maven-pdf-plugin
maven-archetype-p
People are making new archetypes every day.
I did a round of bugfixing a couple of years ago, I could do one again.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache
Agree with Anders:
* +1 to deprecate maven-eclipse-plugin (coming from an happy M2E user from
years), the community must acknowledge that this plugin is not the way to
go and there's a modern an well-maintained alternative.
* -1 to deprecate maven-archetype-plugin IMO it's still one of those
plugi
Hi,
after some discussions at FOSDEM with Hervé, Kristian and Robert in
Brussels i will summarize some ideas we would like to share here:
Make a final release of all plugins with minium Maven 2.2.1
(prerequisites) and Java 1.5
The current state of this approach can be watched on the dist-to
Hi,
On 2/2/15 10:15 AM, Michael Osipov wrote:
Hi Karl Heinz,
I am aware of the retirement plan.
If i take a look into some of jira's it does not look like you are aware
of the procedure, cause you have closed issues with the comment:
"Project has been retired, closing as won't fix."
which
I strongly second that the maven-eclipse-plugin be retired. For us working
in Eclipse, the m2e integration is the way to go. Also, there has not been
any active work on that plugin for many years and I think we should clearly
indicate to the community that there is very little hope anyone would fix
Hi folks,
I have performed another cleanup on JIRA in the last couple of days, most of on
old issues.
Right now, we have more than 2000 open issues. Not manageble from my point of
view.
I have noticed that several plugins haven't been touched in years. What is the
status of
the following plugi
Hi Karl Heinz,
I am aware of the retirement plan. This is the procedure I will go.
Anyawy, I will post the list first to figure out which plugins are
really dead.
Sorry on my part.
Michael
> Hi Michael,
>
> If you like to prepare a list of plugins which should be retired it's a
> good idea bu
Hi Michael,
If you like to prepare a list of plugins which should be retired it's a
good idea but this should be shared on the DEV list before changing the
JIRA in that way...
furthermore only mark retired project in Jira AFTER the project has
VOTEd accordingly...
Apart from that i'm worki
30 matches
Mail list logo
