On Wed, Sep 15, 2010 at 2:44 PM, ant elder <antel...@apache.org> wrote: > On Wed, Sep 15, 2010 at 10:37 AM, Simon Laws <simonsl...@googlemail.com> > wrote: >> On Mon, Sep 13, 2010 at 1:58 PM, ant elder <ant.el...@gmail.com> wrote: >>> On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws <simonsl...@googlemail.com> >>> wrote: >>>> Hi >>>> >>>> >>>> On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng <enjoyj...@gmail.com> wrote: >>>>> What really matters here is the mechanism. The feature poms we have now >>>>> are >>>>> just some pre-canned profiles to demonstrate ways of grouping modules >>>>> together (like the various Eclipse packages for people to pick). They are >>>>> choices and there are always specific needs to regroup. If you are not >>>>> happy >>>>> with the grouping, you can easily add yours. >>>>> Thanks, >>>>> Raymond >>>> >>>> Right, the point here is that we are defining a mechanism that is able >>>> to produce the artifacts that we want to see in the binary Tuscany >>>> distribution. >>> >>> There's lots of different ways the artifacts can be produced, what >>> difference does it really make how its done, users are just interested >>> in the artifcats not how they're made. If we have aggregated jars they >>> can be made with the shade plugin or assembly plugin or several other >>> ways, maven users could use the pom type features or just depend on >>> the module jars to get the transitive dependencies, all the approaches >>> work, what happens inside the build to produce the artifacts seems >>> minor, this question you have next seems like the important thing - >> >> I agree that the exact technical approach we choose is not important >> but I do think it is important that we don't foster multiple ways of >> achieving the same end as a developer community. Otherwise we just go >> off and do our own favourite things and argue that it doesn't matter >> because it's only the result that's important. The problem is then >> that the distribution is constructed from an unmaintainable jigsaw of >> different and competing processes where only certain people know about >> certain parts of the puzzle. That doesn't feel like a very comfortable >> place to be. >> >> ...snip >> > > I agree there are quite a lot of parts which it would be good to > simplify. One thing that could help would be to reduce the number of > all these different dependencies. If we look at the features and > shades that currently exists how many are really needed? I've already > asked about why we need the webservice/binding.ws/ejava ones, really i > think the mains ones are the core/base and perhaps the osgi one, what > would break if we removed the others? > > ...ant >
let's split the webservice/binding.ws from ejava. I can't speak to ejava as I don't know what ejava means precisely (is it an accepted acronym for something?) Originally I had thought it important to have web services separate from base so that people didn't have to have web services if they didn't want to. I'm not so sure now as you can't run the otests without web services. The test I have in mind for defining the base function is what it takes to run the base otests which I would consider to be... Assembly JCAA JCI Policy WebServices (included as you can't run the previous four tests without web services support so we might as well include it) everything else would be an optional extension that the user can choose to include using a simple and obvious common pattern, e.g. binding-jms implementation-spring host-webapp etc. I imagine people have different views. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
