Hudson can't parse config.xml if it contains entities

178 views
Skip to first unread message

Parag Doke

unread,
Dec 3, 2010, 7:14:50 AM12/3/10
to Hudson Users
Hello All.
I am new to Hudson. Currently using version 1.386.
I wanted to have the config.xml use some environment variables, so I
tried something similar to this:
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<!DOCTYPE hudson [
<!ENTITY JAVA_HOME "C:\Java">
]>
<hudson>
.
.
.
Somewhere down, I'm referencing the entity thus: &JAVA_HOME;
XML wise this seems correct. But when Hudson starts, it shows an
exception (copied below). Does anyone know if I'm making a mistake ?

Thanks in advance,
Parag Doke


Running from: C:\Hudson\hudson.war
[Winstone 2010/12/03 17:42:09] - Beginning extraction from war file
hudson home directory: C:\Hudson
Using one-time self-signed certificate
[Winstone 2010/12/03 17:42:10] - AJP13 Listener started: port=8009
[Winstone 2010/12/03 17:42:10] - HTTP Listener started: port=80
Dec 3, 2010 5:42:10 PM hudson.model.Hudson$4 onAttained
INFO: Started initialization
Dec 3, 2010 5:42:10 PM hudson.model.Hudson$4 onAttained
INFO: Listed all plugins
[Winstone 2010/12/03 17:42:10] - Winstone Servlet Engine v0.9.10
running: contro
lPort=disabled
Dec 3, 2010 5:42:10 PM hudson.model.Hudson$4 onAttained
INFO: Prepared all plugins
Dec 3, 2010 5:42:10 PM hudson.model.Hudson$4 onAttained
INFO: Started all plugins
Dec 3, 2010 5:42:10 PM hudson.model.Hudson$4 onAttained
INFO: Augmented all extensions
Dec 3, 2010 5:42:10 PM hudson.model.Hudson$4 onTaskFailed
SEVERE: Failed Loading global config
hudson.util.IOException2: Unable to read C:\Hudson\config.xml
at hudson.XmlFile.unmarshal(XmlFile.java:152)
at hudson.model.Hudson$11.run(Hudson.java:2177)
at org.jvnet.hudson.reactor.TaskGraphBuilder
$TaskImpl.run(TaskGraphBuild
er.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at hudson.model.Hudson$3.runTask(Hudson.java:691)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExec
utor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor
.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.thoughtworks.xstream.converters.ConversionException: :
could not
resolve entity named 'JAVA_HOME' (position: START_TAG seen ...</name>
\n <h
ome>&JAVA_HOME;... @120:24) : : could not resolve entity named
'JAVA_HOME' (po
sition: START_TAG seen ...</name>\n <home>&JAVA_HOME;... @120:24)
---- Debugging information ----
message : : could not resolve entity named
'JAVA_HOME' (position: S
TART_TAG seen ...</name>\n <home>&JAVA_HOME;... @120:24)
cause-exception : com.thoughtworks.xstream.io.StreamException
cause-message : : could not resolve entity named
'JAVA_HOME' (position: S
TART_TAG seen ...</name>\n <home>&JAVA_HOME;... @120:24)
class : hudson.model.Hudson
required-type : java.lang.String
path : /hudson/jdks/jdk/home
line number : 120
-------------------------------
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:89)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
bstractReferenceUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:60)
at
hudson.util.RobustReflectionConverter.unmarshalField(RobustReflection
Converter.java:290)
at
hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionCon
verter.java:233)
at
hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConve
rter.java:180)
at
hudson.util.XStream2$PassthruConverter.unmarshal(XStream2.java:254)
at
hudson.util.XStream2$AssociatedConverterImpl.unmarshal(XStream2.java:
224)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:82)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
bstractReferenceUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:60)
at
com.thoughtworks.xstream.converters.collections.AbstractCollectionCon
verter.readItem(AbstractCollectionConverter.java:71)
at
hudson.util.RobustCollectionConverter.populateCollection(RobustCollec
tionConverter.java:85)
at
com.thoughtworks.xstream.converters.collections.CollectionConverter.u
nmarshal(CollectionConverter.java:61)
at
hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConve
rter.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:82)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
bstractReferenceUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:60)
at
hudson.util.RobustReflectionConverter.unmarshalField(RobustReflection
Converter.java:290)
at
hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionCon
verter.java:233)
at
hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConve
rter.java:180)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:82)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
bstractReferenceUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:60)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller
.java:137)
at
com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarsh
al(AbstractTreeMarshallingStrategy.java:33)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:
926)
at hudson.util.XStream2.unmarshal(XStream2.java:80)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:
912)
at hudson.XmlFile.unmarshal(XmlFile.java:148)
... 9 more
Caused by: com.thoughtworks.xstream.io.StreamException: : could not
resolve ent
ity named 'JAVA_HOME' (position: START_TAG seen ...</name>\n
<home>&JAVA_HO
ME;... @120:24)
at
com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.jav
a:78)
at
com.thoughtworks.xstream.io.xml.AbstractPullReader.readRealEvent(Abst
ractPullReader.java:154)
at
com.thoughtworks.xstream.io.xml.AbstractPullReader.readEvent(Abstract
PullReader.java:141)
at
com.thoughtworks.xstream.io.xml.AbstractPullReader.getValue(AbstractP
ullReader.java:184)
at
com.thoughtworks.xstream.io.ReaderWrapper.getValue(ReaderWrapper.java
:52)
at
com.thoughtworks.xstream.converters.SingleValueConverterWrapper.unmar
shal(SingleValueConverterWrapper.java:49)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:82)
... 42 more
Caused by: org.xmlpull.v1.XmlPullParserException: could not resolve
entity named
'JAVA_HOME' (position: START_TAG seen ...</name>\n
<home>&JAVA_HOME;... @1
20:24)
at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1282)
at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
at
com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.jav
a:63)
... 48 more
Dec 3, 2010 5:42:10 PM hudson.WebAppMain$2 run
SEVERE: Failed to initialize Hudson
org.jvnet.hudson.reactor.ReactorException: hudson.util.IOException2:
Unable to r
ead C:\Hudson\config.xml
at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
at hudson.model.Hudson.executeReactor(Hudson.java:709)
at hudson.model.Hudson.<init>(Hudson.java:627)
at hudson.model.Hudson.<init>(Hudson.java:567)
at hudson.WebAppMain$2.run(WebAppMain.java:220)
Caused by: hudson.util.IOException2: Unable to read C:\Hudson
\config.xml
at hudson.XmlFile.unmarshal(XmlFile.java:152)
at hudson.model.Hudson$11.run(Hudson.java:2177)
at org.jvnet.hudson.reactor.TaskGraphBuilder
$TaskImpl.run(TaskGraphBuild
er.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at hudson.model.Hudson$3.runTask(Hudson.java:691)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExec
utor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor
.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.thoughtworks.xstream.converters.ConversionException: :
could not
resolve entity named 'JAVA_HOME' (position: START_TAG seen ...</name>
\n <h
ome>&JAVA_HOME;... @120:24) : : could not resolve entity named
'JAVA_HOME' (po
sition: START_TAG seen ...</name>\n <home>&JAVA_HOME;... @120:24)
---- Debugging information ----
message : : could not resolve entity named
'JAVA_HOME' (position: S
TART_TAG seen ...</name>\n <home>&JAVA_HOME;... @120:24)
cause-exception : com.thoughtworks.xstream.io.StreamException
cause-message : : could not resolve entity named
'JAVA_HOME' (position: S
TART_TAG seen ...</name>\n <home>&JAVA_HOME;... @120:24)
class : hudson.model.Hudson
required-type : java.lang.String
path : /hudson/jdks/jdk/home
line number : 120
-------------------------------
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:89)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
bstractReferenceUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:60)
at
hudson.util.RobustReflectionConverter.unmarshalField(RobustReflection
Converter.java:290)
at
hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionCon
verter.java:233)
at
hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConve
rter.java:180)
at
hudson.util.XStream2$PassthruConverter.unmarshal(XStream2.java:254)
at
hudson.util.XStream2$AssociatedConverterImpl.unmarshal(XStream2.java:
224)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:82)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
bstractReferenceUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:60)
at
com.thoughtworks.xstream.converters.collections.AbstractCollectionCon
verter.readItem(AbstractCollectionConverter.java:71)
at
hudson.util.RobustCollectionConverter.populateCollection(RobustCollec
tionConverter.java:85)
at
com.thoughtworks.xstream.converters.collections.CollectionConverter.u
nmarshal(CollectionConverter.java:61)
at
hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConve
rter.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:82)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
bstractReferenceUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:60)
at
hudson.util.RobustReflectionConverter.unmarshalField(RobustReflection
Converter.java:290)
at
hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionCon
verter.java:233)
at
hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConve
rter.java:180)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:82)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
bstractReferenceUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:76)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
arshaller.java:60)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller
.java:137)
at
com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarsh
al(AbstractTreeMarshallingStrategy.java:33)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:
926)
at hudson.util.XStream2.unmarshal(XStream2.java:80)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:
912)
at hudson.XmlFile.unmarshal(XmlFile.java:148)
... 9 more
Caused by: com.thoughtworks.xstream.io.StreamException: : could not
resolve ent
ity named 'JAVA_HOME' (position: START_TAG seen ...</name>\n
<home>&JAVA_HO
ME;... @120:24)
at
com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.jav
a:78)
at
com.thoughtworks.xstream.io.xml.AbstractPullReader.readRealEvent(Abst
ractPullReader.java:154)
at
com.thoughtworks.xstream.io.xml.AbstractPullReader.readEvent(Abstract
PullReader.java:141)
at
com.thoughtworks.xstream.io.xml.AbstractPullReader.getValue(AbstractP
ullReader.java:184)
at
com.thoughtworks.xstream.io.ReaderWrapper.getValue(ReaderWrapper.java
:52)
at
com.thoughtworks.xstream.converters.SingleValueConverterWrapper.unmar
shal(SingleValueConverterWrapper.java:49)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
er.java:82)
... 42 more
Caused by: org.xmlpull.v1.XmlPullParserException: could not resolve
entity named
'JAVA_HOME' (position: START_TAG seen ...</name>\n
<home>&JAVA_HOME;... @1
20:24)
at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1282)
at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
at
com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.jav
a:63)
... 48 more
Exception in thread "pool-2-thread-4" java.lang.NullPointerException
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:191)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExec
utor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor
.java:908)
at java.lang.Thread.run(Thread.java:662)

