Use OBR if available to compute the transitive closure of karaf features
Key: FELIX-2402
URL: https://issues.apache.org/jira/browse/FELIX-2402
Project: Felix
Issue
Hi,
The gogo-parent module is not declared in the gogo reactor pom file, despite it
is used (declared as parent) by others gogo modules. Any reason for that ?
Regards,
Clement
I guess it doesn't really matter given the reactor pom file isn't really
used at all ...
On Thu, Jun 10, 2010 at 09:43, Clement Escoffier
clement.escoff...@gmail.com wrote:
Hi,
The gogo-parent module is not declared in the gogo reactor pom file,
despite it is used (declared as parent) by
Hi Folks,
The JBossOSGi Framework now sucessfully integrates the Felix Resolver.
The code for the resolver integration is here
http://github.com/jbosgi/jbosgi-framework/tree/master/resolver/src/main/java/org/jboss/osgi/framework/resolver
By design, this module does not have a dependency on
Dependency manager does not build correctly on Windows
--
Key: FELIX-2403
URL: https://issues.apache.org/jira/browse/FELIX-2403
Project: Felix
Issue Type: Bug
Components:
[
https://issues.apache.org/jira/browse/FELIX-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Demande closed FELIX-2358.
-
Just tested the modification and it works nicely.
That really stabilizes drop-in deployment and
I needed to factor out the reactor pom in a hurry (as previously,
there was only a parent in place of the reactor). Didn't pay much
attention to the reactor but only to the parent for now. Feel free to
fix it :-)
regards,
Karl
On Thu, Jun 10, 2010 at 9:43 AM, Clement Escoffier
[
https://issues.apache.org/jira/browse/FELIX-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12877376#action_12877376
]
Pierre De Rop commented on FELIX-2403:
--
I will look into this issue, because it seems
On Thu, Jun 10, 2010 at 9:57 AM, Thomas Diesler
thomas.dies...@jboss.com wrote:
Hi Folks,
The JBossOSGi Framework now sucessfully integrates the Felix Resolver.
Cool :-)
The code for the resolver integration is here
Done
Regards,
Clement
On 10.06.2010, at 10:29, Karl Pauls wrote:
I needed to factor out the reactor pom in a hurry (as previously,
there was only a parent in place of the reactor). Didn't pay much
attention to the reactor but only to the parent for now. Feel free to
fix it :-)
regards,
Hi Karl,
I like the way you hide the bundleprotectiondomain
There are various other changes like this. Also the Module has changed
from immutable to mutable (i.e. it now has some setters). A possible way
forward would be to provide abstract classes for the interfaces (as I
did) and only
[
https://issues.apache.org/jira/browse/FELIX-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-2381.
Resolution: Fixed
URL: http://svn.apache.org/viewvc?rev=953260view=rev
The default log
[
https://issues.apache.org/jira/browse/FELIX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned FELIX-2360:
--
Assignee: Guillaume Nodet (was: Gert Vanthienen)
Error message from bin/karaf script
[
https://issues.apache.org/jira/browse/FELIX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-2360.
Resolution: Fixed
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M
[
https://issues.apache.org/jira/browse/FELIX-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-2101.
Assignee: Guillaume Nodet
Fix Version/s: karaf-1.6.2
Resolution: Fixed
On 6/9/10 16:49, David Jencks wrote:
The DEPENDENCIES file is completely optional as far as apache policy is
concerned. I wrote the maven code that generates these with the intention of
giving users hints about the other software that would likely be needed to
actually use the artifact
On 6/9/10 17:11, Justin Edelson wrote:
Hmmm. When I looked at the framework DEPENDENCIES file, there was a
reference to codehaus, but I didn't think the framework depends upon
codehaus libraries, just some Maven plugin.
I think it was the RAT plugin, but this has since moved to Apache, right?
On 6/10/10 8:54 AM, Richard S. Hall wrote:
On 6/9/10 17:11, Justin Edelson wrote:
Hmmm. When I looked at the framework DEPENDENCIES file, there was a
reference to codehaus, but I didn't think the framework depends upon
codehaus libraries, just some Maven plugin.
I think it was the RAT
On 6/10/10 3:57, Thomas Diesler wrote:
Hi Folks,
The JBossOSGi Framework now sucessfully integrates the Felix Resolver.
The code for the resolver integration is here
http://github.com/jbosgi/jbosgi-framework/tree/master/resolver/src/main/java/org/jboss/osgi/framework/resolver
By design, this
On 6/10/10 9:03, Justin Edelson wrote:
On 6/10/10 8:54 AM, Richard S. Hall wrote:
On 6/9/10 17:11, Justin Edelson wrote:
Hmmm. When I looked at the framework DEPENDENCIES file, there was a
reference to codehaus, but I didn't think the framework depends upon
codehaus libraries, just
I think we should keep the amount of legal files to the bare minimum, i.e.
make sure the LICENSE and NOTICE files are correct wrt the ASF ways of doing
things. Anything else is not mandatory and imho, should be removed, unless
generated, to avoid the extra work of maintaining those files for no
On 6/10/10 9:47, Guillaume Nodet wrote:
I think we should keep the amount of legal files to the bare minimum, i.e.
make sure the LICENSE and NOTICE files are correct wrt the ASF ways of doing
things. Anything else is not mandatory and imho, should be removed, unless
generated, to avoid the
On 6/10/10 10:45, Guillaume Nodet wrote:
On the DEPENDENCIES, i guess we should first discuss what we want this file
to be used for exactly. acknowledgments about the software the subproject
uses is a bit vague. Is that at runtime ? compile time ? build-time
(including maven, plugins and
Following from the feedback on the project description, the follow
updated description appears to have gained consensus:
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
It sounds good to me. Including bundlerepository is good idea too.
Regards
JB
On 06/09/2010 06:15 PM, Guillaume Nodet wrote:
I'd like to release webconsole and karaf later this week or next week.
If there is any issue with that (or anything that would like to be included
in those releases),
Sorry for my inclusion of bo...@a.o in this message, I only meant to
document the message at d...@f.a.o...if you respond to this message,
please don't cross post to bo...@a.o...
Again, sorry for the confusion...
- richard
On 6/10/10 12:58, Richard S. Hall wrote:
Following from the feedback
Hi,
While I'm not against releasing bundle repository, but I think it
needs to fix FELIX-2306 [1] before it does so. This is a serious
regression from 1.4, and means I can't even think of picking up any
1.6 based version of bundle repository. This is a problem for me since
I want to pick up the
+1
regards,
Karl
On Mon, Jun 7, 2010 at 6:42 PM, Karl Pauls karlpa...@gmail.com wrote:
I would like to call a new vote on the following subproject releases:
gogo 0.6.0
gogo.runtime 0.6.0
gogo.shell 0.6.0
gogo.command 0.6.0
framework 3.0.0
framework.security 1.2.0
main 3.0.0
Time to call the vote on the Felix framework 3.0.0 and Gogo 0.6.0
subproject releases.
* +1 votes from Richard S. Hall, Felix Meschberger, Derek Baum, Chris
Custine, Rob Walker, Gert Vanthienen, Pierre De Rop, Jean-Baptiste
Onofre, Guillaume Nodet, Clement Escoffier, Carsten Ziegeler, and Karl
Do you think you could create a patch for this issue?
On Thursday, June 10, 2010, Alasdair Nottingham n...@apache.org wrote:
Hi,
While I'm not against releasing bundle repository, but I think it
needs to fix FELIX-2306 [1] before it does so. This is a serious
regression from 1.4, and means I
Btw, you don't really need that for Aries Application if that's what you had
in mind. The new API is much more powerful and will allow the aries
application obr resolver to work in a much nicer way without the need to
create resources yourself at all. Just look at the
Not sure whether you are using a fixed version of the framework or not
but just in case, I'm planning to cut a 3.0.1 release in a couple of
days to get the one issue fixed we got in today (obviously, if you can
test it and find other stuff you need fixed, now would be the time for
that too).
On 6/10/10 15:43, Guillaume Nodet wrote:
Do you think you could create a patch for this issue?
If not, I don't think we need to hold up a release...release early and
often, right?
- richard
On Thursday, June 10, 2010, Alasdair Nottinghamn...@apache.org wrote:
Hi,
While I'm not
33 matches
Mail list logo
