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. This feeds local repository with these artifacts before karaf jumps in making it handy for offline development.
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. 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
