James, 'type' isn't being used for anything.....
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
"James Strachan"
<james_strachan@ya To: "Turbine Maven Developers List"
hoo.co.uk> <[EMAIL PROTECTED]>
cc:
05/24/02 04:38 AM Subject: extending the notion of
dependencies...
Please respond to
"Turbine Maven
Developers List"
There's 2 things I'm musing about to enhance the power of the Maven
dependency notion.
A) add a dependency 'category / kind / group'. (I would have used the term
'type' but its already taken in the XML syntax). e.g.
<dependency>
<name>xercesImpl</name>
<category>test</category>
<type>required</type>
<version>2.0.0</version>
<jar>xercesImpl-2.0.0.jar</jar>
</dependency>
This allows dependencies other than of category 'compile'.
e.g. I may require xercesImpl for running the unit tests, but not
compiling.
Indeed I might not want certain implementations of APIs on the classpath
when I compile but need them when I unit test (e.g. JDBC and
implementations
etc.)
Also this could be useful for documentation, if a documentation target
depends on certain fop/batik malarkey, it'd be nice for folks who just want
to build the code rather than the website to not have to download
unnecessary stuff. Even if stuff does get downloaded to the lib.repo it'd
be
nice to not automatically put this stuff on the compile classpath at least.
The way this could work is that by default all dependencies are of category
'compile'. Then any other dependency could be downloaded into the
repository
but not put on the compile classpath; this would allow folks to refer to
them via ${lib.repo}/foo.jar if they wished, letting Maven do the
auto-downloading.
Later on down the line we could enhance this capability by, say, providing
a
common ant call to create a 'test' classpath, ready for running unit tests;
or the existing 'test' target could automatically look for any extra 'test'
dependencies as well as 'compile' dependencies.
B) Adding a new 'project' dependency.
e.g. imagine if we added this to the project.xml
<dependentProjects>
<dependentProject>../project.xml</dependentProject>
</dependentProjects>
I've a real use case for this in Jelly where I want each optional tag
library to be a seperate project in its own right, but to inherit all the
dependencies from the core project. I don't want to have to cut and paste
the core projects dependencies into each new sub project. Then all that
happens is the dependent projects get expanded and added to the projects
list of dependencies. I guess this idea might be close to the reactor
stuff,
though I've never grokked that yet so can't really say for sure.
Thoughts? I'd be happy to provide patches for either/both of these
depending
on if folks think its the way to go or not. Certainly A) seems a fairly
minor thing; B) might be a bit more tricky depending on reactor.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
