2008/8/13 Oleg Gusakov <[EMAIL PROTECTED]>: > Mark - this is the same if one excludes repositories and lives within > pre-existing version set: like Maven having only local repo and OSGi having > one OBR file. > > If we add a variable - repositories that constantly change, then we start > wondering what to do and OSGi joins this discussion as soon as they add this > feature.
I'm not quite sure that I understand the scenario you're describing here? Aren't the repositories defined with the pom and so are constant? > I agree, and it's also too demanding an approach; it requires users to know > a lot of details. In my opinion - build system should be more transparent > and less intrusive. > >> For example, say I need to fix a bug in Project A 3.0 that depends on >> Project B 2.0, amongst many other dependencies. I take A 3.0 and >> determine that the bug is in B 2.0, so I want to update the dependency >> of B in A to 2.1-SNAPSHOT. Assuming that this range was initially >> declared as B[2.0,3.0), using the repository approach I would just >> enable snapshot repositories for the range to resolve to my new >> work-in-progress B 2.1-SNAPSHOT. This works, but it would also open >> the gates for all other ranged dependencies to resolve to snapshots >> too, which I certainly don't want. Whereas if ranges behaved as I've >> described, then we would just update B to [2.0,2.1-SNAPSHOT) during >> development and then reinstate [2.0,3.0) once the fixed B 2.1 has been >> released. > > Why not using 2.1-SNAPSHOT directly? Including it into the range is messier > solution if you ask me. In both cases you have to change the pom, so there > is not distinct advantage in either . Sure, that's an option too. I was keeping the lower bound so that it wasn't temporarily lost when moving to a snapshot, but then I guess that requiring a snapshot also means that you're moving the lower bound anyway. So yes, 2.1-SNAPSHOT would be better :) > BTW - thanks for the references! No worries, shout if you need any more info. I delved into using version ranges with Maven a while ago but unfortunately I found too many issues to realistically be able to use them. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
