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
