-----Original Message-----
From: Emmanuel Venisse [mailto:evenisse@;ifrance.com]
Sent: Tuesday, November 12, 2002 2:16 PM
To: Turbine Maven Users List
Subject: Rep:RE: Ear plugin - how can I set dependency
Hi,
You can use a j2ee project with all your dependencies, and you create
child projects that extend of j2ee project.
j2ee project :
<project>
...
<dependencies>
<!-- j2ee dependencies -->
...
</dependencies>
...
</project>
child projects:
<project>
<extend>j2eeProject.xml</extend>
...
<dependencies>
<!-- Your dependencies -->
...
</dependencies>
</project>
Emmanuel
-----Message d'origine-----
I don't think that's exactly the same.
I am afraid that you can't inherit from many projects for example.
I imagine that you can have other "packs" of libraries e.g.
- Struts
- Company commons
- Logging frameworks (e.g. jakarta-commons logging +log4j)
which you want to integrate in you project.
If you want to manage this kind of dependencies through inheritance this
will be painful and much harder too maintain
My idea is that is better to think rather about logical dependency not a
physical one.
I suppose that some kind of meaningful meta-data describing each dependency
is needed.
And I am adding: it might be nice to have possibility of grouping
dependencies.
In Nathan's solution used grouping of artifacts will be possible
if they are stored in the same folder in repository. This is already fine.
But why not to enable a grouping which is crosscutting many folders in
repository?
More flexible it will be - more powerful it will become.
E.g. there could be a folder which is keeping data like licenses, dtds,
images etc.
and you want use some those artifacts in you project (for example to deploy
it with you application).
Other example describing this idea me might have:
repository
\servletapi
\jars
\dtds
\struts
jars
tlds
and now you can create shortcut:
struts-webapp
which is using servletapi-2.3 + struts-1.1beta2
Note also that in directory "servletapi"
there can be jars and dtds for version 2.2, 2.3, 2.4.
Already grouping on the level in my opinion requires more powerful mechanism
than this which Nathan has described
(e.g. because it will be hard to name every resource using pattern
${name}.${version}.${ext})
But already if this what he proposed was implemented it would be already
much better that now!
Michal
--
To unsubscribe, e-mail: <mailto:turbine-maven-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:turbine-maven-user-help@;jakarta.apache.org>
