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 ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Sep 10, 2010, at 1:31 AM, ant elder wrote: > I'm not sure that i see the value of the feature modules. Take the > webservice or binding-ws ones (they both look like they do the same > thing), why would you use that when it just does the same as using the > actual tuscany ws module tuscany-binding-ws-runtime? Or the ejava > feature that bundles all sorts of unrelated stuff like spring and osgi > and scripting etc, why would you ever want to use that and drag in a > whole lot of unnecessary dependencies when instead you can just depend > on the actual tuscany runtime modules that you need? > > ...ant > > On Thu, Sep 9, 2010 at 5:46 PM, Raymond Feng <[email protected]> wrote: >> Hi, >> There are a few different goals around this area based on previous >> discussions: >> 1) A way to group a set of dependencies which are logically used together to >> perform certain functions >> 2) A way for application developers to specify the required jars on the >> class path (w or w/o maven) >> 3) A way for Tuscany adopters (end users or embedders) to choose the >> functions without dragging in all modules >> Let's try to map these goals to the two approaches we have in Tuscany so far >> (A: feature poms, B: shade jars) >> Here is my vote: >> Goal 1): option A (based on the maven best practice documented at [1]) >> Goal 2): option A for maven users. I'm open to have aggregated jars from >> option B for non-maven users. >> The decision is probably related hosting environment: >> JSE classpath (Option A or B) >> ANT (Option A or B) >> Eclipse classpath (Option A or B) >> OSGi bundles (Option A because we can produce the feature based bundle >> configurations) >> WEB-INF/lib (Option A or B. I'm using maven WAR or dependency plugin to >> handle the jars) >> Goal 3): option A (they can use the pom project to assemble the tuscany >> runtimes from core and selected extensions) >> If we decide to keep both options, I would suggest to align them as follows: >> a) Use feature poms to group the dependencies that goes into a shade jar >> b) Use mavne shade plugin to generate the shaded jar for a given feature >> c) Make the aggregated jars available in maven repo and a separate folder >> under the distro >> [1] >> http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-grouping-deps >> Thanks, >> Raymond >> ________________________________________________________________ >> Raymond Feng >> [email protected] >> Apache Tuscany PMC member and committer: tuscany.apache.org >> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com >> Personal Web Site: www.enjoyjava.com >> ________________________________________________________________ >> On Sep 9, 2010, at 3:34 AM, Simon Laws (JIRA) wrote: >> >> Review/consolidate 2.x distribution structure >> --------------------------------------------- >> >> Key: TUSCANY-3674 >> URL: https://issues.apache.org/jira/browse/TUSCANY-3674 >> Project: Tuscany >> Issue Type: Improvement >> Components: Java SCA Core Runtime >> Affects Versions: Java-SCA-2.0-M5 >> Environment: All >> Reporter: Simon Laws >> >> >> We currently have a number of mechanisms for packaging distributed >> artifacts. Primarily: >> >> - Modules are grouped together into features >> (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/features/) >> - Modules are grouped together into shaded jars >> (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/shades/) >> >> It's not clear why these grouped functions have to be specified in different >> pom.xml files in different places in the code base. >> >> Also the resulting 2.x distributions have both a features directory (from >> the features) and a lib director (containing jars from the shades directory) >> alongside the modules directory. This is at best confusing. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >>
