On 2/06/10 11:29 PM, Jason Porter wrote:
On Tue, Jun 1, 2010 at 23:20, Adam Murdoch<[email protected]> wrote:
On 1/06/10 10:25 AM, Jason Porter wrote:
On Mon, May 31, 2010 at 17:09, Adam Murdoch<[email protected]> wrote:
On 29/05/10 3:57 AM, Steve Appling wrote:
We would really like to resolve the issues related to circular
dependencies (GRADLE-914 in particular) sometime soon. I know this is
marked for 0.9, but so are 91 other issues. Is this something that
anyone
is planning on addressing in the short term (within the next couple of
weeks)? If not, does anyone understand the underlying problem enough to
point me in the right direction?
I know of 2 problems. There may be more, but this is as far as I got:
1. The compile configuration is now transitive by default (for good or
bad).
:( That blows. Should be non transitive, if you need it on your
compile path, put it there. This way I know exact what I need to
compile, not some third level transitive dependency that happens to be
there. Major sad face on this one.
I tend to agree. Ideally this is a short term solution.
An alternative to making the compile configuration non transitive is instead
to have a rule which does some static analysis of the source to enforce that
only the direct dependencies of the compile configuration are used directly
by the source. This rule might be evaluated by a post-compilation task
(against the bytecode), or even during compilation (against the source).
Interesting idea. Sounds really good in theory, in practice though I
think it would add unnecessary time to a build (unless of course we're
able to get Gradle so fast it doesn't matter). If it's a large build
I think it could be really devastating. If this were to be
implemented there should be an easy way to opt-out of it.
I think something like this would be opt-in. It might be something which
the code-quality plugin adds, say.
When we add incremental compilation (that is, compile only the changed
source files and the source files that depend on them) then we will have
exactly the information we need to evaluate the above rules. So it may
not end up being particularly expensive.
Thought I just had: Would it be possible to do some basic static
analysis pre-compile and separate out the compilation into individual
parallel steps so you could parallelize your compile step? It may not
be that great for smaller projects, but may very well be a huge win
for larger / multi project builds. WDYT?
An interesting idea.
For multiple projects, a solution could instead be to add a way to
execute tasks in parallel. This could speed up everything that the build
does, not just compilation.
The advantage of a static analysis approach is that we can use the same
mechanism to evaluate additional rules - such as, to enforce that every
dependency declared in the compile configuration must actually be used by
the source. Or to limit the use of a given dependency to a particular source
package.
Something like this might eventually evolve into a structure definition DSL.
You might be able to, for example, define which classes make up the API of
your code, and Gradle could enforce that the API is independent of the
implementation, that other projects use only the API classes, and so on. It
could use exactly the same information to determine which classes to include
in the javadoc, and to automatically generate an API jar.
This sort of thing is much more helpful to people building frameworks
and other reusable components, but for an application developer
(something that isn't necessarily consumed by other projects) it's
less useful.
If you have project dependencies in a multi-project build, then your
projects have APIs, whether they are implicit or explicit. Something
like the rules above still make sense in this situation and could be
very useful.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
