Review/consolidate 2.x distribution structure
-
Key: TUSCANY-3674
URL: https://issues.apache.org/jira/browse/TUSCANY-3674
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Cor
Hi,
There are a few different goals around this area based on previous discussions:
1) A way to group a set of dependencies which are logically used together to
perform certain functions
2) A way for application developers to specify the required jars on the class
path (w or w/o maven)
3) A wa
I'm not sure that i see the value of the feature modules. Take the
webservice or binding-ws ones (they both look like they do the same
thing), why would you use that when it just does the same as using the
actual tuscany ws module tuscany-binding-ws-runtime? Or the ejava
feature that bundles all so
On Fri, Sep 10, 2010 at 9:31 AM, ant elder wrote:
> I'm not sure that i see the value of the feature modules.
...snip
I'm not sure I understand this uncertainty. Is it that you don't see
the value of
1/ grouping modules in order to generate modules subsets, manifest
jars, shaded jars
or
2/ the
On Fri, Sep 10, 2010 at 9:47 AM, Simon Laws wrote:
> On Fri, Sep 10, 2010 at 9:31 AM, ant elder wrote:
>> I'm not sure that i see the value of the feature modules.
> ...snip
>
> I'm not sure I understand this uncertainty. Is it that you don't see
> the value of
>
> 1/ grouping modules in order to
What really matters here is the mechanism. The feature poms we have now are
just some pre-canned profiles to demonstrate ways of grouping modules together
(like the various Eclipse packages for people to pick). They are choices and
there are always specific needs to regroup. If you are not happy
Hi
On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote:
> What really matters here is the mechanism. The feature poms we have now are
> just some pre-canned profiles to demonstrate ways of grouping modules
> together (like the various Eclipse packages for people to pick). They are
> choices and
>
> Simon and i chatted about this a bit, i'm still not really convinced
> about what the features give us and would still be interested in
> answers to the questions in the previous email about the ws and ejava
> features. I have made a new "base" feature from the shaded base jar
> and changed the
On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws wrote:
> Hi
>
>
> On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote:
>> What really matters here is the mechanism. The feature poms we have now are
>> just some pre-canned profiles to demonstrate ways of grouping modules
>> together (like the various
On Mon, Sep 13, 2010 at 10:48 AM, Simon Laws wrote:
>>
>> Simon and i chatted about this a bit, i'm still not really convinced
>> about what the features give us and would still be interested in
>> answers to the questions in the previous email about the ws and ejava
>> features. I have made a new
On Mon, Sep 13, 2010 at 1:58 PM, ant elder wrote:
> On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws
> wrote:
>> Hi
>>
>>
>> On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote:
>>> What really matters here is the mechanism. The feature poms we have now are
>>> just some pre-canned profiles to demo
> The shaded base includes more than the feature core mainly because it
> works and is used differently. When a uses uses the base jar they get
> that one jar and nothing else so it doesn't really matter if extra
> things are included in base as long as they don't drag in extra
> transitive depende
On Wed, Sep 15, 2010 at 10:46 AM, Simon Laws wrote:
>> The shaded base includes more than the feature core mainly because it
>> works and is used differently. When a uses uses the base jar they get
>> that one jar and nothing else so it doesn't really matter if extra
>> things are included in base
On Wed, Sep 15, 2010 at 10:37 AM, Simon Laws wrote:
> On Mon, Sep 13, 2010 at 1:58 PM, ant elder wrote:
>> On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws
>> wrote:
>>> Hi
>>>
>>>
>>> On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote:
What really matters here is the mechanism. The feature
On Wed, Sep 15, 2010 at 2:44 PM, ant elder wrote:
> On Wed, Sep 15, 2010 at 10:37 AM, Simon Laws
> wrote:
>> On Mon, Sep 13, 2010 at 1:58 PM, ant elder wrote:
>>> On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws
>>> wrote:
Hi
On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrot
On Wed, Sep 15, 2010 at 2:44 PM, ant elder wrote:
> On Wed, Sep 15, 2010 at 10:37 AM, Simon Laws
> wrote:
>> On Mon, Sep 13, 2010 at 1:58 PM, ant elder wrote:
>>> On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws
>>> wrote:
Hi
On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrot
We talked about this face to face amongst the various people who
attended the barcamp last weekend and I thought that we had at least
some common understanding for the "describing groups of function" part
of this puzzle. But in off list conversations that still seems not to
be the case.
I really t
Ok well I've published a snapshot of our maven-bundle-plugin that
allows us to generate some more meta-data for the binary distro. The
snapshot is not synched yet to the Nexus repo so I haven't committed
the distro poms that allow you to build for yourself. I've posted the
resulting zip to my p.o.a
Hi,
What's the difference between "feature" and "extension"?
Thanks,
Raymond
Raymond Feng
rf...@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
On Wed, Sep 29, 2010 at 6:25 PM, Raymond Feng wrote:
> Hi,
> What's the difference between "feature" and "extension"?
> Thanks,
> Raymond
In the bundle plugin config you mean?
In reality in the code nothing at the moment. I had looked on features
as being a somewhat arbitrary but functional coll
To me, the "extension" is just a "feature" that contains only the modules that
make up the "extension" :-). For example, I can model the binding.ws extension
as feature-binding-ws (a pom project that list feature-base, binding-ws,
binding-ws-runtime-axis2, etc.).
I don't know a way to combine m
On Wed, Sep 29, 2010 at 6:11 PM, Simon Laws wrote:
> Ok well I've published a snapshot of our maven-bundle-plugin that
> allows us to generate some more meta-data for the binary distro. The
> snapshot is not synched yet to the Nexus repo so I haven't committed
> the distro poms that allow you to b
On Wed, Sep 29, 2010 at 7:24 PM, Raymond Feng wrote:
> To me, the "extension" is just a "feature" that contains only the modules
> that make up the "extension" :-).
What is the point in that? We call them extensions everywhere else
(doc, spec, code, website etc), so it seems simpler to not obfusc
On Wed, Sep 29, 2010 at 7:24 PM, Raymond Feng wrote:
> To me, the "extension" is just a "feature" that contains only the modules
> that make up the "extension" :-). For example, I can model the binding.ws
> extension as feature-binding-ws (a pom project that list feature-base,
> binding-ws, bindin
On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws wrote:
>
> There is an issue though. The extension meta-data repeats all the
> dependencies that base provides. This actually doesn't make a
> difference because the duplicates don't have a material impact on the
> classpath (other than we might generat
On Thu, Sep 30, 2010 at 9:04 AM, ant elder wrote:
> On Wed, Sep 29, 2010 at 7:24 PM, Raymond Feng wrote:
>> To me, the "extension" is just a "feature" that contains only the modules
>> that make up the "extension" :-).
>
> What is the point in that? We call them extensions everywhere else
> (doc,
On Thu, Sep 30, 2010 at 9:06 AM, ant elder wrote:
> On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws wrote:
>
>>
>> There is an issue though. The extension meta-data repeats all the
>> dependencies that base provides. This actually doesn't make a
>> difference because the duplicates don't have a mater
Simon Laws wrote:
On Thu, Sep 30, 2010 at 9:06 AM, ant elder wrote:
On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws wrote:
There is an issue though. The extension meta-data repeats all the
dependencies that base provides. This actually doesn't make a
difference because the duplicates don't have
Simon Nash wrote:
Simon Laws wrote:
On Thu, Sep 30, 2010 at 9:06 AM, ant elder wrote:
On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws
wrote:
There is an issue though. The extension meta-data repeats all the
dependencies that base provides. This actually doesn't make a
difference because the du
>> I think this will be difficult if the base is made up of a large number
>> of jars and poms. AIUI the exlude list would have to name all the poms
>> in the base. If the list of poms in the base ever changes then all the
>> exclude lists would have to change as well.
>>
>> A simple solution wou
On Thu, Sep 30, 2010 at 11:09 AM, Simon Laws wrote:
>>> I think this will be difficult if the base is made up of a large number
>>> of jars and poms. AIUI the exlude list would have to name all the poms
>>> in the base. If the list of poms in the base ever changes then all the
>>> exclude lists
ant elder wrote:
On Thu, Sep 30, 2010 at 11:09 AM, Simon Laws wrote:
I think this will be difficult if the base is made up of a large number
of jars and poms. AIUI the exlude list would have to name all the poms
in the base. If the list of poms in the base ever changes then all the
exclude li
>>>
>>> Well it would work ok if the "base" remained as an "pom" type pom
>>> which just groups together other modules. The only time this would
>>> need rebuilding would be when the set of dependency jars change. Which
>>> isn't very often.
>>>
>>> The question then remains whether you can exclude
I've now checked in two new modules in the features directory...
tuscany-core-runtime
tuscany-base-runtime
The core-runtime is the set modules required to implement extensions
(exact set still TBD as there's probably too much in there now)
The base-runtime is core-runtime + the modules required f
On Wed, Oct 6, 2010 at 10:02 AM, Simon Laws wrote:
> I've now checked in two new modules in the features directory...
>
> tuscany-core-runtime
> tuscany-base-runtime
>
> The core-runtime is the set modules required to implement extensions
> (exact set still TBD as there's probably too much in ther
> Great.
>
> I don't think the base-runtime should include OSGi or Jetty as that
> drags in dependencies not needed in many environments. It also
> shouldn't include all those dependencies that are included as standard
> in Java 1.6.
>
> I still think base-runtime should include most things that ca
After much messing about with compliance tests thinking that the reorg
had broken them (only to find that there's a real issue there
TUSCANY-3709) I've checked in the mods to demonstrate a structure
which I think has most of the things different people have said they
want in the distro. Here are th
37 matches
Mail list logo