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
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 wrote:
> oh, I forgot about the mi
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 wo
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 wrote:
> I don't think t
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 sys
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
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
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
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 :
> Yes, that would definitely be a problem.
> However, i'm not sure why
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
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
11 matches
Mail list logo
