For lack of anyone more knowledgeable about the Jenkins Ivy plugin stepping
forward, let me throw out a couple more ideas.

Since the ivy.xml that Ivy really cares about when it's resolving is the one
that resides on Nexus, you should share one from an in-house project that's
a common dependency to see if anyone can spot any obvious problems. (I'm
presuming here that you're using Nexus as an Ivy repository and publishing
the ivy.xml rather than publishing POMs.)

Try paring things down to the simplest possible case. Have the plugin manage
no projects other than the one that is the least dependent. See if that
works. If it does, keep adding each dependent project until it stops
working. That would at least isolate where the problem is arising.

Question. Are you hoping to accomplish anything with the Jenkins plugin
beyond automatically ordering your jobs?

On Tue, Feb 22, 2011 at 4:32 PM, Kent Rosenkoetter <
krosenkoet...@cequint.com> wrote:

> I just pulled the source for Ivy 2.1.0.  It looks like the only way
> ModuleDescriptor.getModuleRevisionId() could be null is if somebody uses the
> DefaultModuleDescriptor(ModuleDescriptorParser, Resource) constructor and
> then fails to call DefaultModuleDescriptor.setModuleRevisionId() on it.
>  Alternately, it could happen in DefaultModuleDescriptor.transformInstance()
> if the NamespaceTransformer.transform(ModuleDescriptor) method returns null.
>  The NamespaceTransformer inner class inside of Namespace return null if the
> input is null.
>
> This could be a problem with how the Jenkins Ivy plugin is invoking Ivy,
> but I can't easily pull down the Jenkins source to find out.
>
> -Kent
>
> -----Original Message-----
> From: Kent Rosenkoetter [mailto:krosenkoet...@cequint.com]
> Sent: Tuesday, February 22, 2011 3:32 PM
> To: ivy-user@ant.apache.org
> Subject: RE: Error parsing ivy.xml files using Jenkins
>
> I just tried what you suggested, and got the same failure as before. Even
> with a revision in the ivy.xml file, I still get a NullPointerException.
>
> U         ivy.xml
> At revision 950
> Parsing Ivy Descriptor Files
> Parsing error while reading the ivy file
> /home/thudson/.hudson/workspace/EcidCommon-Ivy-platform/ivy.xml
> ERROR: Failed to parse ivy.xml files
> java.io.IOException<
> http://stacktrace.hudson-labs.org/search?query=java.io.IOException>:
> Unable to parse ivy descriptors
>        at
> hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:530)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles&entity=method
> >
>        at
> hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:366)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun&entity=method
> >
>        at
> hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:420)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.model.AbstractBuild$AbstractRunner.run&entity=method
> >
>        at hudson.model.Run.run(Run.java:1362)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.model.Run.run&entity=method
> >
>        at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.ivy.IvyModuleSetBuild.run&entity=method
> >
>        at
> hudson.model.ResourceController.execute(ResourceController.java:88)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.model.ResourceController.execute&entity=method
> >
>        at hudson.model.Executor.run(Executor.java:145)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.model.Executor.run&entity=method
> >
> Caused by: java.lang.NullPointerException<
> http://stacktrace.hudson-labs.org/search?query=java.lang.NullPointerException
> >
>        at
> org.apache.ivy.core.sort.CollectionOfModulesToSort.addToModulesByModuleId(CollectionOfModulesToSort.java:71)<
> http://stacktrace.hudson-labs.org/search/?query=org.apache.ivy.core.sort.CollectionOfModulesToSort.addToModulesByModuleId&entity=method
> >
>        at
> org.apache.ivy.core.sort.CollectionOfModulesToSort.<init>(CollectionOfModulesToSort.java:66)<
> http://stacktrace.hudson-labs.org/search/?query=org.apache.ivy.core.sort.CollectionOfModulesToSort.%3Cinit%3E&entity=method
> >
>        at
> org.apache.ivy.core.sort.ModuleDescriptorSorter.<init>(ModuleDescriptorSorter.java:51)<
> http://stacktrace.hudson-labs.org/search/?query=org.apache.ivy.core.sort.ModuleDescriptorSorter.%3Cinit%3E&entity=method
> >
>        at
> org.apache.ivy.core.sort.SortEngine.sortModuleDescriptors(SortEngine.java:99)<
> http://stacktrace.hudson-labs.org/search/?query=org.apache.ivy.core.sort.SortEngine.sortModuleDescriptors&entity=method
> >
>        at org.apache.ivy.Ivy.sortModuleDescriptors(Ivy.java:639)<
> http://stacktrace.hudson-labs.org/search/?query=org.apache.ivy.Ivy.sortModuleDescriptors&entity=method
> >
>        at
> hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:803)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call&entity=method
> >
>        at
> hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:742)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call&entity=method
> >
>        at hudson.remoting.UserRequest.perform(UserRequest.java:114)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.remoting.UserRequest.perform&entity=method
> >
>        at hudson.remoting.UserRequest.perform(UserRequest.java:48)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.remoting.UserRequest.perform&entity=method
> >
>        at hudson.remoting.Request$2.run(Request.java:270)<
> http://stacktrace.hudson-labs.org/search/?query=hudson.remoting.Request$2.run&entity=method
> >
>        at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)<
> http://stacktrace.hudson-labs.org/search/?query=java.util.concurrent.Executors$RunnableAdapter.call&entity=method
> >
>        at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)<
> http://stacktrace.hudson-labs.org/search/?query=java.util.concurrent.FutureTask$Sync.innerRun&entity=method
> >
>        at java.util.concurrent.FutureTask.run(FutureTask.java:123)<
> http://stacktrace.hudson-labs.org/search/?query=java.util.concurrent.FutureTask.run&entity=method
> >
>        at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)<
> http://stacktrace.hudson-labs.org/search/?query=java.util.concurrent.ThreadPoolExecutor$Worker.runTask&entity=method
> >
>        at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)<
> http://stacktrace.hudson-labs.org/search/?query=java.util.concurrent.ThreadPoolExecutor$Worker.run&entity=method
> >
>        at java.lang.Thread.run(Thread.java:595)<
> http://stacktrace.hudson-labs.org/search/?query=java.lang.Thread.run&entity=method
> >
> Finished: FAILURE
>
> Jenkins version: 1.396
> Ivy plugin version: 1.15
> According to http://wiki.jenkins-ci.org/display/JENKINS/Ivy+Plugin this
> uses ivy 2.1.0 internally.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ivy-module version="2.2"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>            xsi:noNamespaceSchemaLocation="
> http://ant.apache.org/ivy/schemas/ivy.xsd";
>            xmlns:e="http://ant.apache.org/ivy/extra";>
>      <info organisation="com.cequint" module="Foo" branch="platform"
> status="integration" revision="17.26">
>            <ivyauthor name="Cequint" url="http://www.cequint.com/"/>
>      </info>
>      <configurations>
>            <conf name="compile" transitive="false" visibility="private"
> description="Compiles the source into class files."/>
>            <conf name="runtime" extends="compile" transitive="true"
> description="For running systems that depend on this library."/>
>            <conf name="build" extends="runtime" description="For use in an
> IDE, includes source and JavaDoc."/>
>            <conf name="test" extends="runtime" visibility="private"
> description="Build the unit tests."/>
>      </configurations>
>      <publications>
>            <artifact type="jar" ext="jar">
>                  <conf name="compile"/>
>            </artifact>
>            <artifact type="javadoc" ext="jar" e:classifier="javadoc">
>                  <conf name="build"/>
>            </artifact>
>            <artifact type="source" ext="jar" e:classifier="sources">
>                  <conf name="build"/>
>            </artifact>
>      </publications>
>      <dependencies>
>            <dependency org="log4j" name="log4j" rev="1.2.16"/>
>            <dependency org="org.apache.httpcomponents" name="httpcore"
> rev="4.1" />
>            <dependency org="org.apache.httpcomponents" name="httpclient"
> rev="4.1" />
>            <dependency org="javax.servlet" name="servlet-api" rev="2.5"/>
>            <dependency org="junit" name="junit" rev="4.8.2"
> conf="test->default"/>
>      </dependencies>
> </ivy-module>
>
> -Kent
>
> From: Mitch Gitman [mailto:mgit...@gmail.com]
> Sent: Tuesday, February 22, 2011 11:24 AM
> To: ivy-user@ant.apache.org
> Cc: Kent Rosenkoetter
> Subject: Re: Error parsing ivy.xml files using Jenkins
>
> Here's the line in question from CollectionOfModulesToSort:
>        ModuleId mdId = md.getModuleRevisionId().getModuleId();
>
> The variable md is of type ModuleDescriptor, which is the domain type
> represented by your ivy.xml. The method getModuleRevisionId returns an
> object of ModuleRevisionId. I suspect this call is what's returning null.
> That could very well be due to the absence of the revision, although it's
> not unusual for the ivy.xml in source control to not contain a revision. So
> really, my question about how the revision shows in the published module is
> a diversion and not pertinent to your problem.
>
> On the one hand, I'd go back to my devil's advocacy here. It sounds like
> you're otherwise satisfied with your Ivy integration. In that case, what
> value are you hoping to gain from using the Ivy plugin?
>
> Still, it's curious that the Ivy plugin APPEARS to coughing at what is an
> acceptable input--a source ivy.xml that does not contain a revision--if my
> suspicion is correct.
>
> If you don't mind committing bogus content into source control, just as an
> experiment, try committing a source ivy.xml that does have a Nexus-generated
> revision and see what happens. If this no longer fails, at least you've
> isolated the problem.
>
> Perhaps there's someone out there who has used the Ivy Jenkins plugin in a
> similar arrangement. I haven't. In working with a much larger project base,
> I came to an opposite conclusion than you did:
> * Running multimodule builds: worthwhile.
> * Ivy plugin for Hudson: not worthwhile.
>
> I'd be interested in re-evaluating the plugin's value proposition
> eventually.
>

Reply via email to