On Sun, Jan 23, 2011 at 11:10 PM, Benson Margulies
wrote:
> OK, then, if you give me a patch, I'll see if my long-dormant karma is
> effective, at least in getting some attention.
My proposed patch is probably not something you want in Hudson (in
there, the algorithm for rebuilding the dependency
OK, then, if you give me a patch, I'll see if my long-dormant karma is
effective, at least in getting some attention.
On Sun, Jan 23, 2011 at 2:33 PM, Niklas Gustavsson wrote:
> On Sun, Jan 23, 2011 at 6:21 PM, Benson Margulies
> wrote:
>> I'm a very rusty hudson dev. So I'm reduced to the foll
thanks.
On Jan 23, 2011, at 2:48 PM, Niklas Gustavsson wrote:
> On Sun, Jan 23, 2011 at 6:04 PM, Benson Margulies
> wrote:
>> Now we get the following ... which thinks that it's hudson's fault.
>
> Should be working now. You're build is running as we speak.
>
> /niklas
On Sun, Jan 23, 2011 at 6:04 PM, Benson Margulies wrote:
> Now we get the following ... which thinks that it's hudson's fault.
Should be working now. You're build is running as we speak.
/niklas
On Sun, Jan 23, 2011 at 6:21 PM, Benson Margulies wrote:
> I'm a very rusty hudson dev. So I'm reduced to the following question:
> do we really need interjob hudson dependencies at Apache (the
> downstream/upstream business).
Yes, they are used quite a lot. And, it would seem that testing
depend
Benson,
Right now, when there is a change in Axiom, Hudson will also trigger
builds of Neethi, Woden, Axis2, Sandesha2 and Rampart. This is what we
want because it allows us to ensure non-regression in downstream
projects. This relies on Hudson calculating the dependencies
automatically. Disabling
Niklas,
I'm a very rusty hudson dev. So I'm reduced to the following question:
do we really need interjob hudson dependencies at Apache (the
downstream/upstream business). If all the jobs are set to turn this
off, does it still calculate?
Another view of this would be to look to splitting up huds
Now we get the following ... which thinks that it's hudson's fault.
no change for https://svn.apache.org/repos/asf/webservices/xmlschema/trunk
since the previous build
Unpacking
https://archive.apache.org/dist/maven/binaries/apache-maven-3.0.2-bin.tar.gz
to /home/hudson/hudson-slave/tools/Maven_3
On Sun, Jan 23, 2011 at 1:01 AM, Benson Margulies wrote:
> Looks like the M3 installation isn't sitting in the right place, or
> something else is wrong.
>
> Unpacking
> https://www.apache.org/dist/maven/binaries/apache-maven-3.0-bin.tar.gz
I've fixed the download URL, please try again.
/niklas
Hi
Some of you might have noticed that Hudson can take a long time on
Maven builds in the step called "Parsing POMs". In fact, some builds
will time-out due to this step taking 15 minutes or more. Thing is, as
part of this step, Hudson will do the problematic rebuild of its
dependency graph. This
On Sun, Jan 23, 2011 at 3:48 PM, Niklas Gustavsson wrote:
> On Sun, Jan 23, 2011 at 12:30 PM, Stefan Seelmann wrote:
>> after the Hudson upgrade M2 builds on solaris1 don't work any more, on
>> Ubuntu the same job works.
>
> Could you please try again? I've restarted the slave and can now run
> a
On Sun, Jan 23, 2011 at 12:30 PM, Stefan Seelmann wrote:
> after the Hudson upgrade M2 builds on solaris1 don't work any more, on
> Ubuntu the same job works.
Could you please try again? I've restarted the slave and can now run
an M2 build which previously failed.
/niklas
Hi,
after the Hudson upgrade M2 builds on solaris1 don't work any more, on
Ubuntu the same job works.
Please see the following link or log below:
https://hudson.apache.org/hudson/view/A-F/view/Directory/job/dir-project-jdk15-deploy-site/124/console
Kind Regards,
Stefan
Started by user seelmann
13 matches
Mail list logo
