[2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

Hi,

It has always been a pain to run the ANT scripts against the samples 
manually at the last moment for releases. We often see inconsistent 
behaviors depending on whether a sample is run against the distribution or 
the maven dependencies.  One of the culprits is that the ANT script sets the 
classpath on the distribution while the maven build sets the classpath based 
on the maven dependencies.

In the 2.x stream, we now have opportunities to solve this problem:

1) Instead of just an all-in-one package, we now have a set of distributions 
to include selected Tuscany modules and 3rd-party jars based on the 
functions. The pom.xml for each distribution well defines the dependencies.
2) Building the distributions is much faster than before (only a 1-2 minutes 
on my laptop).
3) Meanwhile, we would like to run the samples under both JSE and OSGi. OSGi 
typically requires a distribution on the file system that is compatible with 
the bundle structure.

I suggest that we better align the samples with a selected distribution and 
automate the testing under JSE and OSGi with Maven and Ant. We can do the 
following:

1) Simply the maven dependency in the pom.xml for samples to only declare a 
distribution, for example,

        <dependency>
            <groupId>org.apache.tuscany.sca</groupId>
            <artifactId>tuscany-distribution-core</artifactId>
            <type>pom</type>
            <version>2.0-SNAPSHOT</version>
        </dependency>

2) Modify the build.xml to use Node (Standalone and Equinox) launchers to 
run the samples. And explore the "junit" Ant task to run test cases in the 
Ant build

3) Automate the post-distribution build to run the test cases in the samples 
to make sure the samples are validated as part of the build.

Thoughts? Are any of you interested in experimenting?

Thanks,
Raymond
 

Re: [2.0] Align samples with the distributions

[ant elder <an...@apache.org>]

Does look like we're getting closer now, a few comments inline:

   ...ant

On Mon, Jan 19, 2009 at 3:25 PM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Sat, Jan 17, 2009 at 8:53 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Fri, Jan 16, 2009 at 2:01 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 1:04 PM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <simonslaws@googlemail.com
>>>> > wrote:
>>>>
>>>>> snip....
>>>>>
>>>>>>
>>>>>> Yes that what the current compact distribution does, its in 1.x right
>>>>>> now as there's few extensions going in 2.x but there should be no problems
>>>>>> with doing it there too.
>>>>>>
>>>>>>    ...ant
>>>>>>
>>>>>> I looked at the compact distro in 1.x and the distro projects in 2.x
>>>>> and this is what I found:
>>>>>
>>>>> Key
>>>>>    Plain text = common between the two
>>>>>    [] = different between the two
>>>>>    * = my opinion
>>>>>
>>>>> A set of maven modules which define dependencies for features
>>>>>    [in /modules or /distribution]
>>>>>    * I prefer /distribution as the feature modules are not providing
>>>>> any new function
>>>>
>>>>
>>>> There's pros and cons, where they are right now enables a facility i've
>>>> not mentioned yet but the where they go is not big deal at the end of the
>>>> day.
>>>>
>>>>
>>>>>
>>>>> Samples depend on only the feature modules that they require
>>>>>
>>>>> An "all" distribution that ships all features
>>>>>
>>>>> [separate distributions that ship individual features]
>>>>>   * I don't mind having them if people want to support them.
>>>>
>>>>
>>>> The problem with doing that is it adds some significant complexity, from
>>>> things like the download page, to things like the documentation for samples
>>>> and how to use etc.
>>>>
>>>
>>> As I say below I don't think we need to decide for M1. I would assert
>>> that we need to be able to have samples depend on separate feature
>>> distributions, modules call then what you will. Doesn't mean we need to ship
>>> them but does mean they need to exist. As in my first point I think this is
>>> a common feature of both approaches as they are currently implemented.
>>>
>>
>> I don't think that would work very well, the "feature" approach is not a
>> feature per extension type so its only really useful for making
>> downloadable distributions. That means for example a sample using xqueryyou have to know
>> xquery is in the "process" feature distribution and download that, but
>> you wouldn't put a maven dependency on the process feature in the xquerysample as that would drag in all the other unnecessary dependencies like
>> bpel and ode, same thing for say a jsonrpc sample which would have a
>> dependency on the jsonrpc binding not the web20 feature as that would
>> drag in all the scripting stuff. The feature idea was that there would be a
>> small number of downloadable feature distributions as a way to manage the
>> growing number of Tuscany extensions, the problem is though that there are
>> no obvious groupings for most of the extensions so the features get quite
>> arbitrary as more extensions are include which makes them unintuitive which
>> just further complicates an already complicated project. Since they were
>> proposed we've asked on the dev list, user list, and in the user survey
>> and pretty much everyone is happy with the one big distribution, i think a
>> 70Meg or so download is just not a big deal these days. What people do seem
>> to want is less jars and an easier way to know which jars are for what, and
>> the compact jars and structured lib folder do that. Even if we didn't use
>> the compact jars, the structure lib folder makes a single distribution much
>> more usable, its obvious what jars are for and users can easily make up
>> their own custom distributions if required by just deleting unneeded lib
>> folders.
>>
>
> So we seem to be getting to the heart of the matter.  We tentatively agree;
>
> 1 - start with one "all" distro
> 2 - add some structure to the libs dir
> 3 - have some grouping of jars that group modules together for easy
> reference from samples etc.
>
> On point 3 the disagreement is the granularity of the grouping. Features vs
> extensions/compact.
>
> Features = small number of features that group more that one extension
> Extension/compact = larger number grouping each extension implementation
>
> I'm not against having a finer granularity of feature
>

Is there disagreement on point 3? No one has actual said they really want
the less granular "fauture" approach to grouping, and if we're not actually
have a downloadable feature distribution just yet there doesn't seem any
point in them AFAICS...so for now lets say the propopsed grouping is a
directory per extension unless someone comes up with a better solution.



>
>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>   * I suggest though in this first instance (M1) we just ship the "all"
>>>>> distro and we can see how we get on with that. This is still build from the
>>>>> separate feature modules.
>>>>>
>>>>
>>>> Yes i agree with just shipping an "all" distro for now. I'd like to
>>>> leave the "how its built" till this discussion has progressed a little
>>>> further though.
>>>>
>>>>
>>>>>
>>>>> [separate tuscany jars vs feature jars]
>>>>>   * I don't particularly like the feature jars as it's another step to
>>>>> go wrong. In particular it uses the shade(?) plugin and you have to
>>>>> configure transformers.
>>>>
>>>>
>>>> I'm puzzeled that you consider that as "another step to go wrong" but
>>>> don't mind having multiple different distributions or building distributions
>>>> out of each other, both of which seem to add much more complexity,
>>>> restrictions, and points of failure to me :)
>>>>
>>>
>>> To me it looks like a step in the process that we don't necessarily need.
>>> In the context of this point my measure of complexity is how many places I
>>> have to specify things. I agree that there are also complexities in
>>> distributing more that one distribution package but I don't see that that's
>>> particularly related to this point.
>>>
>>
>> I'm still not understanding the problem here, adding a shade transformer
>> config is a pretty easy task, we've been doing it for years in the past
>> Tuscany releases and i don't remember a single occasion where its caused any
>> problem. And its only an occasional task for a Tuscany "developer" which
>> makes the "users" life easier every time they use Tuscany - and users have
>> complained about Tuscany having so many jars on lots of occasions. Also, if
>> thats the only hurdle in doing this then all we need to do is write a
>> relatively trivial Tuscany specific extension of the shade plugin and we
>> then wouldn't even need that transformer configuration. We're getting quite
>> a lot of Tuscany specific plugins these days so one more is no big deal.
>>
>>
> Personally I've had a lot of problems with it. 50% of the time it fails in
> my environment (having sais that I haven't tried is since I moved to the Sun
> JDK). Anyhow the utility of this plugin to us will be dictated by the shape
> we want our distribution to take. If we have a single distribution then it
> seems we need to ship separate module jars as the OSGi runtime is expecting
> to load bundles.
>

That doesn't actually follow, yes OSGi needs a bundle but the compact jars
are bundles so they could run in OSGi just fine.

I guess we could write a manifest aggregator for the shade plugin but why
> would we when we can ship the separate module jars
>

because, as users have told us, there's so many seperate module jars it
makes Tuscany look real big and complicated


> and provide a manifest jar to make manual classpath specification easier.
> Maybe I'm missing something here.
>

I'm not sure i'm understanding why we need these manifest jars if we go for
the launcher aproach? We don't really need to support using a manual
classpath if we have a launcher do we?


>
>
>
>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>   [Launcher vs manually specified classpath comes into this]
>>>>>        * Manual classpath is easier with feature jars. Can we use a
>>>>> different approach to support the manual classpath? Manifest jars for each
>>>>> feature?
>>>>
>>>>
>>>> I think we need to make a bit more progress on the "Tuscany runtime
>>>> launching" thread before that can be answered.
>>>>
>>>
>>> Agreed
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> [structured libraries directory]
>>>>>   * I like this. It gives some sense of order to the distro lib
>>>>> directory.
>>>>>
>>>>>
>>>> Me too. Comparing the distros we've had in the past and the different
>>>> varrieties being talked about now i think a structured libraries directory
>>>> makes the most significant improvement for making the distro easier to use
>>>> in the way users have been asking for.
>>>>
>>>>
>>>>>
>>>>> Some other distro thoughts came to mind as I went through:
>>>>>
>>>>> 1/ Can we do something about 3rd party licenses? E.g. automate the
>>>>> command line tools we have that check distro jars are represented in the
>>>>> LICENSE file so that this happens automatically when distro is built. Also
>>>>> it would be nice to have a tool that checks that module NOTICE/LICENSE
>>>>> files match the requirements of the source that they hold. This last is
>>>>> manual at the moment.
>>>>
>>>>
>>>> The way to do this would be to change to use the maven release plugin
>>>> and IANAL plugin which would vastly simplify our distribution build and
>>>> release process, i think it is where i think really we need to get to but it
>>>> will put some restriction on how we shape the distributions which is one of
>>>> the reasons i'm less keen on all these "feature" distros
>>>>
>>>
>>> I looked at this a while back and I agree it adds restrictions. I don't
>>> remember the details so I'll have to read up. I seem to think it was early
>>> days when I looked at it so it was pretty rough at that point.
>>>
>>
>> I think its pretty good these days, I know Geronimo uses it ok.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>> 2/ We need to follow through on the reason Raymond started this thread
>>>>> originally and ensure that samples are tested in the ways that a user will
>>>>> run then when the distribution is built.
>>>>> 3/ As per 2/ but for webapp samples. Can we re-use some of the work
>>>>> that was done for webapps in 1.x itest?
>>>>>
>>>>
>>>> I'm starting to think there should be seperate distributions for OSGi
>>>> and JSE/Webapps etc. Trying to munge all this into a single distribution
>>>> that works for all environments so far looks like its going to make the
>>>> distribution a lot more complex and less user friendly than it needs to be.
>>>> You could consider this part of the "modularity" exercise of 2.0 and not
>>>> munging unrelated things together. If we did that then we can test the
>>>> samples included in the distribution properly in the best way for the target
>>>> environment.
>>>>
>>>
>>>  what would the difference be between these distributions? I think the
>>> jars and their organization would be the same. It comes down to how you
>>> launch/host the runtime so probably some hosting/launching jars would come
>>> and go. Again we need to do more on the launching thread for this point.
>>>
>>
>> Probably need actual distributions to show all the differences but for
>> example the organization isn't the same - the OSGi distro requires the 3rd
>> party jars be each included in its own sub folder which is unnecessary for
>> other environments and would make things like "java -cp" a bit unwieldy.
>> However, if we did go for the one common distro with a structure lib folder
>> then this becomes less of an issue for Ant scripts and launchers.
>>
>
> I suggest we lay out the distribution file directory in some detail and try
> review it. Is this what we're talking about
>
> tuscany-sca-2.0
>   bin
>     tuscany.bat (is this a bat or a jar?)
>

If we go for the dedicated launcher approach suggested in the runtime
launching thread then its a jar. The problem with the bat script approach is
you need different scripts for all the environments (Linux, Windows, etc),
they're not much fun to write, and they hit the 255 character command line
length when setting things like the classpath (which would proabbly be an
issue if we keep all the individual module jars).


>
>     tuscany-default.conf
>     tuscany-osgi.conf
>     ...
>   lib
>     base
>       acitvation-1.1
>         activation-1.1.jar
>         META-INF
>           MANIFEST.MF
>       asm-all-3.1.jar
>       tuscany-assembly-2.0.jar
>       tuscany-core-2.0.jar
>       tuscany-contribution-2.0.jar
>       ...
>       tuscany-base-manifest-2.0.jar
>     spring
>       commons-logging-1.1.1.jar
>       spring-2.5.5.jar
>       tuscany-implementation-spring-2.0.jar
>       tuscany-spring-manifest-2.0.jar
>     webservices
>   samples
>     calculator
>   tutorial
>     store
>
>
>

Re: [2.0] Align samples with the distributions

[Luciano Resende <lu...@gmail.com>]

On Wed, Jan 21, 2009 at 9:04 AM, Simon Laws <si...@googlemail.com> wrote:
>
>
> On Wed, Jan 21, 2009 at 4:16 PM, Luciano Resende <lu...@gmail.com>
> wrote:
>>
>> I'm trying to catch up on this thread, could someone summarize what's
>> the current status and open items ?
>>
>>
>
> Hi Luciano
>
> I'll give it a go.
>
> We've had a long discussion about the structure of the distribution. The
> prime focus of which (IMO) has been the structure of the modules dir. Some
> here would like to add some but there is a snag in that you can easily
> determine which jars are shared.
>
> On the test alignment piece. I've been playing with the distribution as it
> is  over the last couple of days to try and answer the conversation that
> started all this. Working off the "all" distro this is what I have so
> far....
>
> tuscany-sca-2.0-SNAPSHOT/
>    modules/
>       still a flat directory with all modules and 3rd party jars
>    samples/
>       core/
>          binding-sca-calculator/
>             src/
>             build.xml
>        webapp
>           host-webapp-calculator
>        webservice
>            binding-ws-calculator
>
> Note.
>   the samples are grouped
>   I've flipped the names of these example samples to point out their main
> reason for being.

Are we still planning to have multiple distributions in the future ?
If so, what issue we are trying to solve by grouping the samples in
sub-directories compared to different distributions ?

>
> In the case binding-sca-calculator, for example, the ant build.xml runs the
> sample using either the JSE or OSGI laucher. I've made no changes to
> launchers yet subject to discussion on the other thread. So in this case the
> sample is just a contribution. There is  a JUnit test but again this just
> calls the lanucher and treats the sample as a contribution. There is a
> client conponent in the sample that drives it.
>

Ok

> I'm looking at extending the distro module to run the ant script to autmate
> the process we have struggled with in the past. In a way I'd rather have
> this happen as JUnit time but maybe that won't work out. I certainly need
> some help with the webapp version as we need to fire up cargo or something
> to ensure that we can test the webapp deploy stage.
>

If we are trying to solve the issue where we never run our samples
using ant/distribution, this is a good idea. How about something like
a "build smoke test" profile that, after building a distribution would
try to unpack and exercise it using ant ?


> haven't checked these bits in yet.
>
> That's what I see so far.
>
> Simon
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Wed, Jan 21, 2009 at 4:16 PM, Luciano Resende <lu...@gmail.com>wrote:

> I'm trying to catch up on this thread, could someone summarize what's
> the current status and open items ?
>
>
>
Hi Luciano

I'll give it a go.

We've had a long discussion about the structure of the distribution. The
prime focus of which (IMO) has been the structure of the modules dir. Some
here would like to add some but there is a snag in that you can easily
determine which jars are shared.

On the test alignment piece. I've been playing with the distribution as it
is  over the last couple of days to try and answer the conversation that
started all this. Working off the "all" distro this is what I have so
far....

tuscany-sca-2.0-SNAPSHOT/
   modules/
      still a flat directory with all modules and 3rd party jars
   samples/
      core/
         binding-sca-calculator/
            src/
            build.xml
       webapp
          host-webapp-calculator
       webservice
           binding-ws-calculator

Note.
  the samples are grouped
  I've flipped the names of these example samples to point out their main
reason for being.

In the case binding-sca-calculator, for example, the ant build.xml runs the
sample using either the JSE or OSGI laucher. I've made no changes to
launchers yet subject to discussion on the other thread. So in this case the
sample is just a contribution. There is  a JUnit test but again this just
calls the lanucher and treats the sample as a contribution. There is a
client conponent in the sample that drives it.

I'm looking at extending the distro module to run the ant script to autmate
the process we have struggled with in the past. In a way I'd rather have
this happen as JUnit time but maybe that won't work out. I certainly need
some help with the webapp version as we need to fire up cargo or something
to ensure that we can test the webapp deploy stage.

haven't checked these bits in yet.

That's what I see so far.

Simon

Re: [2.0] Align samples with the distributions

[Luciano Resende <lu...@gmail.com>]

I'm trying to catch up on this thread, could someone summarize what's
the current status and open items ?

On Wed, Jan 21, 2009 at 1:36 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:
>>
>> Hi,
>>
>> More comments inline.
>>
>> Thanks,
>> Raymond
>> From: Simon Laws
>> Sent: Tuesday, January 20, 2009 8:41 AM
>> To: dev@tuscany.apache.org
>> Subject: Re: [2.0] Align samples with the distributions
>>>>
>>>>
>>>
>>> Agreed. It's just a local repo. Do you think adding a little structure
>>> add technical difficulty or is a flat structure a personal preference? I'm
>>> interested in situations like this where we have some people who want
>>> solution A and others want solution B (where both solutions are valid). How
>>> do we come to a conclusion? In the past this has tended to stall us a little
>>> so this is a good chance to see if we can do better;-)
>>>
>>> I'm seeing some technical issues:
>>>
>>> 1) Adding a little structure will make the distribution incompatible with
>>> Equinox OSGi launcher and PDE target platform.
>>
>> I believe this is a statement about how it works just now rather than a
>> statement about blockers for change.
>>
>> I more view it as a block for introducing structural changes. The current
>> layout can be directly used as an Equinox installation of bundles or PDE
>> target location.
>
> That seems like FUD to me, I don't see any reason it can't be made to work
> with either structure. This seems to be the main objection so if we can show
> it can work then can we lay this debate to rest?
>
>    ...ant
>
>
>
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

On Tue, Jan 27, 2009 at 10:27 AM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Mon, Jan 26, 2009 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
>
>>  Hi,
>>
>> Please see my comments inline.
>>
>> Thanks,
>> Raymond
>>
>>
>> From: Simon Laws
>> Sent: Monday, January 26, 2009 7:00 AM
>> To: dev@tuscany.apache.org
>> Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align
>> samples with the distributions
>>
>>
>> [[snip]]
>>
>> Hi
>>
>> I'm adding the three samples I've been playing with to the build and the
>> distribution so we can experiment with the process/scripts. I'd like to
>> exploit M1 to get the process a slick as we can while we have a small number
>> of modules. The binding-ws-calculator and host-webapp-calculator samples
>> don't actually work yet as samples. The related function still needs some
>> work.
>>
>> +1 to use samples to validate the distribution structure and grouping.
>>
>> Looking through the distribuion I have some questions/comments;
>>
>> - why "ejava"? Any relation to [1]:-)
>>
>> "ejava" stands for "Enterprise Java". It will potentially include
>> Enterprise Java related pieces such as binding.rmi, binding.ejb,
>> binding.jms, implementation.ejb, implementation.web etc.
>>
>> - How to get hold of the list of jars for a given feature so that I can
>> build a war including the minimum set of jars. It could be an option if the
>> war just referenced an external tuscany distribution but users may not have
>> the option to install one so we probably still need to include the runtime
>> in the war. Is there a trick to extract this info from a manifest. I'd
>> rather not generate another ant script with that info if we can avoid it.
>>
>> How do you produce the WAR file? If you are using maven, then you can add
>> the dependency to the distribution pom project, such as
>> tuscany-distribution-core:pom. For ANT, it's typically done via the war ant
>> task which has the lib element that defines a fileSet. We can easily
>> generate something like modules.lst for each distribution for easy parsing.
>>
>
> Currently I just include everything in modules which is not ideal...
>
>         <fileset id="tuscany.jars" dir="${distro.root}/modules">
>             <include name="*.jar" />
>             <include name="*/*.jar" />
>         </fileset>
>         <war destfile="${sample.war}"
> webxml="${sample.root}/src/main/webapp/WEB-INF/web.xml">
>             <fileset dir="${sample.root}/src/main/webapp"/>
>             <lib refid="tuscany.jars"/>
>             <classes dir="${sample.root}/target/classes"/>
>         </war>
>
> If we want to allow people to build wars from ant scripts then we need to
> have a way for building a lib path from selected features. An alternative is
> to say that people can;t do this with ant but need to use maven to build
> wars and use the maven dependencies. A step back from what we have in 1.x
> though so I'd rather we continue to support any compiles in this case.
>

That seems to be getting to the root of what this is about - how to best
support building webapps with Ant - or more generally - how can people not
using Maven know what Tuscany jars and dependencies they need to be using.
There's lots a different ways we could do that, from just manually
documenting it in a text file to using custom plugins to generate lists. If
we seperate that from what the distributions look like it may help to see
what the best options are.



> We could generate the "fileset" for each feature an maybe this is the
> easiest way but I was interested to know if you had something in mind
> without generating more files.
>
>
>> - tuscany-distribution-ejava etc. This is a question about naming really.
>> I'm undecided as to whether we should actually distribute these things but I
>> am very keen that our distribution(s) are structured so that people can
>> depend on sensible chunks of function rather than all of it. Do we
>> anticipate that there will be groups of function here that aren't named
>> distribution, e.g. tuscany-extension-implementation-bpel or
>> tuscany-extension-binding-jms so that people can include manifests for
>> individual extensions rather than larger groups of them?
>> I think it's about granularity and different combinations of functional
>> modules. Tuscany can only ship a limited number of distros. If we get
>> the technique very simple to declare a "feature", then we can potentially
>> make many configurations available. With what we have, "feature" can extend
>> from one or more features and features can also have overlaps. In fact, we
>> don't have to build a distro for every single feature we define. We can have
>> much less distros than features. For example, one "all" distro can have
>> configurations for "core", "ejava", "webservice" features.
>>
>
> I agree that the idea of having groups of jars represented in the all
> distribrio and the though that these groups might be separately distributed
> are different points.
>

Yes, and if we keep them separate then we can decouple the two and that will
help find good solutions for each. And I think we're all starting to agree
on this and its whats being suggested over on the point 2 in this post:
http://apache.markmail.org/message/2vumrlwjr7ylu3zp

   ...ant

Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

A quick update:

1) I add a flag to control if we generate the distro-specific configuration files or manifest.jar at the top level or under the name of the distro
2) I add the code to generate the build-path.xml which can be directly included into the sample build.xml
3) I add a bit logic to name the distro folder as feature-<xyz> instead of tuscany-distribution-<xyz>.

Thanks,
Raymond


From: Simon Laws 
Sent: Tuesday, January 27, 2009 2:27 AM
To: dev@tuscany.apache.org 
Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions





On Mon, Jan 26, 2009 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:

  Hi,

  Please see my comments inline. 


  Thanks,
  Raymond


  From: Simon Laws 

  Sent: Monday, January 26, 2009 7:00 AM 

  To: dev@tuscany.apache.org 
  Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions



  [[snip]] 


  Hi

  I'm adding the three samples I've been playing with to the build and the distribution so we can experiment with the process/scripts. I'd like to exploit M1 to get the process a slick as we can while we have a small number of modules. The binding-ws-calculator and host-webapp-calculator samples don't actually work yet as samples. The related function still needs some work. 


  +1 to use samples to validate the distribution structure and grouping.


  Looking through the distribuion I have some questions/comments;

  - why "ejava"? Any relation to [1]:-)

  "ejava" stands for "Enterprise Java". It will potentially include Enterprise Java related pieces such as binding.rmi, binding.ejb, binding.jms, implementation.ejb, implementation.web etc.


  - How to get hold of the list of jars for a given feature so that I can build a war including the minimum set of jars. It could be an option if the war just referenced an external tuscany distribution but users may not have the option to install one so we probably still need to include the runtime in the war. Is there a trick to extract this info from a manifest. I'd rather not generate another ant script with that info if we can avoid it.

  How do you produce the WAR file? If you are using maven, then you can add the dependency to the distribution pom project, such as tuscany-distribution-core:pom. For ANT, it's typically done via the war ant task which has the lib element that defines a fileSet. We can easily generate something like modules.lst for each distribution for easy parsing.