Jesse Glick

unread,
Dec 3, 2010, 9:27:30 AM12/3/10
to Hudson Users
On Dec 3, 7:14 am, Parag Doke <parag.d...@gmail.com> wrote:
> I wanted to have the config.xml use some environment variables, so I
> tried something similar to this:
> <!ENTITY JAVA_HOME "C:\Java">

I don't have an answer to your question, but rather than the above
style (which cannot work well since config.xml will be rewritten
without entities after any customization), try just defining a JDK and
associating it with projects. http://wiki.hudson-ci.org/display/HUDSON/Tool+Environment+Plugin
may be helpful here. Or simply define a wrapper script for Hudson
which sets this environment variable.

Parag Doke

unread,
Dec 3, 2010, 10:44:36 AM12/3/10
to Hudson Users
Hello Jesse.
Thank you for your reply.
I am new to Hudson ... so likely that I'm doing things the wrong way.
So if I have JAVA_HOME defined as an environment variable in a batch
file (before launching Hudson) and then I launch Hudson using the
command line, is there a way for Hudson to pick up and read that
value ? If yes, then I guess that is what I am looking for.

By the way, JAVA_HOME was just an example. I was planning to use the
entity method for a few other environment variables too.

Thanks in advance,
Parag Doke

On Dec 3, 7:27 pm, Jesse Glick <jesse.gl...@oracle.com> wrote:
> On Dec 3, 7:14 am, Parag Doke <parag.d...@gmail.com> wrote:
>
> > I wanted to have the config.xml use some environment variables, so I
> > tried something similar to this:
> > <!ENTITY JAVA_HOME "C:\Java">
>
> I don't have an answer to your question, but rather than the above
> style (which cannot work well since config.xml will be rewritten
> without entities after any customization), try just defining a JDK and
> associating it with projects.http://wiki.hudson-ci.org/display/HUDSON/Tool+Environment+Plugin

