Yes, startup speed can be a factor though I am not sure it is as bad
as 10 times slower these days. Some potentially useful info for you:
* if you grab 1.7.1 snapshot or 1.8 snapshot from one of the
CI servers then it avoids one of the big startup delays due to DGM
class loading by loading that info in one go as serialised data.
* targeted for 1.8 but not yet finished is some lazy loading logic
which should speed that up even further
* also targeted for 1.8 is a modularisation of the libraries so you
could package up a streamlined Groovy system that would load quicker
if you didn't need all of the library functionality
* there is a still experimental static groovy project which performs
on par with Java which might allow you to gain some further speed.
So, while Groovy isn't the only game in town these days in terms of
innovative languages on the JVM, it should only improve in the areas
that are of concern to you.
Cheers, Paul.
Alexey Lunacharsky wrote:
Thanks you a lot.
I've heard about grape. But didn't know it is almost what I need.
It is very good point to start... But
The biggest problem with groovy it is very slow at startup.
The pure java solution such Ivy or thin wrapped with ant scripting can be
about 10 times faster for
using from command shell.
2010/1/18 Paul King <pa...@asert.com.au>
Paul King wrote:
Not 100% the same as what you suggest but Groovy's Grape system does some
of what you are asking for. Normally Grapes are used from within scripts,
e.g.:
@Grab('org.apache.ant:ant:1.7.1')
import org.apache.tools.ant.Main
Main.main(['-version'] as String[])
but it also has a commandline interface. Excerpt from doco shown below:
<doco>
Command Line Tools
grape install <groupId> <artifactId> [<version>]
This installs the specified groovy module or maven artifact. If a version
is specified that specific version will be installed, otherwise the most
recent version will be used (as if '*' we passed in).
Even though the doco says maven artifact, it is Ivy under the covers
so it is strictly speaking an Ivy artifact which can be and often is
a maven artifact.
Paul.
grape list
Lists locally installed modules (with their full maven name in the case of
groovy modules) and versions.
grape resolve (<groupId> <artifactId> <version>)+
This returns the file locations of the jars representing the artifcats for
the specified module(s) and the respective transitive dependencies.
</doco>
This may not be what you want but might be a useful starting point.
Cheers, Paul.
Alexey Lunacharsky wrote:
Hello!
Does anybody think about imlementation a "Debian APT"-like tool on the
top
of an Ivy dependency manager. It can manage all java binaries and source
installation in the system on user level,
through home directory located workspace, or on admin level through FHS
on
Unix systems.
For the give what I mean I write some high level usage examples, which
can
be used in unit tests):
$ jpt install apache-ant-1.7.0
by this command ant and all of its dependencies (jars and maybe other
resources such jpt run configurations) are get downloaded and become
available in ivy cache and it can be run by:
$ jpt run apache-ant
This execution will find and organize classpath through ivy depencies
review, and than
run spesified class (which is specified through jpt run configuation XML
file)
$ jpt wrap apache-ant ant
Creates system dependent warapper script for running application through
'jpt run'.
$ ant
will now execute $ jpt run apache-ant
$ jpt unwrap ant
now wrapper no more exist
$ ant
no such command
$ jpt uninstall apache-ant-1.7.0
deletes a softfare binaries if there is no dependencies remain
And so on.
In future it can manage also the libraries source code. And be used for
development environment buildings based on ant or gant scripts.
So many software can be integrated on the top of spring framework etc.
This is the system of my dream!
So I will be very glad if you tell me, if such the system have already
exist
or
why to not imlement such as a thin wrapper across the Ivy?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