Currently I just include everything in modules which is not ideal...

        <fileset id="tuscany.jars" dir="${distro.root}/modules">
            <include name="*.jar" />
            <include name="*/*.jar" />
        </fileset>        
        <war destfile="${sample.war}" webxml="${sample.root}/src/main/webapp/WEB-INF/web.xml">
            <fileset dir="${sample.root}/src/main/webapp"/>
            <lib refid="tuscany.jars"/>
            <classes dir="${sample.root}/target/classes"/>
        </war>  

If we want to allow people to build wars from ant scripts then we need to have a way for building a lib path from selected features. An alternative is to say that people can;t do this with ant but need to use maven to build wars and use the maven dependencies. A step back from what we have in 1.x though so I'd rather we continue to support any compiles in this case. We could generate the "fileset" for each feature an maybe this is the easiest way but I was interested to know if you had something in mind without generating more files. 



  - tuscany-distribution-ejava etc. This is a question about naming really. I'm undecided as to whether we should actually distribute these things but I am very keen that our distribution(s) are structured so that people can depend on sensible chunks of function rather than all of it. Do we anticipate that there will be groups of function here that aren't named distribution, e.g. tuscany-extension-implementation-bpel or tuscany-extension-binding-jms so that people can include manifests for individual extensions rather than larger groups of them? 

  I think it's about granularity and different combinations of functional modules. Tuscany can only ship a limited number of distros. If we get the technique very simple to declare a "feature", then we can potentially make many configurations available. With what we have, "feature" can extend from one or more features and features can also have overlaps. In fact, we don't have to build a distro for every single feature we define. We can have much less distros than features. For example, one "all" distro can have configurations for "core", "ejava", "webservice" features.    

I agree that the idea of having groups of jars represented in the all distribrio and the though that these groups might be separately distributed are different points. I think we need to try different granularity of groups to see what works. The smallest granularity is propably an extension and multiple extensions in a group produce the "features" that are in svn now.  



  I'll post more as they come to mind.

  Simon

  [1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html

Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Mon, Jan 26, 2009 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:

>  Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
>
> From: Simon Laws
> Sent: Monday, January 26, 2009 7:00 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
> with the distributions
>
>
> [[snip]]
>
> Hi
>
> I'm adding the three samples I've been playing with to the build and the
> distribution so we can experiment with the process/scripts. I'd like to
> exploit M1 to get the process a slick as we can while we have a small number
> of modules. The binding-ws-calculator and host-webapp-calculator samples
> don't actually work yet as samples. The related function still needs some
> work.
>
> +1 to use samples to validate the distribution structure and grouping.
>
> Looking through the distribuion I have some questions/comments;
>
> - why "ejava"? Any relation to [1]:-)
>
> "ejava" stands for "Enterprise Java". It will potentially include
> Enterprise Java related pieces such as binding.rmi, binding.ejb,
> binding.jms, implementation.ejb, implementation.web etc.
>
> - How to get hold of the list of jars for a given feature so that I can
> build a war including the minimum set of jars. It could be an option if the
> war just referenced an external tuscany distribution but users may not have
> the option to install one so we probably still need to include the runtime
> in the war. Is there a trick to extract this info from a manifest. I'd
> rather not generate another ant script with that info if we can avoid it.
>
> How do you produce the WAR file? If you are using maven, then you can add
> the dependency to the distribution pom project, such as
> tuscany-distribution-core:pom. For ANT, it's typically done via the war ant
> task which has the lib element that defines a fileSet. We can easily
> generate something like modules.lst for each distribution for easy parsing.
>

Currently I just include everything in modules which is not ideal...

        <fileset id="tuscany.jars" dir="${distro.root}/modules">
            <include name="*.jar" />
            <include name="*/*.jar" />
        </fileset>
        <war destfile="${sample.war}"
webxml="${sample.root}/src/main/webapp/WEB-INF/web.xml">
            <fileset dir="${sample.root}/src/main/webapp"/>
            <lib refid="tuscany.jars"/>
            <classes dir="${sample.root}/target/classes"/>
        </war>

If we want to allow people to build wars from ant scripts then we need to
have a way for building a lib path from selected features. An alternative is
to say that people can;t do this with ant but need to use maven to build
wars and use the maven dependencies. A step back from what we have in 1.x
though so I'd rather we continue to support any compiles in this case. We
could generate the "fileset" for each feature an maybe this is the easiest
way but I was interested to know if you had something in mind without
generating more files.


> - tuscany-distribution-ejava etc. This is a question about naming really.
> I'm undecided as to whether we should actually distribute these things but I
> am very keen that our distribution(s) are structured so that people can
> depend on sensible chunks of function rather than all of it. Do we
> anticipate that there will be groups of function here that aren't named
> distribution, e.g. tuscany-extension-implementation-bpel or
> tuscany-extension-binding-jms so that people can include manifests for
> individual extensions rather than larger groups of them?
> I think it's about granularity and different combinations of functional
> modules. Tuscany can only ship a limited number of distros. If we get
> the technique very simple to declare a "feature", then we can potentially
> make many configurations available. With what we have, "feature" can extend
> from one or more features and features can also have overlaps. In fact, we
> don't have to build a distro for every single feature we define. We can have
> much less distros than features. For example, one "all" distro can have
> configurations for "core", "ejava", "webservice" features.
>

I agree that the idea of having groups of jars represented in the all
distribrio and the though that these groups might be separately distributed
are different points. I think we need to try different granularity of groups
to see what works. The smallest granularity is propably an extension and
multiple extensions in a group produce the "features" that are in svn now.


> I'll post more as they come to mind.
>
> Simon
>
> [1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html<http://cs.joensuu.fi/%7Ejeliot/help/EJava/EJava-language.html>
>

Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

Hi,

Please see my comments inline.

Thanks,
Raymond


From: Simon Laws 
Sent: Monday, January 26, 2009 7:00 AM
To: dev@tuscany.apache.org 
Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions


[[snip]]

Hi

I'm adding the three samples I've been playing with to the build and the distribution so we can experiment with the process/scripts. I'd like to exploit M1 to get the process a slick as we can while we have a small number of modules. The binding-ws-calculator and host-webapp-calculator samples don't actually work yet as samples. The related function still needs some work. 

+1 to use samples to validate the distribution structure and grouping.

Looking through the distribuion I have some questions/comments;

- why "ejava"? Any relation to [1]:-)

"ejava" stands for "Enterprise Java". It will potentially include Enterprise Java related pieces such as binding.rmi, binding.ejb, binding.jms, implementation.ejb, implementation.web etc.

- How to get hold of the list of jars for a given feature so that I can build a war including the minimum set of jars. It could be an option if the war just referenced an external tuscany distribution but users may not have the option to install one so we probably still need to include the runtime in the war. Is there a trick to extract this info from a manifest. I'd rather not generate another ant script with that info if we can avoid it.

How do you produce the WAR file? If you are using maven, then you can add the dependency to the distribution pom project, such as tuscany-distribution-core:pom. For ANT, it's typically done via the war ant task which has the lib element that defines a fileSet. We can easily generate something like modules.lst for each distribution for easy parsing.

- tuscany-distribution-ejava etc. This is a question about naming really. I'm undecided as to whether we should actually distribute these things but I am very keen that our distribution(s) are structured so that people can depend on sensible chunks of function rather than all of it. Do we anticipate that there will be groups of function here that aren't named distribution, e.g. tuscany-extension-implementation-bpel or tuscany-extension-binding-jms so that people can include manifests for individual extensions rather than larger groups of them? 

I think it's about granularity and different combinations of functional modules. Tuscany can only ship a limited number of distros. If we get the technique very simple to declare a "feature", then we can potentially make many configurations available. With what we have, "feature" can extend from one or more features and features can also have overlaps. In fact, we don't have to build a distro for every single feature we define. We can have much less distros than features. For example, one "all" distro can have configurations for "core", "ejava", "webservice" features.    

I'll post more as they come to mind.

Simon

[1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html

Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Sat, Jan 24, 2009 at 4:35 PM, Raymond Feng <en...@gmail.com> wrote:

> a) I'm really puzzled. Have you ever looked into the "all" distribution
> that the current code produces? I don't see big difference than what you
> have said on the ML.
>
>   1) It's similar with the 1.x all-in-one distribution without the
> tuscany-all jar
>   2) 3rd-party non-OSGi jars are placed under individual folders to form
> OSGi bundles
>   3) Instead of one manifest.jar, it comes with multiple
> tuscany-distribution-* folders that group the manifest.jar and osgi
> configurations for a collection of functions.
>
> We now build the "all" distribution based on "core" and "ejava". And I also
> mentioned in the PDF doc that we will only ship the "all" distro for 2.x M1.
>
> PLEASE elaborate what you are not happy with the "all" distro. I might have
> missed or misunderstood the points.
>
> b) I'm sad too. It seems that my hours of work warrants some critics based
> a misinterpretation on a smiley without good facts. I really meant to
> welcome feedbacks from the community with the smiley.
>
> Thanks,
> Raymond
>
> From: ant elder
> Sent: Saturday, January 24, 2009 1:15 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
> with the distributions
>
>
>
> That seems to ignore what we agreed and has been said on the threads about
> this, and i guess you know that as you said "(IMO :-)". Sad that flouting
> consensus warrants a smiley.
>
>  ...ant
>
>
> On Fri, Jan 23, 2009 at 5:25 PM, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> I have made some good progress (IMO :-) to bring up the distribution story
> in 2.x toward M1. The current "all" distribution contains "core" and "ejava"
> (binding.rmi only). You can try to build it with the following command:
>
> cd sca/distribution
> mvn clean install -Pdistribution
>
> Please build the tools and modules first. tuscany-maven-bundle-plugin is
> used to produce some parts of the distribution.
>
> The current story is documented at [1].
>
> Feedbacks are welcome.
>
> [1]
> http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1
>
> Thanks,
> Raymond
>
>
> From: ant elder
> Sent: Friday, January 23, 2009 2:03 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.0] Align samples with the distributions
>
>
>
>
>
> On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> wrote:
>
> I asked early but no ones replied so I'm still missing the point of what
> these manifest classpaths would be used for? If there we use some type of
> launcher there is no need for a manifest classpath is there? A problem with
> that one below is that it includes more than just the core dependencies
> which makes it a little misleading.
>
>  ...ant
>
>
>
> On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com> wrote:
>
> I have added the support to generate the manifest jars which contain the
> classpath for a given distribution. JSE users can just use the manifest jar
> alone to point to the distro he/she wants. For example, to use "core"
> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
> the following MANIFEST.MF. Please note it works well with the flat structure
> under "modules" for all the jars.
>
> Manifest-Version: 1.0
> Implementation-Vendor: The Apache Software Foundation
> Implementation-Title: Apache Tuscany SCA Core Distribution
> Implementation-Version: 2.0-SNAPSHOT
> Implementation-Vendor-Id: org.apache
> Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>
>
> From: ant elder
> Sent: Wednesday, January 21, 2009 1:36 AM
>
> To: dev@tuscany.apache.org
> Subject: Re: [2.0] Align samples with the distributions
>
>
>
>
>
> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> More comments inline.
>
> Thanks,
> Raymond
>
>
> From: Simon Laws
> Sent: Tuesday, January 20, 2009 8:41 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.0] Align samples with the distributions
>
>
>
> Agreed. It's just a local repo. Do you think adding a little structure add
> technical difficulty or is a flat structure a personal preference? I'm
> interested in situations like this where we have some people who want
> solution A and others want solution B (where both solutions are valid). How
> do we come to a conclusion? In the past this has tended to stall us a little
> so this is a good chance to see if we can do better;-)
>
> I'm seeing some technical issues:
>
> 1) Adding a little structure will make the distribution incompatible with
> Equinox OSGi launcher and PDE target platform.
>
> I believe this is a statement about how it works just now rather than a
> statement about blockers for change.
>
> I more view it as a block for introducing structural changes. The current
> layout can be directly used as an Equinox installation of bundles or PDE
> target location.
>
> That seems like FUD to me, I don't see any reason it can't be made to work
> with either structure. This seems to be the main objection so if we can show
> it can work then can we lay this debate to rest?
>
> ...ant
>
>
>
>
>
> I had planned to use the manfiest as the compile dependency in sample ant
> scripts. It seems a useful shorthand to describe a feature.
>
> What i'm not understanding is why you'd want a compile dependency on a
> "feature"?  I can see you might want tot use the specific dependencies you
> know you need, or use wildcards to add all the jars in a folder, or use a
> launcher to manage the dependencies for you. But as a feature includes
> multiple different extension types why would you want to use it as a
> dependency?
>
>  ...ant
>
>
>
>
>
> "But as a feature includes multiple different extension types why would you
> want to use it as a dependency? "
>
>
> Well it depends what you think a feature is.
>
> Some here think features have lots of things in them, others think they
> could have a few things in them. I fall into the latter category.
>
> Some people think that features should be separately distributable some
> think that people will mostly want the all jar. Again I fall into the latter
> category but I would like to build the all jar out of a separate set of
> features rather than all the individual jars.
>
> Why do I want to do that? So that I can refer to individual features from
> my Ant scripts.
>
> Simon
>
>
>
> I've understood we've been using the term "feature" to mean the collection
> of distributions as was done in the equinox fork. If we change the term to
> mean something thats more tightly coupled to each individual extension that
> starts to make more sense to me. I'd still wonder if we really need them if
> we change to using a launcher, and if we had a structured lib folder then
> there doesn't seem any need at all.
>
> So what a proposal could be for 2.0 M1 would be have a single "all" type
> distribution thats just like the 1.x distribution but instead of a single
> tuscany-all jar and manifest jar have multiple manifest jars for each
> extension (or group of extensions if there are some really tightly coupled
> ones).
>
>  ...ant
>
>
>
>
>
>
>
> Sounds good to me. It gives us a place to start so we can establish how
> each type of user we anticipate will exploit the distribution. Doing this
> will hopefully give us a more complete view. So how about we set this up,
> close this thread and start a new thread(s) to discuss how each of the
> different launching options we have already started to discuss will work.
>
> Simon
>
>
> Ok if i don't hear any objections I'll start doing this first thing next
> week.
>
>  ...ant
>

Hi

I'm adding the three samples I've been playing with to the build and the
distribution so we can experiment with the process/scripts. I'd like to
exploit M1 to get the process a slick as we can while we have a small number
of modules. The binding-ws-calculator and host-webapp-calculator samples
don't actually work yet as samples. The related function still needs some
work.

Looking through the distribuion I have some questions/comments;

- why "ejava"? Any relation to [1]:-)

- How to get hold of the list of jars for a given feature so that I can
build a war including the minimum set of jars. It could be an option if the
war just referenced an external tuscany distribution but users may not have
the option to install one so we probably still need to include the runtime
in the war. Is there a trick to extract this info from a manifest. I'd
rather not generate another ant script with that info if we can avoid it.

- tuscany-distribution-ejava etc. This is a question about naming really.
I'm undecided as to whether we should actually distribute these things but I
am very keen that our distribution(s) are structured so that people can
depend on sensible chunks of function rather than all of it. Do we
anticipate that there will be groups of function here that aren't named
distribution, e.g. tuscany-extension-implementation-bpel or
tuscany-extension-binding-jms so that people can include manifests for
individual extensions rather than larger groups of them?

I'll post more as they come to mind.

Simon

[1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html

Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

a) I'm really puzzled. Have you ever looked into the "all" distribution that 
the current code produces? I don't see big difference than what you have 
said on the ML.

    1) It's similar with the 1.x all-in-one distribution without the 
tuscany-all jar
    2) 3rd-party non-OSGi jars are placed under individual folders to form 
OSGi bundles
    3) Instead of one manifest.jar, it comes with multiple 
tuscany-distribution-* folders that group the manifest.jar and osgi 
configurations for a collection of functions.

We now build the "all" distribution based on "core" and "ejava". And I also 
mentioned in the PDF doc that we will only ship the "all" distro for 2.x M1.

PLEASE elaborate what you are not happy with the "all" distro. I might have 
missed or misunderstood the points.

b) I'm sad too. It seems that my hours of work warrants some critics based a 
misinterpretation on a smiley without good facts. I really meant to welcome 
feedbacks from the community with the smiley.

Thanks,
Raymond

From: ant elder
Sent: Saturday, January 24, 2009 1:15 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples 
with the distributions


That seems to ignore what we agreed and has been said on the threads about 
this, and i guess you know that as you said "(IMO :-)". Sad that flouting 
consensus warrants a smiley.

   ...ant


On Fri, Jan 23, 2009 at 5:25 PM, Raymond Feng <en...@gmail.com> wrote:

Hi,

I have made some good progress (IMO :-) to bring up the distribution story 
in 2.x toward M1. The current "all" distribution contains "core" and "ejava" 
(binding.rmi only). You can try to build it with the following command:

cd sca/distribution
mvn clean install -Pdistribution

Please build the tools and modules first. tuscany-maven-bundle-plugin is 
used to produce some parts of the distribution.

The current story is documented at [1].

Feedbacks are welcome.

[1] 
http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1

Thanks,
Raymond


From: ant elder
Sent: Friday, January 23, 2009 2:03 AM
To: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions





On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com> 
wrote:




On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:




On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com> 
wrote:




On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:




On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com> 
wrote:




On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> wrote:

I asked early but no ones replied so I'm still missing the point of what 
these manifest classpaths would be used for? If there we use some type of 
launcher there is no need for a manifest classpath is there? A problem with 
that one below is that it includes more than just the core dependencies 
which makes it a little misleading.

   ...ant



On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com> wrote:

I have added the support to generate the manifest jars which contain the 
classpath for a given distribution. JSE users can just use the manifest jar 
alone to point to the distro he/she wants. For example, to use "core" 
distro, we generate "startup/tuscany-distribution-core-manifest.jar" with 
the following MANIFEST.MF. Please note it works well with the flat structure 
under "modules" for all the jars.

Manifest-Version: 1.0
Implementation-Vendor: The Apache Software Foundation
Implementation-Title: Apache Tuscany SCA Core Distribution
Implementation-Version: 2.0-SNAPSHOT
Implementation-Vendor-Id: org.apache
Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
/modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
/modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
.1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
.6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar


From: ant elder
Sent: Wednesday, January 21, 2009 1:36 AM

To: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions





On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:

Hi,

More comments inline.

Thanks,
Raymond


From: Simon Laws
Sent: Tuesday, January 20, 2009 8:41 AM
To: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions



Agreed. It's just a local repo. Do you think adding a little structure add 
technical difficulty or is a flat structure a personal preference? I'm 
interested in situations like this where we have some people who want 
solution A and others want solution B (where both solutions are valid). How 
do we come to a conclusion? In the past this has tended to stall us a little 
so this is a good chance to see if we can do better;-)

I'm seeing some technical issues:

1) Adding a little structure will make the distribution incompatible with 
Equinox OSGi launcher and PDE target platform.

I believe this is a statement about how it works just now rather than a 
statement about blockers for change.

I more view it as a block for introducing structural changes. The current 
layout can be directly used as an Equinox installation of bundles or PDE 
target location.

That seems like FUD to me, I don't see any reason it can't be made to work 
with either structure. This seems to be the main objection so if we can show 
it can work then can we lay this debate to rest?

 ...ant





I had planned to use the manfiest as the compile dependency in sample ant 
scripts. It seems a useful shorthand to describe a feature.

What i'm not understanding is why you'd want a compile dependency on a 
"feature"?  I can see you might want tot use the specific dependencies you 
know you need, or use wildcards to add all the jars in a folder, or use a 
launcher to manage the dependencies for you. But as a feature includes 
multiple different extension types why would you want to use it as a 
dependency?

   ...ant





"But as a feature includes multiple different extension types why would you 
want to use it as a dependency? "


Well it depends what you think a feature is.

Some here think features have lots of things in them, others think they 
could have a few things in them. I fall into the latter category.

Some people think that features should be separately distributable some 
think that people will mostly want the all jar. Again I fall into the latter 
category but I would like to build the all jar out of a separate set of 
features rather than all the individual jars.

Why do I want to do that? So that I can refer to individual features from my 
Ant scripts.

Simon



I've understood we've been using the term "feature" to mean the collection 
of distributions as was done in the equinox fork. If we change the term to 
mean something thats more tightly coupled to each individual extension that 
starts to make more sense to me. I'd still wonder if we really need them if 
we change to using a launcher, and if we had a structured lib folder then 
there doesn't seem any need at all.

So what a proposal could be for 2.0 M1 would be have a single "all" type 
distribution thats just like the 1.x distribution but instead of a single 
tuscany-all jar and manifest jar have multiple manifest jars for each 
extension (or group of extensions if there are some really tightly coupled 
ones).

   ...ant







Sounds good to me. It gives us a place to start so we can establish how each 
type of user we anticipate will exploit the distribution. Doing this will 
hopefully give us a more complete view. So how about we set this up, close 
this thread and start a new thread(s) to discuss how each of the different 
launching options we have already started to discuss will work.

Simon


Ok if i don't hear any objections I'll start doing this first thing next 
week.

   ...ant 

Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

That seems to ignore what we agreed and has been said on the threads about
this, and i guess you know that as you said "(IMO :-)". Sad that flouting
consensus warrants a smiley.

   ...ant

On Fri, Jan 23, 2009 at 5:25 PM, Raymond Feng <en...@gmail.com> wrote:

>  Hi,
>
> I have made some good progress (IMO :-) to bring up the distribution story
> in 2.x toward M1. The current "all" distribution contains "core" and "ejava"
> (binding.rmi only). You can try to build it with the following command:
>
> cd sca/distribution
> mvn clean install -Pdistribution
>
> Please build the tools and modules first. tuscany-maven-bundle-plugin is
> used to produce some parts of the distribution.
>
> The current story is documented at [1].
>
> Feedbacks are welcome.
>
> [1]
> http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1
>
> Thanks,
> Raymond
>
>  *From:* ant elder <an...@apache.org>
> *Sent:* Friday, January 23, 2009 2:03 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: [2.0] Align samples with the distributions
>
>
>
> On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org>wrote:
>>>>
>>>>>
>>>>>
>>>>>   On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <
>>>>> simonslaws@googlemail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com>wrote:
>>>>>>
>>>>>>> I asked early but no ones replied so I'm still missing the point of
>>>>>>> what these manifest classpaths would be used for? If there we use some type
>>>>>>> of launcher there is no need for a manifest classpath is there? A problem
>>>>>>> with that one below is that it includes more than just the core dependencies
>>>>>>> which makes it a little misleading.
>>>>>>>
>>>>>>>    ...ant
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com>wrote:
>>>>>>>
>>>>>>>> I have added the support to generate the manifest jars which contain
>>>>>>>> the classpath for a given distribution. JSE users can just use the manifest
>>>>>>>> jar alone to point to the distro he/she wants. For example, to use "core"
>>>>>>>> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
>>>>>>>> the following MANIFEST.MF. Please note it works well with the flat structure
>>>>>>>> under "modules" for all the jars.
>>>>>>>>
>>>>>>>> Manifest-Version: 1.0
>>>>>>>> Implementation-Vendor: The Apache Software Foundation
>>>>>>>> Implementation-Title: Apache Tuscany SCA Core Distribution
>>>>>>>> Implementation-Version: 2.0-SNAPSHOT
>>>>>>>> Implementation-Vendor-Id: org.apache
>>>>>>>> Class-Path:
>>>>>>>> ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
>>>>>>>>
>>>>>>>> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
>>>>>>>>
>>>>>>>> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
>>>>>>>>
>>>>>>>> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
>>>>>>>>
>>>>>>>> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
>>>>>>>>
>>>>>>>> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
>>>>>>>>
>>>>>>>> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
>>>>>>>>
>>>>>>>> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
>>>>>>>>
>>>>>>>> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
>>>>>>>>
>>>>>>>> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
>>>>>>>>
>>>>>>>> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
>>>>>>>>
>>>>>>>> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
>>>>>>>>
>>>>>>>> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
>>>>>>>>
>>>>>>>> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
>>>>>>>>
>>>>>>>> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
>>>>>>>>
>>>>>>>> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
>>>>>>>>
>>>>>>>> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
>>>>>>>>
>>>>>>>> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
>>>>>>>>
>>>>>>>> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
>>>>>>>>
>>>>>>>> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
>>>>>>>>
>>>>>>>> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
>>>>>>>>
>>>>>>>> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
>>>>>>>>
>>>>>>>> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
>>>>>>>>
>>>>>>>> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
>>>>>>>>
>>>>>>>> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
>>>>>>>>
>>>>>>>> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
>>>>>>>>
>>>>>>>> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
>>>>>>>>
>>>>>>>> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
>>>>>>>>
>>>>>>>> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
>>>>>>>>
>>>>>>>> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
>>>>>>>>
>>>>>>>> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
>>>>>>>>
>>>>>>>> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
>>>>>>>>
>>>>>>>> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
>>>>>>>>
>>>>>>>> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
>>>>>>>>
>>>>>>>> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
>>>>>>>>
>>>>>>>> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
>>>>>>>>
>>>>>>>> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
>>>>>>>>
>>>>>>>> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
>>>>>>>>
>>>>>>>> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
>>>>>>>>
>>>>>>>> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
>>>>>>>>
>>>>>>>> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
>>>>>>>>
>>>>>>>> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
>>>>>>>>
>>>>>>>> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
>>>>>>>>
>>>>>>>> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
>>>>>>>>
>>>>>>>> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
>>>>>>>> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>>>>>>>>
>>>>>>>>
>>>>>>>> From: ant elder
>>>>>>>> Sent: Wednesday, January 21, 2009 1:36 AM
>>>>>>>>
>>>>>>>> To: dev@tuscany.apache.org
>>>>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> More comments inline.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Raymond
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Simon Laws
>>>>>>>> Sent: Tuesday, January 20, 2009 8:41 AM
>>>>>>>> To: dev@tuscany.apache.org
>>>>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Agreed. It's just a local repo. Do you think adding a little
>>>>>>>> structure add technical difficulty or is a flat structure a personal
>>>>>>>> preference? I'm interested in situations like this where we have some people
>>>>>>>> who want solution A and others want solution B (where both solutions are
>>>>>>>> valid). How do we come to a conclusion? In the past this has tended to stall
>>>>>>>> us a little so this is a good chance to see if we can do better;-)
>>>>>>>>
>>>>>>>> I'm seeing some technical issues:
>>>>>>>>
>>>>>>>> 1) Adding a little structure will make the distribution incompatible
>>>>>>>> with Equinox OSGi launcher and PDE target platform.
>>>>>>>>
>>>>>>>> I believe this is a statement about how it works just now rather
>>>>>>>> than a statement about blockers for change.
>>>>>>>>
>>>>>>>> I more view it as a block for introducing structural changes. The
>>>>>>>> current layout can be directly used as an Equinox installation of bundles or
>>>>>>>> PDE target location.
>>>>>>>>
>>>>>>>> That seems like FUD to me, I don't see any reason it can't be made
>>>>>>>> to work with either structure. This seems to be the main objection so if we
>>>>>>>> can show it can work then can we lay this debate to rest?
>>>>>>>>
>>>>>>>>  ...ant
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I had planned to use the manfiest as the compile dependency in sample
>>>>>> ant scripts. It seems a useful shorthand to describe a feature.
>>>>>
>>>>>
>>>>> What i'm not understanding is why you'd want a compile dependency on a
>>>>> "feature"?  I can see you might want tot use the specific dependencies you
>>>>> know you need, or use wildcards to add all the jars in a folder, or use a
>>>>> launcher to manage the dependencies for you. But as a feature includes
>>>>> multiple different extension types why would you want to use it as a
>>>>> dependency?
>>>>>
>>>>>    ...ant
>>>>>
>>>>>
>>>>>
>>>> "But as a feature includes multiple different extension types why would
>>>> you want to use it as a dependency? "
>>>>
>>>> Well it depends what you think a feature is.
>>>>
>>>> Some here think features have lots of things in them, others think they
>>>> could have a few things in them. I fall into the latter category.
>>>>
>>>> Some people think that features should be separately distributable some
>>>> think that people will mostly want the all jar. Again I fall into the latter
>>>> category but I would like to build the all jar out of a separate set of
>>>> features rather than all the individual jars.
>>>>
>>>> Why do I want to do that? So that I can refer to individual features
>>>> from my Ant scripts.
>>>>
>>>> Simon
>>>>
>>>
>>> I've understood we've been using the term "feature" to mean the
>>> collection of distributions as was done in the equinox fork. If we change
>>> the term to mean something thats more tightly coupled to each individual
>>> extension that starts to make more sense to me. I'd still wonder if we
>>> really need them if we change to using a launcher, and if we had a
>>> structured lib folder then there doesn't seem any need at all.
>>>
>>> So what a proposal could be for 2.0 M1 would be have a single "all" type
>>> distribution thats just like the 1.x distribution but instead of a single
>>> tuscany-all jar and manifest jar have multiple manifest jars for each
>>> extension (or group of extensions if there are some really tightly coupled
>>> ones).
>>>
>>>    ...ant
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> Sounds good to me. It gives us a place to start so we can establish how
>> each type of user we anticipate will exploit the distribution. Doing this
>> will hopefully give us a more complete view. So how about we set this up,
>> close this thread and start a new thread(s) to discuss how each of the
>> different launching options we have already started to discuss will work.
>>
>> Simon
>>
>
> Ok if i don't hear any objections I'll start doing this first thing next
> week.
>
>    ...ant
>

[2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

Hi,

I have made some good progress (IMO :-) to bring up the distribution story in 2.x toward M1. The current "all" distribution contains "core" and "ejava" (binding.rmi only). You can try to build it with the following command:

cd sca/distribution
mvn clean install -Pdistribution

Please build the tools and modules first. tuscany-maven-bundle-plugin is used to produce some parts of the distribution.

The current story is documented at [1].

Feedbacks are welcome.

[1] http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1

Thanks,
Raymond


From: ant elder 
Sent: Friday, January 23, 2009 2:03 AM
To: dev@tuscany.apache.org 
Subject: Re: [2.0] Align samples with the distributions





On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com> wrote:




  On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:




    On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com> wrote:




      On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:




        On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com> wrote:




          On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> wrote:

            I asked early but no ones replied so I'm still missing the point of what these manifest classpaths would be used for? If there we use some type of launcher there is no need for a manifest classpath is there? A problem with that one below is that it includes more than just the core dependencies which makes it a little misleading.

               ...ant 



            On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com> wrote:

              I have added the support to generate the manifest jars which contain the classpath for a given distribution. JSE users can just use the manifest jar alone to point to the distro he/she wants. For example, to use "core" distro, we generate "startup/tuscany-distribution-core-manifest.jar" with the following MANIFEST.MF. Please note it works well with the flat structure under "modules" for all the jars.

              Manifest-Version: 1.0
              Implementation-Vendor: The Apache Software Foundation
              Implementation-Title: Apache Tuscany SCA Core Distribution
              Implementation-Version: 2.0-SNAPSHOT
              Implementation-Vendor-Id: org.apache
              Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
              y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
              30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
              ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
              ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
              y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
              ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
              jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
              her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
              /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
              pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
              r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
              re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
              NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
              sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
              0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
              /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
              i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
              odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
              0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
              OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
              modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
              p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
              dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
              e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
              OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
              uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
              bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
              odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
              r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
              l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
              jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
              s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
              ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
              equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
              ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
              .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
              modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
              atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
              NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
              uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
              .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
              mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
              mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
              les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
              l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar


              From: ant elder
              Sent: Wednesday, January 21, 2009 1:36 AM 

              To: dev@tuscany.apache.org
              Subject: Re: [2.0] Align samples with the distributions





              On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:

              Hi,

              More comments inline.

              Thanks,
              Raymond


              From: Simon Laws
              Sent: Tuesday, January 20, 2009 8:41 AM
              To: dev@tuscany.apache.org
              Subject: Re: [2.0] Align samples with the distributions



              Agreed. It's just a local repo. Do you think adding a little structure add technical difficulty or is a flat structure a personal preference? I'm interested in situations like this where we have some people who want solution A and others want solution B (where both solutions are valid). How do we come to a conclusion? In the past this has tended to stall us a little so this is a good chance to see if we can do better;-)

              I'm seeing some technical issues:

              1) Adding a little structure will make the distribution incompatible with Equinox OSGi launcher and PDE target platform.

              I believe this is a statement about how it works just now rather than a statement about blockers for change.

              I more view it as a block for introducing structural changes. The current layout can be directly used as an Equinox installation of bundles or PDE target location.

              That seems like FUD to me, I don't see any reason it can't be made to work with either structure. This seems to be the main objection so if we can show it can work then can we lay this debate to rest?

               ...ant 





          I had planned to use the manfiest as the compile dependency in sample ant scripts. It seems a useful shorthand to describe a feature. 

        What i'm not understanding is why you'd want a compile dependency on a "feature"?  I can see you might want tot use the specific dependencies you know you need, or use wildcards to add all the jars in a folder, or use a launcher to manage the dependencies for you. But as a feature includes multiple different extension types why would you want to use it as a dependency? 

           ...ant





      "But as a feature includes multiple different extension types why would you want to use it as a dependency? "


      Well it depends what you think a feature is. 

      Some here think features have lots of things in them, others think they could have a few things in them. I fall into the latter category. 

      Some people think that features should be separately distributable some think that people will mostly want the all jar. Again I fall into the latter category but I would like to build the all jar out of a separate set of features rather than all the individual jars. 

      Why do I want to do that? So that I can refer to individual features from my Ant scripts. 

      Simon



    I've understood we've been using the term "feature" to mean the collection of distributions as was done in the equinox fork. If we change the term to mean something thats more tightly coupled to each individual extension that starts to make more sense to me. I'd still wonder if we really need them if we change to using a launcher, and if we had a structured lib folder then there doesn't seem any need at all.

    So what a proposal could be for 2.0 M1 would be have a single "all" type distribution thats just like the 1.x distribution but instead of a single tuscany-all jar and manifest jar have multiple manifest jars for each extension (or group of extensions if there are some really tightly coupled ones).

       ...ant

      

      

     

  Sounds good to me. It gives us a place to start so we can establish how each type of user we anticipate will exploit the distribution. Doing this will hopefully give us a more complete view. So how about we set this up, close this thread and start a new thread(s) to discuss how each of the different launching options we have already started to discuss will work. 

  Simon


Ok if i don't hear any objections I'll start doing this first thing next week.

   ...ant

Re: [2.0] Align samples with the distributions

[ant elder <an...@apache.org>]

On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <simonslaws@googlemail.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com>wrote:
>>>>>
>>>>>> I asked early but no ones replied so I'm still missing the point of
>>>>>> what these manifest classpaths would be used for? If there we use some type
>>>>>> of launcher there is no need for a manifest classpath is there? A problem
>>>>>> with that one below is that it includes more than just the core dependencies
>>>>>> which makes it a little misleading.
>>>>>>
>>>>>>    ...ant
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com>wrote:
>>>>>>
>>>>>>> I have added the support to generate the manifest jars which contain
>>>>>>> the classpath for a given distribution. JSE users can just use the manifest
>>>>>>> jar alone to point to the distro he/she wants. For example, to use "core"
>>>>>>> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
>>>>>>> the following MANIFEST.MF. Please note it works well with the flat structure
>>>>>>> under "modules" for all the jars.
>>>>>>>
>>>>>>> Manifest-Version: 1.0
>>>>>>> Implementation-Vendor: The Apache Software Foundation
>>>>>>> Implementation-Title: Apache Tuscany SCA Core Distribution
>>>>>>> Implementation-Version: 2.0-SNAPSHOT
>>>>>>> Implementation-Vendor-Id: org.apache
>>>>>>> Class-Path:
>>>>>>> ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
>>>>>>> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
>>>>>>> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
>>>>>>> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
>>>>>>> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
>>>>>>> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
>>>>>>> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
>>>>>>> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
>>>>>>> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
>>>>>>> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
>>>>>>> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
>>>>>>> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
>>>>>>> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
>>>>>>> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
>>>>>>> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
>>>>>>> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
>>>>>>> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
>>>>>>> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
>>>>>>> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
>>>>>>> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
>>>>>>> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
>>>>>>> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
>>>>>>> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
>>>>>>> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
>>>>>>> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
>>>>>>> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
>>>>>>> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
>>>>>>> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
>>>>>>> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
>>>>>>> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
>>>>>>> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
>>>>>>> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
>>>>>>> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
>>>>>>> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
>>>>>>> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
>>>>>>> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
>>>>>>> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
>>>>>>> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
>>>>>>> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
>>>>>>> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
>>>>>>> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
>>>>>>> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
>>>>>>> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
>>>>>>> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
>>>>>>> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
>>>>>>> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>>>>>>>
>>>>>>>
>>>>>>> From: ant elder
>>>>>>> Sent: Wednesday, January 21, 2009 1:36 AM
>>>>>>>
>>>>>>> To: dev@tuscany.apache.org
>>>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> More comments inline.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Raymond
>>>>>>>
>>>>>>>
>>>>>>> From: Simon Laws
>>>>>>> Sent: Tuesday, January 20, 2009 8:41 AM
>>>>>>> To: dev@tuscany.apache.org
>>>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Agreed. It's just a local repo. Do you think adding a little
>>>>>>> structure add technical difficulty or is a flat structure a personal
>>>>>>> preference? I'm interested in situations like this where we have some people
>>>>>>> who want solution A and others want solution B (where both solutions are
>>>>>>> valid). How do we come to a conclusion? In the past this has tended to stall
>>>>>>> us a little so this is a good chance to see if we can do better;-)
>>>>>>>
>>>>>>> I'm seeing some technical issues:
>>>>>>>
>>>>>>> 1) Adding a little structure will make the distribution incompatible
>>>>>>> with Equinox OSGi launcher and PDE target platform.
>>>>>>>
>>>>>>> I believe this is a statement about how it works just now rather than
>>>>>>> a statement about blockers for change.
>>>>>>>
>>>>>>> I more view it as a block for introducing structural changes. The
>>>>>>> current layout can be directly used as an Equinox installation of bundles or
>>>>>>> PDE target location.
>>>>>>>
>>>>>>> That seems like FUD to me, I don't see any reason it can't be made to
>>>>>>> work with either structure. This seems to be the main objection so if we can
>>>>>>> show it can work then can we lay this debate to rest?
>>>>>>>
>>>>>>>  ...ant
>>>>>>>
>>>>>>
>>>>>>
>>>>> I had planned to use the manfiest as the compile dependency in sample
>>>>> ant scripts. It seems a useful shorthand to describe a feature.
>>>>
>>>>
>>>> What i'm not understanding is why you'd want a compile dependency on a
>>>> "feature"?  I can see you might want tot use the specific dependencies you
>>>> know you need, or use wildcards to add all the jars in a folder, or use a
>>>> launcher to manage the dependencies for you. But as a feature includes
>>>> multiple different extension types why would you want to use it as a
>>>> dependency?
>>>>
>>>>    ...ant
>>>>
>>>>
>>>>
>>> "But as a feature includes multiple different extension types why would
>>> you want to use it as a dependency? "
>>>
>>> Well it depends what you think a feature is.
>>>
>>> Some here think features have lots of things in them, others think they
>>> could have a few things in them. I fall into the latter category.
>>>
>>> Some people think that features should be separately distributable some
>>> think that people will mostly want the all jar. Again I fall into the latter
>>> category but I would like to build the all jar out of a separate set of
>>> features rather than all the individual jars.
>>>
>>> Why do I want to do that? So that I can refer to individual features from
>>> my Ant scripts.
>>>
>>> Simon
>>>
>>
>> I've understood we've been using the term "feature" to mean the collection
>> of distributions as was done in the equinox fork. If we change the term to
>> mean something thats more tightly coupled to each individual extension that
>> starts to make more sense to me. I'd still wonder if we really need them if
>> we change to using a launcher, and if we had a structured lib folder then
>> there doesn't seem any need at all.
>>
>> So what a proposal could be for 2.0 M1 would be have a single "all" type
>> distribution thats just like the 1.x distribution but instead of a single
>> tuscany-all jar and manifest jar have multiple manifest jars for each
>> extension (or group of extensions if there are some really tightly coupled
>> ones).
>>
>>    ...ant
>>
>>
>>
>>
>>
>>
>>
> Sounds good to me. It gives us a place to start so we can establish how
> each type of user we anticipate will exploit the distribution. Doing this
> will hopefully give us a more complete view. So how about we set this up,
> close this thread and start a new thread(s) to discuss how each of the
> different launching options we have already started to discuss will work.
>
> Simon
>

Ok if i don't hear any objections I'll start doing this first thing next
week.

   ...ant

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:

>
>
> On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> wrote:
>>>>
>>>>> I asked early but no ones replied so I'm still missing the point of
>>>>> what these manifest classpaths would be used for? If there we use some type
>>>>> of launcher there is no need for a manifest classpath is there? A problem
>>>>> with that one below is that it includes more than just the core dependencies
>>>>> which makes it a little misleading.
>>>>>
>>>>>    ...ant
>>>>>
>>>>>
>>>>> On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com>wrote:
>>>>>
>>>>>> I have added the support to generate the manifest jars which contain
>>>>>> the classpath for a given distribution. JSE users can just use the manifest
>>>>>> jar alone to point to the distro he/she wants. For example, to use "core"
>>>>>> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
>>>>>> the following MANIFEST.MF. Please note it works well with the flat structure
>>>>>> under "modules" for all the jars.
>>>>>>
>>>>>> Manifest-Version: 1.0
>>>>>> Implementation-Vendor: The Apache Software Foundation
>>>>>> Implementation-Title: Apache Tuscany SCA Core Distribution
>>>>>> Implementation-Version: 2.0-SNAPSHOT
>>>>>> Implementation-Vendor-Id: org.apache
>>>>>> Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
>>>>>> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
>>>>>> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
>>>>>> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
>>>>>> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
>>>>>> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
>>>>>> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
>>>>>> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
>>>>>> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
>>>>>> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
>>>>>> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
>>>>>> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
>>>>>> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
>>>>>> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
>>>>>> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
>>>>>> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
>>>>>> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
>>>>>> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
>>>>>> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
>>>>>> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
>>>>>> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
>>>>>> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
>>>>>> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
>>>>>> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
>>>>>> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
>>>>>> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
>>>>>> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
>>>>>> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
>>>>>> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
>>>>>> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
>>>>>> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
>>>>>> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
>>>>>> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
>>>>>> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
>>>>>> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
>>>>>> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
>>>>>> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
>>>>>> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
>>>>>> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
>>>>>> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
>>>>>> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
>>>>>> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
>>>>>> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
>>>>>> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
>>>>>> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
>>>>>> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>>>>>>
>>>>>>
>>>>>> From: ant elder
>>>>>> Sent: Wednesday, January 21, 2009 1:36 AM
>>>>>>
>>>>>> To: dev@tuscany.apache.org
>>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> More comments inline.
>>>>>>
>>>>>> Thanks,
>>>>>> Raymond
>>>>>>
>>>>>>
>>>>>> From: Simon Laws
>>>>>> Sent: Tuesday, January 20, 2009 8:41 AM
>>>>>> To: dev@tuscany.apache.org
>>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>>
>>>>>>
>>>>>>
>>>>>> Agreed. It's just a local repo. Do you think adding a little structure
>>>>>> add technical difficulty or is a flat structure a personal preference? I'm
>>>>>> interested in situations like this where we have some people who want
>>>>>> solution A and others want solution B (where both solutions are valid). How
>>>>>> do we come to a conclusion? In the past this has tended to stall us a little
>>>>>> so this is a good chance to see if we can do better;-)
>>>>>>
>>>>>> I'm seeing some technical issues:
>>>>>>
>>>>>> 1) Adding a little structure will make the distribution incompatible
>>>>>> with Equinox OSGi launcher and PDE target platform.
>>>>>>
>>>>>> I believe this is a statement about how it works just now rather than
>>>>>> a statement about blockers for change.
>>>>>>
>>>>>> I more view it as a block for introducing structural changes. The
>>>>>> current layout can be directly used as an Equinox installation of bundles or
>>>>>> PDE target location.
>>>>>>
>>>>>> That seems like FUD to me, I don't see any reason it can't be made to
>>>>>> work with either structure. This seems to be the main objection so if we can
>>>>>> show it can work then can we lay this debate to rest?
>>>>>>
>>>>>>  ...ant
>>>>>>
>>>>>
>>>>>
>>>> I had planned to use the manfiest as the compile dependency in sample
>>>> ant scripts. It seems a useful shorthand to describe a feature.
>>>
>>>
>>> What i'm not understanding is why you'd want a compile dependency on a
>>> "feature"?  I can see you might want tot use the specific dependencies you
>>> know you need, or use wildcards to add all the jars in a folder, or use a
>>> launcher to manage the dependencies for you. But as a feature includes
>>> multiple different extension types why would you want to use it as a
>>> dependency?
>>>
>>>    ...ant
>>>
>>>
>>>
>> "But as a feature includes multiple different extension types why would
>> you want to use it as a dependency? "
>>
>> Well it depends what you think a feature is.
>>
>> Some here think features have lots of things in them, others think they
>> could have a few things in them. I fall into the latter category.
>>
>> Some people think that features should be separately distributable some
>> think that people will mostly want the all jar. Again I fall into the latter
>> category but I would like to build the all jar out of a separate set of
>> features rather than all the individual jars.
>>
>> Why do I want to do that? So that I can refer to individual features from
>> my Ant scripts.
>>
>> Simon
>>
>
> I've understood we've been using the term "feature" to mean the collection
> of distributions as was done in the equinox fork. If we change the term to
> mean something thats more tightly coupled to each individual extension that
> starts to make more sense to me. I'd still wonder if we really need them if
> we change to using a launcher, and if we had a structured lib folder then
> there doesn't seem any need at all.
>
> So what a proposal could be for 2.0 M1 would be have a single "all" type
> distribution thats just like the 1.x distribution but instead of a single
> tuscany-all jar and manifest jar have multiple manifest jars for each
> extension (or group of extensions if there are some really tightly coupled
> ones).
>
>    ...ant
>
>
>
>
>
>
>
Sounds good to me. It gives us a place to start so we can establish how each
type of user we anticipate will exploit the distribution. Doing this will
hopefully give us a more complete view. So how about we set this up, close
this thread and start a new thread(s) to discuss how each of the different
launching options we have already started to discuss will work.

Simon

Re: [2.0] Align samples with the distributions

[ant elder <an...@apache.org>]

On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>> I asked early but no ones replied so I'm still missing the point of what
>>>> these manifest classpaths would be used for? If there we use some type of
>>>> launcher there is no need for a manifest classpath is there? A problem with
>>>> that one below is that it includes more than just the core dependencies
>>>> which makes it a little misleading.
>>>>
>>>>    ...ant
>>>>
>>>>
>>>> On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com>wrote:
>>>>
>>>>> I have added the support to generate the manifest jars which contain
>>>>> the classpath for a given distribution. JSE users can just use the manifest
>>>>> jar alone to point to the distro he/she wants. For example, to use "core"
>>>>> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
>>>>> the following MANIFEST.MF. Please note it works well with the flat structure
>>>>> under "modules" for all the jars.
>>>>>
>>>>> Manifest-Version: 1.0
>>>>> Implementation-Vendor: The Apache Software Foundation
>>>>> Implementation-Title: Apache Tuscany SCA Core Distribution
>>>>> Implementation-Version: 2.0-SNAPSHOT
>>>>> Implementation-Vendor-Id: org.apache
>>>>> Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
>>>>> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
>>>>> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
>>>>> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
>>>>> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
>>>>> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
>>>>> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
>>>>> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
>>>>> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
>>>>> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
>>>>> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
>>>>> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
>>>>> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
>>>>> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
>>>>> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
>>>>> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
>>>>> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
>>>>> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
>>>>> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
>>>>> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
>>>>> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
>>>>> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
>>>>> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
>>>>> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
>>>>> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
>>>>> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
>>>>> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
>>>>> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
>>>>> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
>>>>> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
>>>>> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
>>>>> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
>>>>> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
>>>>> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
>>>>> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
>>>>> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
>>>>> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
>>>>> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
>>>>> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
>>>>> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
>>>>> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
>>>>> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
>>>>> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
>>>>> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
>>>>> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
>>>>> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>>>>>
>>>>>
>>>>> From: ant elder
>>>>> Sent: Wednesday, January 21, 2009 1:36 AM
>>>>>
>>>>> To: dev@tuscany.apache.org
>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> More comments inline.
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>>
>>>>> From: Simon Laws
>>>>> Sent: Tuesday, January 20, 2009 8:41 AM
>>>>> To: dev@tuscany.apache.org
>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>
>>>>>
>>>>>
>>>>> Agreed. It's just a local repo. Do you think adding a little structure
>>>>> add technical difficulty or is a flat structure a personal preference? I'm
>>>>> interested in situations like this where we have some people who want
>>>>> solution A and others want solution B (where both solutions are valid). How
>>>>> do we come to a conclusion? In the past this has tended to stall us a little
>>>>> so this is a good chance to see if we can do better;-)
>>>>>
>>>>> I'm seeing some technical issues:
>>>>>
>>>>> 1) Adding a little structure will make the distribution incompatible
>>>>> with Equinox OSGi launcher and PDE target platform.
>>>>>
>>>>> I believe this is a statement about how it works just now rather than a
>>>>> statement about blockers for change.
>>>>>
>>>>> I more view it as a block for introducing structural changes. The
>>>>> current layout can be directly used as an Equinox installation of bundles or
>>>>> PDE target location.
>>>>>
>>>>> That seems like FUD to me, I don't see any reason it can't be made to
>>>>> work with either structure. This seems to be the main objection so if we can
>>>>> show it can work then can we lay this debate to rest?
>>>>>
>>>>>  ...ant
>>>>>
>>>>
>>>>
>>> I had planned to use the manfiest as the compile dependency in sample ant
>>> scripts. It seems a useful shorthand to describe a feature.
>>
>>
>> What i'm not understanding is why you'd want a compile dependency on a
>> "feature"?  I can see you might want tot use the specific dependencies you
>> know you need, or use wildcards to add all the jars in a folder, or use a
>> launcher to manage the dependencies for you. But as a feature includes
>> multiple different extension types why would you want to use it as a
>> dependency?
>>
>>    ...ant
>>
>>
>>
> "But as a feature includes multiple different extension types why would you
> want to use it as a dependency? "
>
> Well it depends what you think a feature is.
>
> Some here think features have lots of things in them, others think they
> could have a few things in them. I fall into the latter category.
>
> Some people think that features should be separately distributable some
> think that people will mostly want the all jar. Again I fall into the latter
> category but I would like to build the all jar out of a separate set of
> features rather than all the individual jars.
>
> Why do I want to do that? So that I can refer to individual features from
> my Ant scripts.
>
> Simon
>

