You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by David Zeleznik <dz...@ilog.com> on 2003/12/26 19:48:06 UTC
PomTag fails if project.xml references a DTD
Hi,
I am about to submit a bug report on Jira, but I wanted to post details to
the list first. We make extensive use of the PomTag (ie. m:pom) in our jelly
scripts and plugins to be able to share dependencies and other project
properties beyond the single inheritance of <extends>. To further refactor
our project definitions, we tried to use XML entities in some common DTD's
to define such things as developer info, etc. However, it seems that in rc1
the PomTag fails to parse a project.xml that references a DTD.
I have attached an extremely simple test case. Just unzip and try "maven
clean". The error I get is:
[echo] Reading other project...
File...... file:/.. ...../PomTagDTDTest/
Element... m:pom
Line...... 8
Column.... 63
error getting project
BUILD SUCCESSFUL
Total time: 6 seconds
If I comment out the DOCTYPE/DTD reference in otherProject.xml, everything
proceeds fine. I am wondering if this should be considered a bug (it
certainly seems to be one to me)?
--------------------------------------
David Zeleznik
Principal Architect
ILOG - Changing the rules of business
mailto:dzeleznik@ilog.com
http://www.ilog.com
--------------------------------------
RE: PomTag fails if project.xml references a DTD
Posted by David Zeleznik <dz...@ilog.com>.
> I have to wonder whether inheritance is really a better way to go over
> composition of the project definition. OOP went down the path of
> inheritance for a long time, but it is now generally recognised that you
> can get yourself into a horrible horrible mess with deep inheritance
> hierarchies. Witness component driven design which typically uses
> composition to acquire behaviour. I am not suggesting that having
> project "fragments" would be a good idea, just that it might be an idea.
Needless to say, I completely agree ;-) Although supporting more than 1
level of pom inheritance sounds like a good idea, I am not convinced that it
really helps solve some of the more complex use cases. We already use
jelly-driven pom composition quite a bit throughout our build framework so
that we can share common declarations and definitions and ease our
maintainence load. I previously mentioned how our demo projects
automatically append the dependencies of their parent library/app project.
Each of our projects also has an optional project-tests.xml and
project-benches.xml pom. These poms contain additional dependencies and
other info needed to specifically run our unit tests and benchmarks,
respectively. Admittedly, some of this behavior could now be implemented
using user-defined properties that can now be assigned to dependencies. But,
adding this info back into the main project.xml and attaching special flag
properties means that we would have to override almost all of the standard
goals to ignore dependencies that are only relevant for testing and running
benchmarks. With our current implementation, it is actually much simpler
because we only have to override the test goals so that they parse the
additional pom and extract the info needed.
We have not really experimented with the OASIS XMLCatalog capability that is
now built into Ant. I am not an expert, but it sounds like it might be a
"freebie" feature that comes with the xml-commons and only needs to be
exposed somehow to the user. Maybe providing support for xmlcatalogs within
Maven would be a first step towards defining sharable libraries of XML pom
fragments.
> Just a thought for the new year.
Just my thoughts for the new year as well... :-)
--------------------------------------
David Zeleznik
Principal Architect
ILOG - Changing the rules of business
mailto:dzeleznik@ilog.com
http://www.ilog.com
--------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: PomTag fails if project.xml references a DTD
Posted by Ben Walding <be...@walding.com>.
Jason van Zyl wrote:
>On Fri, 2003-12-26 at 13:48, David Zeleznik wrote:
>
>
>>Hi,
>>
>>I am about to submit a bug report on Jira, but I wanted to post details to
>>the list first. We make extensive use of the PomTag (ie. m:pom) in our jelly
>>scripts and plugins to be able to share dependencies and other project
>>properties beyond the single inheritance of <extends>.
>>
>>
>
>Just out of curiosity how many levels of inheritance do you use? You
>probably don't watch the commits but in the maven-project component I
>have arbitrary levels of inheritance working. This component will be
>used be integrated in Maven soon.
>
>
>
I have to wonder whether inheritance is really a better way to go over
composition of the project definition. OOP went down the path of
inheritance for a long time, but it is now generally recognised that you
can get yourself into a horrible horrible mess with deep inheritance
hierarchies. Witness component driven design which typically uses
composition to acquire behaviour. I am not suggesting that having
project "fragments" would be a good idea, just that it might be an idea.
Just a thought for the new year.
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: PomTag fails if project.xml references a DTD
Posted by David Zeleznik <dz...@ilog.com>.
Hi Jason,
> Just out of curiosity how many levels of inheritance do you use?
We currently have 3 levels in our hierarchy => 2 levels of inheritance. In
addition, we have the cross-cutting aspects of trying to factor out and
share common definitions, such as developer info and 3rd party library
dependency definitions. I will try to describe a little bit about our build
architecture, keeping in mind that we started with beta7 so we may be still
using legacy techniques due to sheer inertia.
At the top level, we have "template" projects, one for each project type.
Our broad categories here are libraries, demos/samples, desktop apps,
web-apps, and deliverable products. The differences are not so much the
template project.xml's but the maven.xml's that define unique pre/postgoals
for each template type. All of the templates share some common properties by
using jelly:util to explicitly read in a shared properties file. Each of our
maven projects then extends the appropriate template project. The final
level is our demo/example projects which are mini-apps nested within the
directory structure of the relevant library or application project.
Typically, we have a large number of these (20+) demos for each higher
level project. Each demo has a logical dependency on the library project it
belongs to, and therefore to the library's dependencies as well. However,
demo projects extend the demo template and do not explicitly reference the
library project to which they belong. Therefore, to make maintainence of our
demos (which are by far the most numerous) easier, the template maven.xml
for demo projects has a bunch of jelly that reads the parent library's pom
and adds its dependencies to its own and also appends the classpath.
> You
> probably don't watch the commits but in the maven-project component I
> have arbitrary levels of inheritance working. This component will be
> used be integrated in Maven soon.
Is this related to the transitive inheritance capabilities that have been
mentioned on this list before? Is this something planned for v1.0 or after?
To be quite honest, I am not sure that direct pom inheritance would really
be applicable in our case. Our demo projects are quite different in
structure, properties, goals, etc. from the library they pertain to.
Therefore, a demo project does not pass the classic "is a" test for
inheritance. We just want to be able to auto-magically add the library
project's dependencies and classpath to the demo project. The maven:pom tag
works fine for us and allows us to selectively decide which attributes of
the Project we want to merge.
Our use of XML entity definitions was our recent attempt to solve a
cross-cutting refactorization of developer info, etc. We have approx 250
individual maven projects and growing fast. When a developer's id or email
address changes, we want to be able to change it easily across all projects
she is involved in. Similarly, all of our projects need to be built against
identical versions of third party libraries. For example, we really need to
have a shared common dependency definition for JAXP or Servlet apis that all
projects can reference. When we decide to migrate our products to a new
version, we would like to be able to change the definition in one place.
Admittedly, we can do this with properties:
<developer>
<name>${davidzeleznik.name}</name>
<id>${davidzeleznik.id}</id>
<email>${davidzeleznik.email}</email>
<organization>${davidzeleznik.org}</organization>
<timezone>${davidzeleznik.tz}</timezone>
<roles>
<role>Developer</role>
</roles>
</developer>
But, it is alot easier to be able to define a complete XML entity:
<!ENTITY DavidZeleznik "
<name>David Zeleznik</name>
<id>zeleznik</id>
<email>dzeleznik@ilog.com</email>
<organization>ILOG</organization>
<timezone>-5</timezone>
">
<developer>
&DavidZeleznik;
<roles>
<role>Developer</role>
</roles>
</developer>
Writing this response has got me thinking that both problems, selectively
sharing attributes between demo and parent projects and shared lib/developer
definitions, could be solved by some type of database of XML fragments that
could be included into the poms. I am not sure if the OASIS XMLCatalog
facility provides this kind of capability. Unfortunately, I am not a real
XML guru. However, whatever the implementation, I am thinking that it is
something that could be layered on top of Maven as we know it today, not
built into the Maven core. Anyway, just brainstorming here...
> > To further refactor
> > our project definitions, we tried to use XML entities in some
> common DTD's
> > to define such things as developer info, etc. However, it seems
> that in rc1
> > the PomTag fails to parse a project.xml that references a DTD.
> If it worked prior to rc1 and now it doesn't then I think that would
> count as a bug.
I have no idea if this worked prior to rc1. We tried to add DTD references
as an experiment during the last few days and we have been using rc1 already
now for 2 months or so. I have filed MAVEN-1088 on this.
--------------------------------------
David Zeleznik
Principal Architect
ILOG - Changing the rules of business
mailto:dzeleznik@ilog.com
http://www.ilog.com
--------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: PomTag fails if project.xml references a DTD
Posted by Jason van Zyl <jv...@maven.org>.
On Fri, 2003-12-26 at 13:48, David Zeleznik wrote:
> Hi,
>
> I am about to submit a bug report on Jira, but I wanted to post details to
> the list first. We make extensive use of the PomTag (ie. m:pom) in our jelly
> scripts and plugins to be able to share dependencies and other project
> properties beyond the single inheritance of <extends>.
Just out of curiosity how many levels of inheritance do you use? You
probably don't watch the commits but in the maven-project component I
have arbitrary levels of inheritance working. This component will be
used be integrated in Maven soon.
> To further refactor
> our project definitions, we tried to use XML entities in some common DTD's
> to define such things as developer info, etc. However, it seems that in rc1
> the PomTag fails to parse a project.xml that references a DTD.
>
> I have attached an extremely simple test case. Just unzip and try "maven
> clean". The error I get is:
>
> [echo] Reading other project...
> File...... file:/.. ...../PomTagDTDTest/
> Element... m:pom
> Line...... 8
> Column.... 63
> error getting project
> BUILD SUCCESSFUL
> Total time: 6 seconds
>
> If I comment out the DOCTYPE/DTD reference in otherProject.xml, everything
> proceeds fine. I am wondering if this should be considered a bug (it
> certainly seems to be one to me)?
If it worked prior to rc1 and now it doesn't then I think that would
count as a bug.
> --------------------------------------
> David Zeleznik
> Principal Architect
> ILOG - Changing the rules of business
> mailto:dzeleznik@ilog.com
> http://www.ilog.com
> --------------------------------------
>
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: PomTag fails if project.xml references a DTD
Posted by David Zeleznik <dz...@ilog.com>.
> i have tried your test case because im experimenting similar issues with
> entity references (relative paths not resolved in a multiproject
> context). if i modify slighty your test case it doesnot fail anymore.
> the trick is to pass the absolute path to the maven pom tag. in
> your case :
>
> <m:pom projectDescriptor='${basedir}/otherProject.xml' var='otherPom'/>
Thanks Gilles, that does seem to work and I attached your comment to the bug
report I filed. However, I am still stymied because in our real workspace
the projects are at different levels within the directory hierarchy. In
project.xml, the relative reference to the location of the DTD seems always
to be evaluated against the basedir of the currently *executing* project,
not the location of the project.xml that contains the reference. Therefore
if I have:
/templates/entities.dtd
/projectA
/foo/bar/projectB
And projectB's pom references the dtd as:
<!DOCTYPE project SYSTEM "file:../../entities.dtd">
Then, I can run maven against projectB fine from its own root directory.
However, if projectA uses the m:pom tag to read in projectB's pom, I will
get an error because the location of the DTD is now evaluated with respect
to projectA's basedir.
So for now, XML entities is not a practical solution for us. Maybe the OASIS
XMLCatalog facility that now exists in Ant would provide a first-step
solution if it were to be incorporated into Maven.
--------------------------------------
David Zeleznik
Principal Architect
ILOG - Changing the rules of business
mailto:dzeleznik@ilog.com
http://www.ilog.com
--------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: PomTag fails if project.xml references a DTD
Posted by Gilles Dodinet <rh...@free.fr>.
David Zeleznik wrote:
>I have attached an extremely simple test case. Just unzip and try "maven
>clean". The error I get is:
>
i have tried your test case because im experimenting similar issues with
entity references (relative paths not resolved in a multiproject
context). if i modify slighty your test case it doesnot fail anymore.
the trick is to pass the absolute path to the maven pom tag. in your case :
<m:pom projectDescriptor='${basedir}/otherProject.xml' var='otherPom'/>
my:test:
[echo] Reading other project...
[echo] otherPom.id = other-project:other-project
[echo] Finished reading other project...
hope it helps.
-- gd
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org