Jesse Glick

unread,
Dec 3, 2010, 11:02:58 AM12/3/10
to Hudson Users
On Dec 3, 10:44 am, Parag Doke <parag.d...@gmail.com> wrote:
> So if I have JAVA_HOME defined as an environment variable in a batch
> file (before launching Hudson) and then I launch Hudson using the
> command line, is there a way for Hudson to pick up and read that
> value?

Well, environment variables should be inherited by subprocesses, such
as batch scripts you run for project builds.

(Normally JAVA_HOME is defined automatically by Hudson, simply by
associating a JDK with a project.)

Parag Doke

unread,
Dec 3, 2010, 10:54:06 PM12/3/10
to hudson...@googlegroups.com
Yes. True. But then it makes the Hudson configuration platform specific. I thought you were hinting at something even before the batch/shell script.

What I rather wanted to go for is a config.xml with an external dtd (in the same location - Hudson_home). The dtd would define entities such as JAVA_HOME and some other variables (PATH_SEP is another example -> ; on windows and : on Unixes). The dtd could be created at runtime (just before Hudson is invoked).

When I tried with an external dtd with entities, it did not work. So I tried with internal ones ... but those don't work either.

Batch scripts/shell scripts, I agree is one way out .... but then it makes us maintain a different set of job configurations for different platforms. However, any further ideas are welcome. I'm willing to try this out.

