On 5/6/09 3:24 PM, Filippo Diotalevi wrote:
On Wed, May 6, 2009 at 1:15 AM, Richard S. Hall wrote:
No problem. I have another fix to commit once SVN is working again.
Had the time to do only some tests
- host and fragment import the same package
- host and fragment import the same v
On Wed, May 6, 2009 at 1:15 AM, Richard S. Hall wrote:
> No problem. I have another fix to commit once SVN is working again.
Had the time to do only some tests
- host and fragment import the same package
- host and fragment import the same versioned package
everything is working well.
--
Filipp
No problem. I have another fix to commit once SVN is working again.
-> richard
On 5/5/09 5:19 PM, Filippo Diotalevi wrote:
On Tue, May 5, 2009 at 6:40 PM, Richard S. Hall wrote:
Filippo,
As it turns out, the use case I was trying to solve for GF also had
overlapping requirements, so I wa
On Tue, May 5, 2009 at 6:40 PM, Richard S. Hall wrote:
> Filippo,
>
> As it turns out, the use case I was trying to solve for GF also had
> overlapping requirements, so I was forced to loosen up conflict
> determination to some degree. I did as I said below, which is to check if
> the requirements
Filippo,
As it turns out, the use case I was trying to solve for GF also had
overlapping requirements, so I was forced to loosen up conflict
determination to some degree. I did as I said below, which is to check
if the requirements are identical, if so I allow it, otherwise it is a
conflict a
On 5/3/09 1:45 PM, Filippo Diotalevi wrote:
If redundant imports (same package, same version range) could be
simply ignored it would be great; but if it's too much work to
implement it now, for me it's not a big problem. The support is
definitely good enough (and specification-compliant, for what
On Sun, May 3, 2009 at 4:51 PM, Richard S. Hall wrote:
> I am not so worried since I know the area we are discussing can be improved
> later. I guess the question we need to answer for now is, is this level of
> support good enough to move forward for now and we can improve it later
> (release ear
On May 3, 2009, at 18:13 , Richard S. Hall wrote:
On 5/3/09 11:58 AM, Marcel Offermans wrote:
So what if there was a bundle that actually exported:
foo;version=1.0.0 and foo;version=2.0.0. One could argue that this
would allow this bundle to be wired to the one above, which needs
version 1 and
On 5/3/09 11:58 AM, Marcel Offermans wrote:
So what if there was a bundle that actually exported:
foo;version=1.0.0 and foo;version=2.0.0. One could argue that this
would allow this bundle to be wired to the one above, which needs
version 1 and 2, both of which are exported by the same bundle.
On May 3, 2009, at 16:45 , Richard S. Hall wrote:
For example, the host could
import foo;version=[1.0.0,1.0.0] and the fragment could import
foo;version=[2.0.0,2.0.0]. This would be impossible to resolve.
Version
is just one attribute, but there could be conflicts with any
attribute.
It pr
Yep, you are correct...see my other response.
Thanks for really looking into this.
I am not so worried since I know the area we are discussing can be
improved later. I guess the question we need to answer for now is, is
this level of support good enough to move forward for now and we can
impr
On 5/3/09 10:35 AM, Filippo Diotalevi wrote:
On Sun, May 3, 2009 at 3:41 PM, Richard S. Hall wrote:
The specification is somewhat vague on what it means for a fragment and host
(or other fragments) to conflict. Initially I have taken a conservative view
of this, so if there is any overlap a
On Sun, May 3, 2009 at 4:35 PM, Filippo Diotalevi
wrote:
> Just noticed that the (infamous, by now ;-) hibernate bundle example
> has the same problem for exports: f.i. the "org.hibernate.cfg" package
> is exported by the host bundle and by 2 fragments. Haven't tested this
> use case yet. Do you t
On Sun, May 3, 2009 at 3:41 PM, Richard S. Hall wrote:
> The specification is somewhat vague on what it means for a fragment and host
> (or other fragments) to conflict. Initially I have taken a conservative view
> of this, so if there is any overlap at all I consider them to be in
> conflict.
>
>
The specification is somewhat vague on what it means for a fragment and
host (or other fragments) to conflict. Initially I have taken a
conservative view of this, so if there is any overlap at all I consider
them to be in conflict.
It would be possible to loosen this up by allowing overlap if
On Sun, May 3, 2009 at 12:39 PM, Filippo Diotalevi
wrote:
> Specification wise, I think these double imports should be specified
Sorry, *should not* !
--
Filippo Diotalevi
On Sun, May 3, 2009 at 3:31 AM, Richard S. Hall wrote:
> [..]
> Please try out some fragments and give feedback.
>
> I will likely need to push a release of this soon, since GF has some
> requirements I need to address with it. So any feedback is welcome.
Hi Richard,
I did a fair amount of test
By the way, this version support Spring SL4J bundles (using fragment
to contribute API implementations).
[ 27] [Active ] [1] SLF4J API (1.5.6)
[ 28] [Resolved ] [1] SLF4J Jakarta Commons Logging Binding
(1.5.6)
[ 29] [Active ] [1] Apache Commons Logging (1.1.1)
Reg
p.s. I have deployed new snapshot of framework and main...
On 5/2/09 9:31 PM, Richard S. Hall wrote:
I recently checked in a first pass at providing support for fragments
to do exports, imports, and requires. (Native libraries are not yet
supported since that requires some work on the bundle ca
Hi,
Richard S. Hall schrieb:
> Just to be clear, you are saying we should check to see if it is an
> extension bundle and allow that case, right?
Yes. Currently the ManifestParser constructor calls the
checkAndNormalizeR4() method, which in turn has the following code to
check Extension Bundles:
Just to be clear, you are saying we should check to see if it is an
extension bundle and allow that case, right?
-> richard
Felix Meschberger wrote:
Hi,
Richard S. Hall schrieb:
Daniel,
I just applied a patch to trunk that makes the fragment install
exception configurable. For details:
Hi,
Richard S. Hall schrieb:
> Daniel,
>
> I just applied a patch to trunk that makes the fragment install
> exception configurable. For details:
>
>https://issues.apache.org/jira/browse/FELIX-725
In fact IMHO the Fragment-Host checks are to generous. Because they also
include Framework Ext
Daniel,
I just applied a patch to trunk that makes the fragment install
exception configurable. For details:
https://issues.apache.org/jira/browse/FELIX-725
I have deployed a new maven snapshot or you can build from trunk if you
want to use it.
-> richard
Daniel Rubio wrote:
I hadn't
I hadn't actually tried to upgrade until now, and since some of the
bundles I was using were libraries (apache tomcat, jasper compiler,etc)
I didn't realize they were fragments until I got this message testing on
1.2!
I believe ignoring fragments in 1.0.4 - or the Fragment-Host directive -
Argh!
Yes, we probably should have made that configurable. Where were you when
I was asking about throwing an exception on fragment install? ;-)
I guess the short answer is "no, there is no way to change it". You have
two options at this point:
1. Roll your own release that disables the e
Stuart McCulloch wrote:
2008/8/18 Alin Dreghiciu <[EMAIL PROTECTED]>
On Sat, Aug 16, 2008 at 6:54 PM, Richard S. Hall <[EMAIL PROTECTED]>
wrote:
Hello everyone,
Currently, we log a WARNING when people install a fragment, which says
that
fragments are not fully supported.
2008/8/18 Alin Dreghiciu <[EMAIL PROTECTED]>
> On Sat, Aug 16, 2008 at 6:54 PM, Richard S. Hall <[EMAIL PROTECTED]>
> wrote:
> > Hello everyone,
> > Currently, we log a WARNING when people install a fragment, which says
> that
> > fragments are not fully supported. We should decide if we want to k
Alin Dreghiciu wrote:
On Sat, Aug 16, 2008 at 6:54 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Hello everyone,
Currently, we log a WARNING when people install a fragment, which says that
fragments are not fully supported. We should decide if we want to keep this
as is or be more specific a
On Sat, Aug 16, 2008 at 6:54 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> Hello everyone,
> Currently, we log a WARNING when people install a fragment, which says that
> fragments are not fully supported. We should decide if we want to keep this
> as is or be more specific and indicate the leve
This sounds like great news Richard - nice one.
I noticed when reading the Spring OSGi page that they had a comment on
Felix not fully supporting fragments as a constraint on their dynamic
modules approach, so hopefully it will help with that too.
-- Rob
Richard S. Hall wrote:
Hello everyo
30 matches
Mail list logo
