On Sun, 30 Apr 2006, Alexandre Poitras wrote: [crossposted to dev: proposal near end]
First of all, Maven provides an <optional> flag per dependency. Users of a project declaring those dependencies will need to add any optional dependencies that they might need themselves. I agree, it's a little bit more verbose than just specifying a 'USE' flag or some ivy configuration. However, since not everybody will need all dependencies for Spring Web Flow, and since it would require end users to resort to these kinds of complex configuration, it seems to me that that project is not organized correctly. The project should be split up into more modules, where you have one for the core project, requiring all or most of the non-optional dependencies, and for each optional part (like the struts-example) a separate dependency that will no longer have optional dependencies since you explicitly requested to use it. This is more conforming to component oriented programming. I know that some/most of you probably disagree with me on the above, but Maven is not just a build tool. It's not as flexible as Ant in some ways, since it not only takes a lot of work out of your hands, but it also tries to enforce some philosophies regarding how build should look. However, these usecases are important to us. But it's not always the case that Maven should be changed to support ALL ideas out there. If that were the case, we should've simply kept using Ant. Btw, what about this idea: what if that project declaring optional dependencies (like spring web flow) grouped them in profiles? You'd get for instance a 'struts' profile that added the optional dependencies for struts. We could add a <profiles><profile/>*</profiles> field to the <dependency> tag, and when Maven fetches that pom's dependencies it would take the profiles into account. I believe that this comes very, very close to both the issue mentioned below and to Ivy's way of doing things. Btw, there's also a way doing this without changing the pom format: just use profiles.xml or define the profiles in the pom itself, activated. The problem with this approach is that profile id's are not globally unique, but should, in this case, be dependency unique. Plus, it could be much more verbose. We might alter the treatment of profile Id's to include a groupId:artifactId prefix so that it matches a profile defined in a particular POM. -- Kenney > http://jira.codehaus.org/browse/MNG-935 > > On 4/30/06, Eric Redmond <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
