You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/04/18 16:37:57 UTC
XML Catalogs
Hi,
Since noone reacted on my quest for XML Catalog support in Maven, I am
patching Maven myself to handle it.
I have 2 questions;
1. I'll submit a patch back to the community, so which branch should I make
the diff against.
2. In MavenUtils.getNonJellyProject(), there is a 1), 2) & 3) steps. Would it
be possible for the 2) step (MavenUtils.createContext() ) to be done first,
and the 1) second?? Reason is, I want to pick up properties from the
project.properties and pass it into the parser.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 19 April 2004 01:19, bob mcwhirter wrote:
> Has the w3c done a catalog spec?
Not sure, but I think they either have, or are in the process of doing it...
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Tomasz Pik <pi...@ais.pl>.
bob mcwhirter wrote:
> Ah, catalogs are actually a wonderful thing. They translate identifiers
> to something system-specific, typically. They are mircales in SGML and
> XML has been knocked for not having them previously.
>
> Has the w3c done a catalog spec?
OASIS:
http://www.oasis-open.org/committees/download.php/2384/cs-entity-xml-catalogs-1.0.html
I posted some of ideas about XML processing in maven.
It's rather for support for XML processing rather then solving
cross-projects problems but I thing it might be worth to mention
it here.
I cannot find this email in archives so I'm copying content here
=====
During using war/ear plugins I've found that it will be very useful
to have the possibility to verify deployment descriptors.
I know that validating against DTD is not enough but I think it's
worth a while to find some kind of general solution.
First thought was: just add war-related DTDs as resources for war
plugins and call xml-commons resolver-driven validation.
Same for other plugins.
But there're some problems with such attempt:
* DTDs should be embed into plugins;
* there's no way to add additonal verification like 'my webapp
is using Castor so let's validate mapping.xml too during war
build' because it's not clear where to put those DTDs;
Some of them have working SYSTEMID so may be loaded directly
during verification but this won't work offline and slow down
Maven.
Another idea that comes to me was to specify DTDs as deps, something
like
<dependency>
<artifactId>webapp</artifactId>
<groupId>servletapi</groupid>
<version>2.3</version>
<type>dtd</type>
</dependency>
but this is not enough because there's not enough information to
solve validation problem because there's no way to get PUBLIC/SYSTEM
IDs of given DTD having only DTD so some external info is needed.
In theory this may be added as properties in <dependency> but it's not
a good idea...
So at least it looks for me that with DTD there should be a catalog
entry defining DTD. So xml-validator may download all 'dtd', 'xsd',
'xslt', 'ent' and maybe other files and their 'cat' descriptors,
build one catalog for all of them and then validate given set of files.
This comes to a problem of having two things instead of one and this
is not playing good with Maven dependency model...
After all I think that it might be a good idea to define some kind
of 'xmlarchive' to handle XML in Maven-way. 'xar' or something like
this. With catalog file in META-INF and other files packaged as
java class files.
And finally, with such thing docbook plugin may rely on 'xar' package
containing DocBook stylesheets stored on iBiblio...
What's the opinion about all of this?
Regards,
Tomek
PS1 more about resolving and catalogs
http://xml.apache.org/commons/components/resolver/resolver-article.html
PS2 I know Ant has all of this implemented but the problem is not
in calling validator but in locating DTD/XSD/XSLT files.
====
Regards,
Tomek
> -bob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by bob mcwhirter <bo...@werken.com>.
On Sun, 18 Apr 2004, Jason van Zyl wrote:
> On Sun, 2004-04-18 at 13:19, bob mcwhirter wrote:
> > Ah, catalogs are actually a wonderful thing.
>
> Maybe so, but I still don't think we need them and if the xpp3 parser
> doesn't support them then we can't use them because I'm not using xerces
> just to get catalog support. If they are supported by the xpp3 parser
> then I would make any changes necessary to make them available for
> people to use if it was really deemed necessary. But I don't think they
> will be and I'll try to show so with a large set of generated projects
> which are highly nested to mimic something like Vincent's setup, the
> Avalon setup, Plexus setup and the Geronimo setup.
They can be sorta hacked into any XML parser by using a custom entity-resolver,
I believe. catalogs aren't new tech, just a codified way of using existing
tech.
-bob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-04-18 at 13:19, bob mcwhirter wrote:
> Ah, catalogs are actually a wonderful thing.
Maybe so, but I still don't think we need them and if the xpp3 parser
doesn't support them then we can't use them because I'm not using xerces
just to get catalog support. If they are supported by the xpp3 parser
then I would make any changes necessary to make them available for
people to use if it was really deemed necessary. But I don't think they
will be and I'll try to show so with a large set of generated projects
which are highly nested to mimic something like Vincent's setup, the
Avalon setup, Plexus setup and the Geronimo setup.
> They translate identifiers
> to something system-specific, typically. They are mircales in SGML and
> XML has been knocked for not having them previously.
>
> Has the w3c done a catalog spec?
>
> -bob
>
> On Sun, 18 Apr 2004, Jason van Zyl wrote:
>
> > On Sun, 2004-04-18 at 10:37, Niclas Hedhman wrote:
> > > Hi,
> > >
> > > Since noone reacted on my quest for XML Catalog support in Maven, I am
> > > patching Maven myself to handle it.
> >
> > Probably not the most rational approach. If none of the developers
> > responded it more likely means none of us are interested, which probably
> > means we're not to keen on the idea, which most likely means your patch
> > won't get integrated.
> >
> > You pretty gave no explanation as to why catalogs would be a good thing
> > other than saying:
> >
> > ---
> >
> > I think it could solve a lot of
> > http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
> >
> > ---
> >
> > > I have 2 questions;
> > >
> > > 1. I'll submit a patch back to the community, so which branch should I make
> > > the diff against.
> >
> > You should probably make an attempt to explain yourself a little more
> > clearly before potentially wasting your time.
> >
> > For one, I don't really even know what catalogs are or how they are
> > used, or how they would be of benefit maven. The other thing is that if
> > catalog support is something only supported by things like xerces and
> > not simple parsers like the xpp3 parser then it's definitely not going
> > to survive into maven2.
> >
> > Additionally the patch is certainly not going in before the 1.0 release.
> >
> > > 2. In MavenUtils.getNonJellyProject(), there is a 1), 2) & 3) steps. Would it
> > > be possible for the 2) step (MavenUtils.createContext() ) to be done first,
> > > and the 1) second?? Reason is, I want to pick up properties from the
> > > project.properties and pass it into the parser.
> > >
> > >
> > > Cheers
> > > Niclas
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@maven.org
> > http://maven.apache.org
> >
> > happiness is like a butterfly: the more you chase it, the more it will
> > elude you, but if you turn your attention to other things, it will come
> > and sit softly on your shoulder ...
> >
> > -- Thoreau
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> --
> Bob McWhirter bob@werken.com
> The Werken Company http://werken.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by bob mcwhirter <bo...@werken.com>.
Ah, catalogs are actually a wonderful thing. They translate identifiers
to something system-specific, typically. They are mircales in SGML and
XML has been knocked for not having them previously.
Has the w3c done a catalog spec?
-bob
On Sun, 18 Apr 2004, Jason van Zyl wrote:
> On Sun, 2004-04-18 at 10:37, Niclas Hedhman wrote:
> > Hi,
> >
> > Since noone reacted on my quest for XML Catalog support in Maven, I am
> > patching Maven myself to handle it.
>
> Probably not the most rational approach. If none of the developers
> responded it more likely means none of us are interested, which probably
> means we're not to keen on the idea, which most likely means your patch
> won't get integrated.
>
> You pretty gave no explanation as to why catalogs would be a good thing
> other than saying:
>
> ---
>
> I think it could solve a lot of
> http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
>
> ---
>
> > I have 2 questions;
> >
> > 1. I'll submit a patch back to the community, so which branch should I make
> > the diff against.
>
> You should probably make an attempt to explain yourself a little more
> clearly before potentially wasting your time.
>
> For one, I don't really even know what catalogs are or how they are
> used, or how they would be of benefit maven. The other thing is that if
> catalog support is something only supported by things like xerces and
> not simple parsers like the xpp3 parser then it's definitely not going
> to survive into maven2.
>
> Additionally the patch is certainly not going in before the 1.0 release.
>
> > 2. In MavenUtils.getNonJellyProject(), there is a 1), 2) & 3) steps. Would it
> > be possible for the 2) step (MavenUtils.createContext() ) to be done first,
> > and the 1) second?? Reason is, I want to pick up properties from the
> > project.properties and pass it into the parser.
> >
> >
> > Cheers
> > Niclas
>
> --
> jvz.
>
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Bob McWhirter bob@werken.com
The Werken Company http://werken.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-04-19 at 09:00, Niclas Hedhman wrote:
> On Monday 19 April 2004 20:40, Jason van Zyl wrote:
> > Huh? You don't want to share dependencies anywhere?
>
> No. Just to say that
> xerces -> 2.4.0
> avalon-logkit -> 1.2
> jakarta-bcel -> 5.2
> log4j -> 1.2.1
>
> and so on.
>
> > > I want to have ONE place, where I can list the versions to use
> > > for each artifact. Both the "used" ones as well as the "generated" ones.
> >
> > Sorry, what's the distinction wrt to Maven?
>
> The 'generated ones' need to be 'injected' into pom.currentVersion, the
> dependent ones needs to be 'injected' into 'pom.dependencies'.
Sorry, I have no idea what you mean.
> > You realize that the deployment of a SNAPSHOT produces a timestamped
> > version? You say you don't like the SNAPSHOT but again you don't say
> > why.
>
> One reason is that "those who used it" before my time didn't manage to get it
> to work as it is supposed to, I guess. I.e. no timestamps. That is not
> Maven's problem.
> My 'disapproval' is that it consumes a lot of time connecting to the net. I am
> sure you would say, use "-o"...
That what SNAPSHOTS are implicity to Maven, an indicator which means to
always look for a more recent version. To avoid the connection then yes,
go offline or don't use SNAPSHOTs.
> > > I haven't tried to manipulate the ${pom.currentVersion} directly from
> > > such plugin. Would that work? If so, would that also mean that the plugin
> > > could "fill-in" the versions for all the dependencies as well?
> >
> > The release plugin does this: manipulates the POMs, bumps versions and
> > resolves SNAPSHOTS to their timestamped values before a release so you
> > have real versions for everything before deploying.
>
> Hmmm... I'll look into it.
There's definitely working code there but I would really figure out what
you need first. I'm completely willing to help you with a little tree to
figure out your use case as it is similiar to what's in Geronimo. I'm in
irc again.
>
> Cheers
> Niclas
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 19 April 2004 20:40, Jason van Zyl wrote:
> Huh? You don't want to share dependencies anywhere?
No. Just to say that
xerces -> 2.4.0
avalon-logkit -> 1.2
jakarta-bcel -> 5.2
log4j -> 1.2.1
and so on.
> > I want to have ONE place, where I can list the versions to use
> > for each artifact. Both the "used" ones as well as the "generated" ones.
>
> Sorry, what's the distinction wrt to Maven?
The 'generated ones' need to be 'injected' into pom.currentVersion, the
dependent ones needs to be 'injected' into 'pom.dependencies'.
> You realize that the deployment of a SNAPSHOT produces a timestamped
> version? You say you don't like the SNAPSHOT but again you don't say
> why.
One reason is that "those who used it" before my time didn't manage to get it
to work as it is supposed to, I guess. I.e. no timestamps. That is not
Maven's problem.
My 'disapproval' is that it consumes a lot of time connecting to the net. I am
sure you would say, use "-o"...
> > I haven't tried to manipulate the ${pom.currentVersion} directly from
> > such plugin. Would that work? If so, would that also mean that the plugin
> > could "fill-in" the versions for all the dependencies as well?
>
> The release plugin does this: manipulates the POMs, bumps versions and
> resolves SNAPSHOTS to their timestamped values before a release so you
> have real versions for everything before deploying.
Hmmm... I'll look into it.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2004-04-19 at 07:57, Niclas Hedhman wrote:
> On Monday 19 April 2004 02:05, Jason van Zyl wrote:
>
> > To help you could give me a little tree description of your build and
> > describe how you would like things shared.
>
> > I would assume that ideally, you would like to a parent POM in very
> > top-level directory in order to share as much as possible.
>
> I don't want to share the dependencies, since that just creates cyclic
> dependencies.
Huh? You don't want to share dependencies anywhere?
> I want to have ONE place, where I can list the versions to use
> for each artifact. Both the "used" ones as well as the "generated" ones.
Sorry, what's the distinction wrt to Maven?
> I also don't like the "SNAPSHOT" concept, so I wrote a plugin that whenever an
> artifact is deployed (with or without dist), the version is automatically
> incremented. I also have goals for incrementing the Major, Minor and what we
> call Phase.
You realize that the deployment of a SNAPSHOT produces a timestamped
version? You say you don't like the SNAPSHOT but again you don't say
why.
> I haven't tried to manipulate the ${pom.currentVersion} directly from such
> plugin. Would that work? If so, would that also mean that the plugin could
> "fill-in" the versions for all the dependencies as well?
The release plugin does this: manipulates the POMs, bumps versions and
resolves SNAPSHOTS to their timestamped values before a release so you
have real versions for everything before deploying.
>
> > I'm in IRC now
> > if you want to build a little tree together.
> > irc.codehaus.org #maven
>
> Sorry. I had to go to sleep...
>
>
> Niclas
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 19 April 2004 02:05, Jason van Zyl wrote:
> To help you could give me a little tree description of your build and
> describe how you would like things shared.
> I would assume that ideally, you would like to a parent POM in very
> top-level directory in order to share as much as possible.
I don't want to share the dependencies, since that just creates cyclic
dependencies. I want to have ONE place, where I can list the versions to use
for each artifact. Both the "used" ones as well as the "generated" ones.
I also don't like the "SNAPSHOT" concept, so I wrote a plugin that whenever an
artifact is deployed (with or without dist), the version is automatically
incremented. I also have goals for incrementing the Major, Minor and what we
call Phase.
I haven't tried to manipulate the ${pom.currentVersion} directly from such
plugin. Would that work? If so, would that also mean that the plugin could
"fill-in" the versions for all the dependencies as well?
> I'm in IRC now
> if you want to build a little tree together.
> irc.codehaus.org #maven
Sorry. I had to go to sleep...
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-04-18 at 13:35, Niclas Hedhman wrote:
> On Monday 19 April 2004 01:27, Jason van Zyl wrote:
>
> > > We are trying (@Avalon) the hardest to centralize the versioning of our
> > > 70+ versioned artifacts, their cross-dependencies and all the external
> > > dependencies that are involved.
> >
> > I believe the fellow who manages development said he has it working,
>
> Who could that be? Stephen McConnell? If not, you might be referring to the
> current mess, which I and Stephen are trying to sort out...
No, no. When I asked the other day how heavily used entities were used a
fellow, who was a project manager, said he used entities extensively in
order to keep track of things. Sounded like he had a lot of builds and
had it under control. The post was in the last couple of days.
> > Maybe Vincent or Gilles can forward their usage patterns as I believe
> > for them it does work.
>
> That would be nice to see...
>
> > Recursive inheritance, transitive dependencies will take care of most of
> > the problems. Vincent has also suggested named dependency sets and a
> > more convenient method of declaring a version of a dependency across
> > then board then the jar override mechanism.
>
> > so if the geronimo build is made to work then I
> > think Avalon will have a working model from which to copy.
>
> Ok... that, I guess, is something in the near future.
Once the 1.0 released then we can start the 1.1 path and think about
integrating some bits and pieces from the components. By then I'll have
the little project generator sorted out. I would like to generate
something like a 1000 small projects with a great level of POM
recursion, shared dependencies and anything else I can throw in to find
places where things break down. From there I can incorporate project
ideas from users that have maintenance problems due to the current
limitations.
>
> Niclas
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-04-18 at 13:35, Niclas Hedhman wrote:
> On Monday 19 April 2004 01:27, Jason van Zyl wrote:
> > so if the geronimo build is made to work then I
> > think Avalon will have a working model from which to copy.
>
> Ok... that, I guess, is something in the near future.
To help you could give me a little tree description of your build and
describe how you would like things shared.
I would assume that ideally, you would like to a parent POM in very
top-level directory in order to share as much as possible. Maybe
describe how you would like to share dependencies, how you might like to
control versions of dependencies and that sort of thing. I'm in IRC now
if you want to build a little tree together.
irc.codehaus.org #maven
>
> Niclas
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 19 April 2004 01:27, Jason van Zyl wrote:
> > We are trying (@Avalon) the hardest to centralize the versioning of our
> > 70+ versioned artifacts, their cross-dependencies and all the external
> > dependencies that are involved.
>
> I believe the fellow who manages development said he has it working,
Who could that be? Stephen McConnell? If not, you might be referring to the
current mess, which I and Stephen are trying to sort out...
> Maybe Vincent or Gilles can forward their usage patterns as I believe
> for them it does work.
That would be nice to see...
> Recursive inheritance, transitive dependencies will take care of most of
> the problems. Vincent has also suggested named dependency sets and a
> more convenient method of declaring a version of a dependency across
> then board then the jar override mechanism.
> so if the geronimo build is made to work then I
> think Avalon will have a working model from which to copy.
Ok... that, I guess, is something in the near future.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 19 April 2004 20:07, Vincent Massol wrote:
> This defeats the goal of centralizing dependency definitions. We find it
> better to have:
>
> <dependency>&xml-apis;</dependency>
This is really good tip... :o)
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: XML Catalogs
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: 19 April 2004 13:50
> To: Maven Developers List
> Subject: Re: XML Catalogs
>
>
> Ok. We understand this pattern, and IMHO it is not applicable at all,
> since
> you can't have everything depend on everything.
Err? Where have I said or implied this? That's not what we have and I
can assure you it's applicable as we're using it on a real-life 100
developer project! :-)
> However, the modified version is to have only the 'value entities' and
use
> the
> spelled-out dependencies for each artifact, like;
>
> <!ENTITY % index-of-entities SYSTEM
> "file:index.ent"> %index-of-entities;
>
> <groupId>&xml-apis-group;</groupId>
> <artifactId>&xml-apis-id;</artifactId>
> <version>&xml-apis-version;</version>
This defeats the goal of centralizing dependency definitions. We find it
better to have:
<dependency>&xml-apis;</dependency>
[snip]
Anyway, I was just reporting what works for us. If it doesn't for you
then you'll have to find some other solution.
Cheers,
-Vincent
>
> For this to work, the index.ent file must then point to all (one or
many)
> central files, which may not be redirecting any further.
>
> Now I have a dilemma;
> If I put one large central file, the index.ent files are easy to
maintain,
> just forget about them, but make the central file much harder to deal
> with.
> Many smaller central files are much more easy to deal with (especially
> since I
> wrote a plugin to handle the artifact versioning, which recreates the
> files
> instead of search/replace), but then each index.ent has to be updated
as
> soon
> as a new artifact is inserted into the system (either external or
> internal).
>
> I guess I have no other choice (since there is no interest in Maven
for
> catalogs) to change my plugin so that it either search/replace the
mammoth
> large file or recreates all the index.ent with the content in the
central
> versioning directory.
>
>
> Cheers
> Niclas
>
> On Monday 19 April 2004 01:49, Vincent Massol wrote:
> > Actually I'm not the one who set up this usage of entities on our
> > project. Before that I was only using properties inheritance.
> >
> > But here's how they've done it:
> >
> > At top level:
> >
> > - a project.xml that contains no dependencies
> > - a dependencies.ent that contains all external dependencies:
> >
> > <!ENTITY abbot "
> > <groupId>abbot</groupId>
> > <artifactId>abbot</artifactId>
> > <version>0.11.0</version>
> > ">
> >
> > <!ENTITY activation "
> > <groupId>jaf</groupId>
> > <artifactId>activation</artifactId>
> > <version>1.0.2</version>
> > ">
> >
> > [...]
> >
> > In each project:
> >
> > - a locator.ent file pointing to the dependencies.ent file (using
> > relative paths):
> >
> > <!ENTITY % character-entities SYSTEM
> > "file:../../../Development/dependencies.ent"> %character-entities;
> >
> > - in project.xml, reference the required entity.
> >
> > Hope it helps,
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Jason van Zyl [mailto:jvanzyl@maven.org]
> > > Sent: 18 April 2004 19:27
> > > To: Maven Developers List
> > > Subject: Re: XML Catalogs
> > >
> > > On Sun, 2004-04-18 at 12:23, Niclas Hedhman wrote:
> > > > On Sunday 18 April 2004 23:39, Jason van Zyl wrote:
> > > > > You pretty gave no explanation as to why catalogs would be a
good
> > >
> > > thing
> > >
> > > > > other than saying:
> > > >
> > > > We are trying (@Avalon) the hardest to centralize the versioning
of
> >
> > our
> >
> > > 70+
> > >
> > > > versioned artifacts, their cross-dependencies and all the
external
> > > > dependencies that are involved.
> > >
> > > I believe the fellow who manages development said he has it
working,
> >
> > and
> >
> > > Vincent with the Jelly work around with properties also works
around
> >
> > the
> >
> > > problem and I think he's got a lot more projects then 70. There is
> >
> > also
> >
> > > the mevenide project where you might get some tips as they use
> >
> > entities
> >
> > > as well.
> > >
> > > > The
> > > >
http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
> > > > gave us some ideas, but unfortunately, it doesn't really work,
since
> >
> > ALL
> >
> > > > external references are relative current directory.
> > >
> > > Maybe Vincent or Gilles can forward their usage patterns as I
believe
> > > for them it does work.
> > >
> > > > That means that in every directory we would need a complete
> >
> > "index.ent"
> >
> > > file
> > >
> > > > listing everything, which seems like a big waste of maintenance
> > >
> > > problems.
> > >
> > > > Catalogs is a mechanism to solve the non-portable SYSTEM
> >
> > identifiers,
> >
> > > and map
> > >
> > > > them to the actual locations of those files.
> > > >
> > > > I can recommend the Cocoon explaination
> > > > http://cocoon.apache.org/2.1/userdocs/concepts/catalog.html
> > > > and the link in that document;
> > > > http://www.dpawson.co.uk/docbook/catalogs.html
> > > >
> > > >
> > > > Catalogs or Entity Resolution revolves around using either the
> >
> > PUBLIC or
> >
> > > > SYSTEM identifiers, look it up in the Catalog and return the
file
> >
> > that
> >
> > > the
> > >
> > > > catalog is pointing at (relative to the catalog file!!!).
> > > >
> > > > This solves our problems.
> > > >
> > > >
> > > > If Maven is not interested in this at all, what do you have up
your
> > >
> > > sleeve, so
> > >
> > > > that I can have centralized lists of versions used in all the
> > >
> > > subprojects?
> > >
> > > Recursive inheritance, transitive dependencies will take care of
most
> >
> > of
> >
> > > the problems. Vincent has also suggested named dependency sets and
a
> > > more convenient method of declaring a version of a dependency
across
> > > then board then the jar override mechanism.
> > >
> > > Some of these features are available in the components already,
the
> >
> > rest
> >
> > > of the features will be present soon. At any rate nothing will
change
> >
> > in
> >
> > > the while we're in the motions of releasing 1.0. After 1.0 the
> > > components can be integrated and builds like Avalon's will be
dealt
> >
> > with
> >
> > > easily. One of the criterion for the release of the m2 alpha is
being
> > > able to deal with the geronimo build cleanly and easily the main
point
> > > being that POM handling in m2 is something that can be back ported
> >
> > into
> >
> > > m1 relatively easily so if the geronimo build is made to work then
I
> > > think Avalon will have a working model from which to copy.
> > >
> > > I am also inclined to use as little XML mumbo jumbo like
namespaces,
> > > schema validation, entities and catalogs because it usually
requires
> >
> > the
> >
> > > use of the 500lb gorilla variety of xml parser. In m2 everything
works
> > > well with the 20k xmlpull parser from the extreme labs at the uni
of
> > > Indiana and I love it and plan to keep it that way.
> > >
> > > > Cheers
> > > > Niclas
> > > >
> > > > P.S Time already wasted. ~10 lines of change in MavenUtils.
> > >
> > > --
> > > jvz.
> > >
> > > Jason van Zyl
> > > jason@maven.org
> > > http://maven.apache.org
> > >
> > > happiness is like a butterfly: the more you chase it, the more it
will
> > > elude you, but if you turn your attention to other things, it will
> >
> > come
> >
> > > and sit softly on your shoulder ...
> > >
> > > -- Thoreau
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> +---------//-------------------+
> | http://www.bali.ac |
> | http://niclas.hedhman.org |
> +------//----------------------+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Niclas Hedhman <ni...@hedhman.org>.
Ok. We understand this pattern, and IMHO it is not applicable at all, since
you can't have everything depend on everything.
However, the modified version is to have only the 'value entities' and use the
spelled-out dependencies for each artifact, like;
<!ENTITY % index-of-entities SYSTEM
"file:index.ent"> %index-of-entities;
<groupId>&xml-apis-group;</groupId>
<artifactId>&xml-apis-id;</artifactId>
<version>&xml-apis-version;</version>
For this to work, the index.ent file must then point to all (one or many)
central files, which may not be redirecting any further.
Now I have a dilemma;
If I put one large central file, the index.ent files are easy to maintain,
just forget about them, but make the central file much harder to deal with.
Many smaller central files are much more easy to deal with (especially since I
wrote a plugin to handle the artifact versioning, which recreates the files
instead of search/replace), but then each index.ent has to be updated as soon
as a new artifact is inserted into the system (either external or internal).
I guess I have no other choice (since there is no interest in Maven for
catalogs) to change my plugin so that it either search/replace the mammoth
large file or recreates all the index.ent with the content in the central
versioning directory.
Cheers
Niclas
On Monday 19 April 2004 01:49, Vincent Massol wrote:
> Actually I'm not the one who set up this usage of entities on our
> project. Before that I was only using properties inheritance.
>
> But here's how they've done it:
>
> At top level:
>
> - a project.xml that contains no dependencies
> - a dependencies.ent that contains all external dependencies:
>
> <!ENTITY abbot "
> <groupId>abbot</groupId>
> <artifactId>abbot</artifactId>
> <version>0.11.0</version>
> ">
>
> <!ENTITY activation "
> <groupId>jaf</groupId>
> <artifactId>activation</artifactId>
> <version>1.0.2</version>
> ">
>
> [...]
>
> In each project:
>
> - a locator.ent file pointing to the dependencies.ent file (using
> relative paths):
>
> <!ENTITY % character-entities SYSTEM
> "file:../../../Development/dependencies.ent"> %character-entities;
>
> - in project.xml, reference the required entity.
>
> Hope it helps,
> -Vincent
>
> > -----Original Message-----
> > From: Jason van Zyl [mailto:jvanzyl@maven.org]
> > Sent: 18 April 2004 19:27
> > To: Maven Developers List
> > Subject: Re: XML Catalogs
> >
> > On Sun, 2004-04-18 at 12:23, Niclas Hedhman wrote:
> > > On Sunday 18 April 2004 23:39, Jason van Zyl wrote:
> > > > You pretty gave no explanation as to why catalogs would be a good
> >
> > thing
> >
> > > > other than saying:
> > >
> > > We are trying (@Avalon) the hardest to centralize the versioning of
>
> our
>
> > 70+
> >
> > > versioned artifacts, their cross-dependencies and all the external
> > > dependencies that are involved.
> >
> > I believe the fellow who manages development said he has it working,
>
> and
>
> > Vincent with the Jelly work around with properties also works around
>
> the
>
> > problem and I think he's got a lot more projects then 70. There is
>
> also
>
> > the mevenide project where you might get some tips as they use
>
> entities
>
> > as well.
> >
> > > The
> > > http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
> > > gave us some ideas, but unfortunately, it doesn't really work, since
>
> ALL
>
> > > external references are relative current directory.
> >
> > Maybe Vincent or Gilles can forward their usage patterns as I believe
> > for them it does work.
> >
> > > That means that in every directory we would need a complete
>
> "index.ent"
>
> > file
> >
> > > listing everything, which seems like a big waste of maintenance
> >
> > problems.
> >
> > > Catalogs is a mechanism to solve the non-portable SYSTEM
>
> identifiers,
>
> > and map
> >
> > > them to the actual locations of those files.
> > >
> > > I can recommend the Cocoon explaination
> > > http://cocoon.apache.org/2.1/userdocs/concepts/catalog.html
> > > and the link in that document;
> > > http://www.dpawson.co.uk/docbook/catalogs.html
> > >
> > >
> > > Catalogs or Entity Resolution revolves around using either the
>
> PUBLIC or
>
> > > SYSTEM identifiers, look it up in the Catalog and return the file
>
> that
>
> > the
> >
> > > catalog is pointing at (relative to the catalog file!!!).
> > >
> > > This solves our problems.
> > >
> > >
> > > If Maven is not interested in this at all, what do you have up your
> >
> > sleeve, so
> >
> > > that I can have centralized lists of versions used in all the
> >
> > subprojects?
> >
> > Recursive inheritance, transitive dependencies will take care of most
>
> of
>
> > the problems. Vincent has also suggested named dependency sets and a
> > more convenient method of declaring a version of a dependency across
> > then board then the jar override mechanism.
> >
> > Some of these features are available in the components already, the
>
> rest
>
> > of the features will be present soon. At any rate nothing will change
>
> in
>
> > the while we're in the motions of releasing 1.0. After 1.0 the
> > components can be integrated and builds like Avalon's will be dealt
>
> with
>
> > easily. One of the criterion for the release of the m2 alpha is being
> > able to deal with the geronimo build cleanly and easily the main point
> > being that POM handling in m2 is something that can be back ported
>
> into
>
> > m1 relatively easily so if the geronimo build is made to work then I
> > think Avalon will have a working model from which to copy.
> >
> > I am also inclined to use as little XML mumbo jumbo like namespaces,
> > schema validation, entities and catalogs because it usually requires
>
> the
>
> > use of the 500lb gorilla variety of xml parser. In m2 everything works
> > well with the 20k xmlpull parser from the extreme labs at the uni of
> > Indiana and I love it and plan to keep it that way.
> >
> > > Cheers
> > > Niclas
> > >
> > > P.S Time already wasted. ~10 lines of change in MavenUtils.
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@maven.org
> > http://maven.apache.org
> >
> > happiness is like a butterfly: the more you chase it, the more it will
> > elude you, but if you turn your attention to other things, it will
>
> come
>
> > and sit softly on your shoulder ...
> >
> > -- Thoreau
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: XML Catalogs
Posted by Vincent Massol <vm...@pivolis.com>.
Actually I'm not the one who set up this usage of entities on our
project. Before that I was only using properties inheritance.
But here's how they've done it:
At top level:
- a project.xml that contains no dependencies
- a dependencies.ent that contains all external dependencies:
<!ENTITY abbot "
<groupId>abbot</groupId>
<artifactId>abbot</artifactId>
<version>0.11.0</version>
">
<!ENTITY activation "
<groupId>jaf</groupId>
<artifactId>activation</artifactId>
<version>1.0.2</version>
">
[...]
In each project:
- a locator.ent file pointing to the dependencies.ent file (using
relative paths):
<!ENTITY % character-entities SYSTEM
"file:../../../Development/dependencies.ent"> %character-entities;
- in project.xml, reference the required entity.
Hope it helps,
-Vincent
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 18 April 2004 19:27
> To: Maven Developers List
> Subject: Re: XML Catalogs
>
> On Sun, 2004-04-18 at 12:23, Niclas Hedhman wrote:
> > On Sunday 18 April 2004 23:39, Jason van Zyl wrote:
> >
> > > You pretty gave no explanation as to why catalogs would be a good
> thing
> > > other than saying:
> >
> > We are trying (@Avalon) the hardest to centralize the versioning of
our
> 70+
> > versioned artifacts, their cross-dependencies and all the external
> > dependencies that are involved.
>
> I believe the fellow who manages development said he has it working,
and
> Vincent with the Jelly work around with properties also works around
the
> problem and I think he's got a lot more projects then 70. There is
also
> the mevenide project where you might get some tips as they use
entities
> as well.
>
> > The
> > http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
> > gave us some ideas, but unfortunately, it doesn't really work, since
ALL
> > external references are relative current directory.
>
> Maybe Vincent or Gilles can forward their usage patterns as I believe
> for them it does work.
>
> > That means that in every directory we would need a complete
"index.ent"
> file
> > listing everything, which seems like a big waste of maintenance
> problems.
> >
> >
> > Catalogs is a mechanism to solve the non-portable SYSTEM
identifiers,
> and map
> > them to the actual locations of those files.
> >
> > I can recommend the Cocoon explaination
> > http://cocoon.apache.org/2.1/userdocs/concepts/catalog.html
> > and the link in that document;
> > http://www.dpawson.co.uk/docbook/catalogs.html
> >
> >
> > Catalogs or Entity Resolution revolves around using either the
PUBLIC or
> > SYSTEM identifiers, look it up in the Catalog and return the file
that
> the
> > catalog is pointing at (relative to the catalog file!!!).
> >
> > This solves our problems.
>
> >
> > If Maven is not interested in this at all, what do you have up your
> sleeve, so
> > that I can have centralized lists of versions used in all the
> subprojects?
>
> Recursive inheritance, transitive dependencies will take care of most
of
> the problems. Vincent has also suggested named dependency sets and a
> more convenient method of declaring a version of a dependency across
> then board then the jar override mechanism.
>
> Some of these features are available in the components already, the
rest
> of the features will be present soon. At any rate nothing will change
in
> the while we're in the motions of releasing 1.0. After 1.0 the
> components can be integrated and builds like Avalon's will be dealt
with
> easily. One of the criterion for the release of the m2 alpha is being
> able to deal with the geronimo build cleanly and easily the main point
> being that POM handling in m2 is something that can be back ported
into
> m1 relatively easily so if the geronimo build is made to work then I
> think Avalon will have a working model from which to copy.
>
> I am also inclined to use as little XML mumbo jumbo like namespaces,
> schema validation, entities and catalogs because it usually requires
the
> use of the 500lb gorilla variety of xml parser. In m2 everything works
> well with the 20k xmlpull parser from the extreme labs at the uni of
> Indiana and I love it and plan to keep it that way.
>
> > Cheers
> > Niclas
> >
> > P.S Time already wasted. ~10 lines of change in MavenUtils.
>
> --
> jvz.
>
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will
come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-04-18 at 12:23, Niclas Hedhman wrote:
> On Sunday 18 April 2004 23:39, Jason van Zyl wrote:
>
> > You pretty gave no explanation as to why catalogs would be a good thing
> > other than saying:
>
> We are trying (@Avalon) the hardest to centralize the versioning of our 70+
> versioned artifacts, their cross-dependencies and all the external
> dependencies that are involved.
I believe the fellow who manages development said he has it working, and
Vincent with the Jelly work around with properties also works around the
problem and I think he's got a lot more projects then 70. There is also
the mevenide project where you might get some tips as they use entities
as well.
> The
> http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
> gave us some ideas, but unfortunately, it doesn't really work, since ALL
> external references are relative current directory.
Maybe Vincent or Gilles can forward their usage patterns as I believe
for them it does work.
> That means that in every directory we would need a complete "index.ent" file
> listing everything, which seems like a big waste of maintenance problems.
>
>
> Catalogs is a mechanism to solve the non-portable SYSTEM identifiers, and map
> them to the actual locations of those files.
>
> I can recommend the Cocoon explaination
> http://cocoon.apache.org/2.1/userdocs/concepts/catalog.html
> and the link in that document;
> http://www.dpawson.co.uk/docbook/catalogs.html
>
>
> Catalogs or Entity Resolution revolves around using either the PUBLIC or
> SYSTEM identifiers, look it up in the Catalog and return the file that the
> catalog is pointing at (relative to the catalog file!!!).
>
> This solves our problems.
>
> If Maven is not interested in this at all, what do you have up your sleeve, so
> that I can have centralized lists of versions used in all the subprojects?
Recursive inheritance, transitive dependencies will take care of most of
the problems. Vincent has also suggested named dependency sets and a
more convenient method of declaring a version of a dependency across
then board then the jar override mechanism.
Some of these features are available in the components already, the rest
of the features will be present soon. At any rate nothing will change in
the while we're in the motions of releasing 1.0. After 1.0 the
components can be integrated and builds like Avalon's will be dealt with
easily. One of the criterion for the release of the m2 alpha is being
able to deal with the geronimo build cleanly and easily the main point
being that POM handling in m2 is something that can be back ported into
m1 relatively easily so if the geronimo build is made to work then I
think Avalon will have a working model from which to copy.
I am also inclined to use as little XML mumbo jumbo like namespaces,
schema validation, entities and catalogs because it usually requires the
use of the 500lb gorilla variety of xml parser. In m2 everything works
well with the 20k xmlpull parser from the extreme labs at the uni of
Indiana and I love it and plan to keep it that way.
> Cheers
> Niclas
>
> P.S Time already wasted. ~10 lines of change in MavenUtils.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 19 April 2004 04:11, Jörg Schaible wrote:
> So my /myproject/build/entities directory contains the project.ent and all
> the files that define the real entities like characters.ent,
> versions.ent, ...
>
> project.ent contains the lines:
> <!ENTITY % character-entities SYSTEM "file:characters.ent">
> %character-entities;
> <!ENTITY % version-entities SYSTEM "file:versions.ent"> %version-entities;
> ...
>
> See, that all references files here are located in the same directory.
> All of my locator.ent files contain just one line(1) like:
>
> <!ENTITY % project-entities SYSTEM "file:../../build/entities/project.ent">
> %project-entities;
This doesn't work for me.
If
index.ent
<!ENTITY % project-entities SYSTEM "file:../../build/entities/project.ent">
%project-entities;
project.ent
<!ENTITY % character-entities SYSTEM "file:characters.ent">
%character-entities;
The characters.ent is resolved against 'current working directory' which is
where index.ent is. Or am I doing something utterly wrong elsewhere?
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Jörg Schaible <jo...@gmx.de>.
Niclas Hedhman wrote:
> On Sunday 18 April 2004 23:39, Jason van Zyl wrote:
>
>> You pretty gave no explanation as to why catalogs would be a good thing
>> other than saying:
>
> We are trying (@Avalon) the hardest to centralize the versioning of our
> 70+ versioned artifacts, their cross-dependencies and all the external
> dependencies that are involved.
>
> The
> http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
> gave us some ideas, but unfortunately, it doesn't really work, since ALL
> external references are relative current directory.
>
> That means that in every directory we would need a complete "index.ent"
> file listing everything, which seems like a big waste of maintenance
> problems.
Ah, no, not really. I should have pointed out that a little better. As
described in section 5.1 in step 1 I have one central project.ent
containing all entities used in my POMs and that is the only file
referencesd in my locator.ent files. That does also *not* mean, that the
project.ent contains the entities itself, but includes other the different
entity files.
So my /myproject/build/entities directory contains the project.ent and all
the files that define the real entities like characters.ent,
versions.ent, ...
project.ent contains the lines:
<!ENTITY % character-entities SYSTEM "file:characters.ent">
%character-entities;
<!ENTITY % version-entities SYSTEM "file:versions.ent"> %version-entities;
...
See, that all references files here are located in the same directory.
All of my locator.ent files contain just one line(1) like:
<!ENTITY % project-entities SYSTEM "file:../../build/entities/project.ent">
%project-entities;
(1) I have a second line, since I use the same technic for entities defining
goals. That are all collected in a goal.ent similar to project.ent
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 18 April 2004 23:39, Jason van Zyl wrote:
> You pretty gave no explanation as to why catalogs would be a good thing
> other than saying:
We are trying (@Avalon) the hardest to centralize the versioning of our 70+
versioned artifacts, their cross-dependencies and all the external
dependencies that are involved.
The
http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
gave us some ideas, but unfortunately, it doesn't really work, since ALL
external references are relative current directory.
That means that in every directory we would need a complete "index.ent" file
listing everything, which seems like a big waste of maintenance problems.
Catalogs is a mechanism to solve the non-portable SYSTEM identifiers, and map
them to the actual locations of those files.
I can recommend the Cocoon explaination
http://cocoon.apache.org/2.1/userdocs/concepts/catalog.html
and the link in that document;
http://www.dpawson.co.uk/docbook/catalogs.html
Catalogs or Entity Resolution revolves around using either the PUBLIC or
SYSTEM identifiers, look it up in the Catalog and return the file that the
catalog is pointing at (relative to the catalog file!!!).
This solves our problems.
If Maven is not interested in this at all, what do you have up your sleeve, so
that I can have centralized lists of versions used in all the subprojects?
Cheers
Niclas
P.S Time already wasted. ~10 lines of change in MavenUtils.
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XML Catalogs
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-04-18 at 10:37, Niclas Hedhman wrote:
> Hi,
>
> Since noone reacted on my quest for XML Catalog support in Maven, I am
> patching Maven myself to handle it.
Probably not the most rational approach. If none of the developers
responded it more likely means none of us are interested, which probably
means we're not to keen on the idea, which most likely means your patch
won't get integrated.
You pretty gave no explanation as to why catalogs would be a good thing
other than saying:
---
I think it could solve a lot of
http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities
---
> I have 2 questions;
>
> 1. I'll submit a patch back to the community, so which branch should I make
> the diff against.
You should probably make an attempt to explain yourself a little more
clearly before potentially wasting your time.
For one, I don't really even know what catalogs are or how they are
used, or how they would be of benefit maven. The other thing is that if
catalog support is something only supported by things like xerces and
not simple parsers like the xpp3 parser then it's definitely not going
to survive into maven2.
Additionally the patch is certainly not going in before the 1.0 release.
> 2. In MavenUtils.getNonJellyProject(), there is a 1), 2) & 3) steps. Would it
> be possible for the 2) step (MavenUtils.createContext() ) to be done first,
> and the 1) second?? Reason is, I want to pick up properties from the
> project.properties and pass it into the parser.
>
>
> Cheers
> Niclas
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org