On Jun 15, 2014, at 11:01 AM, Hervé BOUTEMY <[email protected]> wrote:
> Le dimanche 15 juin 2014 09:19:26 Jason van Zyl a écrit : >> On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY <[email protected]> wrote: >>> Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit : >>>>> yes, but how is the constraint expressed and coded? >>>> >>>> Trying to encode these in such a way where you effectively have a >>>> property >>>> graph is hard. Aether has some preliminary support for this but not >>>> really. >>>> In practice to date it's really constrain the version or constrain what >>>> you >>>> are resolving against. >>>> >>>> Either explicit with your version as a concrete version if you want to >>>> resolve against the wild. Or you use ranges and the constraint is encoded >>>> as the list of repositories you are going to resolve against. >>> >>> for the moment, yes, the constraint has to be encoded as the list of >>> repositories you resolve against: if we make this practice clear, things >>> will get much clearer until we find another strategy (I don't have one >>> for the moment) >>> >>>> Given that we have a de facto formalism through our code, specifically in >>>> Aether, that I would gravitate toward using a formalized resolution model >>>> like what OSGi. I'm certainly not a huge proponent of OSGi, but they have >>>> a >>>> completely formalized and specified resolution algorithm. >>> >>> I really didn't find any formalisation of resolution algorithm, either in >>> Aether of OSGi: once a list of version have been found that match the >>> constraint, I still don't see/know what is the chosen one >>> >>> Can you point me to the right direction, please? >> >> You need to download the spec: http://www.osgi.org/Specifications/HomePage >> >> There is a section on versions. > ok, I found the answer: > > "3.8 Resolving Process > ... > An exporter with a higher version is preferred over an exporter with a lower > version" > > then maximum version (compatible with version range) is used: we should be > able to say simply that > > and IIUC: > - nobody finds that any other choice is better in any case > - nobody finds that it looks like LATEST, which was removed because it was > told > not reproducible > There was a proposal for pre-releases (like SNAPSHOTs but was rejected). Honestly I don't think they are needed. At Eclipse we do just fine without them. There are a steam of releases and we pick one that works. More akin to continuous delivery. To further complicate matters you can have an explicit target platform which essentially enumerates your entire runtime and that's what you can resolve against. So you can have ranges in your dependency specification but your target platform is going to have specific versions available for use and it is a logical constraint. This is a little like having a dependencyManagement section if it enumerated the transitive hull and locked down the versions but in Maven's case (without some enforcement) if a dependency was not listed but requested Maven would carry on, where if a bundle was requested and not available in the target platform the resolver would blow up. Unless you're using Tycho without a target platform and then it works more like Maven. It's rather complicated in Tycho as we've tried to make Maven and OSGi cooperate which is like mixing oil and water as Igor would say. > Now I understand how using version ranges is not really compatible with using > SNAPSHOTs: SNAPSHOT is the way to handle limited change when not using ranges > But if you choose to use ranges, you have this de-facto LATEST handling that > makes SNAPSHOTs more a problem than anything It's just how we use "SNAPSHOT". In a Tycho build we use -SNAPSHOT in the Maven POMs and .qualifier in the bundle manifests, but all the bundles and metadata get expanded for deployment. So if you look at the m2e-egit extra manfiest: https://github.com/tesla/m2eclipse-egit/blob/master/org.sonatype.m2e.egit/META-INF/MANIFEST.MF#L5 You will see .qualifier in the version and this gets expanded to a build qualifier which generally contains the UTC date stamp. Now if you look in a deployed version at: http://repository.takari.io:8081/nexus/content/sites/m2e.extras/m2eclipse-egit/0.14.0/N/0.14.0.201405280011/ And you open the artifacts.jar and look at artifact.xml you will see that there is no trace of the .qualifier. So the resolver is not dealing with the literal ".qualifier" it's just dealing with numerics. Really I think this is where we will get insofar deploying artifacts and metadata with expanded qualifiers. I think our discussion on Wednesday will include having build-time vs consumption-time POMs. The consumption-time POM can have most of the build information stripped out and we can likely have it be fully expanded. I'll post something on Monday so people can prepare for Wednesday. > > For the moment, I continue to like SNAPSHOTs + preferred versions :) It works in many cases and for 10 years ago it was better than anything else. The fatal flaw with snapshots (which would not be hard to fix) is that each build in a reactor for the same build gets a different timestamp which makes it impossible to version what really belongs together as a set. Would be easy enough to fix using the maven.build.timestamp consistently instead of new Date() everytime the metadata generator is called. At any rate I will eventually push for something like .qualifier and fully interpolate the consumption-time POMs. But we will also have to have discussions about compile-time vs runtime. We have a weird conflation between the two but Maven is primarily a build time specification and systems like OSGi are runtime specification. It would be useful to account for both of those in Maven eventually. > But I start to see all the implications of using ranges: this is a whole > other > organization > > > Regards, > > Hervé > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- Simplex sigillum veri. (Simplicity is the seal of truth.)
