Yeah it's a good start.
On 2/24/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 2/22/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
> On 2/21/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> > On 2/21/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
> > > ...
> > > 3) I think the next step
On 2/22/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 2/21/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> On 2/21/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
> > ...
> > 3) I think the next step is to get all of the great thinking that was
> > in this thread into a Confluence page. I
On 2/21/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
On 2/21/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
> ...
> 3) I think the next step is to get all of the great thinking that was
> in this thread into a Confluence page. Is this still the best
> location?:
>
http://docs.safehaus.org/dis
Enrique,
On 2/21/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 2/9/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> John,
>
> Doing this means committing to OSGi and I'm not going to be too
> comfortable with doing this until I see:
> ...
> To tell you the truth we have big concerns that ov
On 2/9/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
John,
Doing this means committing to OSGi and I'm not going to be too
comfortable with doing this until I see:
...
To tell you the truth we have big concerns that overshadow the container
effort right now. First on that list is multi master re
Alex Karasulu wrote:
John E. Conlon wrote:
Alex Karasulu wrote:
John E. Conlon wrote:
Hi Alex,
Thanks for the comments. See inline for responses.
Truly thanks for your effort to push OSGi along. I really want to go
this route but I want all our bases covered.
Having read your response a
John E. Conlon wrote:
Alex Karasulu wrote:
John E. Conlon wrote:
Hi Alex,
Thanks for the comments. See inline for responses.
Truly thanks for your effort to push OSGi along. I really want to go
this route but I want all our bases covered.
Having read your response and Emmanuel's, I think
Alex Karasulu wrote:
John E. Conlon wrote:
Hi Alex,
Thanks for the comments. See inline for responses.
Truly thanks for your effort to push OSGi along. I really want to go
this route but I want all our bases covered.
Having read your response and Emmanuel's, I think I would like to wait
John E. Conlon wrote:
Hi Alex,
Thanks for the comments. See inline for responses.
Truly thanks for your effort to push OSGi along. I really want to go
this route but I want all our bases covered.
Having read your response and Emmanuel's, I think I would like to wait
until we have a *non*-
Hi Emmanuel ,
Emmanuel Lecharny wrote:
John E. Conlon a écrit :
Hi Alex,
Thanks for the comments. See inline for responses.
Alex Karasulu wrote:
Doing this means committing to OSGi and I'm not going to be too
comfortable with doing this until I see:
We can look at this two ways. From o
David Jencks wrote:
IMO if including the osgi metadata in the jars won't break anything
else we should put it in right away.
That is the idea. Just an accommodation to OSGi metadata right now.
It doesn't need to work completely or even partially. I think that
one of the benefits of the osgi
Hi Stefano,
Thanks for all the elaboration.
Hopefully we'll have a common approach to both James
and ApacheDS in the end so that we can share
documentation and maintenance efforts across both
servers.
Incidentally I have a couple of questions for you
regarding James installers, but let me start
Ole Ersoy ha scritto:
Hey Guys,
It looks like James (Apache Mail Server) has done a
lot of research on XBean and OSGi already.
Hi Ole, I'm a James PMC member,
Well, we did not really much research. One fine day Alan Cabrera
suggested us to move to maven2+xbean: someone liked the idea, someon
IMO if including the osgi metadata in the jars won't break anything
else we should put it in right away. It doesn't need to work
completely or even partially. I think that one of the benefits of
the osgi effort even for non-osgi uses is that it encourages cleaner
division of responsibilit
Never mind I found it.
thanks,
John
John E. Conlon wrote:
Hi Ole,
I went to the XBean site and could not find any documentation. Is
there an article or something you could point me reference so I can
take a look?
cheers,
John
Ole Ersoy wrote:
Sorry - The link below was a little further
Hi Ole,
I went to the XBean site and could not find any documentation. Is there
an article or something you could point me reference so I can take a look?
cheers,
John
Ole Ersoy wrote:
Sorry - The link below was a little further back in
the thread:
Here's the one where the OSGi discussion
John E. Conlon a écrit :
Hi Alex,
Thanks for the comments. See inline for responses.
Alex Karasulu wrote:
Doing this means committing to OSGi and I'm not going to be too
comfortable with doing this until I see:
We can look at this two ways. From one perspective we would not be
committin
Hi Alex,
Thanks for the comments. See inline for responses.
Alex Karasulu wrote:
Doing this means committing to OSGi and I'm not going to be too
comfortable with doing this until I see:
We can look at this two ways. From one perspective we would not be
committing 'fully' to OSGi, as the deco
Sorry - The link below was a little further back in
the thread:
Here's the one where the OSGi discussion starts,
although the previous messages on the thread are a
good backdrop.
http://mail-archives.apache.org/mod_mbox/james-server-dev/200604.mbox/[EMAIL
PROTECTED]
--- Ole Ersoy <[EMAIL PROTE
Hey Guys,
It looks like James (Apache Mail Server) has done a
lot of research on XBean and OSGi already.
It sounds like they are favoring OSGi over XBean due
in part to it being standardized through JCP. It also
sounds like there is an XBean facade for OSGi.
Here's a link to the James thread, s
John,
I'd be interested in helping with the "Integration
Testing Framework" part (I'm actually interested in
helping with a lot more, but I only have half a brain,
and that only works part of the time so...)
Anyways, I think it would make a nice little companion
top in the "Testing Guide" that I'
John,
Doing this means committing to OSGi and I'm not going to be too
comfortable with doing this until I see:
(1) some good "in situ" integration testing framework that allows us to
easily test services within the target container as part of the maven
build process,
(2) good test coverage,
Sounds really cool :-)
+2
Incidentally - I'm writing a Unit Testing Guide.
In it I'm recommending that all methods be made
public,
and if the temptation was to make them private, put
them in "Helper" classes instead that are named
ClassToBeHelpedHelper, indicating that they have a
very close rel
Think it is time to begin the process of moving OSGi into our trunk for
the 1.5.0-SNAPSHOT.
Propose that instead of adding parallel projects that wrap our existing
projects in OSGi bundles, that we instead add OSGi metadata to the jars
that are created by our existing projects. This is easil
24 matches
Mail list logo
