I don't have much experience with the reference: url, so I'm not really sure of the drawbacks. What happens if the file is deleted and overwritten because aether downloaded a new snapshot instead of the one that was installed ?
On Wed, Apr 20, 2011 at 22:45, David Jencks <[email protected]> wrote: > I don't think that's a good idea. > > No one has addressed my other concern that directly using mvn: urls for stuff > in system means all feature bundles get copied info the framework. > > I would like to consider installing bundles in system using reference: urls > rather than mvn urls, even if the bundle is specified with a mvn url in a > feature descriptor. > > I'd also consider optionally using reference:urls for files that aether has > downloaded into a local maven repo, which would further reduce copying but > might introduce other problems. On the other hand it might solve the > BundleWatcher problem that currently requires pax-url-aether to be embedded > in shell.dev. > > thanks > david jencks > > > On Apr 20, 2011, at 1:29 PM, Achim Nierbeck 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<[email protected]> >>> 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<[email protected]>: >>>>> 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<[email protected]> >>>>> 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/
