Slight nit…. ASF voting policy says “SHOULD” for 72 hr window, not “MUST”,
exactly so that in emergencies such as with log4j a fix can be voted on and
released within hours.
David Jencks
> On Feb 25, 2022, at 7:53 AM, Grzegorz Grzybek wrote:
>
> Hello
>
> I don't have clea
You may find using a DS component with required configuration and configuration
via an annotation considerably simpler.
david jencks
> On Jul 14, 2017, at 11:35 PM, Guillaume Nodet <gno...@apache.org> wrote:
>
> The standard way to obtain the configuration is to registered a
&
+1
david jencks
> On Oct 17, 2016, at 2:33 AM, Grzegorz Grzybek <gr.grzy...@gmail.com> wrote:
>
> Hello
>
> I've created https://issues.apache.org/jira/browse/KARAF-4774 to consider
> deprecation/removal of gemini-blueprint support.
>
> I had this idea after r
this helps…. I’ll try to answer more questions after you’ve taken a look.
david jencks
> On May 12, 2016, at 12:47 AM, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> Sounds interesting. Can you give some pointers to the respective code?
>
> Christian
>
&
into the
generated document. I use it (publicly) for the the felix ds extension
attributes (DSExt annotation in the felix scr-ext-anno project.
david jencks
> On May 12, 2016, at 12:18 AM, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> We currently use java ann
Perhaps no one would be surprised that I think this is a good idea :-)
david jencks
> On Mar 17, 2016, at 9:06 AM, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> I see the issue for blueprint as it is quite heavy weight.
> Scr on the other hand is just one b
the service
type.
thanks
david jencks
> On Jan 11, 2016, at 9:56 AM, b...@petinou.fr wrote:
>
> Thanks David,
>
> I tried that by get an error on karaf startup:
> cannot register Component org.osgi.service.component.ComponentException:
> Component FileReaderFactory val
Well, you need cmpn 6 for the ds 1.3 annotations (in particular @Reference
applicable to a field). I thought this was on maven central but haven’t
looked. If necessary you can get it from the OSGI site.
david jencks
> On Jan 11, 2016, at 12:35 AM, b...@petinou.fr wrote:
>
> Hi
the version of an
exported package.
thanks
david jencks
On May 24, 2014, at 2:35 AM, Achim Nierbeck bcanh...@googlemail.com wrote:
Please find my comments below.
Regards, Achim
sent from mobile device
Am 24.05.2014 00:57 schrieb David Jencks david_jen...@yahoo.com:
Well, your
thought that when the subsystems spec was ready karat would drop its
proprietary features.
thanks
david jencks
On Apr 17, 2014, at 12:56 AM, Guillaume Nodet gno...@apache.org wrote:
Reminder: region is a concept which allows partitioning the OSGi framework
between multiple defined regions
when is this going to be useful rather than misleading? There's no transaction
manager support that i can see.
david jencks
On Feb 13, 2014, at 2:29 PM, jbono...@apache.org wrote:
Updated Branches:
refs/heads/karaf-2.3.x 56239e9cb - c56e9c5ce
[KARAF-2729] Add support of XA datasources
You might want to educate yourself on DS before dismissing it.
david jencks
On Dec 6, 2013, at 2:05 PM, Łukasz Dywicki l...@code-house.org wrote:
Yes Joed,
You got the point I wanted to reflect. DS and SCR is still dependency which,
for sure, may be optional. Switching to poorer
Great idea! I think that scr/ds is better suited to framework service wiring
than blueprint.
thanks
david jencks
On Dec 4, 2013, at 12:48 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
Sounds very interesting. Less is more. I absolutely need to try this :).
Thanks,
Hadrian
On 12/04
The scope of karat features is also much much smaller than subsystems since
karat features don't provide isolation.
david jencks
On Apr 12, 2013, at 9:54 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hi Andrei,
the first plan is to coexist.
It's the same plan for P2 repositories
I think that both the LiCENSE and especially the NOTICE file should not contain
information about software used by (and not contained in) the artifact the
legal files apply to. Especially the NOTICE should be as short as possible to
minimize the requirements on the user to display it.
david
that is not going to happen. Karaf could use
subsystems and drop its proprietary feature concept however.
david jencks
unfortunately almost all non karaf-related projects produce feature files,
therefore we have to take care of it then.
I'm not sure about the proposed artifacts beeing coupled to tight
.
thanks
david jencks
On Aug 27, 2012, at 9:56 AM, Charles Moulliard wrote:
Hi,
I get this error on Apache Github Karaf repo :
git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags
origin karaf-2.3.x:karaf-2.3.x
Pushing to ssh://g...@github.com/apache/karaf
ERROR
+1
I thought of this too for the same reason.
thanks
david jencks
On Jul 30, 2012, at 2:53 PM, Jean-Baptiste Onofré wrote:
Hi all,
I made some tests on a VM without Internet connection this afternoon, using a
local Archiva Maven repo configured in Karaf.
I saw that using Apache
installed, would that be a problem? (or
used dynamic import :- )
david jencks
On Jul 25, 2012, at 8:13 AM, Scott England-Sullivan wrote:
Do you see the capability feature extension being able to handle the case
where say the web console feature s installed and then you add the event
admin
Are you on trunk? I think that's how the karaf assemblies are built there.
thanks
david jencks
On Jun 8, 2012, at 8:48 AM, Romain Gilles wrote:
Hi,
I don't know if this feature already exist, but I think no. I would like to
provision my most used features within my Karaf custom distribution
handler, and I'm not sure anyone else agrees with me.
thanks
david jencks
On Jun 2, 2012, at 2:17 AM, Christian Schneider wrote:
After my rather emotional driven first answer I would like to elaborate a bit
more.
I have put a lot of effort into my implementation of feature reading in the
main
. This is infuriating from the
perspective of wanting to use our own capabilities but I think necessary for a
reasonable release process.
david jencks
On May 23, 2012, at 7:20 AM, Daniel Kulp wrote:
On Wednesday, May 23, 2012 04:04:05 PM Christian Schneider wrote:
I agree. We should redcommend the packaging
require very clear and overwhelming advantages to be
considered.
I've never suggested reading more than one feature during startup. I think the
current approach of generating startup.properties from features specified in
the assembly's pom is just fine.
thanks
david jencks
On May 8, 2012, at 12:01
the
startup code quite a bit.
thanks
david jencks
On May 6, 2012, at 1:28 PM, Christian Schneider wrote:
I did not have the intention to make this more complicated. I just removed
the other options.
So what exactly do you -1?
I already committed the first step of the implementation
-kar features deprecated
-- heavily encourage use of obr.
maven and osgi are really not very compatible and trying to pretend they are
IMO leads to too many problems and suppresses the usefulness of osgi.
thanks
david jencks
On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
Please, keep
david jencks
On Mar 20, 2012, at 10:24 PM, Jean-Baptiste Onofré wrote:
Anyway, as the startup.properties is generated, we don't have the guarantee
that the one that we test is the one that we distribute.
I propose:
1/ don't generate the startup.properties, define it by hand, and use the same
what would be wrong with a flat system repo so
you'd just give the file name and then using mvn urls for stuff that is fetches
through aether and stays in the local maven repo.
thanks
david jencks
On Mar 7, 2012, at 2:48 AM, Jean-Baptiste Onofré wrote:
I was quite surprised with the latest
don't think there's any good reason to keep the maven repo structure
in our kars or to unpack the contents when installing; a jar: url ought to work
fine.
thanks
david jencks
On Mar 6, 2012, at 7:28 AM, Christian Schneider wrote:
I just discussed with JB how a correct config for pax url could look
I've opened
http://forge.ow2.org/tracker/index.php?func=detailaid=316321group_id=23atid=350023
with a patch that uses bnd to create proper osgi metadata so repackaging asm
will be unnecessary. Possibly comments indicating this would be useful would
help the idea gain traction.
thanks
david
I haven't gotten that to work. I tried
-# preceding first license line (entire content included verbatim)
-# on every license header line (it numbered the lines)
/ on every line (entire content included verbatim).
Anything obvious I'm doing wrong or any other ideas?
thanks
david jencks
On Nov
.
I'm not sure what to do about this.
Is there a specification for aether? Or maybe this is an aether bug?
thanks
david jencks
On Jan 15, 2012, at 11:41 PM, Jean-Baptiste Onofré wrote:
Hi David,
even without the prepend (+) in the configuration file (your latest commit),
the issue
I need the karaf activator stuff too. I thought the karaf part was done, but
making sure it works properly and is documented is essential to me.
thanks
david jencks
On Jan 16, 2012, at 7:31 AM, Daniel Kulp wrote:
On Saturday, January 14, 2012 9:19:53 AM David Jencks wrote:
We've been
already, but it's not in an osgi
friendly form yet).
I'm -1 on non-apache locations and I really don't think this fits with openejb
any better than karaf.
thanks
david jencks
On Jan 16, 2012, at 4:29 AM, Christian Schneider wrote:
I would be fine with both options.
Christian
Am 16.01.2012 13
technology, it's more of a
usability extension to existing enterprise functionality.
thanks
david jencks
On Jan 15, 2012, at 1:56 AM, Claus Ibsen wrote:
Hi
At first thought the commands seems cool.
However one part (the SQL execute) they risk introduce a security
vulnerability
with a proper fix.
thanks!
david jencks
handler registration until configuration is present
...
thanks
david jencks
On Jan 14, 2012, at 7:02 AM, Jean-Baptiste Onofré wrote:
Another issue that we have to address is the startup time.
Karaf 2.2.x is very quick to start (something like 5 seconds on my machine),
whereas Karaf 3.0.0
specific features do you need in 3.0 that aren't there right now?
anyway +1 from me.
thanks
david jencks
On Jan 14, 2012, at 9:04 AM, Christian Schneider wrote:
Basically this is a good idea. I am just unsure if we are already at the
point where we should do the branch.
Do we have all features
. On another machine the pax url wrap
bundle does not start similar to what you are seeing (slf4j missing).
Will keep looking...
thanks
david jencks
On Jan 14, 2012, at 10:13 AM, Jean-Baptiste Onofré wrote:
It's what I did:
- git clone mvn clean install -DskipTests on ops4j base, swissbox, url
know the
snapshot publishing policy at ops4j.
david jencks
I'm going to check if the ${karaf.default.repository} is correctly used in
Pax URL localRepository.
I suspect the + (prepend) could be the cause of the problem (I gonna check).
I will give you more information later today
packs stuff into a kar.
I don't yet know if this makes sense... it would result in it being easy to
make installable child instances with properties defined in the pom. Putting
the idea out in case I forget about it :-)
thanks
david jencks
files) by hand but once made
you can include it in a karaf assembly and then it works fine.
thanks!
david jencks
On Jan 11, 2012, at 11:02 PM, Jean-Baptiste Onofré wrote:
Hi David,
What do you think about something like:
karaf@root instance:create geronimo-my
karaf@root instance:connect
but they don't
show up as available with our tab completion. My impression is the Scott's new
ones are slightly more capable.
thanks
david jencks
On Jan 9, 2012, at 1:55 PM, Łukasz Dywicki wrote:
Hey Scott,
Many thanks for providing the patch. Lack of the scr commands was our issue
from ages, thanks
but is less flexible.
Since these proposals change the behavior of the url handler I would like to
discuss them before committing. On the other hand KARAF-910 has been a serious
problem in karaf for a long time so I would like to commit the fixes soon.
Many thanks
david jencks
really avoid it as much
as possible.
BTW the fix for KARAF-910 involves the changes to paxurl attached to KARAF-910
and also making the feature service wait to start for the mvn url handler.
thoughts?
thanks
david jencks
straighten this out.
- The colors of the output on the console are very faint (light gray and light
yellow). I'm not sure how this is configured but would it be possible to make
it darker?
thanks!
david jencks
On Jan 7, 2012, at 3:10 PM, sully6768 wrote:
Hello All,
I have submitted a set
Hi... inline
On Jan 8, 2012, at 10:54 AM, Scott England-Sullivan wrote:
Hi Dave,
My comments are inlined below.
Scott ES
On Jan 8, 2012, at 3:17 AM, David Jencks david_jen...@yahoo.com wrote:
I've modified this a bit to work with trunk and committed the results. This
looks
Is this failure perhaps due to the recent ssl certificate change? I think the
error is in the deploy phase.
thanks
david jencks
On Jan 6, 2012, at 10:36 AM, Apache Jenkins Server wrote:
See https://builds.apache.org/job/Karaf/846/changes
Changes:
[gnodet] [KARAF-1142] Get rid
. The feature
service might need to be modified slightly to work without regions.
david jencks
On Jan 5, 2012, at 6:13 AM, Ioannis Canellos wrote:
Hi all,
After the talk about the size of distributions I started giving a look at
the minimal distribution.
An obvious change is to remove
you need to build with -X and try to find the
well-concealed reason among the megabytes of irrelevant logging.
david jencks
On Jan 5, 2012, at 9:29 AM, Charles Moulliard wrote:
Is it something that we already know ?
[INFO] --- karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor
be
visible if the service they expose isn't available. I think this is a good
idea but I'm open to discussion.
thanks
david jencks
jre.properties, use the karaf-activator approach to spec jars in endorsed, and
recompile anything that expects a stax or jaxb package version. We wont need
to modify jre.properties at all.
thanks
david jencks
Best regards,
Lukasz
Wiadomość napisana przez Guillaume Nodet w dniu 2011-12-27
geronimo capabilities.
thanks
david jencks
give us a fairly manageable way to set
the package versions on the specs.
thanks!
david jencks
On Dec 26, 2011, at 12:09 PM, Christian Schneider wrote:
I am +1 for not exporting the packages by default in the system bundle.
I also have an idea how we could create an environment for people who
be caused by unspecified package versions for spec
packages. People at osgi have talked about figuring out some recommendations
but I don't think anyone has actually worked on it yet.
thanks
david jencks
On Dec 26, 2011, at 7:05 PM, Daniel Kulp wrote:
On Monday, December 26, 2011 8:13:39 PM Guillaume
the problems that will show up.
thanks
david jencks
On Dec 14, 2011, at 10:02 AM, Charles Moulliard wrote:
OpenEJB is involved into the TCK process so KarafEE will inherit it
On Wed, Dec 14, 2011 at 6:26 PM, Guillaume Nodet gno...@gmail.com wrote:
So in order to convince architects
david jencks
On Dec 5, 2011, at 3:04 AM, Guillaume Nodet wrote:
I don't experience any problems with equinox at the moment.
Di you fix those or worked around them ?
On Sat, Dec 3, 2011 at 00:56, David Jencks david_jen...@yahoo.com wrote:
I still don't know what the problem is, but if you start
?) and the others to a
new deployers feature in standard that replaces the kar feature (the kar
deployer was already installed in framework).
Does anyone think we need more granularity in deployers?
With this change I no longer think we need the full kar.
thanks
david jencks
assembly).
This way they are easy to leave out or add in a custom assembly. Whether they
are in any particular custom assembly is less important to me.
thanks!
david jencks
On Dec 5, 2011, at 9:54 PM, Jean-Baptiste Onofré wrote:
Sorry, I mean:
- blueprint, kar, wrap deployers
at least update all the other little blueprint bundles? Maybe
aries needs to rethink the division into bundles and separate the extender
(which isn't likely to change) from the core (which might) so the core can be
updated independently.
thanks
david jencks
On Sun, Dec 4, 2011 at 02:57, David
them.
thanks
david jencks
. If anyone wants to take a look or
has any ideas what might be going on I'd appreciate it.
I commented out the use equinox line of the 3 failing tests but you can try
starting the apache-karaf server under equinox.
thanks
david jencks
FWIW I like it the way it is, I'm very used to unix scripts not having a .sh,
I'd vote -1 also.
thanks
david jencks
On Nov 30, 2011, at 7:07 AM, Daniel Kulp wrote:
I'm more -1 to it. It really is against normal unix conventions to do it.
A user shouldn't need to know if an executable
I don't see any apache license headers in the manual .conf files. I think we
have to fix this ASAP or remove the manual. Does anyone know how to make a
comment in scalate so we can do this?
thanks
david jencks
deployer in with
some spring feature?
Also I think we should put all the spring related features in a spring feature
repo so it's easier to have a spring-free karaf if you want it.
thanks
david jencks
On Nov 28, 2011, at 9:57 PM, Jean-Baptiste Onofré wrote:
Hi David,
yes I saw that. I removed
I tried to fix the pages I modified
thanks
david jencks
On Nov 27, 2011, at 2:55 AM, Glen Mazza wrote:
David (and everyone else), you should be using Maven and Karaf instead of
maven and karaf.
Glen
On 11/26/2011 03:33 PM, djen...@apache.org wrote:
Author: djencks
Date: Sat Nov
suggests to me that having each demo as a kar or feature
would be appropriate.
thanks
david jencks
On Nov 25, 2011, at 3:04 PM, Jamie G. wrote:
Apologies for confusion; under assemblies we have apache-karaf and
apache-karaf-minimal, with an empty directory for apache-karaf-full.
So two
yes, that works:-) thanks.
I noticed that the browser title is Apache Karaf ${pom.version} Guide but I
couldn't find the source that generates this. Maybe the source should be
${project.version} also to get the actual version in the title?
thanks!
david jencks
On Nov 25, 2011, at 11:18 PM
to upgrade to jetty 8? would this be a pax upgrade or karaf
upgrade?
thanks
david jencks
On Nov 24, 2011, at 2:31 PM, Guillaume Nodet wrote:
I think we should start planning a 3.0 release as soon as possible.
I have the following big new features in mind:
* regions (KARAF-1009)
* subshells
the regions jar doesn't let you do this, and
although I think that ability will be needed for subsystems I don't propose to
implement it yet.
Is this something we want in karaf?
thanks
david jencks
rather than adding multiple kitchen sinks full of new features to 2.x. and
never working on getting 3.0 done enough to release. If we can get 3.0 out I
have no problem with people (not including me) then backporting all the
interesting features into 2.x.
thanks
david jencks
On Nov 9, 2011
IIUC -1 as this removes the feature, blueprint, and wrap deployers from the
server. (and possibly other stuff).
david jencks
On Oct 11, 2011, at 7:47 AM, jbono...@apache.org wrote:
Author: jbonofre
Date: Tue Oct 11 14:47:44 2011
New Revision: 1181815
URL: http://svn.apache.org/viewvc?rev
feature I'm
getting? I think this is why people have pretty much universally adopted FQN
for bundle symbolic names, and I think the same reasoning applies here.
BTW, I suggested the longer names when I started running into exactly this
problem between karaf and geronimo features.
thanks
david
by blueprint simultaneously.
Is this intended or is there something wrong in the blueprint configuration,
such as prototype rather than singleton scope? (can't remember the right
terms)
thanks
david jencks
.
I think that being able to trace a feature back to the project it came from
using its name is really valuable.
So I'd concentrate on presentation improvements.
thanks
david jencks
On Oct 12, 2011, at 3:57 PM, Ioannis Canellos wrote:
Though I liked the idea of symbolic-name like features
: If Karaf has any declarative service, they will need
to be changed to work in a manner suggested by this RFC.
karaf doesn't have any, but you've sure piqued my interest :-)
thanks
david jencks
-
Mike Van
Mike Van's Open Source Technologies Blog
--
View this message in context:
http
the config deployer
gets going and installs the mvn url handler config these problems would stop.
Could you describe how you are thinking of solving this problem?
thanks
david jencks
On Oct 5, 2011, at 12:27 AM, Jean-Baptiste Onofré (Commented) (JIRA) wrote:
[
https://issues.apache.org/jira
downloading and installing bizarre versions of jars that I'm beginning to
question its use at all.
do the osgi:update and dev:watch work on anything other than snapshot versions?
thanks
david jencks
On Sep 30, 2011, at 1:18 AM, Guillaume Nodet wrote:
I have a problem with the way the current
On trunk, I've been having severe problems lately with the mvn url handler
downloading ancient snapshots and overwriting my just-built snapshots.
Is this a configuration problem or something dreadfully wrong with the url
handler design (or just a bug)?
thanks
david jencks
confirmation of
this.
thanks
david jencks
On Sep 12, 2011, at 10:43 PM, Andreas Pieber wrote:
Oha... OK, the build is still a problem, but I was fooled by the fact that
the old org.apache.karaf/apache-karaf distribution was renamed to
org.apache.karaf.assemblies/apache-karaf-full... We should
looks good but i still hope we might get 3.0 out before then
thanks
david jencks
On Aug 31, 2011, at 11:34 PM, Jean-Baptiste Onofré wrote:
Hi all,
Due to my mistake, the Karaf board report wasn't due last month but this
month (September).
I updated the board report wiki page
these are redundant but I
can be talked out of this view.
I'm slowly working on updating some of the manual to cover the packagings in
the karaf-maven-plugin and the new mojos.
thanks
david jencks
I keep wondering how standard the spring features are and wonder if they
would be better in a separate spring feature repository. Thoughts?
(I'm thinking trunk only)
thanks
david jencks
that running the build should require manually downloading a
commercial product. If there's some way to make it ok to distribute the manual
can we at least make it so that you need to specify a profile to generate the
pdf?
thanks
david jencks
On Aug 24, 2011, at 11:16 PM, Jean-Baptiste Onofré wrote
far the wicket behavior just seems bizarre to me
but I suppose there must be a good reason. It certainly seems like a big
nuisance to have to write serializable copies of everything.
thanks
david jencks
Kind regards,
Andreas
On Thu, Aug 25, 2011 at 07:27, David Jencks david_jen
Can you explain why you want this? I think serializable objects usually lead
to nothing but trouble.
thanks
david jencks
On Aug 24, 2011, at 9:00 PM, Andreas Pieber wrote:
While it is not required for the karaf-webconsole it would still help if
various simple java bean objects in Karaf
to do anything else.
I can do most of the above with the exception of making sure everything
everyone wants is in the new-style assemblies.
What else is needed?
thanks
david jencks
kind of branch?
thanks
david jencks
Our feature names are quite short (e.g. jndi) and it seems to me this is
likely to cause confusion when features get more widely adopted. Would it make
sense to change them to be more like typical symbolic names, eg.
org.apache.karaf.feature.jndi?
thanks
david jencks
What is it supposed to be? I don't see a proposal or explanation on the dev
list (maybe I missed it)
thanks
david jencks
On Aug 9, 2011, at 9:50 AM, Jean-Baptiste Onofré wrote:
Hi all,
I started Apache Karaf Cave on github today:
https://github.com/jbonofre/karaf-cave
Feel free to ask
descriptions and update them there
too so the packagings can work. The features packaging appears to work ok now,
I haven't tried the kar or assembly packagings.
thanks
david jencks
the
framework already understands entries like !com.sun.xml.bind so maybe for that
property we can just merge everything together into one string.
thanks
david jencks
On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote:
I disagree with that. Jaxb, stax and other libraries provided by the JRE
to modify the effective jre.properties
by installing a .kar file rather than editing it by hand.
thanks
david jencks
On Jul 12, 2011, at 12:33 PM, mikevan wrote:
David,
From my experience, the only time I need to use a negation operator in
jre.properties is if I want to explictly show users
On Jul 12, 2011, at 2:28 PM, Daniel Kulp wrote:
On Tuesday, July 12, 2011 12:41:18 PM David Jencks wrote:
I probably didn't explain my idea very well
I was thinking that the base jre.properties might have
javax.xml.bind
in the jdk6 entry in it to indicate that it's using the jaxb
with osgi.
This does only work with apis that actually use ServiceLoader rather than the
ones that just sort of act like they do
thanks
david jencks
On Jul 12, 2011, at 3:38 PM, Daniel Kulp wrote:
The issue is less the impl version than it is the api version. The API
version is just 2.1
If we do this I think this is how to do it but I'm not at all convinced the
code complexity is worth the possible convenience.
thanks
david jencks
On May 21, 2011, at 12:55 AM, Guillaume Nodet wrote:
Maybe an easier way would be to track features that have been
explicitely installed
Thanks for the clarification :-) These are supported in trunk. I think I'd
call them a feature dependency.
thanks
david jencks
On May 21, 2011, at 12:16 AM, Ioannis Canellos wrote:
Forgive me if I didn't express my self right. By inner feature I mean the
reuse of a top-level feature inside
. If we do support them I think uninstalling them as part of the enclosing
feature is more reasonable than leaving them in place.
thanks
david jencks
On May 20, 2011, at 11:36 PM, Ioannis Canellos wrote:
A week ago I saw a question in the user list regarding uninstalling inner
features.
Our
are in that would make it easier to
import an assembly containing 150 bundles 50 of which you don't use than the
100 you do use.
thanks
david jencks
On May 3, 2011, at 12:22 PM, mikevan wrote:
mikevan wrote:
For folks developing applications to deploy into Karaf on closed networks
AFAICT neither Mike nor your proposal
address.
And, I still don't have any problem with adding such a mega-assembly. I don't
think it will help anyone in a closed environment but it does seem like it
might make all the possibilities easier to discover and play with.
thanks
david jencks
On May 3
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
1 - 100 of 159 matches
Mail list logo
