Experimentation around dependency analysis

[Gilles Scokart <gs...@gmail.com>]

I'm currently making some experimentation using ASM library to analyse
jars in order to identify dependencies.

I would like to end up with a tool (in the form of a taglib) that
allows to manage more properly the dependencies of the module.

The kind of tool I currently foresee for compile dependencies are:
- A task that fail a build is some jar are not required in a compile path.
- A task that produce a report helping to identify that a jar is
required in the compile path.

Then, I would like to dig further into the runtime dependencies.  For
that, I think it should be possible to write a tool to which we give
sets of root classes and methods, and that can deduce the runtime
dependencies.  In order to resolve the reflection, or some other
dynamic call, the tool should be able to use some assertion provided
by the user that limit the possible execution path.
Such runtime analysis could be used to help to document correct
runtime classpath, and could also be used to find dead code in an
application.

I would like to share the code.  However even if such a tool could be
a nice companion of ivy, I don't think it should be included directly
in ivy.
And it doesn't fit into the core of ant neither.

So I'm worndering where to place it?  We have a sandbox in the ant
svn.  There is also the apache lab. Or I could start a project on
sourceforge, google code or somewhere else.

What would you advice?


-- 
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Experimentation around dependency analysis

[Gilles Scokart <gs...@gmail.com>]

My first idea was to put the code in the ant sandbox.
But one of the objective is to help/encourage maven user to publish
better quality pom.  So, I felt that starting from the ant sandbox was
not the really adapted.

I also tought to the Apache labs.  But I was fearing to be blocked
there : labs project are not allowed to release, and I think that I
will need to release something if I want to attract maven and ivy
users.

So, I made a Belgium compromise...  I choosed sf.net.  But this choice
is certainly not carved in stone.



2008/11/11 Stefan Bodewig <bo...@apache.org>:
> On 2008-11-11, Gilles Scokart <gs...@gmail.com> wrote:
>
>> My experimentation has now taken the form of a project on source
>> forge [1].
>
> Looks interesting.
>
> I'm not questioning your choice of sf.net, but I hopw you know that
> Ant's sandbox is open for you as well.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>



-- 
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Experimentation around dependency analysis

[Stefan Bodewig <bo...@apache.org>]

On 2008-11-11, Gilles Scokart <gs...@gmail.com> wrote:

> My experimentation has now taken the form of a project on source
> forge [1].

Looks interesting.

I'm not questioning your choice of sf.net, but I hopw you know that
Ant's sandbox is open for you as well.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Experimentation around dependency analysis

[Gilles Scokart <gs...@gmail.com>]

My experimentation has now taken the form of a project on source forge [1].

I currently have an ant task that validates that a compile path is minimal.
I plan to add a report that help to identify why a library is used,
add support to analyze runtime dependencies and integrate that with
maven.

For my tests, I also experimented a little bit with ant-unit.  I have
written a small Junit 4 wraper arround an ant-unit tests.  It is still
very limited, but I found it useful to run and to debug the ant tasks
from my IDE like I can debug my "classical" unit tests.


[1] http://deco-project.sourceforge.net/



2008/10/13 Gilles Scokart <gs...@gmail.com>:
> I'm currently making some experimentation using ASM library to analyse
> jars in order to identify dependencies.
>
> I would like to end up with a tool (in the form of a taglib) that
> allows to manage more properly the dependencies of the module.
>
> The kind of tool I currently foresee for compile dependencies are:
> - A task that fail a build is some jar are not required in a compile path.
> - A task that produce a report helping to identify that a jar is
> required in the compile path.
>
> Then, I would like to dig further into the runtime dependencies.  For
> that, I think it should be possible to write a tool to which we give
> sets of root classes and methods, and that can deduce the runtime
> dependencies.  In order to resolve the reflection, or some other
> dynamic call, the tool should be able to use some assertion provided
> by the user that limit the possible execution path.
> Such runtime analysis could be used to help to document correct
> runtime classpath, and could also be used to find dead code in an
> application.
>
> I would like to share the code.  However even if such a tool could be
> a nice companion of ivy, I don't think it should be included directly
> in ivy.
> And it doesn't fit into the core of ant neither.
>
> So I'm worndering where to place it?  We have a sandbox in the ant
> svn.  There is also the apache lab. Or I could start a project on
> sourceforge, google code or somewhere else.
>
> What would you advice?
>
>
> --
> Gilles Scokart
>



-- 
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org