Colin Sampaleanu wrote:
Well you may be making the distinction between scopes and profiles, but for some cases it seems to me to be a rather arbitrary difference, and Ivy's configurations at least can to a decent extent be used for both.
I'm not sure about that - I think we've got both scope and profiles pretty well nailed down and its clear which does which. Profiles go beyond just dependencies. Maven, last time I checked, did a few more things than dependency management ;)
Well, examples is probably the best I can contribute here, more than answers :-). I'm actually looking for the latter, or at least trying to arrive at some sort of best-practice answers.
Absolutely, we've got the same aims. Thanks for taking the time to talk it through - its given me a few extra points to help us get it resolved in our next design conference.
But aside from these, I guess the question is how you handle/declare optional dependencies. Take Spring Framework for exmaple, near and dear to my heart.
It's a good example.
So it would be nice for the dependency sytem to allow the library creator (us, the Spring developers in this case) to come up with certain standard configs or dependency declarations that people can use as-is, but is it even realistic to think this can be done, given the actual complex dependency requirements?
As far as I can tell, absolutely. This is the reason that Maven keeps demanding separate projects to build different artifacts. The code only appears once, and then you can repackage it into all those other JARs, with a POM that represents exactly what that particular JAR depends on.
For something like spring-hibernate.jar for example, in the Ivy case (not even thinking about Maven), about all I can think of doing is exposing a config which pulls in all the optional Hibernate dependencies, and then people can (easily) exclude stuff they know they don't actually need, and another one which pulls in only Hibernate and any other deps which will always be needed, and then people using that can add stuff they know they actually need.
This is the only viable choice. The user can only select the dependency at the granularity you've given them (ie, spring-hibernate + all the hibernate dependencies you've used in there, whether they use them or not). Then, they can filter out the ones they don't want. We're discussing a way to do this in the Maven POM right now because to be realistic, it will happen - but the ideal is that you can just as easilly split your functionality along the same lines (spring-hibernate-core, spring-hibernate-jta as well as an aggregated spring-hibernate) but this starts getting impossible at the 3rd or 4th level of depedency too.
Anyway, its good that spring is thinking about it in these terms rather than lumping it all together as the only way which seems to be popular elsewhere. Its great to have that as a distribution channel, but its nice to have a choice. For the end project, it is easiest for them manage their project the less they have to depend on - but that doesn't mean fewer dependant jars, but more concise ones if you get my drift (and I have indeed drifted there).
In the Maven case, where there is no idea (last I checked) of user-defined scopes, I wouldn't know how to offer even this level of control.
No, its not necessarily about definable scopes. I'm looking at explicit blocking of certain dependencies and their dependencies. We have a dependency management section that should be used for that.
- Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
