Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.0.0
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
This bug is being filed per the request of Andres as described in the mailing list chain: http://markmail.org/message/zfaoh6gx7jccis4o
When running my app, it takes a very long time to resolve all the dependencies and I'm not sure what the difference between all of them are.
Here's the console output:
Running script D:\Java\griffon-1.0.0\scripts\RunApp.groovy
Resolving dependencies...
Dependencies resolved in 657ms.
Environment set to development Resolving framework plugin dependencies ... Framework plugin dependencies resolved in 28863 ms.
Resolving plugin dependencies ...
Plugin dependencies resolved in 16060 ms.
Launching application ...
Here is my dependency.resolution from BuildConfig.groovy:
griffon.project.dependency.resolution = {
// inherit Griffon' default dependencies
inherits("global") { }
log "warn" // log level of Ivy resolver, either 'error', 'warn', 'info', 'debug' or 'verbose'
repositories {
griffonPlugins()
griffonHome()
griffonCentral()
mavenLocal()
mavenRepo "http://...repository/"
mavenCentral()
}
dependencies {
// specify dependencies here under either 'build', 'compile', 'runtime' or 'test' scopes eg.
compile 'com.data.match:match-profiling:1.0.0.M3-SNAPSHOT',
'com.data.empi:empi-commons:1.0.0.M3-SNAPSHOT'
}
}
I have a few questions, first what is the difference between "Resolving Dependencies", "Resolving framework plugin dependencies", and "resolving plugin dependencies"? And any idea why resolving framework plugins and plugins are taking so long?
I created a new project and copy and pasted all repo's and dependencies over. I had the same slow behavior. I then went through and commented out each one to see what effect it had on the start up.
When I commented out the dependency 'com.data.match:match-profiling:1.0.0.M3-SNAPSHOT' it had a 2 second start up which is significantly more reasonable. And as you had suggested in your first response the snapshot dependency could be force checking everytime. Unfortunately I have run the griffon -Dgriffon.offline.mode=true compile And I've placed the griffon.offline.mode=true in the BuildConfig. But neither have any effect on the start up time.
griffon.offline.mode=true
griffon.project.dependency.resolution =
Resolving dependencies...
Dependencies resolved in 599ms.
Environment set to development
Resolving framework plugin dependencies ...
Framework plugin dependencies resolved in 28270 ms.
Resolving plugin dependencies ...
Plugin dependencies resolved in 15494 ms.
When the particular dependency is commented out I got:
Dependencies resolved in 637ms.
Environment set to development
Resolving framework plugin dependencies ...
Framework plugin dependencies resolved in 874 ms.
Resolving plugin dependencies ...
Plugin dependencies resolved in 1563 ms.
The thing is why would the SNAPSHOT dependency effect the framework plugins? And any idea why the offline mode didn't seem to have any effect?
A bit of information regarding dependency resolution:
Resolving dependencies...
These are the default build dependencies required by the griffon command to bootstrap itself
Resolving framework plugin dependencies ...
These are plugin dependencies installed at $GRIFFON_HOME/plugins. These plugins are know as framework plugins and affect all projects.
Resolving plugin dependencies ...
These are the project's plugins and JAR dependencies.
Projects have the option to override dependencies provided by framework plugins. For example, say you have git-0.2 installed as a framework dependency and git-0.3 as a project dependency. Events and scripts from git-0.3 should be used in this case, for any other project git-0.2 will be used. This forces application dependencies to be parsed (but not resolved) when the framework dependencies resolution step occurs.
Now, dependency parsing takes a while mostly because it depends on Ivy and the code has yet to be optimized for speed. This is one of the key areas of Griffon we're keen in upgrading in the next releases.