This is the same old debate about scope versus configuration.
Check out Xavier Hanin's blog, specifically the comments.
http://jroller.com/page/xavierhanin?entry=maven_features_comparison
I agree with you, somewhat. The ability to override a dependency in M2 is
far more verbose. In contrast, Ivy forces you configure your desired
classpath, where M2 has pre-defined scopes, and I don't want to lose that
pre-defined power. But l also like the concept of configurations,
specifically for cases like Spring. I would like to see something like
custom configurations, perhaps ID'd inclusions? In any case, most anything
useful would require a POM change, which I wouldn't imagine would happen
soon.
Spring framework could define dependency blocks with ID.
<dependency>
<groupId>*javax.faces*</groupId>
<artifactId>jsf-api</artifactId>
<includedAs>jsf</includedAs>
</dependency>
Then users of Spring framework may include them:
<dependency>
<groupId>*org.springframework*</groupId>
<artifactId>spring-webflow</artifactId>
<include>default,jsf</include>
</dependency>
Eric
On 4/30/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote:
I am curious how heavy Maven2 users are getting around the lack of
custom scopes.
Profiles seem to fill the need sometimes, allowing you to produce a
module (jar file) that is specific to a particular profile, having
dependencies specific to that profile.
This assumes you are actually ok with having a separate jar file for
each profile.
But how are people handling the publishing of _one_ module which in use
may have various sets of runtime dependencies which need to be combined,
for the user of that module?
As an example, consider Spring Web Flow, published as
spring-webflow.jar. It has a set of base runtime dependencies which are
always needed. It also has some runtime dependencies that are needed
only for use with Spring MVC. It also has some runtime dependencies
which are needed only for use with Struts. And some only for JSF.
Compile time dependencies are mostly a combination of all of these, btw.
This is pretty trivial to handle with the Ivy dependency manager (used
for Spring Web Flow right now), since for a module's published
dependencies, Ivy allows you to define different 'configurations',
basically custom scopes. So a module can publish any number of
configurations, and another module depending on yours would specify any
of them they need. The config declaration for Spring Web Flow looks like
this:
<configurations>
<conf name="default" extends="mvc" />
<conf name="global" visibility="private" />
<conf name="buildtime" visibility="private" />
<conf name="test" visibility="private" />
<!-- public webflow configurations other projects may use -->
<conf name="mvc" visibility="public" extends="global"/>
<conf name="portlet" visibility="public" extends="mvc"/>
<conf name="struts" visibility="public" extends="global"/>
<conf name="jsf" visibility="public" extends="global"/>
</configurations>
This just declares the configuration names and visibility, then actual
dependencies are declared and added into one or more configs.
A project needing Spring Web Flow including the JSF capabilities would
declare that dependency as
<dependency org="springframework" name="spring-webflow"
rev="latest.integration" conf="global->default,jsf"/>
basically it is saying, for it's own 'global' config, it needs Spring
Web Flow's 'default' and 'jsf' configs.
How are people handling this kind of need in Maven. I am not happy with
the options I see:
- use profiles: this implies publishing a separate jar for each
profile, not something I wish to do
- declare minimal dependencies and force people to manually include:
this implies that a module like spring web flow would declare only the
minimal sets of dependencies, and then users of the module would
manually add in other dependencies. This seems unacceptable.
- declare all possible dependencies and force people to manually
exclude: this implies a module like Spring Web Flow would declare all
dependencies, and then users of the module would manually exclude some
dependencies. This seems unacceptable.
There are lots of projects out there which have optional dependencies
(hibernate, etc.). Short of manual inclusions/exclusions, how are people
handling this in Maven2?
Regards,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
