This approach is reasonable to some point, but it can start getting
ridiculous too. It's a question of granularity and how far you wish to
take it. There are a number of projects out there which have a lot of
optional dependencies. Spring Web Flow aside, Spring Framework itself is
one of them, Hibernate another, etc, and there are cases where we talk
about multiple optional dependencies that may optionally be combined
with each other, leading to an explosion of jars.
Your suggested approach implies that library jar packaging be completely
driven by dependencies used, i.e. have a one to one correlation; this is
just not possible, or really desirable sometimes.
Colin
On 4/30/2006 12:03 PM, Arik Kfir wrote:
Personally, I don't like the approach you specified. If I have a project
which MIGHT use project X, Y or Z, I would expect that project to be
split
to four jars: project-core, project-x, project-y and project-z. The
project-core would require a set of dependencies that are always
needed, the
project-x would require project-core (and its dependencies) along with
the X
dependency, and so on...
I think the maven approach is far more elegant because you always know
exactly what you have and what you need.
just my 2 cents....
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]
--
______________________________________
Cheers,
Arik Kfir [EMAIL PROTECTED]
Linux user, number 415067 - http://counter.li.org/
http://corleon.dnsalias.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
