Any specific reason we're not configuring the memory for this CI job?
It has never run successfully; can we disable it?
/Anders
-- Forwarded message --
From: Apache Jenkins Server
Date: Sat, Oct 13, 2012 at 12:37 AM
Subject: Build failed in Jenkins: maven-plugins-ITs-m3-windows #
> In the case of Cargo does it fork by default and there the logging is all
> self-contained by virtue of running in its own VM?
To be honest I don't know. I think it doesn't fork, but I could be
wrong. But it doesn't really matter, Cargo was just one example.
But after having spent some more ti
I believe we will be able to have more controlled "veins" of logging, or domain
specific logging, once SLF4J is in place. For example if I'm interested only in
plugin execution, or artifact resolution we will be able to do that.
On Oct 12, 2012, at 9:22 AM, Anders Hammar wrote:
>>> If all log
In the case of Cargo does it fork by default and there the logging is all
self-contained by virtue of running in its own VM?
On Oct 12, 2012, at 8:12 AM, Anders Hammar wrote:
>> In the context of Maven, is there any added value in pluging having a
>> separated logging environment? If there is n
Although I understand we can make the merged repository work, at least
with some discipline from developers, I think merged source repository
makes changes to the integration tests perceptually "okay", which imho
is rarely the case. I actually maintained fork of maven ITs for
awhile, and personall
>> If all logging from the embedded framework gets directed to the Maven
>> output console, it could get messy. I'm thinking something like how
>> the surefire plugin works where the user is directed to the surefire
>> reports for further problem info (stacktraces etc.)
> those would be the cases w
On 12 October 2012 13:12, Anders Hammar wrote:
> > In the context of Maven, is there any added value in pluging having a
> > separated logging environment? If there is no added value, then merged
> > logging is the way to go.
>
Going separate makes it very difficult for the end user to figure ou
> In the context of Maven, is there any added value in pluging having a
> separated logging environment? If there is no added value, then merged
> logging is the way to go.
Could one possible case be a plugin which embeds some "framework"
which uses slf4j to log to it's own log file(s)? And in thi
On 12.10.2012 00:01, Jason van Zyl wrote:
> Ceki made some sample plugins and we'll post something tomorrow about
> some options for integration. Basically Merged vs Mixed: do we want to
> funnel everything into the the core logging backend, or let the plugin
> completely decided by declaring bot
My mails came out sort-of in the wrong order, and I'm not sure if I agree
with myself on splitting it changes <-> core changes.
There is no technical mandate for this, not even a practical one since
establishing mergeability from 2.2.1 -> 3.X turned out to be simple.
But as a personal work habit
"It may still be a good idea to do IT and core-change as two different
commits"
If we merge core and ITs I think it will be important to do it (and thus to
ask it to contributors - or we'll need to do it on our side).
I always see few reasons to merge them and find the process a little bit
complex
11 matches
Mail list logo
