Luciano Resende wrote:
I have created TUSCANY-2167 to track this issue, and I'm now
evaluating our calculator sample, and calculator-webapp sample to see
where all the dependencies are coming from. One thing I noticed is
that policy-xml is bringing a lot of ws-security related dependencies
to these applications, and I'm now trying to move this dependencies to
a policy-xml-ws module that would be available only when the
application is using the ws-binding. I'd also take a look in other
dependencies and see if I can cleanup them before our next RC.
Please let me know if you have questions and/or comments.
+1 for removing unecessary dependencies and refactoring modules
where necessary, as in the security case you described. Thanks
for taking a look at this.
Moving ws-security dependencies to policy-xml-ws is better than
having them in policy-xml, though this doesn't seem quite right if
someone is trying to use a different policy (not security) with the
Web Service binding. Should they be in policy-xml-ws-security?
To get the full benefit of this, it would also be necessary to
refactor binding-ws-axis2 so that it does not pull in all the
ws-security stuff.
On the more general point of sample dependencies, I think it
would be a very valuable exercise to use the samples to create
dependency profiles of what is really needed to run each sample
(with bogus dependencies removed). When we have this information,
I think it would be useful to look for clustering between
different samples to establish profiles of groups of dependencies
that are typically needed together. We might be able to come
up with a partially ordered tree containing functional units
for Tuscany SCA Java, and indicate for each node in the tree
which samples it enables.
These functional units would typically be larger than a single
maven module. I'm expecting that we might have between 12 and 20
functional units in the whole of Tuscany SCA Java.
Here's a illustration of what I mean:
tuscany-core [runs: calculator, simple-callback]
tuscany-ws [runs: helloworld-ws-reference&service, simple-callback-ws]
tuscany-ws-security [runs: helloworld-ws-reference&service-secure]
tuscany-jms [runs: helloworld-reference&service-jms]
tuscany-webapp [runs: calculator-webapp]
tuscany-script [runs: calculator-script]
etc.
I don't know how deeply nested this would be, or whether it's a
simple tree (as shown above) or a graph where some samples would
require multiple functional units from different branches of the
tree. For example, the sample calculator-ws-webapp might require
bringing in the functional units tuscany-ws and tuscany-webapp.
Simon
[1] https://issues.apache.org/jira/browse/TUSCANY-2167
On Fri, Mar 28, 2008 at 6:42 PM, haleh mahbod <[EMAIL PROTECTED]> wrote:
Should this mvn command be put in the development guide for samples so
anyone creating a new sample runs these commands and gets rid of unnecessary
dependencies?
On 3/28/08, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Try mvn dependency:analyze. It analyzes the dependencies of this project
> and
> determines which are: used and declared; used and undeclared; unused and
> declared.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
> Sent: Friday, March 28, 2008 1:02 PM
> To: <[email protected]>
> Subject: Re: [SCA 1.2] SCA Sample dependencies
>
> > Luciano Resende wrote:
> >> I was looking at some sample applications dependencies last night, and
> >> realized that our simple calculator-webapp is huge and with a lot of
> >> unnecessary dependencies being dragged to it's WEB-INF\lib. This might
> >> cause the impression that SCA is heavy, when it's not. Should we spend
> >> some time around reviewing these dependencies before next RC ?
> >>
> >
> > +1 I'd suggest to start with calculator (not even the webapp version), I
> > can see dependencies on Xalan, Xerces, Axiom there, no idea why they are
> > required. I've traced Xalan to assembly-xml, and removing it from the
> pom
> > doesn't seem to break it. I think we need a thorough review of the
> > dependencies that have progressively been added to the core runtime, and
> > see if they're all really needed or just oversights that can be cleaned
> > up.
> >
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