I've understood we've been using the term "feature" to mean the collection
of distributions as was done in the equinox fork. If we change the term to
mean something thats more tightly coupled to each individual extension that
starts to make more sense to me. I'd still wonder if we really need them if
we change to using a launcher, and if we had a structured lib folder then
there doesn't seem any need at all.

So what a proposal could be for 2.0 M1 would be have a single "all" type
distribution thats just like the 1.x distribution but instead of a single
tuscany-all jar and manifest jar have multiple manifest jars for each
extension (or group of extensions if there are some really tightly coupled
ones).

   ...ant

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:

>
>
> On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> wrote:
>>
>>> I asked early but no ones replied so I'm still missing the point of what
>>> these manifest classpaths would be used for? If there we use some type of
>>> launcher there is no need for a manifest classpath is there? A problem with
>>> that one below is that it includes more than just the core dependencies
>>> which makes it a little misleading.
>>>
>>>    ...ant
>>>
>>>
>>> On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com>wrote:
>>>
>>>> I have added the support to generate the manifest jars which contain the
>>>> classpath for a given distribution. JSE users can just use the manifest jar
>>>> alone to point to the distro he/she wants. For example, to use "core"
>>>> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
>>>> the following MANIFEST.MF. Please note it works well with the flat structure
>>>> under "modules" for all the jars.
>>>>
>>>> Manifest-Version: 1.0
>>>> Implementation-Vendor: The Apache Software Foundation
>>>> Implementation-Title: Apache Tuscany SCA Core Distribution
>>>> Implementation-Version: 2.0-SNAPSHOT
>>>> Implementation-Vendor-Id: org.apache
>>>> Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
>>>> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
>>>> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
>>>> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
>>>> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
>>>> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
>>>> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
>>>> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
>>>> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
>>>> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
>>>> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
>>>> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
>>>> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
>>>> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
>>>> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
>>>> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
>>>> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
>>>> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
>>>> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
>>>> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
>>>> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
>>>> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
>>>> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
>>>> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
>>>> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
>>>> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
>>>> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
>>>> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
>>>> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
>>>> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
>>>> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
>>>> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
>>>> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
>>>> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
>>>> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
>>>> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
>>>> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
>>>> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
>>>> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
>>>> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
>>>> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
>>>> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
>>>> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
>>>> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
>>>> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
>>>> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>>>>
>>>>
>>>> From: ant elder
>>>> Sent: Wednesday, January 21, 2009 1:36 AM
>>>>
>>>> To: dev@tuscany.apache.org
>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> More comments inline.
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>>
>>>> From: Simon Laws
>>>> Sent: Tuesday, January 20, 2009 8:41 AM
>>>> To: dev@tuscany.apache.org
>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>
>>>>
>>>>
>>>> Agreed. It's just a local repo. Do you think adding a little structure
>>>> add technical difficulty or is a flat structure a personal preference? I'm
>>>> interested in situations like this where we have some people who want
>>>> solution A and others want solution B (where both solutions are valid). How
>>>> do we come to a conclusion? In the past this has tended to stall us a little
>>>> so this is a good chance to see if we can do better;-)
>>>>
>>>> I'm seeing some technical issues:
>>>>
>>>> 1) Adding a little structure will make the distribution incompatible
>>>> with Equinox OSGi launcher and PDE target platform.
>>>>
>>>> I believe this is a statement about how it works just now rather than a
>>>> statement about blockers for change.
>>>>
>>>> I more view it as a block for introducing structural changes. The
>>>> current layout can be directly used as an Equinox installation of bundles or
>>>> PDE target location.
>>>>
>>>> That seems like FUD to me, I don't see any reason it can't be made to
>>>> work with either structure. This seems to be the main objection so if we can
>>>> show it can work then can we lay this debate to rest?
>>>>
>>>>  ...ant
>>>>
>>>
>>>
>> I had planned to use the manfiest as the compile dependency in sample ant
>> scripts. It seems a useful shorthand to describe a feature.
>
>
> What i'm not understanding is why you'd want a compile dependency on a
> "feature"?  I can see you might want tot use the specific dependencies you
> know you need, or use wildcards to add all the jars in a folder, or use a
> launcher to manage the dependencies for you. But as a feature includes
> multiple different extension types why would you want to use it as a
> dependency?
>
>    ...ant
>
>
>
"But as a feature includes multiple different extension types why would you
want to use it as a dependency? "

Well it depends what you think a feature is.

Some here think features have lots of things in them, others think they
could have a few things in them. I fall into the latter category.

Some people think that features should be separately distributable some
think that people will mostly want the all jar. Again I fall into the latter
category but I would like to build the all jar out of a separate set of
features rather than all the individual jars.

Why do I want to do that? So that I can refer to individual features from my
Ant scripts.

Simon

Re: [2.0] Align samples with the distributions

[ant elder <an...@apache.org>]

On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> wrote:
>
>> I asked early but no ones replied so I'm still missing the point of what
>> these manifest classpaths would be used for? If there we use some type of
>> launcher there is no need for a manifest classpath is there? A problem with
>> that one below is that it includes more than just the core dependencies
>> which makes it a little misleading.
>>
>>    ...ant
>>
>>
>> On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com>wrote:
>>
>>> I have added the support to generate the manifest jars which contain the
>>> classpath for a given distribution. JSE users can just use the manifest jar
>>> alone to point to the distro he/she wants. For example, to use "core"
>>> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
>>> the following MANIFEST.MF. Please note it works well with the flat structure
>>> under "modules" for all the jars.
>>>
>>> Manifest-Version: 1.0
>>> Implementation-Vendor: The Apache Software Foundation
>>> Implementation-Title: Apache Tuscany SCA Core Distribution
>>> Implementation-Version: 2.0-SNAPSHOT
>>> Implementation-Vendor-Id: org.apache
>>> Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
>>> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
>>> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
>>> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
>>> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
>>> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
>>> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
>>> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
>>> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
>>> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
>>> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
>>> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
>>> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
>>> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
>>> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
>>> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
>>> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
>>> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
>>> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
>>> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
>>> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
>>> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
>>> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
>>> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
>>> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
>>> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
>>> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
>>> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
>>> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
>>> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
>>> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
>>> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
>>> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
>>> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
>>> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
>>> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
>>> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
>>> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
>>> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
>>> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
>>> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
>>> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
>>> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
>>> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
>>> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
>>> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>>>
>>>
>>> From: ant elder
>>> Sent: Wednesday, January 21, 2009 1:36 AM
>>>
>>> To: dev@tuscany.apache.org
>>> Subject: Re: [2.0] Align samples with the distributions
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> More comments inline.
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>>> From: Simon Laws
>>> Sent: Tuesday, January 20, 2009 8:41 AM
>>> To: dev@tuscany.apache.org
>>> Subject: Re: [2.0] Align samples with the distributions
>>>
>>>
>>>
>>> Agreed. It's just a local repo. Do you think adding a little structure
>>> add technical difficulty or is a flat structure a personal preference? I'm
>>> interested in situations like this where we have some people who want
>>> solution A and others want solution B (where both solutions are valid). How
>>> do we come to a conclusion? In the past this has tended to stall us a little
>>> so this is a good chance to see if we can do better;-)
>>>
>>> I'm seeing some technical issues:
>>>
>>> 1) Adding a little structure will make the distribution incompatible with
>>> Equinox OSGi launcher and PDE target platform.
>>>
>>> I believe this is a statement about how it works just now rather than a
>>> statement about blockers for change.
>>>
>>> I more view it as a block for introducing structural changes. The current
>>> layout can be directly used as an Equinox installation of bundles or PDE
>>> target location.
>>>
>>> That seems like FUD to me, I don't see any reason it can't be made to
>>> work with either structure. This seems to be the main objection so if we can
>>> show it can work then can we lay this debate to rest?
>>>
>>>  ...ant
>>>
>>
>>
> I had planned to use the manfiest as the compile dependency in sample ant
> scripts. It seems a useful shorthand to describe a feature.


What i'm not understanding is why you'd want a compile dependency on a
"feature"?  I can see you might want tot use the specific dependencies you
know you need, or use wildcards to add all the jars in a folder, or use a
launcher to manage the dependencies for you. But as a feature includes
multiple different extension types why would you want to use it as a
dependency?

   ...ant

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> wrote:

> I asked early but no ones replied so I'm still missing the point of what
> these manifest classpaths would be used for? If there we use some type of
> launcher there is no need for a manifest classpath is there? A problem with
> that one below is that it includes more than just the core dependencies
> which makes it a little misleading.
>
>    ...ant
>
>
> On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> I have added the support to generate the manifest jars which contain the
>> classpath for a given distribution. JSE users can just use the manifest jar
>> alone to point to the distro he/she wants. For example, to use "core"
>> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
>> the following MANIFEST.MF. Please note it works well with the flat structure
>> under "modules" for all the jars.
>>
>> Manifest-Version: 1.0
>> Implementation-Vendor: The Apache Software Foundation
>> Implementation-Title: Apache Tuscany SCA Core Distribution
>> Implementation-Version: 2.0-SNAPSHOT
>> Implementation-Vendor-Id: org.apache
>> Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
>> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
>> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
>> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
>> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
>> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
>> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
>> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
>> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
>> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
>> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
>> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
>> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
>> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
>> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
>> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
>> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
>> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
>> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
>> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
>> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
>> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
>> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
>> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
>> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
>> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
>> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
>> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
>> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
>> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
>> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
>> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
>> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
>> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
>> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
>> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
>> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
>> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
>> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
>> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
>> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
>> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
>> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
>> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
>> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
>> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>>
>>
>> From: ant elder
>> Sent: Wednesday, January 21, 2009 1:36 AM
>>
>> To: dev@tuscany.apache.org
>> Subject: Re: [2.0] Align samples with the distributions
>>
>>
>>
>>
>>
>> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> More comments inline.
>>
>> Thanks,
>> Raymond
>>
>>
>> From: Simon Laws
>> Sent: Tuesday, January 20, 2009 8:41 AM
>> To: dev@tuscany.apache.org
>> Subject: Re: [2.0] Align samples with the distributions
>>
>>
>>
>> Agreed. It's just a local repo. Do you think adding a little structure add
>> technical difficulty or is a flat structure a personal preference? I'm
>> interested in situations like this where we have some people who want
>> solution A and others want solution B (where both solutions are valid). How
>> do we come to a conclusion? In the past this has tended to stall us a little
>> so this is a good chance to see if we can do better;-)
>>
>> I'm seeing some technical issues:
>>
>> 1) Adding a little structure will make the distribution incompatible with
>> Equinox OSGi launcher and PDE target platform.
>>
>> I believe this is a statement about how it works just now rather than a
>> statement about blockers for change.
>>
>> I more view it as a block for introducing structural changes. The current
>> layout can be directly used as an Equinox installation of bundles or PDE
>> target location.
>>
>> That seems like FUD to me, I don't see any reason it can't be made to work
>> with either structure. This seems to be the main objection so if we can show
>> it can work then can we lay this debate to rest?
>>
>>  ...ant
>>
>
>
I had planned to use the manfiest as the compile dependency in sample ant
scripts. It seems a useful shorthand to describe a feature.

Simon

Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

I asked early but no ones replied so I'm still missing the point of what
these manifest classpaths would be used for? If there we use some type of
launcher there is no need for a manifest classpath is there? A problem with
that one below is that it includes more than just the core dependencies
which makes it a little misleading.

   ...ant

On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <en...@gmail.com> wrote:

> I have added the support to generate the manifest jars which contain the
> classpath for a given distribution. JSE users can just use the manifest jar
> alone to point to the distro he/she wants. For example, to use "core"
> distro, we generate "startup/tuscany-distribution-core-manifest.jar" with
> the following MANIFEST.MF. Please note it works well with the flat structure
> under "modules" for all the jars.
>
> Manifest-Version: 1.0
> Implementation-Vendor: The Apache Software Foundation
> Implementation-Title: Apache Tuscany SCA Core Distribution
> Implementation-Version: 2.0-SNAPSHOT
> Implementation-Vendor-Id: org.apache
> Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
> y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
> 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
> ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
> ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
> y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
> ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
> jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
> her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
> /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
> pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
> r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
> re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
> NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
> sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
> 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
> /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
> i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
> odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
> 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
> OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
> modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
> p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
> dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
> e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
> OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
> uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
> bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
> odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
> r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
> l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
> jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
> s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
> ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
> equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
> ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
> .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
> modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
> atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
> NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
> uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
> .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
> mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
> mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
> les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
> l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar
>
>
> From: ant elder
> Sent: Wednesday, January 21, 2009 1:36 AM
>
> To: dev@tuscany.apache.org
> Subject: Re: [2.0] Align samples with the distributions
>
>
>
>
>
> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> More comments inline.
>
> Thanks,
> Raymond
>
>
> From: Simon Laws
> Sent: Tuesday, January 20, 2009 8:41 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.0] Align samples with the distributions
>
>
>
> Agreed. It's just a local repo. Do you think adding a little structure add
> technical difficulty or is a flat structure a personal preference? I'm
> interested in situations like this where we have some people who want
> solution A and others want solution B (where both solutions are valid). How
> do we come to a conclusion? In the past this has tended to stall us a little
> so this is a good chance to see if we can do better;-)
>
> I'm seeing some technical issues:
>
> 1) Adding a little structure will make the distribution incompatible with
> Equinox OSGi launcher and PDE target platform.
>
> I believe this is a statement about how it works just now rather than a
> statement about blockers for change.
>
> I more view it as a block for introducing structural changes. The current
> layout can be directly used as an Equinox installation of bundles or PDE
> target location.
>
> That seems like FUD to me, I don't see any reason it can't be made to work
> with either structure. This seems to be the main objection so if we can show
> it can work then can we lay this debate to rest?
>
>  ...ant
>

Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

I have added the support to generate the manifest jars which contain the 
classpath for a given distribution. JSE users can just use the manifest jar 
alone to point to the distro he/she wants. For example, to use "core" 
distro, we generate "startup/tuscany-distribution-core-manifest.jar" with 
the following MANIFEST.MF. Please note it works well with the flat structure 
under "modules" for all the jars.

Manifest-Version: 1.0
Implementation-Vendor: The Apache Software Foundation
Implementation-Title: Apache Tuscany SCA Core Distribution
Implementation-Version: 2.0-SNAPSHOT
Implementation-Vendor-Id: org.apache
Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan
y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705
30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur
ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar
,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan
y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x
ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT.
jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc
her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,..
/modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works
pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja
r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co
re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S
NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j
sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2.
0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,..
/modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap
i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m
odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2
0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH
OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../
modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt
p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo
dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac
e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH
OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t
uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri
bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m
odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja
r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp
l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT.
jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module
s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement
ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility-
equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar
,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2
.1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../
modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d
atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S
NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t
uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1
.6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple
mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i
mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu
les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm
l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar


From: ant elder
Sent: Wednesday, January 21, 2009 1:36 AM
To: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions





On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:

Hi,

More comments inline.

Thanks,
Raymond


From: Simon Laws
Sent: Tuesday, January 20, 2009 8:41 AM
To: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions



Agreed. It's just a local repo. Do you think adding a little structure add 
technical difficulty or is a flat structure a personal preference? I'm 
interested in situations like this where we have some people who want 
solution A and others want solution B (where both solutions are valid). How 
do we come to a conclusion? In the past this has tended to stall us a little 
so this is a good chance to see if we can do better;-)

I'm seeing some technical issues:

1) Adding a little structure will make the distribution incompatible with 
Equinox OSGi launcher and PDE target platform.

I believe this is a statement about how it works just now rather than a 
statement about blockers for change.

I more view it as a block for introducing structural changes. The current 
layout can be directly used as an Equinox installation of bundles or PDE 
target location.

That seems like FUD to me, I don't see any reason it can't be made to work 
with either structure. This seems to be the main objection so if we can show 
it can work then can we lay this debate to rest?

   ...ant 

Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:

>  Hi,
>
> More comments inline.
>
> Thanks,
> Raymond
>
>  *From:* Simon Laws <si...@googlemail.com>
> *Sent:* Tuesday, January 20, 2009 8:41 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: [2.0] Align samples with the distributions
>
>
>>>
>> Agreed. It's just a local repo. Do you think adding a little structure add
>> technical difficulty or is a flat structure a personal preference? I'm
>> interested in situations like this where we have some people who want
>> solution A and others want solution B (where both solutions are valid). How
>> do we come to a conclusion? In the past this has tended to stall us a little
>> so this is a good chance to see if we can do better;-)
>>
>> I'm seeing some technical issues:
>>
>> 1) Adding a little structure will make the distribution incompatible with
>> Equinox OSGi launcher and PDE target platform.
>>
>
> I believe this is a statement about how it works just now rather than a
> statement about blockers for change.
>
> I more view it as a block for introducing structural changes. The current
> layout can be directly used as an Equinox installation of bundles or PDE
> target location.
>

That seems like FUD to me, I don't see any reason it can't be made to work
with either structure. This seems to be the main objection so if we can show
it can work then can we lay this debate to rest?

   ...ant

Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

On Tue, Jan 20, 2009 at 4:41 PM, Simon Laws <si...@googlemail.com>wrote:

>
>>>
>> Agreed. It's just a local repo. Do you think adding a little structure add
>> technical difficulty or is a flat structure a personal preference? I'm
>> interested in situations like this where we have some people who want
>> solution A and others want solution B (where both solutions are valid). How
>> do we come to a conclusion? In the past this has tended to stall us a little
>> so this is a good chance to see if we can do better;-)
>>
>> I'm seeing some technical issues:
>>
>> 1) Adding a little structure will make the distribution incompatible with
>> Equinox OSGi launcher and PDE target platform.
>>
>
> I believe this is a statement about how it works just now rather than a
> statement about blockers for change.
>
>
>> 2) There will be overlapping jars between features, with a flat structure,
>> each artifact will have a unique location in the distro folder.
>>
>
> True. This point is move valid I think. Think about this a little more some
> feature will have three types of dependencies in the context of the Tuscany
> organization
>
> SomeFeature depends on
> 1/     jars from other features (e.g. core)
> 2/     jars for the explicit dependecies for the module
> 3/     jars from transitive dependencies that don't appear in either 1 or 2
>
>
> in 3 there could be jars that are common with other features but you don't
> know precisely which. I guess this may break this idea or we could just put
> these in a common sub dir.
>

I don't see any problem with overlapping jars. There's various ways of
dealing with them, anything from just including them in the base lib, using
a (or several) common libs, or just letting them be duplicated etc. I'd
already looked through all the dependencies in 1.4 and don't see any we
can't deal with, if anyone does see one then bring up the specific case and
i'm sure we'll be able to think of a way to handle it.

   ...ant

Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

Hi,

I went ahead to enable our maven bundle plugin to generate the startup/<distro-manifest.jar>. The distributions/core/pom.xml has been updated. Please try to see if it matches your expectation.

Thanks,
Raymond


From: Simon Laws 
Sent: Tuesday, January 20, 2009 9:44 AM
To: dev@tuscany.apache.org 
Subject: Re: [2.0] Align samples with the distributions





    1) Adding a little structure will make the distribution incompatible with Equinox OSGi launcher and PDE target platform. 

  I believe this is a statement about how it works just now rather than a statement about blockers for change. 

  I more view it as a block for introducing structural changes. The current layout can be directly used as an Equinox installation of bundles or PDE target location.

But looking at the docs having sub dirs doesn't prevent the bundles there being used either in an Equinox install and as part of the PDE target. It would be very surprising if it did. Granted our code doesn't handle it but that's our code. 
 




    2) There will be overlapping jars between features, with a flat structure, each artifact will have a unique location in the distro folder.   

  True. This point is move valid I think. Think about this a little more some feature will have three types of dependencies in the context of the Tuscany organization

  SomeFeature depends on 
  1/     jars from other features (e.g. core)
  2/     jars for the explicit dependecies for the module
  3/     jars from transitive dependencies that don't appear in either 1 or 2 

  in 3 there could be jars that are common with other features but you don't know precisely which. I guess this may break this idea or we could just put these in a common sub dir. 

  The bottom line is that most likely we won't be able to find a good partition of the jars unless we start to introduce duplications. That's why I prefer to keep the structure fairly flat. 

I'm just suggesting that the partition is based on whatever features are defined so that when you unwrap the distribution you get the impression that it's made up of different selectable parts. I agree that the type 3 jars are the problematic ones to which I don't have a good solution other than to assume that transitive dependencies might overlap. 

How about I first take a look at generating a manifest jar based on a feature and see if that moves me any nearer to satisfaction. This at least holds the list of jars for the feature.  The JSE user can include manifest jars as appropriate. You still can't tell by looking at the manifest which jars are specific to the feature and which overlap with other features. However in doing this inspiration might strike. 
 




    3) Since the distro is just a local repo, only the configuration of the grouping matters for users. Having extra jars in the distro shouldn't bother if we overlay multiple functional distros into the same directory.

  I'm not sure I get this point but are you getting at a point about how we configure the launchers/provide manifest jars?  

  Yes, I see the manifest jars as the index to the set of jars for a functional feature.
Ok, I'm going to go ahead and add manifest jars for one of the features and see how that goes.  



      modules
         +--- tuscany-assembly-2.0.0.jar
         +--- tuscany-assembly-xml-2.0.0.jar
         +--- stax-api-1.0-2
              +--- META-INF/MANIFEST.MF
              +--- stat-api-1.0-2.jar

      I'm against adding extra structures for the libs folder to achieve the grouping. 

      2) Grouping of modules into functional features

      This should be a very light layer on top of 1). It should be just a set of configurations to organize the modules by function. When another distribution is downloaded, it should be possible to just unzip it into the existing distribution without any conflicts.

      For the 1st milestone of 2.x, we could try to get "api", "core" and potentially "webservice" distributions out. 

    These all sounds like fine collections of function to me but can we go with the "all" distro for M1 where 

    all = api + core + webserivce. 

    It seems we can agree on "all". It seems we can agree that we need to be able to point samples etc at more coarsly grained modules, we don't seem to be able to agree whether these coarser grained modules should be distributed. Once we know how this works and have tried to create the distribution we may take a different view. 
     


      3) Configuration of the features for specific hosting environments

      * Maven: A pom project that list the set of modules for the functional feature
      * JSE/WebApp: generate a launcher jar whose META-INF/MANIFEST.MF that uses the Class-Path header to define the classpath entries 
    Will the launcher be required to start the OSGi runtime? 

    Not really, we just reuse the JAR MANIFEST.MF to define the classpath for JSE. In the WebApp scheme, if we point to a Tuscany distro and use the manifest jar to bootstrap the Tuscany runtime when the webapp is started, it works the same way as JSE.

  Sorry. I put the question in the wrong place. I was referring to the point below. Are you suggesting that the only way that tuscany will run in OSGi is if someone starts up an OSGi container with a config.ini specified?

  No. It's just one way to tell the Equinox runtime the collection of bundles. I list them as examples to show that we can have simple configurations on top of our distro to group them into functional features for various hosting environments.

