Some random thoughts in random order...
- At some level the problem is similar to the
Bundle-RequiredExecutionEnvironment problem. There are certain core
framework implementation features that a bundle might need (e.g.,
fragments, buddy loading, ...) and the services that are required.
- Not
On Feb 8, 2008 6:20 AM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
> We've been suffering from this "framework tainting" for quite sometime
> now. Equinox ships many bundles/services that work on other frameworks
> (as well as ones that work without OSGi at all!). The Equinox community
> (well at lea
On Feb 6, 2008 5:58 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> Stuart McCulloch wrote:
> > also the subproject documentation that is there is (imho) not visible enough
> > ( have to click Documentation->...um...->Subproject Documentation->aha... )
> >
> > perhaps we could add a direct link to
We've been suffering from this "framework tainting" for quite sometime
now. Equinox ships many bundles/services that work on other frameworks
(as well as ones that work without OSGi at all!). The Equinox community
(well at least me) would like to participate in figuring out a way to
depict or
Stuart McCulloch wrote:
also the subproject documentation that is there is (imho) not visible enough
( have to click Documentation->...um...->Subproject Documentation->aha... )
perhaps we could add a direct link to the subprojects page from the main
page?
Yes, something like that would be a
On 07/02/2008, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>
> Again, I am still unclear why there is this implicit acceptance among
> some to just assume that it makes sense for others to view our
> subprojects as tainted by our framework. However, rather than argue the
> merits of that, I would ra
Again, I am still unclear why there is this implicit acceptance among
some to just assume that it makes sense for others to view our
subprojects as tainted by our framework. However, rather than argue the
merits of that, I would rather think about how to address it.
The only idea I have is two
On Jan 15, 2008 8:32 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>
> Further, I am not really certain about what is being said here. This
> thread seems to imply that if we did "rm -rf framework" in our trunk
> directory, then it would be possible for our bundles to be seen as
> framework indep
Niclas Hedhman wrote:
On Wednesday 16 January 2008 22:47, Richard S. Hall wrote:
I have been hoping for a testing harness for some time. This is not my
area of strength, but I have almost given up hope that someone else will
look into it.
Perhaps because it is an unglamorous task...
On Wednesday 16 January 2008 22:47, Richard S. Hall wrote:
> I have been hoping for a testing harness for some time. This is not my
> area of strength, but I have almost given up hope that someone else will
> look into it.
Perhaps because it is an unglamorous task...
Cheers
--
Niclas Hedhman, So
Stuart McCulloch wrote:
+1 for portable bundles... I've been really frustrated at times when
I want to mix certain compendium services, only to find there's no
framework that can support certain mixes of Equinox, Knopflerfish
and Felix bundles
Agreed.
sounds like we need a testing harness
I guess that people that want to swap Http Service implementations
they will stick to Http Service API so basically they should get the
same expected behavior on using any of the implementations.
Extensions can be added as like there was another service that they
can use. and when a developer co
On Jan 16, 2008 3:06 PM, Rob Walker <[EMAIL PROTECTED]> wrote:
>
> ...
> That's one reason I've always been reluctant to see the Felix Http Service
> "adorned" or extended with features beyond the standard. I can see how
> beneficial such extensions are, but they then mean bundles and
> application
On 16/01/2008, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>
> It seems that some of these issues are arguments against Apache process,
> so I am not sure what to say about that.
horses for courses ;) there's no ideal process for every situation
and the lightweight process at ops4j is very encour
Clearly, not everything need be or can be developed at Felix, but the
implication that we might as well accept that Felix bundles will only
be used by Felix users seems awfully counter to all of the concepts
for which OSGi stands.
I'd totally agree here.
Whilst most Felix member use the
It seems that some of these issues are arguments against Apache process,
so I am not sure what to say about that.
Further, I am not really certain about what is being said here. This
thread seems to imply that if we did "rm -rf framework" in our trunk
directory, then it would be possible for o
Beside Niclas points there are some additional facts related to OPS4J:
* it's open participation meaning that virtually anybody can
contribute. No need for patches.
* release process. we tend to release often.
Alin
On Jan 13, 2008 1:05 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Thursday 1
Niclas Hedhman wrote:
On Thursday 10 January 2008 23:09, Richard S. Hall wrote:
There is no attempt by any of our sub-projects to specifically tie
themselves to the Felix framework as far as I am aware. I think we want
all of our work to be interoperable where possible, so I think this is a
n
On Thursday 10 January 2008 23:09, Richard S. Hall wrote:
> There is no attempt by any of our sub-projects to specifically tie
> themselves to the Felix framework as far as I am aware. I think we want
> all of our work to be interoperable where possible, so I think this is a
> non-issue.
Yes, that
e respond to
dev@felix.apache.org
To
dev@felix.apache.org
cc
Subject
Re: http.jetty based on Jetty 6
Well, the original Felix project proposal was to implement the entire
spec and bring open source OSGi communities together under one project.
So, it seems to me that we should have our own and/or en
Niclas Hedhman wrote:
On Wednesday 09 January 2008 23:07, Richard S. Hall wrote:
Well, the original Felix project proposal was to implement the entire
spec and bring open source OSGi communities together under one project.
So, it seems to me that we should have our own and/or encouraging PAX
On Wednesday 09 January 2008 23:07, Richard S. Hall wrote:
> Well, the original Felix project proposal was to implement the entire
> spec and bring open source OSGi communities together under one project.
> So, it seems to me that we should have our own and/or encouraging PAX to
> join us.
The re
Richard S. Hall wrote:
Well, the original Felix project proposal was to implement the entire
spec and bring open source OSGi communities together under one
project. So, it seems to me that we should have our own and/or
encouraging PAX to join us.
Seems fair to me
-- Rob
Well, the original Felix project proposal was to implement the entire
spec and bring open source OSGi communities together under one project.
So, it seems to me that we should have our own and/or encouraging PAX to
join us.
-> richard
Felix Meschberger wrote:
Hi all,
Thanks for the feedback
I have a total split-brain on this.
On the one hand, I like Felix having it's own Http Service - but that's
partly a sentimental/parochial response because Richard and I started it
so I feel some attachment to it.
On the other hand, wasted/duplicated effort never seems like a good idea
- it'
Hi all,
Thanks for the feedback and the pointers to Pax-Web at OPS4J. It quickly
checked it out and it works for me.
Now back to our Felix implementation: I just quickly hacked to gether
some support upto the point, where it runs for me. I attached a patch to
the Felix trunk to FELIX-55 and would
Just to share my experience Pax Web we included jetty servlet api 2.5
and then export and import it. I did some tests a while ago by using
pax together with external servlet api versions starting with servlet
2.2 and tests bundles requiring those earlier versions and everything
worked just fine.
Felix Meschberger wrote:
Hi all,
As already noted I am working on integration Jetty 6 in the http.jetty
bundle. On the course, I wonder, whether it would make sense to include
the Servlet API required by Jetty 6 in this bundle.
My reasoning for this is, that the servlet API version is closely t
On 09/01/2008, Rob Walker <[EMAIL PROTECTED]> wrote:
>
> Good news - saw your comment on FELIX-55.
>
> Be very good to get on a later version of jetty - it's served us well to
> date with the heavy lifting of our Http Service and making sure it
> performs and works reasonably well, so would be very
Good news - saw your comment on FELIX-55.
Be very good to get on a later version of jetty - it's served us well to
date with the heavy lifting of our Http Service and making sure it
performs and works reasonably well, so would be very happy to get onto a
more recent version.
We're starting t
Hi all,
As already noted I am working on integration Jetty 6 in the http.jetty
bundle. On the course, I wonder, whether it would make sense to include
the Servlet API required by Jetty 6 in this bundle.
My reasoning for this is, that the servlet API version is closely tied
to the Servlet Containe
31 matches
Mail list logo
