2017-02-01 16:57 GMT+01:00 Łukasz Dywicki <[email protected]>: > Main reason is consistency of dependency resolution process. Also if > you declare dependencies in POM for assembly projects then it's group > id/artifact id gets resolved before plugin execution.
I sense some fundamental problem in the above assumption. If you use version ranges in your POM (like "[1.0, 1.1)") then what "gets resolved" is something from withing the range (according to maven understanding of ranges), So in your local repository you'll get some metadata (from the moment of resolution) and some artifact (best fit from metadata). When (even in same JVM process) Karaf feature resolution is performed and you have a *copy* of Maven range into feature range, then existing (previously resolved) metadata+artifact don't mean anything - because according to some update policy, metadata may be tried to be fetched again. Or even there may be newer artifact falling into the range available remotely. > This feeds local > repository with these artifacts before karaf jumps in making it handy > for offline development. > Discrepancy between OSGi and Maven range is one thing, but we just can't rely on previously resolved artifacts to satisfy another "version range" → "version" resolution (org.eclipse.aether.impl.VersionRangeResolver) without remote access... > > If you rely just on plugin itself it will always require access to > remote repositories since pax-url is not using resolver available in > maven. I might be wrong on that but that was my observation so far. > No it doesn't - Aether constructs it's own org.eclipse.aether.RepositorySystem and configures it using DI. My suggestion is - add your own org.code_house.maven.osgi.resolver.compatible.CompatibleOsgiVersionRangeResolver to pax-url and modify org.ops4j.pax.url.mvn.internal.AetherBasedResolver#newRepositorySystem() method to set it as configured org.eclipse.aether.impl.VersionRangeResolver *when some new property is configured* in org.ops4j.pax.url.mvn PID. I wouldn't change default behavior. regards Grzegorz Grzybek > > Anyhow if maven part doesn't fit anywhere I can keep it on github for > now and see how it will evolve. > > Best regards, > Lukasz > > 2017-02-01 15:05 GMT+01:00 Guillaume Nodet <[email protected]>: > > Why do we need to change maven's behavior ? > > The karaf-maven-plugin does not really use maven when downloading things > > other than the maven dependencies, it always use pax-url-aether to do the > > downloads. > > > > 2017-02-01 14:49 GMT+01:00 Łukasz Dywicki <[email protected]>: > > > >> It is fine for me too, but we still need this piece of code embeddable > >> in maven build as maven core extension. That's why I didn't opt for > >> pax in first place. > >> > >> Cheers, > >> Lukasz > >> > >> 2017-02-01 14:32 GMT+01:00 Christian Schneider <[email protected] > >: > >> > I also think we should better just change on the pax url level. > Someone > >> else > >> > using the AetherBasedResolver might expect the default behaviour. > >> > > >> > Christian > >> > > >> > > >> > On 01.02.2017 14:28, Guillaume Nodet wrote: > >> >> > >> >> Right. Not sure it's worth it, but why not. > >> >> I still think the best location for the osgi-compatible version > resolver > >> >> is > >> >> in pax-url-aether, as it's really the only place it will be used > afaik, > >> >> but > >> >> again, it's no big deal. > >> >> > >> >> 2017-02-01 14:14 GMT+01:00 Łukasz Dywicki <[email protected]>: > >> >> > >> >>> What I was thinking about was something like that: > >> >>> AetherBasedResolver.class.getResources("META-INF/pax- > >> >>> customization.properties") > >> >>> then just parsing it and pushing into ServiceLocator instance > created > >> >>> by MavenRepositorySystemUtil. We can do that because > >> >>> DefaultServiceLocator implementation is mutable as Grzegorz pointed > >> >>> out. Since we will be in internal package getResources should behave > >> >>> properly in both cases. > >> >>> > >> >>> Cheers, > >> >>> Lukasz > >> >>> > >> > > >> > -- > >> > Christian Schneider > >> > http://www.liquid-reality.de > >> > > >> > Open Source Architect > >> > http://www.talend.com > >> > > >> > > > > > > > > -- > > ------------------------ > > Guillaume Nodet >
