Does not maven use a catalog manager such that
entity's resolution per system can be configured by edit of the
corresponding catalog file?
Reference "http://www.sagehill.net/docbookxsl/WriteCatalog.html";
Eg: Given <!ENTITY developerCa SYSTEM "developer-ca.xml">
1. Find your system's catalogmanager.properties file and add
<nextCatalog catalog="maven.cat.xml"/> to the corresponding catalog.xml
2. Create this maven.cat.xml to manage the developerCa entities.
3. Each deployment would carry the correct basedir entry to resolve the
systemid to appropriate path.
<?xml version="1.0" ?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" >
<group prefer="public"
<!-- Using the Windows URI form -->
xml:base="file:///c:/usr/local/share/sdf/">
<system
systemId="developer-ca.xml"
uri="developerCa/conf/maven/developer-ca.xml"/>
</group>
</catalog>
-----Original Message-----
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 09, 2005 2:21 PM
To: Maven Users List
Subject: Re: using xml entities in project.xml
You've got the right ideas. The POM should be self contained, and the
aim in the future is to ensure this is the case by making all the
expressions self referencing, folding in properties, making <extend>
declarative, and discouraging the use of entities.
This is seen as a better way to do it than snapshot the POM when it is
published with the current entity values.
Basically, if there is something you need to do with entities, Maven
should support it internally.
Is there a reason that inheritence will not work for you in this
instance?
Cheers,
Brett
On Wed, 09 Feb 2005 14:13:37 +0100, Christian Andersson <[EMAIL PROTECTED]>
wrote:
> Hi there, I've have found a small problem with using xml entities in
> maven 1.0.2
>
> I'm using xml-entities to be able to reuse xml-parts so that I do not
> have to write the same stuff over and over again in every maven
> project I'm handling.
>
> example:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE project [
> <!ENTITY developerCa SYSTEM "../../conf/maven/developer-ca.xml">
> ]>
> <project>
> ...
> <developers>
> &developerCa;
> <developers>
> ...
> </project>
>
> as you can see I'm using a relative path for the entity, the reson for
> this is that we are several developers and unfourtunally we have
> plased the "root" in different places so using
> /work/projects/conf/maven/developer-ca.xml for path will not work.
>
> anyway this works perfectly for all projects I have, except for a few
> exceptions, projects that are maven-plugins...
>
> The first time I do plugin:install for a project that has xml-entities
> everything works as expected (the plugin gets installed) however from
> now on, maven will crash, since it cannot find/open the
> developer-ca.xml file.
>
> the reason for this is that the project.xml file is placed in the
> plugon directory of maven and maven then loads it and since the real
> path now is different, the relative path is also different.
>
> at the moment I have cheated and solved this by maing sure that the
> path maven looks for actually exists and containes the files needed,
> but this I think is a ugly hack and sould not be needed.
>
> If I'm using xml-entities the wrong way, I'd appreciate a lesson .-)
>
> othervice what i suggest is that the project.xml that the project.xml
> files that gets copied around should be a complete project.xml file ie
> all entities should be removed and the content of the entities should
> be placed where the entities was used. in my case it should look
> something like this...
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <project>
> ...
> <developers>
> <developer>
> ...
> </developer>
> <developers>
> ...
> </project>
>
> I hope I'm making sence here .-)
>
> /Christian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