On another note, it seems that the parses being used by Hudson are from ThoughWorks (going by the strack trace). Does anyone know of some drawbacks with that related to entity parsing ? If so, any links in that context will be really appreciated (only so that I can subscribe to the bug details and be notified when the issue is fixed).

Thanks in advance again,
Parag Doke
--
Parag Doke
Save paper, save trees. Do not print emails/documents unless absolutely necessary.

Larry Shatzer, Jr.

unread,
Dec 4, 2010, 9:19:30 AM12/4/10
to hudson...@googlegroups.com
On Fri, Dec 3, 2010 at 8:54 PM, Parag Doke <parag...@gmail.com> wrote:
Yes. True. But then it makes the Hudson configuration platform specific. I thought you were hinting at something even before the batch/shell script.


I don't see how, since Hudson will download and install the JDK on the slave, or hudson instance, and use that. You just define what version of the JDK you want, and hudson takes care of the rest.
 
-- Larry

Les Mikesell

unread,
Dec 3, 2010, 11:08:54 AM12/3/10
to hudson...@googlegroups.com
On 12/3/2010 9:44 AM, Parag Doke wrote:
> Hello Jesse.
> Thank you for your reply.
> I am new to Hudson ... so likely that I'm doing things the wrong way.
> So if I have JAVA_HOME defined as an environment variable in a batch
> file (before launching Hudson) and then I launch Hudson using the
> command line, is there a way for Hudson to pick up and read that
> value ? If yes, then I guess that is what I am looking for.
>
> By the way, JAVA_HOME was just an example. I was planning to use the
> entity method for a few other environment variables too.

You probably won't always want JAVA_HOME as a constant. You may want to
install different jdk versions and specify which to use in a build, and
each node may have each version installed in different locations. I'm
not sure if it is from the base system or a plugin we have installed,
but our main 'configure system' has a place to add global environment
variables as well as a way to add JDK's with version names that are then
added in each 'Node Properties' with a corresponding location for each tool.

