On Thu, Oct 14, 2010 at 10:08 AM, Simon Laws <[email protected]> wrote: > On Thu, Oct 14, 2010 at 9:29 AM, ant elder <[email protected]> wrote: >> On Thu, Oct 14, 2010 at 8:56 AM, Simon Laws <[email protected]> >> wrote: >>> On Thu, Oct 14, 2010 at 8:27 AM, ant elder (JIRA) >>> <[email protected]> wrote: >>>> Aggregate JARs don't work with Maven >>>> ------------------------------------ >>>> >>>> Key: TUSCANY-3721 >>>> URL: https://issues.apache.org/jira/browse/TUSCANY-3721 >>>> Project: Tuscany >>>> Issue Type: Bug >>>> Reporter: ant elder >>>> Fix For: Java-SCA-2.0-Beta1 >>>> >>>> >>>> The new aggregate JARs don't work with Maven because the shade plugin >>>> isn't configured to promote transitive dependencies which that means all >>>> the individual module jars are still included as transitive dependencies >>>> and added to the classpath. Updating the shade config to promote >>>> transitive dependencies also doesn't work as the shade plugin doesn't work >>>> with pom type dependencies. >>>> >>>> >>>> -- >>>> This message is automatically generated by JIRA. >>>> - >>>> You can reply to this email to add a comment to the issue online. >>>> >>>> >>> >>> I've yet to try this out and really understand what the issue is here >>> so my next comment may be rubbish but.... >>> >>> I wonder whether this really matters. We have other poms that describe >>> the contents of aggregate jars so do we need the user to be able to >>> depend on the aggregated jar itself from Maven? >>> >> >> I'd like to fix it as i prefer the aggregate jars to the pom type >> approach. If they are fixed then that question could be flipped around >> to be: if we have the aggregate jars do users really need to use the >> pom type dependencies? >> >> To put this in (my) perspective look at whats common practice in other >> projects. I can point at lots of projects that aggregate small modules >> into easier to manage and use aggregate jars. On the other hand i >> don't know of a single other project in the world that you use with a >> pom type dependency. Take the Tuscany build as an example - it uses >> zillions of dependencies but not a single one is a pom type >> dependency. What ever the pros and cons the pom type approach is much >> less common, and that makes sense to me as fewer jars and dependencies >> is simpler. >> >> I think its good to try to have Tuscany work in as normal a way as >> possible because that makes it easier for people getting started with >> Tuscany. This is why i keep on trying have things be "normal" in >> Tuscany - the Maven build to use the standard build commands, the IDE >> setup to use standard IDE set up, the Tuscany APIs to match what the >> SCA specs describe, etc, the aggregate base jar is just more of that. >> Fine if people also want to experiment with other approaches too but i >> think we should strive have the more commonly understood approaches >> work as well where possible. >> >> ...ant > > I'll give it a go as I'm still not clear what the actual problem is. >
The problem is that the shade plugin doesn't work with pom type dependencies, so when the dependency reduced pom.xml is created it still contains the pom type dependency so all the individual Tuscany modules are still included as transitive dependencies, so everything is duplicated and both the shaded jar and individual module jars get included on the classpath and included in things like the webapp lib directory. The only easy way around this i can see is to duplicate what the pom type module does and include the actual module dependencies in the aggregate jar pom.xml. I guess the shade plugin could be fixed but i have had a look but it wasn't immediately obvious where its going wrong, and we'd have to wait for the fixed version to be released. This is similar to the dependency plugin also not working with pom type dependencies (and is probably just another symptom of the fact that pom type dependencies are a little uncommon). ...ant
