On Oct 6, 2006, at 4:16 AM, ant elder wrote:
Where do you see all this fitting in with the M2 release? I'd like
an M2
release real soon, what do you think we need for that and how about
leaving
all the OSGi stuff for after M2?
Yep, I see it after M2, since I'd like to get the release out
On Oct 6, 2006, at 7:00 AM, Ken Tam wrote:
Thoughts on the search order/priority for these classloader
hierarchies? Child-before-parent has some real advantages here -- it
lets extensions specify exactly what version of a dependency to use
and expose to its consumers, rather than have the hostin
1) we can support ordinary jars by adding multi-parent support to the
composite classloader. This would work in conjunction with the XML
dependency mechanism by allowing the dependency to be loaded in an
isolated classloader which would then be one parent of the runtime
component and one parent of
The release plan had osgi in the "include if its ready" category. IMO
I don't think it's ready yet so would put it in the "contrib"
category (in the source, not in the binary, YMMV).
The need for multi-parent is really driven by SDO and Spring
support. In the webapp environment the user is
On Oct 5, 2006, at 11:28 PM, Jim Marino wrote:
A more complex case is where a composite at some arbitrary depth
down the application tree wants to share a class with a system
component (such as an extension) that is at some other arbitrary
depth down the runtime tree. We have two solutions o
Where do you see all this fitting in with the M2 release? I'd like an M2
release real soon, what do you think we need for that and how about leaving
all the OSGi stuff for after M2?
...ant
On 10/6/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> For the webapp host, the default application is con
For the webapp host, the default application is contained in the
host environment (e.g. it contains JSPs, Servlets et al that are
part of the webapp). The default composite has a classloader that
is a child of the webapp one so has a classpath that is all the
application code + any 's speci
On Oct 5, 2006, at 8:19 AM, Ken Tam wrote:
Failure to communicate -- I was _agreeing_ with Rick, and saying that
if we _didn't_ solve 765 (in particular supporting the pre-scan idea),
it would result in an "increasingly crappy user experience". I _like_
just being able to drop extensions into a
It's actually even more complex than the situation that you outline
as we need to deal with a hierarchy of classloaders on both the
application and runtime sides. In general, we also will not have the
ability to control what gets added to the host environment's
classloaders that are the par
On 10/5/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
Classifying this as "signing up for an increasingly crappy
user experience" is deriding all the work people have put into this
already and is certainly disrespectful of the motivations this
community. Quit whining, and thanks for volunteerin
On 10/5/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Oct 5, 2006, at 7:10 AM, Ken Tam wrote:
> Yeah, I haven't run into the ordering issue because I'm just dealing
> with individual extensions, but that completely makes sense.
>
> It feels like if we're going to stay on the track of this maven
On Oct 5, 2006, at 7:10 AM, Ken Tam wrote:
Yeah, I haven't run into the ordering issue because I'm just dealing
with individual extensions, but that completely makes sense.
It feels like if we're going to stay on the track of this maven(-like)
depot system for managing extensions, I would suppor
On 10/5/06, ant elder <[EMAIL PROTECTED]> wrote:
I agree its not clear how all this is supposed to work, Venkat and I have
also both just being struggling with it.
To be complete, adding to your (a) and (b) in (3) there's also a (c) where
both the extension and application logic may share a depe
As Rick said, the the war plugin has a configuration
element do the packaging as Meeraj described here:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/%
[EMAIL PROTECTED]
In general, you would not want to list extensions as normal pom
dependencies as that would have sid
The last time I looked at the WAR plugin (or last time I checked it in
:-)), it would write the extensions to WEB-INF/tuscany/extensions
directory of the WAR and the transitive dependencies to
WEB-INF/tuscany/repository directory in a Maven repo format. Only the
boot libraries and their transitive
On 10/5/06, cr22rc <[EMAIL PROTECTED]> wrote:
Ken Tam wrote:
> While working with Andy on fixing some of the Spring samples, and
> taking a look at the way the war plugin has replaced the web distro, I
> ran into a number of issues relating to extensions and their
> dependencies.
>
> 1) It's no
Ken Tam wrote:
While working with Andy on fixing some of the Spring samples, and
taking a look at the way the war plugin has replaced the web distro, I
ran into a number of issues relating to extensions and their
dependencies.
1) It's not obvious how someone building a webapp sample expresses
I agree its not clear how all this is supposed to work, Venkat and I have
also both just being struggling with it.
To be complete, adding to your (a) and (b) in (3) there's also a (c) where
both the extension and application logic may share a dependency. Examples of
this are js.jar for the JavaSc
At 12:07 05/10/2006, Ken Tam wrote:
missing metadata needed to do that right. What do folks think about
simplifying it by being more explicit, and then slowly moving back to
a more automatic model?
Gets my vote.
andy
___
N
19 matches
Mail list logo