ok, I see. 
 





      * OSGi: Generate a config.ini which lists the set of bundles to be used by the OSGi runtime 

      * Eclipse: Generate a target platform definition or feature.xml

      Thanks,
      Raymond

  Regards

  Simon 

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

>
>
>>
>> 1) Adding a little structure will make the distribution incompatible with
>> Equinox OSGi launcher and PDE target platform.
>>
>
> I believe this is a statement about how it works just now rather than a
> statement about blockers for change.
>
> I more view it as a block for introducing structural changes. The current
> layout can be directly used as an Equinox installation of bundles or PDE
> target location.
>

But looking at the docs having sub dirs doesn't prevent the bundles there
being used either in an Equinox install and as part of the PDE target. It
would be very surprising if it did. Granted our code doesn't handle it but
that's our code.


>
>
>> 2) There will be overlapping jars between features, with a flat structure,
>> each artifact will have a unique location in the distro folder.
>>
>
> True. This point is move valid I think. Think about this a little more some
> feature will have three types of dependencies in the context of the Tuscany
> organization
>
> SomeFeature depends on
> 1/     jars from other features (e.g. core)
> 2/     jars for the explicit dependecies for the module
> 3/     jars from transitive dependencies that don't appear in either 1 or 2
>
>
> in 3 there could be jars that are common with other features but you don't
> know precisely which. I guess this may break this idea or we could just put
> these in a common sub dir.
> The bottom line is that most likely we won't be able to find a good
> partition of the jars unless we start to introduce duplications. That's why
> I prefer to keep the structure fairly flat.
>

I'm just suggesting that the partition is based on whatever features are
defined so that when you unwrap the distribution you get the impression that
it's made up of different selectable parts. I agree that the type 3 jars are
the problematic ones to which I don't have a good solution other than to
assume that transitive dependencies might overlap.

How about I first take a look at generating a manifest jar based on a
feature and see if that moves me any nearer to satisfaction. This at least
holds the list of jars for the feature.  The JSE user can include manifest
jars as appropriate. You still can't tell by looking at the manifest which
jars are specific to the feature and which overlap with other features.
However in doing this inspiration might strike.


>
>
>> 3) Since the distro is just a local repo, only the configuration of the
>> grouping matters for users. Having extra jars in the distro shouldn't bother
>> if we overlay multiple functional distros into the same directory.
>>
>
> I'm not sure I get this point but are you getting at a point about how we
> configure the launchers/provide manifest jars?
>
> Yes, I see the manifest jars as the index to the set of jars for a
> functional feature.
>
Ok, I'm going to go ahead and add manifest jars for one of the features and
see how that goes.

>
>     modules
>>>    +--- tuscany-assembly-2.0.0.jar
>>>    +--- tuscany-assembly-xml-2.0.0.jar
>>>    +--- stax-api-1.0-2
>>>         +--- META-INF/MANIFEST.MF
>>>         +--- stat-api-1.0-2.jar
>>>
>>> I'm against adding extra structures for the libs folder to achieve the
>>> grouping.
>>>
>>> 2) Grouping of modules into functional features
>>>
>>> This should be a very light layer on top of 1). It should be just a set
>>> of configurations to organize the modules by function. When another
>>> distribution is downloaded, it should be possible to just unzip it into the
>>> existing distribution without any conflicts.
>>>
>>> For the 1st milestone of 2.x, we could try to get "api", "core" and
>>> potentially "webservice" distributions out.
>>>
>>
>> These all sounds like fine collections of function to me but can we go
>> with the "all" distro for M1 where
>>
>> all = api + core + webserivce.
>>
>> It seems we can agree on "all". It seems we can agree that we need to be
>> able to point samples etc at more coarsly grained modules, we don't seem to
>> be able to agree whether these coarser grained modules should be
>> distributed. Once we know how this works and have tried to create the
>> distribution we may take a different view.
>>
>>
>>>
>>> 3) Configuration of the features for specific hosting environments
>>>
>>> * Maven: A pom project that list the set of modules for the functional
>>> feature
>>> * JSE/WebApp: generate a launcher jar whose META-INF/MANIFEST.MF that
>>> uses the Class-Path header to define the classpath entries
>>>
>> Will the launcher be required to start the OSGi runtime?
>>
>> Not really, we just reuse the JAR MANIFEST.MF to define the classpath for
>> JSE. In the WebApp scheme, if we point to a Tuscany distro and use the
>> manifest jar to bootstrap the Tuscany runtime when the webapp is started, it
>> works the same way as JSE.
>>
>
> Sorry. I put the question in the wrong place. I was referring to the point
> below. Are you suggesting that the only way that tuscany will run in OSGi is
> if someone starts up an OSGi container with a config.ini specified?
>
> No. It's just one way to tell the Equinox runtime the collection of
> bundles. I list them as examples to show that we can have simple
> configurations on top of our distro to group them into functional
> features for various hosting environments.
>

ok, I see.


>
>
>>    * OSGi: Generate a config.ini which lists the set of bundles to be
>>> used by the OSGi runtime
>>>
>>   * Eclipse: Generate a target platform definition or feature.xml
>>>
>>> Thanks,
>>> Raymond
>>>
>>
> Regards
>
> Simon
>
>

Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

Hi,

More comments inline.

Thanks,
Raymond


From: Simon Laws 
Sent: Tuesday, January 20, 2009 8:41 AM
To: dev@tuscany.apache.org 
Subject: Re: [2.0] Align samples with the distributions



  Agreed. It's just a local repo. Do you think adding a little structure add technical difficulty or is a flat structure a personal preference? I'm interested in situations like this where we have some people who want solution A and others want solution B (where both solutions are valid). How do we come to a conclusion? In the past this has tended to stall us a little so this is a good chance to see if we can do better;-)

  I'm seeing some technical issues:

  1) Adding a little structure will make the distribution incompatible with Equinox OSGi launcher and PDE target platform. 

I believe this is a statement about how it works just now rather than a statement about blockers for change. 

I more view it as a block for introducing structural changes. The current layout can be directly used as an Equinox installation of bundles or PDE target location.


  2) There will be overlapping jars between features, with a flat structure, each artifact will have a unique location in the distro folder.   

True. This point is move valid I think. Think about this a little more some feature will have three types of dependencies in the context of the Tuscany organization

SomeFeature depends on 
1/     jars from other features (e.g. core)
2/     jars for the explicit dependecies for the module
3/     jars from transitive dependencies that don't appear in either 1 or 2 

in 3 there could be jars that are common with other features but you don't know precisely which. I guess this may break this idea or we could just put these in a common sub dir. 

The bottom line is that most likely we won't be able to find a good partition of the jars unless we start to introduce duplications. That's why I prefer to keep the structure fairly flat. 


  3) Since the distro is just a local repo, only the configuration of the grouping matters for users. Having extra jars in the distro shouldn't bother if we overlay multiple functional distros into the same directory.

I'm not sure I get this point but are you getting at a point about how we configure the launchers/provide manifest jars?  

Yes, I see the manifest jars as the index to the set of jars for a functional feature. 


    modules
       +--- tuscany-assembly-2.0.0.jar
       +--- tuscany-assembly-xml-2.0.0.jar
       +--- stax-api-1.0-2
            +--- META-INF/MANIFEST.MF
            +--- stat-api-1.0-2.jar

    I'm against adding extra structures for the libs folder to achieve the grouping. 

    2) Grouping of modules into functional features

    This should be a very light layer on top of 1). It should be just a set of configurations to organize the modules by function. When another distribution is downloaded, it should be possible to just unzip it into the existing distribution without any conflicts.

    For the 1st milestone of 2.x, we could try to get "api", "core" and potentially "webservice" distributions out. 

  These all sounds like fine collections of function to me but can we go with the "all" distro for M1 where 

  all = api + core + webserivce. 

  It seems we can agree on "all". It seems we can agree that we need to be able to point samples etc at more coarsly grained modules, we don't seem to be able to agree whether these coarser grained modules should be distributed. Once we know how this works and have tried to create the distribution we may take a different view. 
   


    3) Configuration of the features for specific hosting environments

    * Maven: A pom project that list the set of modules for the functional feature
    * JSE/WebApp: generate a launcher jar whose META-INF/MANIFEST.MF that uses the Class-Path header to define the classpath entries 
  Will the launcher be required to start the OSGi runtime? 

  Not really, we just reuse the JAR MANIFEST.MF to define the classpath for JSE. In the WebApp scheme, if we point to a Tuscany distro and use the manifest jar to bootstrap the Tuscany runtime when the webapp is started, it works the same way as JSE.

Sorry. I put the question in the wrong place. I was referring to the point below. Are you suggesting that the only way that tuscany will run in OSGi is if someone starts up an OSGi container with a config.ini specified?

No. It's just one way to tell the Equinox runtime the collection of bundles. I list them as examples to show that we can have simple configurations on top of our distro to group them into functional features for various hosting environments.



    * OSGi: Generate a config.ini which lists the set of bundles to be used by the OSGi runtime 

    * Eclipse: Generate a target platform definition or feature.xml

    Thanks,
    Raymond

Regards

Simon 

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

>
>
>>
> Agreed. It's just a local repo. Do you think adding a little structure add
> technical difficulty or is a flat structure a personal preference? I'm
> interested in situations like this where we have some people who want
> solution A and others want solution B (where both solutions are valid). How
> do we come to a conclusion? In the past this has tended to stall us a little
> so this is a good chance to see if we can do better;-)
>
> I'm seeing some technical issues:
>
> 1) Adding a little structure will make the distribution incompatible with
> Equinox OSGi launcher and PDE target platform.
>

I believe this is a statement about how it works just now rather than a
statement about blockers for change.


> 2) There will be overlapping jars between features, with a flat structure,
> each artifact will have a unique location in the distro folder.
>

True. This point is move valid I think. Think about this a little more some
feature will have three types of dependencies in the context of the Tuscany
organization

SomeFeature depends on
1/     jars from other features (e.g. core)
2/     jars for the explicit dependecies for the module
3/     jars from transitive dependencies that don't appear in either 1 or 2

in 3 there could be jars that are common with other features but you don't
know precisely which. I guess this may break this idea or we could just put
these in a common sub dir.


> 3) Since the distro is just a local repo, only the configuration of the
> grouping matters for users. Having extra jars in the distro shouldn't bother
> if we overlay multiple functional distros into the same directory.
>

I'm not sure I get this point but are you getting at a point about how we
configure the launchers/provide manifest jars?

>   modules
>>    +--- tuscany-assembly-2.0.0.jar
>>    +--- tuscany-assembly-xml-2.0.0.jar
>>    +--- stax-api-1.0-2
>>         +--- META-INF/MANIFEST.MF
>>         +--- stat-api-1.0-2.jar
>>
>> I'm against adding extra structures for the libs folder to achieve the
>> grouping.
>>
>> 2) Grouping of modules into functional features
>>
>> This should be a very light layer on top of 1). It should be just a set of
>> configurations to organize the modules by function. When another
>> distribution is downloaded, it should be possible to just unzip it into the
>> existing distribution without any conflicts.
>>
>> For the 1st milestone of 2.x, we could try to get "api", "core" and
>> potentially "webservice" distributions out.
>>
>
> These all sounds like fine collections of function to me but can we go with
> the "all" distro for M1 where
>
> all = api + core + webserivce.
>
> It seems we can agree on "all". It seems we can agree that we need to be
> able to point samples etc at more coarsly grained modules, we don't seem to
> be able to agree whether these coarser grained modules should be
> distributed. Once we know how this works and have tried to create the
> distribution we may take a different view.
>
>
>>
>> 3) Configuration of the features for specific hosting environments
>>
>> * Maven: A pom project that list the set of modules for the functional
>> feature
>> * JSE/WebApp: generate a launcher jar whose META-INF/MANIFEST.MF that uses
>> the Class-Path header to define the classpath entries
>>
> Will the launcher be required to start the OSGi runtime?
>
> Not really, we just reuse the JAR MANIFEST.MF to define the classpath for
> JSE. In the WebApp scheme, if we point to a Tuscany distro and use the
> manifest jar to bootstrap the Tuscany runtime when the webapp is started, it
> works the same way as JSE.
>

Sorry. I put the question in the wrong place. I was referring to the point
below. Are you suggesting that the only way that tuscany will run in OSGi is
if someone starts up an OSGi container with a config.ini specified?

>
>   * OSGi: Generate a config.ini which lists the set of bundles to be used
>> by the OSGi runtime
>>
>   * Eclipse: Generate a target platform definition or feature.xml
>>
>> Thanks,
>> Raymond
>>
>
Regards

Simon

Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

Hi,

More comments inline.

Thanks,
Raymond


From: Simon Laws 
Sent: Monday, January 19, 2009 9:46 AM
To: dev@tuscany.apache.org 
Subject: Re: [2.0] Align samples with the distributions


Hi Raymond

comments in line...

Simon


On Mon, Jan 19, 2009 at 5:32 PM, Raymond Feng <en...@gmail.com> wrote:

  Hi,

  I'm catching up the discussions and I have to admit the thread has too many levels of nesting and it becomes difficult to read. Here is my view:

  1) The structure of the distribution: 

  I see this as a repository of the Tuscany modules, 3rd party jars and other things for the Tuscany standalone runtime and other environments where Tuscany is embedded. IMO, we should keep the structure simple and independent of the grouping. I'm happy with the current approach in 2.x:

Agreed. It's just a local repo. Do you think adding a little structure add technical difficulty or is a flat structure a personal preference? I'm interested in situations like this where we have some people who want solution A and others want solution B (where both solutions are valid). How do we come to a conclusion? In the past this has tended to stall us a little so this is a good chance to see if we can do better;-)

I'm seeing some technical issues:

1) Adding a little structure will make the distribution incompatible with Equinox OSGi launcher and PDE target platform. 
2) There will be overlapping jars between features, with a flat structure, each artifact will have a unique location in the distro folder.   
3) Since the distro is just a local repo, only the configuration of the grouping matters for users. Having extra jars in the distro shouldn't bother if we overlay multiple functional distros into the same directory.
  modules
     +--- tuscany-assembly-2.0.0.jar
     +--- tuscany-assembly-xml-2.0.0.jar
     +--- stax-api-1.0-2
          +--- META-INF/MANIFEST.MF
          +--- stat-api-1.0-2.jar

  I'm against adding extra structures for the libs folder to achieve the grouping. 

  2) Grouping of modules into functional features

  This should be a very light layer on top of 1). It should be just a set of configurations to organize the modules by function. When another distribution is downloaded, it should be possible to just unzip it into the existing distribution without any conflicts.

  For the 1st milestone of 2.x, we could try to get "api", "core" and potentially "webservice" distributions out. 

These all sounds like fine collections of function to me but can we go with the "all" distro for M1 where 

all = api + core + webserivce. 

It seems we can agree on "all". It seems we can agree that we need to be able to point samples etc at more coarsly grained modules, we don't seem to be able to agree whether these coarser grained modules should be distributed. Once we know how this works and have tried to create the distribution we may take a different view. 
 


  3) Configuration of the features for specific hosting environments

  * Maven: A pom project that list the set of modules for the functional feature
  * JSE/WebApp: generate a launcher jar whose META-INF/MANIFEST.MF that uses the Class-Path header to define the classpath entries 
Will the launcher be required to start the OSGi runtime? 

Not really, we just reuse the JAR MANIFEST.MF to define the classpath for JSE. In the WebApp scheme, if we point to a Tuscany distro and use the manifest jar to bootstrap the Tuscany runtime when the webapp is started, it works the same way as JSE.

  * OSGi: Generate a config.ini which lists the set of bundles to be used by the OSGi runtime 

  * Eclipse: Generate a target platform definition or feature.xml

  Thanks,
  Raymond


  From: Simon Laws 
  Sent: Monday, January 19, 2009 7:25 AM
  To: dev@tuscany.apache.org ; antelder@apache.org 
  Subject: Re: [2.0] Align samples with the distributions






  On Sat, Jan 17, 2009 at 8:53 AM, ant elder <an...@apache.org> wrote:




    On Fri, Jan 16, 2009 at 2:01 PM, Simon Laws <si...@googlemail.com> wrote:




      On Fri, Jan 16, 2009 at 1:04 PM, ant elder <an...@apache.org> wrote:




        On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <si...@googlemail.com> wrote:

          snip.... 


            Yes that what the current compact distribution does, its in 1.x right now as there's few extensions going in 2.x but there should be no problems with doing it there too.

               ...ant



          I looked at the compact distro in 1.x and the distro projects in 2.x and this is what I found:

          Key 
             Plain text = common between the two
             [] = different between the two
             * = my opinion 


          A set of maven modules which define dependencies for features
             [in /modules or /distribution]
             * I prefer /distribution as the feature modules are not providing any new function

        There's pros and cons, where they are right now enables a facility i've not mentioned yet but the where they go is not big deal at the end of the day. 




          Samples depend on only the feature modules that they require

          An "all" distribution that ships all features

          [separate distributions that ship individual features]
            * I don't mind having them if people want to support them.

        The problem with doing that is it adds some significant complexity, from things like the download page, to things like the documentation for samples and how to use etc.

      As I say below I don't think we need to decide for M1. I would assert that we need to be able to have samples depend on separate feature distributions, modules call then what you will. Doesn't mean we need to ship them but does mean they need to exist. As in my first point I think this is a common feature of both approaches as they are currently implemented. 

    I don't think that would work very well, the "feature" approach is not a feature per extension type so its only really useful for making downloadable distributions. That means for example a sample using xquery you have to know xquery is in the "process" feature distribution and download that, but you wouldn't put a maven dependency on the process feature in the xquery sample as that would drag in all the other unnecessary dependencies like bpel and ode, same thing for say a jsonrpc sample which would have a dependency on the jsonrpc binding not the web20 feature as that would drag in all the scripting stuff. The feature idea was that there would be a small number of downloadable feature distributions as a way to manage the growing number of Tuscany extensions, the problem is though that there are no obvious groupings for most of the extensions so the features get quite arbitrary as more extensions are include which makes them unintuitive which just further complicates an already complicated project. Since they were proposed we've asked on the dev list, user list, and in the user survey and pretty much everyone is happy with the one big distribution, i think a 70Meg or so download is just not a big deal these days. What people do seem to want is less jars and an easier way to know which jars are for what, and the compact jars and structured lib folder do that. Even if we didn't use the compact jars, the structure lib folder makes a single distribution much more usable, its obvious what jars are for and users can easily make up their own custom distributions if required by just deleting unneeded lib folders.

  So we seem to be getting to the heart of the matter.  We tentatively agree;

  1 - start with one "all" distro
  2 - add some structure to the libs dir
  3 - have some grouping of jars that group modules together for easy reference from samples etc.

  On point 3 the disagreement is the granularity of the grouping. Features vs extensions/compact. 

  Features = small number of features that group more that one extension
  Extension/compact = larger number grouping each extension implementation

  I'm not against having a finer granularity of feature 



      




         

            * I suggest though in this first instance (M1) we just ship the "all" distro and we can see how we get on with that. This is still build from the separate feature modules.


        Yes i agree with just shipping an "all" distro for now. I'd like to leave the "how its built" till this discussion has progressed a little further though.
         

          [separate tuscany jars vs feature jars]
            * I don't particularly like the feature jars as it's another step to go wrong. In particular it uses the shade(?) plugin and you have to configure transformers. 

        I'm puzzeled that you consider that as "another step to go wrong" but don't mind having multiple different distributions or building distributions out of each other, both of which seem to add much more complexity, restrictions, and points of failure to me :)


      To me it looks like a step in the process that we don't necessarily need. In the context of this point my measure of complexity is how many places I have to specify things. I agree that there are also complexities in distributing more that one distribution package but I don't see that that's particularly related to this point. 

    I'm still not understanding the problem here, adding a shade transformer config is a pretty easy task, we've been doing it for years in the past Tuscany releases and i don't remember a single occasion where its caused any problem. And its only an occasional task for a Tuscany "developer" which makes the "users" life easier every time they use Tuscany - and users have complained about Tuscany having so many jars on lots of occasions. Also, if thats the only hurdle in doing this then all we need to do is write a relatively trivial Tuscany specific extension of the shade plugin and we then wouldn't even need that transformer configuration. We're getting quite a lot of Tuscany specific plugins these days so one more is no big deal. 
     
  Personally I've had a lot of problems with it. 50% of the time it fails in my environment (having sais that I haven't tried is since I moved to the Sun JDK). Anyhow the utility of this plugin to us will be dictated by the shape we want our distribution to take. If we have a single distribution then it seems we need to ship separate module jars as the OSGi runtime is expecting to load bundles. I guess we could write a manifest aggregator for the shade plugin but why would we when we can ship the separate module jars and provide a manifest jar to make manual classpath specification easier. Maybe I'm missing something here. 
   


       


         

            [Launcher vs manually specified classpath comes into this]
                 * Manual classpath is easier with feature jars. Can we use a different approach to support the manual classpath? Manifest jars for each feature?

        I think we need to make a bit more progress on the "Tuscany runtime launching" thread before that can be answered.

      Agreed
       


         


          [structured libraries directory]
            * I like this. It gives some sense of order to the distro lib directory.



        Me too. Comparing the distros we've had in the past and the different varrieties being talked about now i think a structured libraries directory makes the most significant improvement for making the distro easier to use in the way users have been asking for.
         

          Some other distro thoughts came to mind as I went through:

          1/ Can we do something about 3rd party licenses? E.g. automate the command line tools we have that check distro jars are represented in the LICENSE file so that this happens automatically when distro is built. Also 
          it would be nice to have a tool that checks that module NOTICE/LICENSE files match the requirements of the source that they hold. This last is manual at the moment. 

        The way to do this would be to change to use the maven release plugin and IANAL plugin which would vastly simplify our distribution build and release process, i think it is where i think really we need to get to but it will put some restriction on how we shape the distributions which is one of the reasons i'm less keen on all these "feature" distros  

      I looked at this a while back and I agree it adds restrictions. I don't remember the details so I'll have to read up. I seem to think it was early days when I looked at it so it was pretty rough at that point.  

    I think its pretty good these days, I know Geronimo uses it ok.
     






          2/ We need to follow through on the reason Raymond started this thread originally and ensure that samples are tested in the ways that a user will run then when the distribution is built. 
          3/ As per 2/ but for webapp samples. Can we re-use some of the work that was done for webapps in 1.x itest?


        I'm starting to think there should be seperate distributions for OSGi and JSE/Webapps etc. Trying to munge all this into a single distribution that works for all environments so far looks like its going to make the distribution a lot more complex and less user friendly than it needs to be. You could consider this part of the "modularity" exercise of 2.0 and not munging unrelated things together. If we did that then we can test the samples included in the distribution properly in the best way for the target environment.

       what would the difference be between these distributions? I think the jars and their organization would be the same. It comes down to how you launch/host the runtime so probably some hosting/launching jars would come and go. Again we need to do more on the launching thread for this point. 


    Probably need actual distributions to show all the differences but for example the organization isn't the same - the OSGi distro requires the 3rd party jars be each included in its own sub folder which is unnecessary for other environments and would make things like "java -cp" a bit unwieldy. However, if we did go for the one common distro with a structure lib folder then this becomes less of an issue for Ant scripts and launchers. 

  I suggest we lay out the distribution file directory in some detail and try review it. Is this what we're talking about
   
  tuscany-sca-2.0
    bin
      tuscany.bat (is this a bat or a jar?)
      tuscany-default.conf
      tuscany-osgi.conf
      ...
    lib
      base
        acitvation-1.1
          activation-1.1.jar
          META-INF
            MANIFEST.MF
        asm-all-3.1.jar
        tuscany-assembly-2.0.jar
        tuscany-core-2.0.jar
        tuscany-contribution-2.0.jar
        ...
        tuscany-base-manifest-2.0.jar
      spring 
        commons-logging-1.1.1.jar
        spring-2.5.5.jar
        tuscany-implementation-spring-2.0.jar
        tuscany-spring-manifest-2.0.jar
      webservices
    samples
      calculator
    tutorial
      store

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

Hi Raymond

comments in line...

Simon

