You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by David Jencks <da...@yahoo.com> on 2011/04/20 18:50:55 UTC
features can prefer remote snapshots over ones in system (at least in trunk)
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
Re: features can prefer remote snapshots over ones in system (at least in trunk)
Posted by David Jencks <da...@yahoo.com>.
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 <bc...@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<bc...@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<gn...@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<da...@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/
Re: features can prefer remote snapshots over ones in system (at
least in trunk)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bc...@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<bc...@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<gn...@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<da...@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/
Re: features can prefer remote snapshots over ones in system (at least in trunk)
Posted by David Jencks <da...@yahoo.com>.
On Apr 20, 2011, at 2:25 PM, Guillaume Nodet wrote:
> 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 ?
That would certainly be something to look into. I think aether-downloaded files will all be timestamped and not overwritten, so the bigger risk is if you are locally rebuilding a snapshot. Possibly only using reference urls for snapshots where you also set up a bundlewatcher would work?
I haven't tried this yet either.... although I have run karaf off the local maven repo from inside a maven build, which seems to work fine.
thanks
david jencks
>
> On Wed, Apr 20, 2011 at 22:45, David Jencks <da...@yahoo.com> 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<bc...@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<gn...@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<da...@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/
Re: features can prefer remote snapshots over ones in system (at
least in trunk)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <da...@yahoo.com> 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<bc...@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<gn...@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<da...@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/
Re: features can prefer remote snapshots over ones in system (at
least in trunk)
Posted by Achim Nierbeck <bc...@googlemail.com>.
HI David,
comments inline
regards, achim
> I don't think that's a good idea.
>
just thinking :)
> 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.
>
sounds quite reasonable I think this is quite a good solution
> 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.
>
I think this is worth to be tested, but never the less
if we have an issue with pax-url-aether we need to open an issue at
ops4j or fix it by ourselves, probably both :)
> 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<bc...@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<gn...@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<da...@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/
>>>>>
>>>
Re: features can prefer remote snapshots over ones in system (at least in trunk)
Posted by David Jencks <da...@yahoo.com>.
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<bc...@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<gn...@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<da...@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/
>>>>
>>
>>
>
Re: features can prefer remote snapshots over ones in system (at
least in trunk)
Posted by Achim Nierbeck <bc...@googlemail.com>.
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<bc...@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<gn...@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<da...@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/
>>>
>
>
Re: features can prefer remote snapshots over ones in system (at
least in trunk)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bc...@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 <gn...@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 <da...@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/
Re: features can prefer remote snapshots over ones in system (at
least in trunk)
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <gn...@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 <da...@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/
>
Re: features can prefer remote snapshots over ones in system (at
least in trunk)
Posted by Guillaume Nodet <gn...@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 <da...@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/