Hi Bengt,
no I mean in any version since 2.2.0: if you remove all repositories in
etc/org.ops4j.pax.url.mvn.cfg, you will be in offline mode (it means
that Karaf will use only artifacts present in the system repo).
Regards
JB
On 02/03/2012 09:44 AM, Bengt Rodehav wrote:
Thanks I appreciate it.
When you say it's already available I guess you mean on trunk - right? I
think the problems I've had was on version 2.2.0 (I haven't tested since).
At that time I don't think removing all repositories helped. There were
still some default search that was not disabled (possibly to Central). Has
this behaviour changed on trunk?
/Bengt
2012/2/3 Jean-Baptiste Onofré<j...@nanthrax.net>
Hi Bengt,
basically, the "offline" mode is already possible, you just have to remove
all repositories in the etc/org.ops4j.pax.url.mvn.cfg.
However, I will add a special option in pax-url for that.
Regards
JB
On 02/02/2012 07:24 PM, Bengt Rodehav wrote:
Link URL looks interesting although I would regard them as a complement to
direct maven resolving.
I'v always considered the maven support in Karaf as a very useful feature.
Especially during development since Karaf will pick up my newly built
artifacts directly from my local maven repository. I'm sure it is also
useful for populating the bundle cache directly from the Internet although
I would never use that feature in production (I create a custom
distribution containing everything I need instead).
What I'm trying to say is that I don't want to take away the maven support
since it's really useful (in development) but I would like to be able to
control it (in production) so that:
*Priority 1*: I can stop maven from downloading anything from the Internet
("offline" mode). This I think must be mandatory for any production system
- how else do you know what code you are running?
*Priority 2*: I can restrict maven to only use artifacts contained in my
custom distribution (mainly the system folder). This would stop maven from
accessing my local maven repo. This would make it easier to verify that my
custom distribution contains everything before moving to production.
/Bengt
2012/2/2 Toni Menzel<t...@okidokiteam.com>
FYI, with "making the link URL handler more clever" i mean probably
encoding the Maven coordinates (GAV) into the link url somehow (by
convention), so that it allows to fallback to some other handler (aether
e.g.) when the link cannot be resolved. Not sure yet. Maybe you guys have
an idea?
On Thu, Feb 2, 2012 at 6:33 PM, Toni Menzel<t...@okidokiteam.com>
wrote:
One thing you can do is using "link" URLs.
This is implemented in the pax-url-link project and resolves URLs like:
link:classpath:META-INF/links/**junit.link to an InputStream that
contains
text with first line treated as the real URL.
So, for example, if you include a file with content:
mvn:org.junit/junit/4.8.2
in Classpath at location /META-INF/links/junit.link, you will get the
maven resolution.
But you also could have another runtime dependency resolving the
aforementioned link in class path like:
classpath:junit.jar
which then would use an embedded jar.
You see this brings in some indirection into the resolving process.
In Karaf i could think of shipping a "batteries-included" artifact that
includes many frequently used components, another (maybe an
enterprise.jar)
that contains another set of embedded batteries.
Good thing is, you never lose the ability to possibly fall back to mvn
resolvers taking down the artifact from outer space (online maven).
Did you consider this, yet?
Toni
On Thu, Feb 2, 2012 at 10:04 AM, Jean-Baptiste Onofré<j...@nanthrax.net
wrote:
Hi all,
On Karaf trunk (3.0), we currently from an issue around artifact
resolution (due to pax-url/aether).
It's something that David, Achim and I are aware, but I would like to
warn and inform everyone (to avoid unpredictable behaviors ;)).
1/ SNAPSHOT resolution
Currently, the system repo doesn't contain Maven metadata, sha1, Maven
properties files. So, Aether always downloads the SNAPSHOT from Central
and
overrides the file locally in system repo.
For instance, if you change the Karaf features file locally in the
build,
the generated distribution will embed the updated file, but this file
will
be overrided (when you perform feature:list or feature:list-url) by the
one
on snapshot remote repo.
A "simple" workaround is to deploy the feature file (mvn deploy), but
it's really ugly.
2/ Karaf bootstrap time
A side effect is that Karaf 3.0 is really long to start and bootstrap,
because Karaf checkes for update for each bundles/artifacts in system
repo.
I evaluated that Karaf 3 takes 10 more times than Karaf 2 to start
(depending of the network connection).
I consider it as a major issue, and I'm focusing on it (on both Karaf
and
Pax URL).
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Toni Menzel Source<http://tonimenzel.com>
--
Toni Menzel Source<http://tonimenzel.com>
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