On Mon, Jan 19, 2009 at 5:32 PM, Raymond Feng <en...@gmail.com> wrote:

>  Hi,
>
> I'm catching up the discussions and I have to admit the thread has too many
> levels of nesting and it becomes difficult to read. Here is my view:
>
> 1) The structure of the distribution:
>
> I see this as a repository of the Tuscany modules, 3rd party jars and other
> things for the Tuscany standalone runtime and other environments where
> Tuscany is embedded. IMO, we should keep the structure simple and
> independent of the grouping. I'm happy with the current approach in 2.x:
>
>
Agreed. It's just a local repo. Do you think adding a little structure add
technical difficulty or is a flat structure a personal preference? I'm
interested in situations like this where we have some people who want
solution A and others want solution B (where both solutions are valid). How
do we come to a conclusion? In the past this has tended to stall us a little
so this is a good chance to see if we can do better;-)


> modules
>    +--- tuscany-assembly-2.0.0.jar
>    +--- tuscany-assembly-xml-2.0.0.jar
>    +--- stax-api-1.0-2
>         +--- META-INF/MANIFEST.MF
>         +--- stat-api-1.0-2.jar
>
> I'm against adding extra structures for the libs folder to achieve the
> grouping.
>
> 2) Grouping of modules into functional features
>
> This should be a very light layer on top of 1). It should be just a set of
> configurations to organize the modules by function. When another
> distribution is downloaded, it should be possible to just unzip it into the
> existing distribution without any conflicts.
>
> For the 1st milestone of 2.x, we could try to get "api", "core" and
> potentially "webservice" distributions out.
>

These all sounds like fine collections of function to me but can we go with
the "all" distro for M1 where

all = api + core + webserivce.

It seems we can agree on "all". It seems we can agree that we need to be
able to point samples etc at more coarsly grained modules, we don't seem to
be able to agree whether these coarser grained modules should be
distributed. Once we know how this works and have tried to create the
distribution we may take a different view.


>
> 3) Configuration of the features for specific hosting environments
>
> * Maven: A pom project that list the set of modules for the functional
> feature
> * JSE/WebApp: generate a launcher jar whose META-INF/MANIFEST.MF that uses
> the Class-Path header to define the classpath entries
>
Will the launcher be required to start the OSGi runtime?

> * OSGi: Generate a config.ini which lists the set of bundles to be used by
> the OSGi runtime
>
* Eclipse: Generate a target platform definition or feature.xml
>
> Thanks,
> Raymond
>
>  *From:* Simon Laws <si...@googlemail.com>
> *Sent:* Monday, January 19, 2009 7:25 AM
> *To:* dev@tuscany.apache.org ; antelder@apache.org
> *Subject:* Re: [2.0] Align samples with the distributions
>
>
>
> On Sat, Jan 17, 2009 at 8:53 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>>  On Fri, Jan 16, 2009 at 2:01 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>>  On Fri, Jan 16, 2009 at 1:04 PM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>>  On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <
>>>> simonslaws@googlemail.com> wrote:
>>>>
>>>>>  snip....
>>>>>
>>>>>>
>>>>>> Yes that what the current compact distribution does, its in 1.x right
>>>>>> now as there's few extensions going in 2.x but there should be no problems
>>>>>> with doing it there too.
>>>>>>
>>>>>>    ...ant
>>>>>>
>>>>>> I looked at the compact distro in 1.x and the distro projects in 2.x
>>>>> and this is what I found:
>>>>>
>>>>> Key
>>>>>    Plain text = common between the two
>>>>>    [] = different between the two
>>>>>    * = my opinion
>>>>>
>>>>> A set of maven modules which define dependencies for features
>>>>>    [in /modules or /distribution]
>>>>>    * I prefer /distribution as the feature modules are not providing
>>>>> any new function
>>>>
>>>>
>>>> There's pros and cons, where they are right now enables a facility i've
>>>> not mentioned yet but the where they go is not big deal at the end of the
>>>> day.
>>>>
>>>>
>>>>>
>>>>> Samples depend on only the feature modules that they require
>>>>>
>>>>> An "all" distribution that ships all features
>>>>>
>>>>> [separate distributions that ship individual features]
>>>>>   * I don't mind having them if people want to support them.
>>>>
>>>>
>>>> The problem with doing that is it adds some significant complexity, from
>>>> things like the download page, to things like the documentation for samples
>>>> and how to use etc.
>>>>
>>>
>>> As I say below I don't think we need to decide for M1. I would assert
>>> that we need to be able to have samples depend on separate feature
>>> distributions, modules call then what you will. Doesn't mean we need to ship
>>> them but does mean they need to exist. As in my first point I think this is
>>> a common feature of both approaches as they are currently implemented.
>>>
>>
>> I don't think that would work very well, the "feature" approach is not a
>> feature per extension type so its only really useful for making
>> downloadable distributions. That means for example a sample using xqueryyou have to know
>> xquery is in the "process" feature distribution and download that, but
>> you wouldn't put a maven dependency on the process feature in the xquerysample as that would drag in all the other unnecessary dependencies like
>> bpel and ode, same thing for say a jsonrpc sample which would have a
>> dependency on the jsonrpc binding not the web20 feature as that would
>> drag in all the scripting stuff. The feature idea was that there would be a
>> small number of downloadable feature distributions as a way to manage the
>> growing number of Tuscany extensions, the problem is though that there are
>> no obvious groupings for most of the extensions so the features get quite
>> arbitrary as more extensions are include which makes them unintuitive which
>> just further complicates an already complicated project. Since they were
>> proposed we've asked on the dev list, user list, and in the user survey
>> and pretty much everyone is happy with the one big distribution, i think a
>> 70Meg or so download is just not a big deal these days. What people do seem
>> to want is less jars and an easier way to know which jars are for what, and
>> the compact jars and structured lib folder do that. Even if we didn't use
>> the compact jars, the structure lib folder makes a single distribution much
>> more usable, its obvious what jars are for and users can easily make up
>> their own custom distributions if required by just deleting unneeded lib
>> folders.
>>
>
> So we seem to be getting to the heart of the matter.  We tentatively agree;
>
> 1 - start with one "all" distro
> 2 - add some structure to the libs dir
> 3 - have some grouping of jars that group modules together for easy
> reference from samples etc.
>
> On point 3 the disagreement is the granularity of the grouping. Features vs
> extensions/compact.
>
> Features = small number of features that group more that one extension
> Extension/compact = larger number grouping each extension implementation
>
> I'm not against having a finer granularity of feature
>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>   * I suggest though in this first instance (M1) we just ship the "all"
>>>>> distro and we can see how we get on with that. This is still build from the
>>>>> separate feature modules.
>>>>>
>>>>
>>>> Yes i agree with just shipping an "all" distro for now. I'd like to
>>>> leave the "how its built" till this discussion has progressed a little
>>>> further though.
>>>>
>>>>
>>>>>
>>>>> [separate tuscany jars vs feature jars]
>>>>>   * I don't particularly like the feature jars as it's another step to
>>>>> go wrong. In particular it uses the shade(?) plugin and you have to
>>>>> configure transformers.
>>>>
>>>>
>>>> I'm puzzeled that you consider that as "another step to go wrong" but
>>>> don't mind having multiple different distributions or building distributions
>>>> out of each other, both of which seem to add much more complexity,
>>>> restrictions, and points of failure to me :)
>>>>
>>>
>>> To me it looks like a step in the process that we don't necessarily need.
>>> In the context of this point my measure of complexity is how many places I
>>> have to specify things. I agree that there are also complexities in
>>> distributing more that one distribution package but I don't see that that's
>>> particularly related to this point.
>>>
>>
>> I'm still not understanding the problem here, adding a shade transformer
>> config is a pretty easy task, we've been doing it for years in the past
>> Tuscany releases and i don't remember a single occasion where its caused any
>> problem. And its only an occasional task for a Tuscany "developer" which
>> makes the "users" life easier every time they use Tuscany - and users have
>> complained about Tuscany having so many jars on lots of occasions. Also, if
>> thats the only hurdle in doing this then all we need to do is write a
>> relatively trivial Tuscany specific extension of the shade plugin and we
>> then wouldn't even need that transformer configuration. We're getting quite
>> a lot of Tuscany specific plugins these days so one more is no big deal.
>>
>>
> Personally I've had a lot of problems with it. 50% of the time it fails in
> my environment (having sais that I haven't tried is since I moved to the Sun
> JDK). Anyhow the utility of this plugin to us will be dictated by the shape
> we want our distribution to take. If we have a single distribution then it
> seems we need to ship separate module jars as the OSGi runtime is expecting
> to load bundles. I guess we could write a manifest aggregator for the shade
> plugin but why would we when we can ship the separate module jars and
> provide a manifest jar to make manual classpath specification easier. Maybe
> I'm missing something here.
>
>
>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>   [Launcher vs manually specified classpath comes into this]
>>>>>        * Manual classpath is easier with feature jars. Can we use a
>>>>> different approach to support the manual classpath? Manifest jars for each
>>>>> feature?
>>>>
>>>>
>>>> I think we need to make a bit more progress on the "Tuscany runtime
>>>> launching" thread before that can be answered.
>>>>
>>>
>>> Agreed
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> [structured libraries directory]
>>>>>   * I like this. It gives some sense of order to the distro lib
>>>>> directory.
>>>>>
>>>>>
>>>> Me too. Comparing the distros we've had in the past and the different
>>>> varrieties being talked about now i think a structured libraries directory
>>>> makes the most significant improvement for making the distro easier to use
>>>> in the way users have been asking for.
>>>>
>>>>
>>>>>
>>>>> Some other distro thoughts came to mind as I went through:
>>>>>
>>>>> 1/ Can we do something about 3rd party licenses? E.g. automate the
>>>>> command line tools we have that check distro jars are represented in the
>>>>> LICENSE file so that this happens automatically when distro is built. Also
>>>>> it would be nice to have a tool that checks that module NOTICE/LICENSE
>>>>> files match the requirements of the source that they hold. This last is
>>>>> manual at the moment.
>>>>
>>>>
>>>> The way to do this would be to change to use the maven release plugin
>>>> and IANAL plugin which would vastly simplify our distribution build and
>>>> release process, i think it is where i think really we need to get to but it
>>>> will put some restriction on how we shape the distributions which is one of
>>>> the reasons i'm less keen on all these "feature" distros
>>>>
>>>
>>> I looked at this a while back and I agree it adds restrictions. I don't
>>> remember the details so I'll have to read up. I seem to think it was early
>>> days when I looked at it so it was pretty rough at that point.
>>>
>>
>> I think its pretty good these days, I know Geronimo uses it ok.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>> 2/ We need to follow through on the reason Raymond started this thread
>>>>> originally and ensure that samples are tested in the ways that a user will
>>>>> run then when the distribution is built.
>>>>> 3/ As per 2/ but for webapp samples. Can we re-use some of the work
>>>>> that was done for webapps in 1.x itest?
>>>>>
>>>>
>>>> I'm starting to think there should be seperate distributions for OSGi
>>>> and JSE/Webapps etc. Trying to munge all this into a single distribution
>>>> that works for all environments so far looks like its going to make the
>>>> distribution a lot more complex and less user friendly than it needs to be.
>>>> You could consider this part of the "modularity" exercise of 2.0 and not
>>>> munging unrelated things together. If we did that then we can test the
>>>> samples included in the distribution properly in the best way for the target
>>>> environment.
>>>>
>>>
>>>  what would the difference be between these distributions? I think the
>>> jars and their organization would be the same. It comes down to how you
>>> launch/host the runtime so probably some hosting/launching jars would come
>>> and go. Again we need to do more on the launching thread for this point.
>>>
>>
>> Probably need actual distributions to show all the differences but for
>> example the organization isn't the same - the OSGi distro requires the 3rd
>> party jars be each included in its own sub folder which is unnecessary for
>> other environments and would make things like "java -cp" a bit unwieldy.
>> However, if we did go for the one common distro with a structure lib folder
>> then this becomes less of an issue for Ant scripts and launchers.
>>
>
> I suggest we lay out the distribution file directory in some detail and try
> review it. Is this what we're talking about
>
> tuscany-sca-2.0
>   bin
>     tuscany.bat (is this a bat or a jar?)
>     tuscany-default.conf
>     tuscany-osgi.conf
>     ...
>   lib
>     base
>       acitvation-1.1
>         activation-1.1.jar
>         META-INF
>           MANIFEST.MF
>       asm-all-3.1.jar
>       tuscany-assembly-2.0.jar
>       tuscany-core-2.0.jar
>       tuscany-contribution-2.0.jar
>       ...
>       tuscany-base-manifest-2.0.jar
>     spring
>       commons-logging-1.1.1.jar
>       spring-2.5.5.jar
>       tuscany-implementation-spring-2.0.jar
>       tuscany-spring-manifest-2.0.jar
>     webservices
>   samples
>     calculator
>   tutorial
>     store
>
>
>

Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

Hi,

I'm catching up the discussions and I have to admit the thread has too many levels of nesting and it becomes difficult to read. Here is my view:

1) The structure of the distribution: 

I see this as a repository of the Tuscany modules, 3rd party jars and other things for the Tuscany standalone runtime and other environments where Tuscany is embedded. IMO, we should keep the structure simple and independent of the grouping. I'm happy with the current approach in 2.x:

modules
   +--- tuscany-assembly-2.0.0.jar
   +--- tuscany-assembly-xml-2.0.0.jar
   +--- stax-api-1.0-2
        +--- META-INF/MANIFEST.MF
        +--- stat-api-1.0-2.jar

I'm against adding extra structures for the libs folder to achieve the grouping. 

2) Grouping of modules into functional features

This should be a very light layer on top of 1). It should be just a set of configurations to organize the modules by function. When another distribution is downloaded, it should be possible to just unzip it into the existing distribution without any conflicts.

For the 1st milestone of 2.x, we could try to get "api", "core" and potentially "webservice" distributions out. 

3) Configuration of the features for specific hosting environments

* Maven: A pom project that list the set of modules for the functional feature
* JSE/WebApp: generate a launcher jar whose META-INF/MANIFEST.MF that uses the Class-Path header to define the classpath entries 
* OSGi: Generate a config.ini which lists the set of bundles to be used by the OSGi runtime
* Eclipse: Generate a target platform definition or feature.xml

Thanks,
Raymond


From: Simon Laws 
Sent: Monday, January 19, 2009 7:25 AM
To: dev@tuscany.apache.org ; antelder@apache.org 
Subject: Re: [2.0] Align samples with the distributions





On Sat, Jan 17, 2009 at 8:53 AM, ant elder <an...@apache.org> wrote:




  On Fri, Jan 16, 2009 at 2:01 PM, Simon Laws <si...@googlemail.com> wrote:




    On Fri, Jan 16, 2009 at 1:04 PM, ant elder <an...@apache.org> wrote:




      On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <si...@googlemail.com> wrote:

        snip.... 


          Yes that what the current compact distribution does, its in 1.x right now as there's few extensions going in 2.x but there should be no problems with doing it there too.

             ...ant



        I looked at the compact distro in 1.x and the distro projects in 2.x and this is what I found:

        Key 
           Plain text = common between the two
           [] = different between the two
           * = my opinion 


        A set of maven modules which define dependencies for features
           [in /modules or /distribution]
           * I prefer /distribution as the feature modules are not providing any new function

      There's pros and cons, where they are right now enables a facility i've not mentioned yet but the where they go is not big deal at the end of the day. 




        Samples depend on only the feature modules that they require

        An "all" distribution that ships all features

        [separate distributions that ship individual features]
          * I don't mind having them if people want to support them.

      The problem with doing that is it adds some significant complexity, from things like the download page, to things like the documentation for samples and how to use etc.

    As I say below I don't think we need to decide for M1. I would assert that we need to be able to have samples depend on separate feature distributions, modules call then what you will. Doesn't mean we need to ship them but does mean they need to exist. As in my first point I think this is a common feature of both approaches as they are currently implemented. 

  I don't think that would work very well, the "feature" approach is not a feature per extension type so its only really useful for making downloadable distributions. That means for example a sample using xquery you have to know xquery is in the "process" feature distribution and download that, but you wouldn't put a maven dependency on the process feature in the xquery sample as that would drag in all the other unnecessary dependencies like bpel and ode, same thing for say a jsonrpc sample which would have a dependency on the jsonrpc binding not the web20 feature as that would drag in all the scripting stuff. The feature idea was that there would be a small number of downloadable feature distributions as a way to manage the growing number of Tuscany extensions, the problem is though that there are no obvious groupings for most of the extensions so the features get quite arbitrary as more extensions are include which makes them unintuitive which just further complicates an already complicated project. Since they were proposed we've asked on the dev list, user list, and in the user survey and pretty much everyone is happy with the one big distribution, i think a 70Meg or so download is just not a big deal these days. What people do seem to want is less jars and an easier way to know which jars are for what, and the compact jars and structured lib folder do that. Even if we didn't use the compact jars, the structure lib folder makes a single distribution much more usable, its obvious what jars are for and users can easily make up their own custom distributions if required by just deleting unneeded lib folders.

So we seem to be getting to the heart of the matter.  We tentatively agree;

1 - start with one "all" distro
2 - add some structure to the libs dir
3 - have some grouping of jars that group modules together for easy reference from samples etc.

On point 3 the disagreement is the granularity of the grouping. Features vs extensions/compact. 

Features = small number of features that group more that one extension
Extension/compact = larger number grouping each extension implementation

I'm not against having a finer granularity of feature 



    




       

          * I suggest though in this first instance (M1) we just ship the "all" distro and we can see how we get on with that. This is still build from the separate feature modules.


      Yes i agree with just shipping an "all" distro for now. I'd like to leave the "how its built" till this discussion has progressed a little further though.
       

        [separate tuscany jars vs feature jars]
          * I don't particularly like the feature jars as it's another step to go wrong. In particular it uses the shade(?) plugin and you have to configure transformers. 

      I'm puzzeled that you consider that as "another step to go wrong" but don't mind having multiple different distributions or building distributions out of each other, both of which seem to add much more complexity, restrictions, and points of failure to me :)


    To me it looks like a step in the process that we don't necessarily need. In the context of this point my measure of complexity is how many places I have to specify things. I agree that there are also complexities in distributing more that one distribution package but I don't see that that's particularly related to this point. 

  I'm still not understanding the problem here, adding a shade transformer config is a pretty easy task, we've been doing it for years in the past Tuscany releases and i don't remember a single occasion where its caused any problem. And its only an occasional task for a Tuscany "developer" which makes the "users" life easier every time they use Tuscany - and users have complained about Tuscany having so many jars on lots of occasions. Also, if thats the only hurdle in doing this then all we need to do is write a relatively trivial Tuscany specific extension of the shade plugin and we then wouldn't even need that transformer configuration. We're getting quite a lot of Tuscany specific plugins these days so one more is no big deal. 
   
Personally I've had a lot of problems with it. 50% of the time it fails in my environment (having sais that I haven't tried is since I moved to the Sun JDK). Anyhow the utility of this plugin to us will be dictated by the shape we want our distribution to take. If we have a single distribution then it seems we need to ship separate module jars as the OSGi runtime is expecting to load bundles. I guess we could write a manifest aggregator for the shade plugin but why would we when we can ship the separate module jars and provide a manifest jar to make manual classpath specification easier. Maybe I'm missing something here. 
 


     


       

          [Launcher vs manually specified classpath comes into this]
               * Manual classpath is easier with feature jars. Can we use a different approach to support the manual classpath? Manifest jars for each feature?

      I think we need to make a bit more progress on the "Tuscany runtime launching" thread before that can be answered.

    Agreed
     


       


        [structured libraries directory]
          * I like this. It gives some sense of order to the distro lib directory.



      Me too. Comparing the distros we've had in the past and the different varrieties being talked about now i think a structured libraries directory makes the most significant improvement for making the distro easier to use in the way users have been asking for.
       

        Some other distro thoughts came to mind as I went through:

        1/ Can we do something about 3rd party licenses? E.g. automate the command line tools we have that check distro jars are represented in the LICENSE file so that this happens automatically when distro is built. Also 
        it would be nice to have a tool that checks that module NOTICE/LICENSE files match the requirements of the source that they hold. This last is manual at the moment. 

      The way to do this would be to change to use the maven release plugin and IANAL plugin which would vastly simplify our distribution build and release process, i think it is where i think really we need to get to but it will put some restriction on how we shape the distributions which is one of the reasons i'm less keen on all these "feature" distros  

    I looked at this a while back and I agree it adds restrictions. I don't remember the details so I'll have to read up. I seem to think it was early days when I looked at it so it was pretty rough at that point.  

  I think its pretty good these days, I know Geronimo uses it ok.
   






        2/ We need to follow through on the reason Raymond started this thread originally and ensure that samples are tested in the ways that a user will run then when the distribution is built. 
        3/ As per 2/ but for webapp samples. Can we re-use some of the work that was done for webapps in 1.x itest?


      I'm starting to think there should be seperate distributions for OSGi and JSE/Webapps etc. Trying to munge all this into a single distribution that works for all environments so far looks like its going to make the distribution a lot more complex and less user friendly than it needs to be. You could consider this part of the "modularity" exercise of 2.0 and not munging unrelated things together. If we did that then we can test the samples included in the distribution properly in the best way for the target environment.

     what would the difference be between these distributions? I think the jars and their organization would be the same. It comes down to how you launch/host the runtime so probably some hosting/launching jars would come and go. Again we need to do more on the launching thread for this point. 


  Probably need actual distributions to show all the differences but for example the organization isn't the same - the OSGi distro requires the 3rd party jars be each included in its own sub folder which is unnecessary for other environments and would make things like "java -cp" a bit unwieldy. However, if we did go for the one common distro with a structure lib folder then this becomes less of an issue for Ant scripts and launchers. 

I suggest we lay out the distribution file directory in some detail and try review it. Is this what we're talking about
 
tuscany-sca-2.0
  bin
    tuscany.bat (is this a bat or a jar?)
    tuscany-default.conf
    tuscany-osgi.conf
    ...
  lib
    base
      acitvation-1.1
        activation-1.1.jar
        META-INF
          MANIFEST.MF
      asm-all-3.1.jar
      tuscany-assembly-2.0.jar
      tuscany-core-2.0.jar
      tuscany-contribution-2.0.jar
      ...
      tuscany-base-manifest-2.0.jar
    spring 
      commons-logging-1.1.1.jar
      spring-2.5.5.jar
      tuscany-implementation-spring-2.0.jar
      tuscany-spring-manifest-2.0.jar
    webservices
  samples
    calculator
  tutorial
    store

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Sat, Jan 17, 2009 at 8:53 AM, ant elder <an...@apache.org> wrote:

>
>
> On Fri, Jan 16, 2009 at 2:01 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Fri, Jan 16, 2009 at 1:04 PM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>> snip....
>>>>
>>>>>
>>>>> Yes that what the current compact distribution does, its in 1.x right
>>>>> now as there's few extensions going in 2.x but there should be no problems
>>>>> with doing it there too.
>>>>>
>>>>>    ...ant
>>>>>
>>>>> I looked at the compact distro in 1.x and the distro projects in 2.x
>>>> and this is what I found:
>>>>
>>>> Key
>>>>    Plain text = common between the two
>>>>    [] = different between the two
>>>>    * = my opinion
>>>>
>>>> A set of maven modules which define dependencies for features
>>>>    [in /modules or /distribution]
>>>>    * I prefer /distribution as the feature modules are not providing any
>>>> new function
>>>
>>>
>>> There's pros and cons, where they are right now enables a facility i've
>>> not mentioned yet but the where they go is not big deal at the end of the
>>> day.
>>>
>>>
>>>>
>>>> Samples depend on only the feature modules that they require
>>>>
>>>> An "all" distribution that ships all features
>>>>
>>>> [separate distributions that ship individual features]
>>>>   * I don't mind having them if people want to support them.
>>>
>>>
>>> The problem with doing that is it adds some significant complexity, from
>>> things like the download page, to things like the documentation for samples
>>> and how to use etc.
>>>
>>
>> As I say below I don't think we need to decide for M1. I would assert that
>> we need to be able to have samples depend on separate feature distributions,
>> modules call then what you will. Doesn't mean we need to ship them but does
>> mean they need to exist. As in my first point I think this is a common
>> feature of both approaches as they are currently implemented.
>>
>
> I don't think that would work very well, the "feature" approach is not a
> feature per extension type so its only really useful for making
> downloadable distributions. That means for example a sample using xqueryyou have to know
> xquery is in the "process" feature distribution and download that, but you
> wouldn't put a maven dependency on the process feature in the xquerysample as that would drag in all the other unnecessary dependencies like
> bpel and ode, same thing for say a jsonrpc sample which would have a
> dependency on the jsonrpc binding not the web20 feature as that would drag
> in all the scripting stuff. The feature idea was that there would be a small
> number of downloadable feature distributions as a way to manage the growing
> number of Tuscany extensions, the problem is though that there are no
> obvious groupings for most of the extensions so the features get quite
> arbitrary as more extensions are include which makes them unintuitive which
> just further complicates an already complicated project. Since they were
> proposed we've asked on the dev list, user list, and in the user survey
> and pretty much everyone is happy with the one big distribution, i think a
> 70Meg or so download is just not a big deal these days. What people do seem
> to want is less jars and an easier way to know which jars are for what, and
> the compact jars and structured lib folder do that. Even if we didn't use
> the compact jars, the structure lib folder makes a single distribution much
> more usable, its obvious what jars are for and users can easily make up
> their own custom distributions if required by just deleting unneeded lib
> folders.
>

