Please do, time to fix misbehaviors in Pax URL Aether.. On Thu, Feb 2, 2012 at 10:58 PM, Bengt Rodehav <[email protected]> wrote:
> I have been experimenting with the config.properties regarding this before > but I remember having problems preventing the normal maven way of > resolving. I'll take a look at this again. > > /Bengt > > 2012/2/2 Toni Menzel <[email protected]> > > > On Thu, Feb 2, 2012 at 10:03 PM, Bengt Rodehav <[email protected]> > wrote: > > > > > Yes, of course there are uses for "online" mode. I hope noone believes > > that > > > I want to remove that possibility. It can even be the default as long > as > > > there are ways to "lock down" Karaf. It's both a matter of "security" > > > (don't use unknown or untested code in production) and of "convenience" > > > (verify in development that the installation includes everything > needed). > > > > > > @Toni > > > > > > >What you also can do is using a local, shipped with karaf maven > > repository > > > >and set that as the only one (already possible) > > > > > > I wasn't aware of this. Can you enlighten me about how this is done? > > > > > > > Well, you can always set the repositories in Pax URL via System-, Bundle > > and/or directly inside the URL. Not really sure what the standards do > look > > like in Karaf, but i bet its set in a config properties file. There you'd > > set repositories to some local, relative folder. > > Of cause, some initial routine needs to create/unpack that repository (it > > will look like you .m2/repositories e.g.) initially. > > Or you ship that in the standard karaf.zip. > > > > Hope that is clear? > > > > > > > > > > /Bengt > > > > > > 2012/2/2 Toni Menzel <[email protected]> > > > > > > > On Thu, Feb 2, 2012 at 8:28 PM, Christian Schneider < > > > > [email protected] > > > > > wrote: > > > > > > > > > I also think the offline feature is really important. At talend for > > > > > example we want > > > > > to make sure our distribution works when offline so this setting > > could > > > > > also be useful for tests. > > > > > > > > > > On the other hand I would not really say that downloading artifacts > > on > > > > > demand would never happen in production. > > > > > I can very well imagine deploying a very small container and then > > > > > downloading libs and custom applications from > > > > > a company maven repo. Of course this is different from downloading > > from > > > > > the internet but from the karaf point of view it > > > > > is not an offline mode. > > > > > > > > > > > > > correct! > > > > And when you think about cloud deployment, or at least a clustered > > setup, > > > > you'd be thankful for one central source. All karaf instances > > > (technically > > > > "naked" would take their artifacts from there. > > > > If you want it more sophisticated (e.g. a push approach), you'd use > > > Apache > > > > ACE perhaps (inside Karaf). In the long run i could see some kind of > > > deeper > > > > integration of the two projects for initial provisioning (say, Karaf > > has > > > > just the bare bone container and bootstrapping stuff, everything else > > > comes > > > > from an ACE Repository. > > > > Just an idea so far.. > > > > > > > > > > > > > > > > > > Christian > > > > > > > > > > Am 02.02.2012 19:24, schrieb Bengt Rodehav: > > > > > > > > > > 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<[email protected]> > > > > >> > > > > >> 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<[email protected] > > > > > > >>> 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é< > > > [email protected] > > > > >>>> 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é > > > > >>>>> [email protected] > > > > >>>>> http://blog.nanthrax.net > > > > >>>>> Talend - http://www.talend.com > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> -- > > > > >>>> Toni Menzel Source<http://tonimenzel.com> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>> -- > > > > >>> Toni Menzel Source<http://tonimenzel.com> > > > > >>> > > > > >>> > > > > > > > > > > -- > > > > > > > > > > Christian Schneider > > > > > http://www.liquid-reality.de > > > > > > > > > > Open Source Architect > > > > > Talend Application Integration Division http://www.talend.com > > > > > > > > > > > > > > > > > > > > > > -- > > > > Toni Menzel Source <http://tonimenzel.com> > > > > > > > > > > > > > > > -- > > Toni Menzel Source <http://tonimenzel.com> > > > -- Toni Menzel Source <http://tonimenzel.com>
