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. > > >