So we seem to be getting to the heart of the matter.  We tentatively agree;

1 - start with one "all" distro
2 - add some structure to the libs dir
3 - have some grouping of jars that group modules together for easy
reference from samples etc.

On point 3 the disagreement is the granularity of the grouping. Features vs
extensions/compact.

Features = small number of features that group more that one extension
Extension/compact = larger number grouping each extension implementation

I'm not against having a finer granularity of feature


>
>
>>
>>
>>>
>>>
>>>>
>>>>   * I suggest though in this first instance (M1) we just ship the "all"
>>>> distro and we can see how we get on with that. This is still build from the
>>>> separate feature modules.
>>>>
>>>
>>> Yes i agree with just shipping an "all" distro for now. I'd like to leave
>>> the "how its built" till this discussion has progressed a little further
>>> though.
>>>
>>>
>>>>
>>>> [separate tuscany jars vs feature jars]
>>>>   * I don't particularly like the feature jars as it's another step to
>>>> go wrong. In particular it uses the shade(?) plugin and you have to
>>>> configure transformers.
>>>
>>>
>>> I'm puzzeled that you consider that as "another step to go wrong" but
>>> don't mind having multiple different distributions or building distributions
>>> out of each other, both of which seem to add much more complexity,
>>> restrictions, and points of failure to me :)
>>>
>>
>> To me it looks like a step in the process that we don't necessarily need.
>> In the context of this point my measure of complexity is how many places I
>> have to specify things. I agree that there are also complexities in
>> distributing more that one distribution package but I don't see that that's
>> particularly related to this point.
>>
>
> I'm still not understanding the problem here, adding a shade transformer
> config is a pretty easy task, we've been doing it for years in the past
> Tuscany releases and i don't remember a single occasion where its caused any
> problem. And its only an occasional task for a Tuscany "developer" which
> makes the "users" life easier every time they use Tuscany - and users have
> complained about Tuscany having so many jars on lots of occasions. Also, if
> thats the only hurdle in doing this then all we need to do is write a
> relatively trivial Tuscany specific extension of the shade plugin and we
> then wouldn't even need that transformer configuration. We're getting quite
> a lot of Tuscany specific plugins these days so one more is no big deal.
>
>
Personally I've had a lot of problems with it. 50% of the time it fails in
my environment (having sais that I haven't tried is since I moved to the Sun
JDK). Anyhow the utility of this plugin to us will be dictated by the shape
we want our distribution to take. If we have a single distribution then it
seems we need to ship separate module jars as the OSGi runtime is expecting
to load bundles. I guess we could write a manifest aggregator for the shade
plugin but why would we when we can ship the separate module jars and
provide a manifest jar to make manual classpath specification easier. Maybe
I'm missing something here.


>
>>
>>
>>>
>>>
>>>
>>>>
>>>>   [Launcher vs manually specified classpath comes into this]
>>>>        * Manual classpath is easier with feature jars. Can we use a
>>>> different approach to support the manual classpath? Manifest jars for each
>>>> feature?
>>>
>>>
>>> I think we need to make a bit more progress on the "Tuscany runtime
>>> launching" thread before that can be answered.
>>>
>>
>> Agreed
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>> [structured libraries directory]
>>>>   * I like this. It gives some sense of order to the distro lib
>>>> directory.
>>>>
>>>>
>>> Me too. Comparing the distros we've had in the past and the different
>>> varrieties being talked about now i think a structured libraries directory
>>> makes the most significant improvement for making the distro easier to use
>>> in the way users have been asking for.
>>>
>>>
>>>>
>>>> Some other distro thoughts came to mind as I went through:
>>>>
>>>> 1/ Can we do something about 3rd party licenses? E.g. automate the
>>>> command line tools we have that check distro jars are represented in the
>>>> LICENSE file so that this happens automatically when distro is built. Also
>>>> it would be nice to have a tool that checks that module NOTICE/LICENSE
>>>> files match the requirements of the source that they hold. This last is
>>>> manual at the moment.
>>>
>>>
>>> The way to do this would be to change to use the maven release plugin and
>>> IANAL plugin which would vastly simplify our distribution build and release
>>> process, i think it is where i think really we need to get to but it will
>>> put some restriction on how we shape the distributions which is one of the
>>> reasons i'm less keen on all these "feature" distros
>>>
>>
>> I looked at this a while back and I agree it adds restrictions. I don't
>> remember the details so I'll have to read up. I seem to think it was early
>> days when I looked at it so it was pretty rough at that point.
>>
>
> I think its pretty good these days, I know Geronimo uses it ok.
>
>
>>
>>
>>>
>>>
>>>> 2/ We need to follow through on the reason Raymond started this thread
>>>> originally and ensure that samples are tested in the ways that a user will
>>>> run then when the distribution is built.
>>>> 3/ As per 2/ but for webapp samples. Can we re-use some of the work that
>>>> was done for webapps in 1.x itest?
>>>>
>>>
>>> I'm starting to think there should be seperate distributions for OSGi and
>>> JSE/Webapps etc. Trying to munge all this into a single distribution that
>>> works for all environments so far looks like its going to make the
>>> distribution a lot more complex and less user friendly than it needs to be.
>>> You could consider this part of the "modularity" exercise of 2.0 and not
>>> munging unrelated things together. If we did that then we can test the
>>> samples included in the distribution properly in the best way for the target
>>> environment.
>>>
>>
>>  what would the difference be between these distributions? I think the
>> jars and their organization would be the same. It comes down to how you
>> launch/host the runtime so probably some hosting/launching jars would come
>> and go. Again we need to do more on the launching thread for this point.
>>
>
> Probably need actual distributions to show all the differences but for
> example the organization isn't the same - the OSGi distro requires the 3rd
> party jars be each included in its own sub folder which is unnecessary for
> other environments and would make things like "java -cp" a bit unwieldy.
> However, if we did go for the one common distro with a structure lib folder
> then this becomes less of an issue for Ant scripts and launchers.
>

I suggest we lay out the distribution file directory in some detail and try
review it. Is this what we're talking about

tuscany-sca-2.0
  bin
    tuscany.bat (is this a bat or a jar?)
    tuscany-default.conf
    tuscany-osgi.conf
    ...
  lib
    base
      acitvation-1.1
        activation-1.1.jar
        META-INF
          MANIFEST.MF
      asm-all-3.1.jar
      tuscany-assembly-2.0.jar
      tuscany-core-2.0.jar
      tuscany-contribution-2.0.jar
      ...
      tuscany-base-manifest-2.0.jar
    spring
      commons-logging-1.1.1.jar
      spring-2.5.5.jar
      tuscany-implementation-spring-2.0.jar
      tuscany-spring-manifest-2.0.jar
    webservices
  samples
    calculator
  tutorial
    store

Re: [2.0] Align samples with the distributions

[ant elder <an...@apache.org>]

On Fri, Jan 16, 2009 at 2:01 PM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Fri, Jan 16, 2009 at 1:04 PM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>> snip....
>>>
>>>>
>>>> Yes that what the current compact distribution does, its in 1.x right
>>>> now as there's few extensions going in 2.x but there should be no problems
>>>> with doing it there too.
>>>>
>>>>    ...ant
>>>>
>>>> I looked at the compact distro in 1.x and the distro projects in 2.x and
>>> this is what I found:
>>>
>>> Key
>>>    Plain text = common between the two
>>>    [] = different between the two
>>>    * = my opinion
>>>
>>> A set of maven modules which define dependencies for features
>>>    [in /modules or /distribution]
>>>    * I prefer /distribution as the feature modules are not providing any
>>> new function
>>
>>
>> There's pros and cons, where they are right now enables a facility i've
>> not mentioned yet but the where they go is not big deal at the end of the
>> day.
>>
>>
>>>
>>> Samples depend on only the feature modules that they require
>>>
>>> An "all" distribution that ships all features
>>>
>>> [separate distributions that ship individual features]
>>>   * I don't mind having them if people want to support them.
>>
>>
>> The problem with doing that is it adds some significant complexity, from
>> things like the download page, to things like the documentation for samples
>> and how to use etc.
>>
>
> As I say below I don't think we need to decide for M1. I would assert that
> we need to be able to have samples depend on separate feature distributions,
> modules call then what you will. Doesn't mean we need to ship them but does
> mean they need to exist. As in my first point I think this is a common
> feature of both approaches as they are currently implemented.
>

I don't think that would work very well, the "feature" approach is not a
feature per extension type so its only really useful for making
downloadabledistributions. That means for example a sample using
xquery you have to know xquery is in the "process" feature distribution and
download that, but you wouldn't put a maven dependency on the process
feature in the xquery sample as that would drag in all the other unnecessary
dependencies like bpel and ode, same thing for say a jsonrpc sample which
would have a dependency on the jsonrpc binding not the web20 feature as that
would drag in all the scripting stuff. The feature idea was that there would
be a small number of downloadable feature distributions as a way to manage
the growing number of Tuscany extensions, the problem is though that there
are no obvious groupings for most of the extensions so the features get
quite arbitrary as more extensions are include which makes them unintuitive
which just further complicates an already complicated project. Since they
were proposed we've asked on the dev list, user list, and in the user survey
and pretty much everyone is happy with the one big distribution, i think a
70Meg or so download is just not a big deal these days. What people do seem
to want is less jars and an easier way to know which jars are for what, and
the compact jars and structured lib folder do that. Even if we didn't use
the compact jars, the structure lib folder makes a single distribution much
more usable, its obvious what jars are for and users can easily make up
their own custom distributions if required by just deleting unneeded lib
folders.


>
>
>>
>>
>>>
>>>   * I suggest though in this first instance (M1) we just ship the "all"
>>> distro and we can see how we get on with that. This is still build from the
>>> separate feature modules.
>>>
>>
>> Yes i agree with just shipping an "all" distro for now. I'd like to leave
>> the "how its built" till this discussion has progressed a little further
>> though.
>>
>>
>>>
>>> [separate tuscany jars vs feature jars]
>>>   * I don't particularly like the feature jars as it's another step to go
>>> wrong. In particular it uses the shade(?) plugin and you have to configure
>>> transformers.
>>
>>
>> I'm puzzeled that you consider that as "another step to go wrong" but
>> don't mind having multiple different distributions or building distributions
>> out of each other, both of which seem to add much more complexity,
>> restrictions, and points of failure to me :)
>>
>
> To me it looks like a step in the process that we don't necessarily need.
> In the context of this point my measure of complexity is how many places I
> have to specify things. I agree that there are also complexities in
> distributing more that one distribution package but I don't see that that's
> particularly related to this point.
>

I'm still not understanding the problem here, adding a shade transformer
config is a pretty easy task, we've been doing it for years in the past
Tuscany releases and i don't remember a single occasion where its caused any
problem. And its only an occasional task for a Tuscany "developer" which
makes the "users" life easier every time they use Tuscany - and users have
complained about Tuscany having so many jars on lots of occasions. Also, if
thats the only hurdle in doing this then all we need to do is write a
relatively trivial Tuscany specific extension of the shade plugin and we
then wouldn't even need that transformer configuration. We're getting quite
a lot of Tuscany specific plugins these days so one more is no big deal.


>
>
>
>>
>>
>>
>>>
>>>   [Launcher vs manually specified classpath comes into this]
>>>        * Manual classpath is easier with feature jars. Can we use a
>>> different approach to support the manual classpath? Manifest jars for each
>>> feature?
>>
>>
>> I think we need to make a bit more progress on the "Tuscany runtime
>> launching" thread before that can be answered.
>>
>
> Agreed
>
>
>>
>>
>>
>>>
>>>
>>> [structured libraries directory]
>>>   * I like this. It gives some sense of order to the distro lib
>>> directory.
>>>
>>>
>> Me too. Comparing the distros we've had in the past and the different
>> varrieties being talked about now i think a structured libraries directory
>> makes the most significant improvement for making the distro easier to use
>> in the way users have been asking for.
>>
>>
>>>
>>> Some other distro thoughts came to mind as I went through:
>>>
>>> 1/ Can we do something about 3rd party licenses? E.g. automate the
>>> command line tools we have that check distro jars are represented in the
>>> LICENSE file so that this happens automatically when distro is built. Also
>>> it would be nice to have a tool that checks that module NOTICE/LICENSE
>>> files match the requirements of the source that they hold. This last is
>>> manual at the moment.
>>
>>
>> The way to do this would be to change to use the maven release plugin and
>> IANAL plugin which would vastly simplify our distribution build and release
>> process, i think it is where i think really we need to get to but it will
>> put some restriction on how we shape the distributions which is one of the
>> reasons i'm less keen on all these "feature" distros
>>
>
> I looked at this a while back and I agree it adds restrictions. I don't
> remember the details so I'll have to read up. I seem to think it was early
> days when I looked at it so it was pretty rough at that point.
>

I think its pretty good these days, I know Geronimo uses it ok.


>
>
>>
>>
>>> 2/ We need to follow through on the reason Raymond started this thread
>>> originally and ensure that samples are tested in the ways that a user will
>>> run then when the distribution is built.
>>> 3/ As per 2/ but for webapp samples. Can we re-use some of the work that
>>> was done for webapps in 1.x itest?
>>>
>>
>> I'm starting to think there should be seperate distributions for OSGi and
>> JSE/Webapps etc. Trying to munge all this into a single distribution that
>> works for all environments so far looks like its going to make the
>> distribution a lot more complex and less user friendly than it needs to be.
>> You could consider this part of the "modularity" exercise of 2.0 and not
>> munging unrelated things together. If we did that then we can test the
>> samples included in the distribution properly in the best way for the target
>> environment.
>>
>
>  what would the difference be between these distributions? I think the jars
> and their organization would be the same. It comes down to how you
> launch/host the runtime so probably some hosting/launching jars would come
> and go. Again we need to do more on the launching thread for this point.
>

Probably need actual distributions to show all the differences but for
example the organization isn't the same - the OSGi distro requires the 3rd
party jars be each included in its own sub folder which is unnecessary for
other environments and would make things like "java -cp" a bit unwieldy.
However, if we did go for the one common distro with a structure lib folder
then this becomes less of an issue for Ant scripts and launchers.

   ...ant

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Fri, Jan 16, 2009 at 1:04 PM, ant elder <an...@apache.org> wrote:

>
>
> On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <si...@googlemail.com>wrote:
>
>> snip....
>>
>>>
>>> Yes that what the current compact distribution does, its in 1.x right now
>>> as there's few extensions going in 2.x but there should be no problems with
>>> doing it there too.
>>>
>>>    ...ant
>>>
>>> I looked at the compact distro in 1.x and the distro projects in 2.x and
>> this is what I found:
>>
>> Key
>>    Plain text = common between the two
>>    [] = different between the two
>>    * = my opinion
>>
>> A set of maven modules which define dependencies for features
>>    [in /modules or /distribution]
>>    * I prefer /distribution as the feature modules are not providing any
>> new function
>
>
> There's pros and cons, where they are right now enables a facility i've not
> mentioned yet but the where they go is not big deal at the end of the day.
>
>
>>
>> Samples depend on only the feature modules that they require
>>
>> An "all" distribution that ships all features
>>
>> [separate distributions that ship individual features]
>>   * I don't mind having them if people want to support them.
>
>
> The problem with doing that is it adds some significant complexity, from
> things like the download page, to things like the documentation for samples
> and how to use etc.
>

As I say below I don't think we need to decide for M1. I would assert that
we need to be able to have samples depend on separate feature distributions,
modules call then what you will. Doesn't mean we need to ship them but does
mean they need to exist. As in my first point I think this is a common
feature of both approaches as they are currently implemented.

>
>
>
>>
>>   * I suggest though in this first instance (M1) we just ship the "all"
>> distro and we can see how we get on with that. This is still build from the
>> separate feature modules.
>>
>
> Yes i agree with just shipping an "all" distro for now. I'd like to leave
> the "how its built" till this discussion has progressed a little further
> though.
>
>
>>
>> [separate tuscany jars vs feature jars]
>>   * I don't particularly like the feature jars as it's another step to go
>> wrong. In particular it uses the shade(?) plugin and you have to configure
>> transformers.
>
>
> I'm puzzeled that you consider that as "another step to go wrong" but don't
> mind having multiple different distributions or building distributions out
> of each other, both of which seem to add much more complexity, restrictions,
> and points of failure to me :)
>

To me it looks like a step in the process that we don't necessarily need. In
the context of this point my measure of complexity is how many places I have
to specify things. I agree that there are also complexities in distributing
more that one distribution package but I don't see that that's particularly
related to this point.


>
>
>
>>
>>   [Launcher vs manually specified classpath comes into this]
>>        * Manual classpath is easier with feature jars. Can we use a
>> different approach to support the manual classpath? Manifest jars for each
>> feature?
>
>
> I think we need to make a bit more progress on the "Tuscany runtime
> launching" thread before that can be answered.
>

Agreed


>
>
>
>>
>>
>> [structured libraries directory]
>>   * I like this. It gives some sense of order to the distro lib directory.
>>
>>
> Me too. Comparing the distros we've had in the past and the different
> varrieties being talked about now i think a structured libraries directory
> makes the most significant improvement for making the distro easier to use
> in the way users have been asking for.
>
>
>>
>> Some other distro thoughts came to mind as I went through:
>>
>> 1/ Can we do something about 3rd party licenses? E.g. automate the command
>> line tools we have that check distro jars are represented in the LICENSE
>> file so that this happens automatically when distro is built. Also
>> it would be nice to have a tool that checks that module NOTICE/LICENSE
>> files match the requirements of the source that they hold. This last is
>> manual at the moment.
>
>
> The way to do this would be to change to use the maven release plugin and
> IANAL plugin which would vastly simplify our distribution build and release
> process, i think it is where i think really we need to get to but it will
> put some restriction on how we shape the distributions which is one of the
> reasons i'm less keen on all these "feature" distros
>

I looked at this a while back and I agree it adds restrictions. I don't
remember the details so I'll have to read up. I seem to think it was early
days when I looked at it so it was pretty rough at that point.

>
>
>
>> 2/ We need to follow through on the reason Raymond started this thread
>> originally and ensure that samples are tested in the ways that a user will
>> run then when the distribution is built.
>> 3/ As per 2/ but for webapp samples. Can we re-use some of the work that
>> was done for webapps in 1.x itest?
>>
>
> I'm starting to think there should be seperate distributions for OSGi and
> JSE/Webapps etc. Trying to munge all this into a single distribution that
> works for all environments so far looks like its going to make the
> distribution a lot more complex and less user friendly than it needs to be.
> You could consider this part of the "modularity" exercise of 2.0 and not
> munging unrelated things together. If we did that then we can test the
> samples included in the distribution properly in the best way for the target
> environment.
>

 what would the difference be between these distributions? I think the jars
and their organization would be the same. It comes down to how you
launch/host the runtime so probably some hosting/launching jars would come
and go. Again we need to do more on the launching thread for this point.


>
>    ...ant
>
>
>

Re: [2.0] Align samples with the distributions

[ant elder <an...@apache.org>]

On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <si...@googlemail.com>wrote:

> snip....
>
>>
>> Yes that what the current compact distribution does, its in 1.x right now
>> as there's few extensions going in 2.x but there should be no problems with
>> doing it there too.
>>
>>    ...ant
>>
>> I looked at the compact distro in 1.x and the distro projects in 2.x and
> this is what I found:
>
> Key
>    Plain text = common between the two
>    [] = different between the two
>    * = my opinion
>
> A set of maven modules which define dependencies for features
>    [in /modules or /distribution]
>    * I prefer /distribution as the feature modules are not providing any
> new function


There's pros and cons, where they are right now enables a facility i've not
mentioned yet but the where they go is not big deal at the end of the day.


>
> Samples depend on only the feature modules that they require
>
> An "all" distribution that ships all features
>
> [separate distributions that ship individual features]
>   * I don't mind having them if people want to support them.


The problem with doing that is it adds some significant complexity, from
things like the download page, to things like the documentation for samples
and how to use etc.


>
>   * I suggest though in this first instance (M1) we just ship the "all"
> distro and we can see how we get on with that. This is still build from the
> separate feature modules.
>

Yes i agree with just shipping an "all" distro for now. I'd like to leave
the "how its built" till this discussion has progressed a little further
though.


>
> [separate tuscany jars vs feature jars]
>   * I don't particularly like the feature jars as it's another step to go
> wrong. In particular it uses the shade(?) plugin and you have to configure
> transformers.


I'm puzzeled that you consider that as "another step to go wrong" but don't
mind having multiple different distributions or building distributions out
of each other, both of which seem to add much more complexity, restrictions,
and points of failure to me :)


>
>   [Launcher vs manually specified classpath comes into this]
>        * Manual classpath is easier with feature jars. Can we use a
> different approach to support the manual classpath? Manifest jars for each
> feature?


I think we need to make a bit more progress on the "Tuscany runtime
launching" thread before that can be answered.


>
>
> [structured libraries directory]
>   * I like this. It gives some sense of order to the distro lib directory.
>
>
Me too. Comparing the distros we've had in the past and the different
varrieties being talked about now i think a structured libraries directory
makes the most significant improvement for making the distro easier to use
in the way users have been asking for.


>
> Some other distro thoughts came to mind as I went through:
>
> 1/ Can we do something about 3rd party licenses? E.g. automate the command
> line tools we have that check distro jars are represented in the LICENSE
> file so that this happens automatically when distro is built. Also
> it would be nice to have a tool that checks that module NOTICE/LICENSE
> files match the requirements of the source that they hold. This last is
> manual at the moment.


The way to do this would be to change to use the maven release plugin and
IANAL plugin which would vastly simplify our distribution build and release
process, i think it is where i think really we need to get to but it will
put some restriction on how we shape the distributions which is one of the
reasons i'm less keen on all these "feature" distros


> 2/ We need to follow through on the reason Raymond started this thread
> originally and ensure that samples are tested in the ways that a user will
> run then when the distribution is built.
> 3/ As per 2/ but for webapp samples. Can we re-use some of the work that
> was done for webapps in 1.x itest?
>

I'm starting to think there should be seperate distributions for OSGi and
JSE/Webapps etc. Trying to munge all this into a single distribution that
works for all environments so far looks like its going to make the
distribution a lot more complex and less user friendly than it needs to be.
You could consider this part of the "modularity" exercise of 2.0 and not
munging unrelated things together. If we did that then we can test the
samples included in the distribution properly in the best way for the target
environment.

   ...ant

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

snip....

>
> Yes that what the current compact distribution does, its in 1.x right now
> as there's few extensions going in 2.x but there should be no problems with
> doing it there too.
>
>    ...ant
>
> I looked at the compact distro in 1.x and the distro projects in 2.x and
this is what I found:

Key
   Plain text = common between the two
   [] = different between the two
   * = my opinion

A set of maven modules which define dependencies for features
   [in /modules or /distribution]
   * I prefer /distribution as the feature modules are not providing any new
function

Samples depend on only the feature modules that they require

An "all" distribution that ships all features

[separate distributions that ship individual features]
  * I don't mind having them if people want to support them.
  * I suggest though in this first instance (M1) we just ship the "all"
distro and we can see how we get on with that. This is still build from the
separate feature modules.

[separate tuscany jars vs feature jars]
  * I don't particularly like the feature jars as it's another step to go
wrong. In particular it uses the shade(?) plugin and you have to configure
transformers.
  [Launcher vs manually specified classpath comes into this]
       * Manual classpath is easier with feature jars. Can we use a
different approach to support the manual classpath? Manifest jars for each
feature?

