You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Meeraj Kunnumpurath (JIRA)" <tu...@ws.apache.org> on 2006/09/16 11:44:23 UTC
[jira] Commented: (TUSCANY-727) Transitive Dependencies in
Composites
[ http://issues.apache.org/jira/browse/TUSCANY-727?page=comments#action_12435205 ]
Meeraj Kunnumpurath commented on TUSCANY-727:
---------------------------------------------
This is a rough outline for the proposed mechanism for handling dependencies ....
1. Applications that use extensions should specify the extensions they use in the tuscany maven war plugin using the configuration/extensions/dependency(0..*) element.
2. The articat id, group id, version etc of the extension should be specified.
3. The war plugin will include the artifacts for the specified extensions in the WEB-INF/tuscany/exensions directory.
4. The application builder can optionally configure the WAR plugin to load all the dependencies for the extensions transitively into the WAR file using configuration/extensions/loadExtensionDependencies(0..1) element.
5. If this element is set to true the dependencies are loaded transitively into WEB-INF/tuscany/repository directory in a structure similar to a maven repo.
6. At runtime, if the composite contains a dependency element, the artifact resolver will resolve it and its dependencies transitively from WEB-INF/tuscany/repository directory.
7. If unable to do do, it will try the same using an injected local and set of remote directories.
8. If it still fails, it throws a runtime error.
> Transitive Dependencies in Composites
> -------------------------------------
>
> Key: TUSCANY-727
> URL: http://issues.apache.org/jira/browse/TUSCANY-727
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core
> Affects Versions: Java-M2
> Reporter: Meeraj Kunnumpurath
> Assigned To: Meeraj Kunnumpurath
> Fix For: Java-M2
>
>
> Dependencies defined in composites need to be resolved transitively. Currently artifact id specified in the SCDL is resolved non-transitively from a local Maven repo (location injected) in, using custom code. We may be able to leverage on the existing Maven artifact API. Also, we need to cater for scenarios where a local Maven repository is not available in the deployed environment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-727) Transitive Dependencies in Composites
Posted by ant elder <an...@gmail.com>.
Ok I still really have little idea how dependencies are classloaders are
going to work for M2, and this worries me a bit as I've had to spend so many
hours in the past sorting out classloader issues in Tuscany. If the
<dependency> element is optional and I don't use one and don't use Maven
meta-data is there any way to handle dependencies? If i want to use AXIOM in
my app and shared across the WS binding and the JavaScript container how do
I get the AXIOM classes in a common classloader? How are the data binding
extensions going to be using the correct classloader for a container or
application? I know you said I could share AXIOM between two extensions by
adding it as a dependency of a composite that is their parent but could you
give an example of what that looks like for those examples? I expect i'm
just being slow, so sorry for all the questions.
...ant
On 9/17/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Sep 17, 2006, at 2:37 AM, ant elder wrote:
>
> > From whats been posted previously about this I'm still not really
> > clear
> > exactly how things are going to work. Here's a couple of questions:
> >
> > Are composites required to use the non-standard dependency element
> > in the
> > SCDL? I'm hoping not and that there will be a way to get things
> > working
> > without that
>
> They are not - that's value add that Tuscany provides. Unfortunately,
> the spec does not define a mechanism for packaging code etc. with a
> composite so there is no non-"non-standard" way to do it. Things that
> are standard in Java, like Class-Path's specified in jar files, still
> work but even using JAR files is "non-standard".
>
> The <dependency> element I think is useful as it allows you to define
> a composite using just a bare XML file - there's no need to bundle it
> up into a JAR file just to associate the code with it. Using
> declarative dependencies also allows the runtime to support different
> resolution strategies which is good.
>
> AIUI we will also be supporting dependencies from the Maven meta-data
> in a jar - so if someone used Maven to build the war (or added the
> info themselves) then we will be able to pick that up automatically
> and they would not need to specify a <dependency> element at all.
>
> Jim has also mentioned using OSGi bundling as well and I think that
> would be another alternative we could support. If you have
> suggestions on another way to get things working let's figure out how
> we can make them all work together.
>
> > What does the classloader hierarchy look like for a complete
> > system? -
> > Could there be a couple of examples showing what classloaders
> > exist, what
> > their parents area and what jars they hold for a system which has a
> > couple
> > of extensions and and application composite?
>
> I agree we need good documentation on the classloading strategy and
> how it works.
>
> > One thing i'm wondering about
> > here is how classes get shared, say there are two extensions using
> > OMElement
> > then where do the AXIOM jars go?
>
> We're trying to keep the classloading approach separate from where
> the jars go. Experience has shown that using location to define
> classloading hierarchy is not sufficient to cover the ways in which
> people want to share or isolate the code. So the simple approach is
> to put all the JARs in a well known place/structure (the repo) where
> they can easily be used by a classloader hierarchy.
>
> To answer your question, it depends on whether they two extensions
> want to share AXIOM code (because they interact) or be isolated from
> each other (to avoid coupling). SCA by default isolates composites
> from each other (e.g. all peer interactions are by-reference) so if
> the two composites are peers then they would each have their own copy
> of AXIOM to fit the way the assembly spec works. If on the other hand
> the two composites are related to each other then they would have a
> common ancestor and the sharing would done by that ancestor. Putting
> it another way, you can share AXIOM between two extensions by adding
> it as a dependency of a composite that it their parent. This seems
> natural as it works in the same way normal Java classloading does
> where classes in parent classloader are shared by all its children.
>
> >
> > I like being able to load all the dependencies into a WAR, for one
> > thing I
> > think it makes it much more obvious whats going on when you can see
> > all the
> > jars in the war. But, a war now ends up being quite complicated -
> > there's
> > the classes dir, the lib dir, the tuscany/boot dir, tuscany/
> > extensions, and
> > now also tuscany/repository with all its sub directories.
>
> I think you've hit the nail on the head right here - if you put
> everything in the jar then you get everything in the jar and it is
> complicated. That is one reason for allowing people to externalize
> the code so that we can make the jar simpler.
>
> > Is there anyway
> > there could be a more simple setup? For example, tuscany/boot is
> > really a
> > single flat directory for the Tuscany runtime jars, so could there
> > be a
> > similar way for extensions to also use a single flat directory?
>
> We are doing that - WEB-INF/tuscany/extensions is a single flat
> directory. Where the repo kicks in is for the hierarchy of
> dependencies that all of those extensions have. With the advantage of
> being able to reuse any of the Maven repos available to you on the
> internet or in more secure locations inside your organization.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [jira] Commented: (TUSCANY-727) Transitive Dependencies in Composites
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 17, 2006, at 2:37 AM, ant elder wrote:
> From whats been posted previously about this I'm still not really
> clear
> exactly how things are going to work. Here's a couple of questions:
>
> Are composites required to use the non-standard dependency element
> in the
> SCDL? I'm hoping not and that there will be a way to get things
> working
> without that
They are not - that's value add that Tuscany provides. Unfortunately,
the spec does not define a mechanism for packaging code etc. with a
composite so there is no non-"non-standard" way to do it. Things that
are standard in Java, like Class-Path's specified in jar files, still
work but even using JAR files is "non-standard".
The <dependency> element I think is useful as it allows you to define
a composite using just a bare XML file - there's no need to bundle it
up into a JAR file just to associate the code with it. Using
declarative dependencies also allows the runtime to support different
resolution strategies which is good.
AIUI we will also be supporting dependencies from the Maven meta-data
in a jar - so if someone used Maven to build the war (or added the
info themselves) then we will be able to pick that up automatically
and they would not need to specify a <dependency> element at all.
Jim has also mentioned using OSGi bundling as well and I think that
would be another alternative we could support. If you have
suggestions on another way to get things working let's figure out how
we can make them all work together.
> What does the classloader hierarchy look like for a complete
> system? -
> Could there be a couple of examples showing what classloaders
> exist, what
> their parents area and what jars they hold for a system which has a
> couple
> of extensions and and application composite?
I agree we need good documentation on the classloading strategy and
how it works.
> One thing i'm wondering about
> here is how classes get shared, say there are two extensions using
> OMElement
> then where do the AXIOM jars go?
We're trying to keep the classloading approach separate from where
the jars go. Experience has shown that using location to define
classloading hierarchy is not sufficient to cover the ways in which
people want to share or isolate the code. So the simple approach is
to put all the JARs in a well known place/structure (the repo) where
they can easily be used by a classloader hierarchy.
To answer your question, it depends on whether they two extensions
want to share AXIOM code (because they interact) or be isolated from
each other (to avoid coupling). SCA by default isolates composites
from each other (e.g. all peer interactions are by-reference) so if
the two composites are peers then they would each have their own copy
of AXIOM to fit the way the assembly spec works. If on the other hand
the two composites are related to each other then they would have a
common ancestor and the sharing would done by that ancestor. Putting
it another way, you can share AXIOM between two extensions by adding
it as a dependency of a composite that it their parent. This seems
natural as it works in the same way normal Java classloading does
where classes in parent classloader are shared by all its children.
>
> I like being able to load all the dependencies into a WAR, for one
> thing I
> think it makes it much more obvious whats going on when you can see
> all the
> jars in the war. But, a war now ends up being quite complicated -
> there's
> the classes dir, the lib dir, the tuscany/boot dir, tuscany/
> extensions, and
> now also tuscany/repository with all its sub directories.
I think you've hit the nail on the head right here - if you put
everything in the jar then you get everything in the jar and it is
complicated. That is one reason for allowing people to externalize
the code so that we can make the jar simpler.
> Is there anyway
> there could be a more simple setup? For example, tuscany/boot is
> really a
> single flat directory for the Tuscany runtime jars, so could there
> be a
> similar way for extensions to also use a single flat directory?
We are doing that - WEB-INF/tuscany/extensions is a single flat
directory. Where the repo kicks in is for the hierarchy of
dependencies that all of those extensions have. With the advantage of
being able to reuse any of the Maven repos available to you on the
internet or in more secure locations inside your organization.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-727) Transitive Dependencies in Composites
Posted by ant elder <an...@gmail.com>.
>From whats been posted previously about this I'm still not really clear
exactly how things are going to work. Here's a couple of questions:
Are composites required to use the non-standard dependency element in the
SCDL? I'm hoping not and that there will be a way to get things working
without that
What does the classloader hierarchy look like for a complete system? -
Could there be a couple of examples showing what classloaders exist, what
their parents area and what jars they hold for a system which has a couple
of extensions and and application composite? One thing i'm wondering about
here is how classes get shared, say there are two extensions using OMElement
then where do the AXIOM jars go?
I like being able to load all the dependencies into a WAR, for one thing I
think it makes it much more obvious whats going on when you can see all the
jars in the war. But, a war now ends up being quite complicated - there's
the classes dir, the lib dir, the tuscany/boot dir, tuscany/extensions, and
now also tuscany/repository with all its sub directories. Is there anyway
there could be a more simple setup? For example, tuscany/boot is really a
single flat directory for the Tuscany runtime jars, so could there be a
similar way for extensions to also use a single flat directory?
...ant
On 9/16/06, Meeraj Kunnumpurath (JIRA) <tu...@ws.apache.org> wrote:
>
> [
> http://issues.apache.org/jira/browse/TUSCANY-727?page=comments#action_12435205]
>
> Meeraj Kunnumpurath commented on TUSCANY-727:
> ---------------------------------------------
>
> This is a rough outline for the proposed mechanism for handling
> dependencies ....
>
> 1. Applications that use extensions should specify the extensions they use
> in the tuscany maven war plugin using the
> configuration/extensions/dependency(0..*) element.
> 2. The articat id, group id, version etc of the extension should be
> specified.
> 3. The war plugin will include the artifacts for the specified extensions
> in the WEB-INF/tuscany/exensions directory.
> 4. The application builder can optionally configure the WAR plugin to load
> all the dependencies for the extensions transitively into the WAR file using
> configuration/extensions/loadExtensionDependencies(0..1) element.
> 5. If this element is set to true the dependencies are loaded transitively
> into WEB-INF/tuscany/repository directory in a structure similar to a maven
> repo.
> 6. At runtime, if the composite contains a dependency element, the
> artifact resolver will resolve it and its dependencies transitively from
> WEB-INF/tuscany/repository directory.
> 7. If unable to do do, it will try the same using an injected local and
> set of remote directories.
> 8. If it still fails, it throws a runtime error.
>
>
> > Transitive Dependencies in Composites
> > -------------------------------------
> >
> > Key: TUSCANY-727
> > URL: http://issues.apache.org/jira/browse/TUSCANY-727
> > Project: Tuscany
> > Issue Type: New Feature
> > Components: Java SCA Core
> > Affects Versions: Java-M2
> > Reporter: Meeraj Kunnumpurath
> > Assigned To: Meeraj Kunnumpurath
> > Fix For: Java-M2
> >
> >
> > Dependencies defined in composites need to be resolved transitively.
> Currently artifact id specified in the SCDL is resolved non-transitively
> from a local Maven repo (location injected) in, using custom code. We may be
> able to leverage on the existing Maven artifact API. Also, we need to cater
> for scenarios where a local Maven repository is not available in the
> deployed environment.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>