I'm not so sure. I wonder if we should make any use of pax-url-aether/mvn optional and resolve mvn urls where the artifact is in system ourselves (any use reference: urls here). This is what startup.properties does now.
So.... for any mvn url we: 1. check system and if found use that artifact with a reference: url otherwise: 2. if available, use aether or pax-url-aether to resolve the artifact and either 2.a. use a reference: url to the local file system artifact aether provisions 2.b use the url handler to supply an input stream to the framework. I think putting maven metadata in system would imply we are not using reference urls at all which is a problem for me. I don't think having 2 copies of big jars is a good idea. thanks david jencks On Apr 21, 2011, at 2:49 AM, Guillaume Nodet wrote: > I'm not sure. I think using aether has some benefits, but we need to > make sure that we can actually control what happens. > I guess the real downside is that we need to add maven metadata to the > system folder I think. > > On Wed, Apr 20, 2011 at 22:29, Achim Nierbeck <bcanh...@googlemail.com> wrote: >> oh, I forgot about the minimal one :( >> the standard one is using it. So do you suggest that we revert to the >> standard pax-url-mvn bundle >> to get this snapshot issue resolved? >> >> regards, Achim >> >> >>> Ah, right, aether behaves differently and does not have this notion of >>> default repositories. I think we may want to fix pax-aether in order >>> to support that. I think it's just about having a custom local repo >>> pointing to system and checking if the artifact can be resolved in >>> that one first. >>> >>> Note that the snapshot problem isn't really trivial. If we use >>> pax-aether and the system dir as a local repository, we can't really >>> use it as a 'default' repository, else snapshots won't ever be >>> downloaded again. >>> At the same time, we want people to be able to update snapshots easily >>> (similar to dev:watch but using remote repositories). >>> >>> Where is aether installed ? The startup properties still list the mvn >>> handler and not aether: >>> >>> http://svn.apache.org/repos/asf/karaf/trunk/assemblies/apache-karaf/src/main/filtered-resources/minimal/startup.properties >>> >>> On Wed, Apr 20, 2011 at 18:59, Achim Nierbeck<bcanh...@googlemail.com> >>> wrote: >>>> >>>> maybe we need to ask toni if he changed something on pax-url-aether >>>> that changed this behavior >>>> since with 3.0 we use pax-url-aether instead of pax-url-mvn to resolve >>>> the dependencies. >>>> >>>> regards, achim >>>> >>>> 2011/4/20 Guillaume Nodet<gno...@gmail.com>: >>>>> >>>>> Yes, that would definitely be a problem. >>>>> However, i'm not sure why it happens. The mvn url handler is >>>>> configured with system as a default repository which should override >>>>> any other repository, including the default m2 local repository (and >>>>> obviously any remote repository). I did that a while ago to solve >>>>> this exact problem. >>>>> >>>>> On Wed, Apr 20, 2011 at 18:50, David Jencks<david_jen...@yahoo.com> >>>>> wrote: >>>>>> >>>>>> I discovered that features can pull in snapshots from the apache >>>>>> snapshot repo rather than the ones you carefully installed into system if >>>>>> someone does a deploy of a snapshot between when you assembled the server >>>>>> and started it. >>>>>> >>>>>> I found this behavior very disconcerting and I'm not sure it's what we >>>>>> want. >>>>>> >>>>>> One way to change this and also fix the "we're copying all the bundles >>>>>> into the framework" problem might be to examine each feature bundle and >>>>>> if >>>>>> its in system use a reference: url instead of the supplied mvn url. >>>>>> >>>>>> The situation in more detail: >>>>>> >>>>>> build a snapshot bundle X locally with local modifications. >>>>>> assemble a server X in the system repo and a feature using X in boot >>>>>> features. >>>>>> >>>>>> Someone else deploys a different X snapshot to say apache snapshot repo >>>>>> >>>>>> Start the server you assembled..... the feature starts and >>>>>> pax-url-aether fetches the X from apache snapshot repo instead of the >>>>>> one in >>>>>> system. >>>>>> >>>>>> thoughts? >>>>>> >>>>>> thanks >>>>>> david jencks >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> Open Source SOA >>>>> http://fusesource.com >>>>> >>>>> Connect at CamelOne May 24-26 >>>>> The Open Source Integration Conference >>>>> http://camelone.com/ >>>>> >>> >>> >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > Connect at CamelOne May 24-26 > The Open Source Integration Conference > http://camelone.com/