[structured libraries directory]
  * I like this. It gives some sense of order to the distro lib directory.


Some other distro thoughts came to mind as I went through:

1/ Can we do something about 3rd party licenses? E.g. automate the command
line tools we have that check distro jars are represented in the LICENSE
file so that this happens automatically when distro is built. Also
it would be nice to have a tool that checks that module NOTICE/LICENSE files
match the requirements of the source that they hold. This last is manual at
the moment.
2/ We need to follow through on the reason Raymond started this thread
originally and ensure that samples are tested in the ways that a user will
run then when the distribution is built.
3/ As per 2/ but for webapp samples. Can we re-use some of the work that was
done for webapps in 1.x itest?

I'm happy to help with any of these.

Simon

Re: [2.0] Align samples with the distributions

[ant elder <an...@apache.org>]

On Thu, Jan 15, 2009 at 12:06 PM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Thu, Jan 15, 2009 at 11:43 AM, ant elder <an...@gmail.com> wrote:
>
>> As an fyi to where this is up to there is a compact distribution at [1]
>> now which does what was described in this thread. So I'd now like to try to
>> see if we can come up with a single Tuscany distribution that everyone could
>> be happy with as it would make things much simpler if there is one main
>> distribution.
>>
>> One thing i think is an improvement is instead of having all the jars in a
>> single lib folder to have the lib folder include sub directories for the
>> various extensions as that makes it much more obvious what jars are required
>> for what function, and it makes much easier to remove jars if you don't want
>> some function. For example:
>>
>> lib/
>>    tuscany core modules and their dependencies like asm and cglib
>> lib/webservices
>>  tuscany webservices modules and their dependencies like axis2
>> lib/bpel
>>  tuscany bpel modules and their dependencies ode
>> lib/standalone
>>  tuscany standalone runtime modules and dependencies like jetty
>> lib/jdk5
>>  the dependency jars needed when using JDK5 not JDK6, like stax, jaxb etc
>> lib/...folders for all the other extensions
>>
>> So instead of having lots of distributions which you can download
>> individually to build up a custom install you have a single distribution
>> that you can remove stuff from to make a custom install.
>>
>> Any comments on that approach?
>>
>>    ...ant
>>
>
> Hi Ant
>
> Can we have an all distribution and the individual ones that build up to
> create the all distribution? From Raymond's original post is would be useful
> to have samples depend on just the individual parts that they need so that
> when you create an eclipse project you don't get every module in Tuscany as
> a dependency.
>

That is exactly what this gives us, for example take a look at the
calculator , spring, or webservice samples included in the distribution.
And, IMHO it is vastly more user friendly than having a dozen or so
different distributions that you need to download one by one depending on
what your application needs.


>
> Re. the grouping of libs. I like the sound of that if we can make it work
> for all environments. Have you code code that does this? Can we try that in
> 2.x and see if it's possible?
>
>
Yes that what the current compact distribution does, its in 1.x right now as
there's few extensions going in 2.x but there should be no problems with
doing it there too.

   ...ant

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

On Thu, Jan 15, 2009 at 11:43 AM, ant elder <an...@gmail.com> wrote:

> As an fyi to where this is up to there is a compact distribution at [1] now
> which does what was described in this thread. So I'd now like to try to see
> if we can come up with a single Tuscany distribution that everyone could be
> happy with as it would make things much simpler if there is one main
> distribution.
>
> One thing i think is an improvement is instead of having all the jars in a
> single lib folder to have the lib folder include sub directories for the
> various extensions as that makes it much more obvious what jars are required
> for what function, and it makes much easier to remove jars if you don't want
> some function. For example:
>
> lib/
>    tuscany core modules and their dependencies like asm and cglib
> lib/webservices
>  tuscany webservices modules and their dependencies like axis2
> lib/bpel
>  tuscany bpel modules and their dependencies ode
> lib/standalone
>  tuscany standalone runtime modules and dependencies like jetty
> lib/jdk5
>  the dependency jars needed when using JDK5 not JDK6, like stax, jaxb etc
> lib/...folders for all the other extensions
>
> So instead of having lots of distributions which you can download
> individually to build up a custom install you have a single distribution
> that you can remove stuff from to make a custom install.
>
> Any comments on that approach?
>
>    ...ant
>

Hi Ant

Can we have an all distribution and the individual ones that build up to
create the all distribution? From Raymond's original post is would be useful
to have samples depend on just the individual parts that they need so that
when you create an eclipse project you don't get every module in Tuscany as
a dependency.

Re. the grouping of libs. I like the sound of that if we can make it work
for all environments. Have you code code that does this? Can we try that in
2.x and see if it's possible?

Simon

Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

As an fyi to where this is up to there is a compact distribution at [1] now
which does what was described in this thread. So I'd now like to try to see
if we can come up with a single Tuscany distribution that everyone could be
happy with as it would make things much simpler if there is one main
distribution.

One thing i think is an improvement is instead of having all the jars in a
single lib folder to have the lib folder include sub directories for the
various extensions as that makes it much more obvious what jars are required
for what function, and it makes much easier to remove jars if you don't want
some function. For example:

lib/
   tuscany core modules and their dependencies like asm and cglib
lib/webservices
 tuscany webservices modules and their dependencies like axis2
lib/bpel
 tuscany bpel modules and their dependencies ode
lib/standalone
 tuscany standalone runtime modules and dependencies like jetty
lib/jdk5
 the dependency jars needed when using JDK5 not JDK6, like stax, jaxb etc
lib/...folders for all the other extensions

So instead of having lots of distributions which you can download
individually to build up a custom install you have a single distribution
that you can remove stuff from to make a custom install.

Any comments on that approach?

   ...ant

[1]
https://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/distribution/compact/

On Mon, Dec 29, 2008 at 2:33 PM, ant elder <an...@gmail.com> wrote:

> I'm going to start trying to do this now, any comments, suggests and help
> welcome as it progresses. For now think i'll use the 1.x branch as that will
> be easier to show the different extensions.
>
>    ...ant
>
>
> On Fri, Dec 12, 2008 at 11:27 AM, ant elder <an...@gmail.com> wrote:
>
>> Yes right now the compact distribution uses JSE 1.6 and it just supports
>> the equivalent of the current core distribution (plus some initial webapp
>> support).
>>
>> What i had in mind for this is to make something small and simple that
>> makes it easy to start out trying Tuscany. It doesn't have to support the
>> complete range of features in 2.0, for that you'd need the other
>> distributions, so just pick a subset of Tuscany functionality and extensions
>> - the popular things highlighted from the user survey. If there was going to
>> be just the one distribution in 2.0 this might be making things more
>> complicated but as it looks like there is going to be lots (9?) one more
>> distribution wont add much complexity.
>>
>> It would included a minimum of jars, they'd be laid out so its easy to see
>> which jars are required for each bit of function, and where possible jars
>> would be aggregated so there are only a very small number of them. There'd
>> also only be a minimum of samples included, just enough to show each high
>> level bit of functionality, with pointers to the website and samples
>> included in other distributions for more comprehensive coverage.
>>
>> I think this is worth trying now anyway, we could see how it pans out as
>> 2.0 progresses?
>>
>>   ...ant
>>
>>
>> On Fri, Dec 12, 2008 at 6:07 AM, Raymond Feng <en...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > What features can be supported by the "compact" distro? Does the
>> "compact"
>> > require JSE 1.6? We can probably include 3 distributions in M1:
>> >
>> > minimum (compact)
>> > core: implementation.java + binding.sca (local)
>> > webservice: core + binding.ws
>> >
>> > Thanks,
>> > Raymond
>> > From: ant elder
>> > Sent: Thursday, December 11, 2008 12:06 AM
>> > To: dev@tuscany.apache.org
>> > Subject: Re: [2.0] Align samples with the distributions
>> >
>> >
>> > On Wed, Dec 10, 2008 at 9:52 PM, Raymond Feng <en...@gmail.com>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> It has always been a pain to run the ANT scripts against the samples
>> >> manually at the last moment for releases. We often see inconsistent
>> >> behaviors depending on whether a sample is run against the distribution
>> or
>> >> the maven dependencies.  One of the culprits is that the ANT script
>> sets the
>> >> classpath on the distribution while the maven build sets the classpath
>> based
>> >> on the maven dependencies.
>> >>
>> >> In the 2.x stream, we now have opportunities to solve this problem:
>> >>
>> >> 1) Instead of just an all-in-one package, we now have a set of
>> >> distributions to include selected Tuscany modules and 3rd-party jars
>> based
>> >> on the functions. The pom.xml for each distribution well defines the
>> >> dependencies.
>> >> 2) Building the distributions is much faster than before (only a 1-2
>> >> minutes on my laptop).
>> >> 3) Meanwhile, we would like to run the samples under both JSE and OSGi.
>> >> OSGi typically requires a distribution on the file system that is
>> compatible
>> >> with the bundle structure.
>> >>
>> >> I suggest that we better align the samples with a selected distribution
>> >> and automate the testing under JSE and OSGi with Maven and Ant. We can
>> do
>> >> the following:
>> >>
>> >> 1) Simply the maven dependency in the pom.xml for samples to only
>> declare
>> >> a distribution, for example,
>> >>
>> >>       <dependency>
>> >>           <groupId>org.apache.tuscany.sca</groupId>
>> >>           <artifactId>tuscany-distribution-core</artifactId>
>> >>           <type>pom</type>
>> >>           <version>2.0-SNAPSHOT</version>
>> >>       </dependency>
>> >>
>> >> 2) Modify the build.xml to use Node (Standalone and Equinox) launchers
>> to
>> >> run the samples. And explore the "junit" Ant task to run test cases in
>> the
>> >> Ant build
>> >>
>> >> 3) Automate the post-distribution build to run the test cases in the
>> >> samples to make sure the samples are validated as part of the build.
>> >>
>> >> Thoughts? Are any of you interested in experimenting?
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >>
>> >
>> > We also now have the "compact" distribution which fixes these same
>> problems,
>> > is even easier to use, and is also fast to build (<20 secs on my
>> laptop). I
>> > think its worth including this as a released distribution option and
>> used by
>> > some samples.
>> >
>> >    ...ant
>> >
>> >
>>
>>
>

Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

I'm going to start trying to do this now, any comments, suggests and help
welcome as it progresses. For now think i'll use the 1.x branch as that will
be easier to show the different extensions.

   ...ant

On Fri, Dec 12, 2008 at 11:27 AM, ant elder <an...@gmail.com> wrote:

> Yes right now the compact distribution uses JSE 1.6 and it just supports
> the equivalent of the current core distribution (plus some initial webapp
> support).
>
> What i had in mind for this is to make something small and simple that
> makes it easy to start out trying Tuscany. It doesn't have to support the
> complete range of features in 2.0, for that you'd need the other
> distributions, so just pick a subset of Tuscany functionality and extensions
> - the popular things highlighted from the user survey. If there was going to
> be just the one distribution in 2.0 this might be making things more
> complicated but as it looks like there is going to be lots (9?) one more
> distribution wont add much complexity.
>
> It would included a minimum of jars, they'd be laid out so its easy to see
> which jars are required for each bit of function, and where possible jars
> would be aggregated so there are only a very small number of them. There'd
> also only be a minimum of samples included, just enough to show each high
> level bit of functionality, with pointers to the website and samples
> included in other distributions for more comprehensive coverage.
>
> I think this is worth trying now anyway, we could see how it pans out as
> 2.0 progresses?
>
>   ...ant
>
>
> On Fri, Dec 12, 2008 at 6:07 AM, Raymond Feng <en...@gmail.com> wrote:
> > Hi,
> >
> > What features can be supported by the "compact" distro? Does the
> "compact"
> > require JSE 1.6? We can probably include 3 distributions in M1:
> >
> > minimum (compact)
> > core: implementation.java + binding.sca (local)
> > webservice: core + binding.ws
> >
> > Thanks,
> > Raymond
> > From: ant elder
> > Sent: Thursday, December 11, 2008 12:06 AM
> > To: dev@tuscany.apache.org
> > Subject: Re: [2.0] Align samples with the distributions
> >
> >
> > On Wed, Dec 10, 2008 at 9:52 PM, Raymond Feng <en...@gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> It has always been a pain to run the ANT scripts against the samples
> >> manually at the last moment for releases. We often see inconsistent
> >> behaviors depending on whether a sample is run against the distribution
> or
> >> the maven dependencies.  One of the culprits is that the ANT script sets
> the
> >> classpath on the distribution while the maven build sets the classpath
> based
> >> on the maven dependencies.
> >>
> >> In the 2.x stream, we now have opportunities to solve this problem:
> >>
> >> 1) Instead of just an all-in-one package, we now have a set of
> >> distributions to include selected Tuscany modules and 3rd-party jars
> based
> >> on the functions. The pom.xml for each distribution well defines the
> >> dependencies.
> >> 2) Building the distributions is much faster than before (only a 1-2
> >> minutes on my laptop).
> >> 3) Meanwhile, we would like to run the samples under both JSE and OSGi.
> >> OSGi typically requires a distribution on the file system that is
> compatible
> >> with the bundle structure.
> >>
> >> I suggest that we better align the samples with a selected distribution
> >> and automate the testing under JSE and OSGi with Maven and Ant. We can
> do
> >> the following:
> >>
> >> 1) Simply the maven dependency in the pom.xml for samples to only
> declare
> >> a distribution, for example,
> >>
> >>       <dependency>
> >>           <groupId>org.apache.tuscany.sca</groupId>
> >>           <artifactId>tuscany-distribution-core</artifactId>
> >>           <type>pom</type>
> >>           <version>2.0-SNAPSHOT</version>
> >>       </dependency>
> >>
> >> 2) Modify the build.xml to use Node (Standalone and Equinox) launchers
> to
> >> run the samples. And explore the "junit" Ant task to run test cases in
> the
> >> Ant build
> >>
> >> 3) Automate the post-distribution build to run the test cases in the
> >> samples to make sure the samples are validated as part of the build.
> >>
> >> Thoughts? Are any of you interested in experimenting?
> >>
> >> Thanks,
> >> Raymond
> >>
> >>
> >
> > We also now have the "compact" distribution which fixes these same
> problems,
> > is even easier to use, and is also fast to build (<20 secs on my laptop).
> I
> > think its worth including this as a released distribution option and used
> by
> > some samples.
> >
> >    ...ant
> >
> >
>
>

Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

Yes right now the compact distribution uses JSE 1.6 and it just supports the
equivalent of the current core distribution (plus some initial webapp
support).

What i had in mind for this is to make something small and simple that makes
it easy to start out trying Tuscany. It doesn't have to support the complete
range of features in 2.0, for that you'd need the other distributions, so
just pick a subset of Tuscany functionality and extensions - the popular
things highlighted from the user survey. If there was going to be just the
one distribution in 2.0 this might be making things more complicated but as
it looks like there is going to be lots (9?) one more distribution wont add
much complexity.

It would included a minimum of jars, they'd be laid out so its easy to see
which jars are required for each bit of function, and where possible jars
would be aggregated so there are only a very small number of them. There'd
also only be a minimum of samples included, just enough to show each high
level bit of functionality, with pointers to the website and samples
included in other distributions for more comprehensive coverage.

I think this is worth trying now anyway, we could see how it pans out as 2.0
progresses?

  ...ant

On Fri, Dec 12, 2008 at 6:07 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> What features can be supported by the "compact" distro? Does the "compact"
> require JSE 1.6? We can probably include 3 distributions in M1:
>
> minimum (compact)
> core: implementation.java + binding.sca (local)
> webservice: core + binding.ws
>
> Thanks,
> Raymond
> From: ant elder
> Sent: Thursday, December 11, 2008 12:06 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.0] Align samples with the distributions
>
>
> On Wed, Dec 10, 2008 at 9:52 PM, Raymond Feng <en...@gmail.com> wrote:
>>
>> Hi,
>>
>> It has always been a pain to run the ANT scripts against the samples
>> manually at the last moment for releases. We often see inconsistent
>> behaviors depending on whether a sample is run against the distribution
or
>> the maven dependencies.  One of the culprits is that the ANT script sets
the
>> classpath on the distribution while the maven build sets the classpath
based
>> on the maven dependencies.
>>
>> In the 2.x stream, we now have opportunities to solve this problem:
>>
>> 1) Instead of just an all-in-one package, we now have a set of
>> distributions to include selected Tuscany modules and 3rd-party jars
based
>> on the functions. The pom.xml for each distribution well defines the
>> dependencies.
>> 2) Building the distributions is much faster than before (only a 1-2
>> minutes on my laptop).
>> 3) Meanwhile, we would like to run the samples under both JSE and OSGi.
>> OSGi typically requires a distribution on the file system that is
compatible
>> with the bundle structure.
>>
>> I suggest that we better align the samples with a selected distribution
>> and automate the testing under JSE and OSGi with Maven and Ant. We can do
>> the following:
>>
>> 1) Simply the maven dependency in the pom.xml for samples to only declare
>> a distribution, for example,
>>
>>       <dependency>
>>           <groupId>org.apache.tuscany.sca</groupId>
>>           <artifactId>tuscany-distribution-core</artifactId>
>>           <type>pom</type>
>>           <version>2.0-SNAPSHOT</version>
>>       </dependency>
>>
>> 2) Modify the build.xml to use Node (Standalone and Equinox) launchers to
>> run the samples. And explore the "junit" Ant task to run test cases in
the
>> Ant build
>>
>> 3) Automate the post-distribution build to run the test cases in the
>> samples to make sure the samples are validated as part of the build.
>>
>> Thoughts? Are any of you interested in experimenting?
>>
>> Thanks,
>> Raymond
>>
>>
>
> We also now have the "compact" distribution which fixes these same
problems,
> is even easier to use, and is also fast to build (<20 secs on my laptop).
I
> think its worth including this as a released distribution option and used
by
> some samples.
>
>    ...ant
>
>

Re: [2.0] Align samples with the distributions

[Raymond Feng <en...@gmail.com>]

Hi,

What features can be supported by the "compact" distro? Does the "compact" require JSE 1.6? We can probably include 3 distributions in M1:

minimum (compact)
core: implementation.java + binding.sca (local)
webservice: core + binding.ws

Thanks,
Raymond


From: ant elder 
Sent: Thursday, December 11, 2008 12:06 AM
To: dev@tuscany.apache.org 
Subject: Re: [2.0] Align samples with the distributions





On Wed, Dec 10, 2008 at 9:52 PM, Raymond Feng <en...@gmail.com> wrote:

  Hi,

  It has always been a pain to run the ANT scripts against the samples manually at the last moment for releases. We often see inconsistent behaviors depending on whether a sample is run against the distribution or the maven dependencies.  One of the culprits is that the ANT script sets the classpath on the distribution while the maven build sets the classpath based on the maven dependencies.

  In the 2.x stream, we now have opportunities to solve this problem:

  1) Instead of just an all-in-one package, we now have a set of distributions to include selected Tuscany modules and 3rd-party jars based on the functions. The pom.xml for each distribution well defines the dependencies.
  2) Building the distributions is much faster than before (only a 1-2 minutes on my laptop).
  3) Meanwhile, we would like to run the samples under both JSE and OSGi. OSGi typically requires a distribution on the file system that is compatible with the bundle structure.

  I suggest that we better align the samples with a selected distribution and automate the testing under JSE and OSGi with Maven and Ant. We can do the following:

  1) Simply the maven dependency in the pom.xml for samples to only declare a distribution, for example,

        <dependency>
            <groupId>org.apache.tuscany.sca</groupId>
            <artifactId>tuscany-distribution-core</artifactId>
            <type>pom</type>
            <version>2.0-SNAPSHOT</version>
        </dependency>

  2) Modify the build.xml to use Node (Standalone and Equinox) launchers to run the samples. And explore the "junit" Ant task to run test cases in the Ant build

  3) Automate the post-distribution build to run the test cases in the samples to make sure the samples are validated as part of the build.

  Thoughts? Are any of you interested in experimenting?

  Thanks,
  Raymond




We also now have the "compact" distribution which fixes these same problems, is even easier to use, and is also fast to build (<20 secs on my laptop). I think its worth including this as a released distribution option and used by some samples.

   ...ant

Re: [2.0] Align samples with the distributions

[ant elder <an...@gmail.com>]

On Wed, Dec 10, 2008 at 9:52 PM, Raymond Feng <en...@gmail.com> wrote:

> Hi,
>
> It has always been a pain to run the ANT scripts against the samples
> manually at the last moment for releases. We often see inconsistent
> behaviors depending on whether a sample is run against the distribution or
> the maven dependencies.  One of the culprits is that the ANT script sets the
> classpath on the distribution while the maven build sets the classpath based
> on the maven dependencies.
>
> In the 2.x stream, we now have opportunities to solve this problem:
>
> 1) Instead of just an all-in-one package, we now have a set of
> distributions to include selected Tuscany modules and 3rd-party jars based
> on the functions. The pom.xml for each distribution well defines the
> dependencies.
> 2) Building the distributions is much faster than before (only a 1-2
> minutes on my laptop).
> 3) Meanwhile, we would like to run the samples under both JSE and OSGi.
> OSGi typically requires a distribution on the file system that is compatible
> with the bundle structure.
>
> I suggest that we better align the samples with a selected distribution and
> automate the testing under JSE and OSGi with Maven and Ant. We can do the
> following:
>
> 1) Simply the maven dependency in the pom.xml for samples to only declare a
> distribution, for example,
>
>       <dependency>
>           <groupId>org.apache.tuscany.sca</groupId>
>           <artifactId>tuscany-distribution-core</artifactId>
>           <type>pom</type>
>           <version>2.0-SNAPSHOT</version>
>       </dependency>
>
> 2) Modify the build.xml to use Node (Standalone and Equinox) launchers to
> run the samples. And explore the "junit" Ant task to run test cases in the
> Ant build
>
> 3) Automate the post-distribution build to run the test cases in the
> samples to make sure the samples are validated as part of the build.
>
> Thoughts? Are any of you interested in experimenting?
>
> Thanks,
> Raymond
>
>
>
We also now have the "compact" distribution which fixes these same problems,
is even easier to use, and is also fast to build (<20 secs on my laptop). I
think its worth including this as a released distribution option and used by
some samples.

   ...ant

Re: [2.0] Align samples with the distributions

[Simon Laws <si...@googlemail.com>]

Hi Raymond

Comments in line...

Simon

On Wed, Dec 10, 2008 at 9:52 PM, Raymond Feng <en...@gmail.com> wrote:

> Hi,
>
> It has always been a pain to run the ANT scripts against the samples
> manually at the last moment for releases. We often see inconsistent
> behaviors depending on whether a sample is run against the distribution or
> the maven dependencies.  One of the culprits is that the ANT script sets the
> classpath on the distribution while the maven build sets the classpath based
> on the maven dependencies.
>
> In the 2.x stream, we now have opportunities to solve this problem:
>
> 1) Instead of just an all-in-one package, we now have a set of
> distributions to include selected Tuscany modules and 3rd-party jars based
> on the functions. The pom.xml for each distribution well defines the
> dependencies.
> 2) Building the distributions is much faster than before (only a 1-2
> minutes on my laptop).
> 3) Meanwhile, we would like to run the samples under both JSE and OSGi.
> OSGi typically requires a distribution on the file system that is compatible
> with the bundle structure.
>
> I suggest that we better align the samples with a selected distribution and
> automate the testing under JSE and OSGi with Maven and Ant. We can do the
> following:
>
> 1) Simply the maven dependency in the pom.xml for samples to only declare a
> distribution, for example,
>
>       <dependency>
>           <groupId>org.apache.tuscany.sca</groupId>
>           <artifactId>tuscany-distribution-core</artifactId>
>           <type>pom</type>
>           <version>2.0-SNAPSHOT</version>
>       </dependency>


Sounds like it's worth a try. Anything we can do to make the samples
automatically consistent with the distribution gets a bit +1 from me

>
>
> 2) Modify the build.xml to use Node (Standalone and Equinox) launchers to
> run the samples. And explore the "junit" Ant task to run test cases in the
> Ant build


I've created a new build.xml for calculator-exquinox that relies on running
either the JSE or Equinox launcher. Two separate targets at the moment. I'm
not so keen on using Ant to call JUnit simply because I'd like the user to
be able to look in the ant script and see the commands they would type on
the command line being used.


>
>
> 3) Automate the post-distribution build to run the test cases in the
> samples to make sure the samples are validated as part of the build.
>

Are you suggesting that the samples would be build as part of the normal to
down build?


>
> Thoughts? Are any of you interested in experimenting?
>
> Thanks,
> Raymond
>
>
>