> > >> Looking at the code it's interesting as >> ContributionServiceImp.processReadPhase() has special code to ensure that >> all the intents, policy sets etc from all definitions that are found during >> the read of a single contribution are added to the >> policyDefinitionsResolver. However when it comes to resolve time, as Raymond >> points out, the definitions.xml files are resolved independently, one at a >> time. Hence successful resolution is order dependent. >> >> It seems to me that the solution to this depends on whether we take the >> spec at face value and assume that definitions.xml files that can appear in >> contributions in Tuscany are logically part of "a global, SCA Domain-wide >> file". Or if these individual definitions.xml files are subject to >> contribution import/export semantics? >> >> If the former then we need some separate domain level processing (just >> before the build phase?) that does policy resolution. If the latter we need >> to make sure that the policy artifacts are resolved in the correct order >> across definitions files within a contribution rather than just within a >> single definitons.xml file. >> >> To me the latter seems to fit the contribution model more accurately and >> hence it seems to be the more consistent of the two. Does seem to contradict >> the spec though. >> >> Simon >> >> > Two thoughts: > > - We should follow the spec and assume that definitions.xml are global in > an SCA domain. Using the contribution resolve mechanism would contribute to > pollute app artifacts (contributions) with Policy related declarations (as > your app contributions would have to declare imports for the policies). > > - This issue is just another manifestation of a bigger issue with the > Contribution service which runs the resolve phase too early, per > contribution, before all contributions are read. Fixing that will fix the > Policy issue and will allow us to remove the workarounds in the current > Policy processing code, which - although I didn't completely understand that > code - seems to change the Intent's unresolved flag when it shouldn't. > > -- > Jean-Sebastien >
The JIRA (https://issues.apache.org/jira/browse/TUSCANY-2499) lead to the discussion in the parent thread the implications of which are a change in contribution processing. Summary of current front end process steps as it pertains to definitions.xml processing. For each extension module Aggregate definitions.xml into SCA Domain level defintions.xml For each contribution contribution processor read contribution resolve contribution resolve defintions.xml artifacts in the context of the contribution and SCA Domain level defintions.xml (hich just has artifacts from extensions) If I interpret the previous comments correctly this needs to become. For each extension module Aggregate definitions.xml into SCA Domain level defintions.xml For each contribution read contribution For each contribution Aggregate definitions.xml into SCA Domain level defintions.xml For each contribution resolve contribution resolve defintions.xml artifacts in the context of the SCA Domain level definitions.xml Is this right? As an aside, I used the scenario that kicked off the parent thread to document a TODO on the definitions.xml page in the user guide ( http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+definitions.xml) Regards Simon
