karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [DISCUSS] Change in the lib directory
Date Thu, 19 Feb 2015 11:00:56 GMT
Though it's a very minor fix in pax-exam to add support lib/boot jars.
Given this folder does not even exists in previous versions of karaf,
there's even no need to add an if statement around.  I have a local fix for
it and it seems to work.

2015-02-19 11:41 GMT+01:00 Guillaume Nodet <gnodet@apache.org>:

> I've experimented a bit and one of the main problem is that ... pax-exam
> karaf container breaks.
> It would have to be adapted and released before we can actually do the
> change in karaf.
>
> 2015-02-19 11:21 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com>:
>
>> Hi Guillaume,
>>
>> sounds reasonable, but I think we had a Jira Issue for that.
>> And if I remember correctly it had been tried to fix but somehow got
>> rolled
>> back.
>> So we should check that issue to understand the difficulties we had with
>> it.
>>
>> regards, Achim
>>
>>
>> 2015-02-19 11:08 GMT+01:00 Guillaume Nodet <gnodet@apache.org>:
>>
>> > 2015-02-19 11:01 GMT+01:00 Fabian Lange <fabian.lange@codecentric.de>:
>> >
>> > > Hi Guillaume,
>> > >
>> > > as somebody who put stuff to lib, I discovered that karaf* magic
>> myself.
>> > >
>> > > I think lib/system is more explicit. But then I would prefer if all
>> > > jars there are added to the JVM classpath, not only karaf*.
>> > >
>> >
>> > Yes, definitely, sorry to not have been more clear, but that was
>> definitely
>> > the idea.  So instead of having special karaf* jars, it would simply
>> load
>> > all jars in lib/system.
>> >
>> >
>> > >
>> > > Also worth noting: I have not found a nice way to include the JVM
>> > > tools.jar (pre Java 9) onto the classpath without patching the
>> > > karaf.sh. Not sure if this is a karaf use-case and it could be simpler
>> > > (tools.jar is tricky and actually going away with 9)
>> > >
>> >
>> > I'm sure we can find a solution, but it seems to me that there are
>> still a
>> > lot
>> > of stuff that is missing or bound to change in Java 9 ...
>> >
>> >
>> > >
>> > > Fabian
>> > >
>> > > On Thu, Feb 19, 2015 at 9:38 AM, Guillaume Nodet <gnodet@gmail.com>
>> > wrote:
>> > > > I'm thinking about slightly changing the way the lib folder is
>> > organised
>> > > in
>> > > > Karaf 4.
>> > > > With all previous versions, the lib folder can contains jar with 2
>> > > > different set of jars:
>> > > >   - karaf*.jar will be loaded when the JVM is started (they are
>> > appended
>> > > to
>> > > > the class path of the java command)
>> > > >   - other jars are loaded by the Main class along with the osgi
>> > framework
>> > > > jar
>> > > >
>> > > > The convention that jars named karaf*.jar are loaded and available
>> to
>> > the
>> > > > Main class (for example for jdbc lock access) is not really explicit
>> > > enough
>> > > > imho.
>> > > >
>> > > > I wonder if it would make sense to set up a separate lib/system
>> > directory
>> > > > which would contain those karaf*.jar files (thus avoiding the need
>> to
>> > > > rename them).
>> > > > We could keep the lib/ folder for jars that will be loaded by the
>> Main
>> > > > class, or even move them to a separate directory such as lib/app,
>> but
>> > I'm
>> > > > not really sure it brings anything.
>> > > >
>> > > > Thoughts ?
>> > > >
>> > > > Guillaume
>> > > >
>> > > > --
>> > > > ------------------------
>> > > > Guillaume Nodet
>> > > > ------------------------
>> > > > Red Hat, Open Source Integration
>> > > >
>> > > > Email: gnodet@redhat.com
>> > > > Web: http://fusesource.com
>> > > > Blog: http://gnodet.blogspot.com/
>> > >
>> >
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message