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>[EMAIL PROTECTED]</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:[EMAIL PROTECTED]
http://www.ilog.com
--------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
