> -----Original Message-----
> From: James Strachan [mailto:[EMAIL PROTECTED]]
> Sent: 23 May 2002 19:38
> To: Turbine Maven Developers List
> Subject: extending the notion of dependencies...
>
> 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>
>
+1. I think there are also other elements that would be interesting :
- A notion of "installed" jars (same as the pkgdir of Gump), i.e. jars
that do not need to be downloaded. In my case, the jars are in our CVS
somewhere (we're building a product and we want to control our external
jars). By default a jar is downloadable but this can be overridden.
- A notion of location. By default, the jar is found in lib.repo. If a
location is specified it is looked for in that directory. Jars that have
a location are not downloaded.
The 2 notions can be combined. Specifying a location can mean that the
jar is an installed jar that should not be downloaded but can be found
in the said directory.
What is my motivation for this ? It is because subprojects can depend
upon jars produced by other subprojects but the 2 subprojects can form a
single project. In other word a given subproject does not perform
releases. Only the project does. This is very frequent when you're
working on a product project where you divide the work by defining
several subprojects. It is of course less true when you work on
framework which is what most of us are doing when working on Jakarta
projects. But when it comes to using Maven on customer projects, it is
really necessary I think.
In the same spirit, there could be another notion :
- A notion of project reference, i.e. this jar is produced by that
project which is located there and which you start this way (hum this
looks more and more like Gump :-)). Then when you build the project and
Maven finds the jar is missing it can start the build for the dependent
project.
I guess this is more than a cosmetic change and would need to be clearly
thought out. I seem to remember Jason had some idea on the subject (is
that the Reactor ?).
I'd like to know if it is the direction being followed by Maven ?
> 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>
>
+1
> 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:turbine-maven-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:turbine-maven-dev-
> [EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
