I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
Anyone want to add anything or discuss anything before I spin this? I'm not in
any rush so if folks want to talk about logging we can. But given the fact once
SLF4J initializes it can't change the implementation plugins inte
my +1
2012/11/28 Olivier Lamy :
> Hi,
>
> I'd like to release the archetype for maven plugin.
> The goal is to have an archetype which generate project using new mojo
> annotations (and a sample to run maven-invoker-plugin)
> We fixed 2 issues:
> http://jira.codehaus.org/browse/MARCHETYPES/fixforv
Ah, thanks for clarifying. I'll leave it as is then.
/Anders (mobile)
Den 30 nov 2012 20:24 skrev "Dennis Lundberg" :
> On 2012-11-30 12:52, Anders Hammar wrote:
> >> * Git doesn't seem to be available on the ubuntu-ARM nodes that the jdk
> >> 1.7 job is running on. Kind of surprised as I thought
At the end of the day, either Maven uses a standard logging API inside
plugins, or it does not. Using a standard logging API has giant
advantages - but it can inconvenience people integrating complex code
via plugins.
In this thread, there are two approaches to removing that
inconvenience: a plugi
Anything is possible but I honestly don't want to do it because I don't really
think it's worth it. Just use SLF4J properly, that's your path. I don't think
this is really that onerous and deprives developers of their liberty :-) So
many systems use SLF4J and I don't think many of them allow mag
Would it be possible to implement something (nasty and rather iki under
the covers) along the lines of using say a
MavenLoggerFactory.getLogger(Foo.class, ImplementationClass.class,
String config).
If this variation is used to get a Logger, use ClassWorlds or something
to create a new classlo
On Fri, November 30, 2012 12:33 pm, Mark Struberg wrote:
>
>>I don't believe it's valid to just let everyone do whatever they want.
>
> Well, I think this is the fundamental point we disagree on.
> Maven is not only a build system but also a container which runs user
> specific stuff. And a contain
On Nov 30, 2012, at 12:33 PM, Mark Struberg wrote:
>
>> I don't believe it's valid to just let everyone do whatever they want.
>
> Well, I think this is the fundamental point we disagree on.
> Maven is not only a build system
No, but the only other one people are contemplating using, Gradle,
>I don't believe it's valid to just let everyone do whatever they want.
Well, I think this is the fundamental point we disagree on.
Maven is not only a build system but also a container which runs user specific
stuff. And a container should try to isolate as much internal details from it's
user
On Nov 30, 2012, at 11:55 AM, Mark Struberg wrote:
> That's all broken by design as already predicted 2 months ago.
>
It is not broken by design and you're not being helpful. Retreating into trying
to implement all this ourselves is not a solution. Try it Mark, implement your
system and igno
That's all broken by design as already predicted 2 months ago.
Imo the only portable way is to NOT expose slf4j in the Core Realm at all.
The other way would be to introduce a plugin-plugin configuration which says
logging yes/no.
LieGrue,
strub
- Original Message -
> From: Stephen C
On Nov 30, 2012, at 11:15 AM, Stephen Connolly
wrote:
> What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
>
If it's in 3.0.4 then you are using Mojo.getLog(), which is probably the ideal
case, and this will work without change in 3.1.0.
> Currently 3.0.4 does not pr
On 2012-11-30 12:52, Anders Hammar wrote:
>> * Git doesn't seem to be available on the ubuntu-ARM nodes that the jdk
>> 1.7 job is running on. Kind of surprised as I thought this was handled by
>> the Jenkins plugin and should then not be a problem. Does anyone know?
>>
>
> Sorry, this should have
What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
Currently 3.0.4 does not provide either the api or an impl, so I need both
as a dependency..,
I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
and part of the plugin jar (because it makes most sen
For case 2) I would say only fork if your logging is know to interfere with
standard SLF4J practices which I think would be rare. But I'll see how easy it
is to implement a flag while I'm looking at this in general.
On Nov 30, 2012, at 4:20 AM, Stephen Connolly
wrote:
> I tend to agree. There
I agree that the Sonar plugin is bogus and unrelated to the discussion
at hand, and I accept your explanation that we're not, in fact, going
to derail legitimate 'self-contained' plugins.
-
To unsubscribe, e-mail: dev-unsubscr...@
On Nov 30, 2012, at 4:09 AM, Benson Margulies wrote:
>>
>> That's the magic I would like to avoid. Anything is possible but I would
>> prefer how a plugin author should integrate with our SLF4J logging.
>
> Here's the crux of the disagreement. To be clear, I'm not trying to
> derail any 3.1.0
I have another suggestion related to commit messages. Generally git commit
messages follow following template:
-
First line contains summary of the change
After one empty line there is more or less free-form text describing the commit
in more detail. This can include:
* lists
* urls
* basic
Patches generated with git-format-patch will retain original author when
applied. This is what we require in m2e for example, it makes much
easier to credit code contributions and generate stats reports.
Patches generated with git-diff (or plain diff, for that matter) do not
have author informati
Hi All,
In sonar-core, looking at the Logback class in the
org.sonar.core.config package, you can find following lines:
import ch.qos.logback.classic.LoggerContext;
import org.slf4j.LoggerFactory;
...
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
Sonar is assuming that
On Fri, Nov 30, 2012 at 7:20 AM, Stephen Connolly
wrote:
> I tend to agree. There are two use-cases I see that a plugin has for
> bundling a logging implementation:
>
> 1. They are wanting to shunt the logs from the build tool they are invoking
> on to the user. Typically if they are being good pl
I tend to agree. There are two use-cases I see that a plugin has for
bundling a logging implementation:
1. They are wanting to shunt the logs from the build tool they are invoking
on to the user. Typically if they are being good plugins they just take the
logging output and shunt it onto org.apach
On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl wrote:
>
> On Nov 29, 2012, at 5:56 PM, Benson Margulies wrote:
>
>>>
>>> Currently I'm of the mind that if you make a Maven plugin that uses
>>> something that employs SLF4J then the best practice is to only use the API
>>> and let the host choos
> * Git doesn't seem to be available on the ubuntu-ARM nodes that the jdk
> 1.7 job is running on. Kind of surprised as I thought this was handled by
> the Jenkins plugin and should then not be a problem. Does anyone know?
>
Sorry, this should have been "the solaris" nodes. The ARM ones are down s
I am interested in other peoples thoughts with respect to
https://jira.codehaus.org/browse/MVERSIONS-200
Basically, if you have the old deprecated expressions like
${parent.groupId} in your poms, then it blows up.
My question is should I add support for these expressions (and then remove
it agai
All of the core-integration-testing-maven-3-xxx jobs are now switched
configuration wise. However, I ran into some problems:
* Git doesn't seem to be available on the ubuntu-ARM nodes that the jdk 1.7
job is running on. Kind of surprised as I thought this was handled by the
Jenkins plugin and shou
I'll work on the core-integration-testing-maven-3-xxx ones.
/Anders
On Fri, Nov 30, 2012 at 9:02 AM, Olivier Lamy wrote:
> I have switched only 2 jenkins jobs:
> * https://builds.apache.org/view/M-R/view/Maven/job/maven-3.0.x/
> *
> https://builds.apache.org/view/M-R/view/Maven/job/core-integr
A question from a git rookie:
If we're applying a proper git patch, then the "submitted by" row shouldn't
be required in the commit message as git will handle this. Right?
/Anders
On Fri, Nov 30, 2012 at 9:04 AM, Olivier Lamy wrote:
> In the future could we avoid those non necessary commit ?
>
> I'll send a separate thread about the logging options after chatting with
> Simon.
>
I filed MNG-5394 [1] about creating a page on the site where we could
document on how logging should be done in a plugin. This doesn't have to be
done before we release 3.1.0 though as it's a site task.
/Anders
Back to version 2.2:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=97e8ae273784d86d3cb6b7849848c05919ac4896
On Nov 30, 2012, at 12:08 AM, Anders Hammar wrote:
> Great. And from the JIRAs I take it that the default m-war-p has been
> changed (downgraded to 2.2?).
>
> /Ander
Great. And from the JIRAs I take it that the default m-war-p has been
changed (downgraded to 2.2?).
/Anders
On Fri, Nov 30, 2012 at 9:00 AM, Jason van Zyl wrote:
> Just and update on the 3.1.0 saga.
>
> I'm going to fix the NPE in the MavenCli[1] now, and I'm going to chat
> with Simon Brandho
In the future could we avoid those non necessary commit ?
I have started a git convention page here:
http://maven.apache.org/developers/conventions/git.html
See the workflow section.
All fixes/improvements for this doc will be appreciate :-)
2012/11/30 :
> Updated Branches:
> refs/heads/master
I have switched only 2 jenkins jobs:
* https://builds.apache.org/view/M-R/view/Maven/job/maven-3.0.x/
*
https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3/
Lack of time today to switch others.
If any volunteer that will be appreciate :-)
2012/11/30 Olivier Lamy :
Just and update on the 3.1.0 saga.
I'm going to fix the NPE in the MavenCli[1] now, and I'm going to chat with
Simon Brandhof tomorrow about the use of Logback in Sonar[2]. Kristian also
added the proper disposing the realms[3] by cleaning up some handing of arrays
between threads which were ca
34 matches
Mail list logo