--
Les Mikesell
lesmi...@gmail.com

Parag Doke

unread,
Dec 5, 2010, 12:20:40 AM12/5/10
to hudson...@googlegroups.com
Thanks for the replies.
However, no! Maybe I shouldn't have mentioned JAVA_HOME as an example.
Let us just ignore that for the moment and consider a totally new tool ABC. So the objectives:
1) Need this variable ABC_HOME to be defined and read within the Hudson configuration.
2) Need the configuration to be independent of the platform (so no batch / shell).

The config.xml references an external dtd placed adjacent to the config.xml where I can define the value for ABC_HOME. The config.xml will stay unchanged (possibly could be checked in into the relevant source control system). Each time I deploy the same configuration on a different system, all I need to do it modify the dtd (could be very few lines).

For such a configuration, it seems that the parser isn't able to pick up entity values. This is the original problem I am trying to state. I agree that the suggestions / replies were intended at providing alternatives to achieve the same end result ... and I am thankful to you for that.

But the original issue ... picking up entity values ... got sidelined. Has anyone had success in having Hudson work with entities defined in the config.xml ? Or defined in an external dtd ?

Thanks in advance,
Parag Doke

Sami Tikka

unread,
Dec 5, 2010, 12:36:00 AM12/5/10
to hudson...@googlegroups.com
Every Hudson node configuration has a place for node-specific environment variables. That's exactly the place for ABC_HOME kind of variables that could be in different locations in different nodes.

But I guess you have really set your mind on your way of doing it :)

-- Sami

Parag Doke

unread,
Dec 5, 2010, 12:42:27 AM12/5/10
to hudson...@googlegroups.com
Hello Sami.
Well you almost caught me there :-).
I rather want the parser issue (if I'm not making a mistake and there is a genuine problem there) to be fixed. For now, it seems I have no option but to go for system specific configurations as you and others on this thread have suggested.

Thanks,
Parag Doke

Larry Shatzer, Jr.

unread,
Dec 5, 2010, 9:38:37 AM12/5/10
to hudson...@googlegroups.com
On Sat, Dec 4, 2010 at 10:20 PM, Parag Doke <parag...@gmail.com> wrote:
But the original issue ... picking up entity values ... got sidelined. Has anyone had success in having Hudson work with entities defined in the config.xml ? Or defined in an external dtd ?


I would tend to stay away from there, since Hudson will rewrite the config.xml when they are modified in the GUI, so it may rewrite the XML without the entities.

-- Larry

Mark Waite

unread,
Dec 5, 2010, 9:48:52 AM12/5/10
to hudson...@googlegroups.com
Parag,

I assume the answer is "no" to your original question ("can Hudson read entities from an external DTD?").  Your experiments seem to show it does not work that way, and no one has offered evidence that would refute your experiment.

I would go one step further and say that even if the answer is "yes", you probably shouldn't do it, since there has been no hint from others in the community that it will work, and others in the community have suggested alternatives which seem to meet the needs without the complexity of reading a DTD in Hudson.

Use environment variables, or use other techniques to detect and act on system state.  It is a proven technique where many users will be able to assist, and seems more likely to give you rapid and reliable results.

Mark Waite

Jesse Glick

unread,
Dec 6, 2010, 10:41:58 AM12/6/10
to Hudson Users
On Dec 5, 12:20 am, Parag Doke <parag.d...@gmail.com> wrote:
> So the objectives:

Now we can talk.

> 1) Need this variable ABC_HOME to be defined and read within the Hudson
> configuration.
> 2) Need the configuration to be independent of the platform (so no batch /
> shell).

No problem; any tool can be defined with an abstract name that will be
resolved properly for each node. This is not limited to JDKs.
http://wiki.hudson-ci.org/display/HUDSON/Tool+Auto-Installation

> The config.xml references an external dtd

This will never work well, so don't even try.
Reply all
Reply to author
Forward
0 new messages