Tom Eyckmans wrote:
2009/3/13 Adam Murdoch <[email protected]
<mailto:[email protected]>>
Tom Eyckmans wrote:
Hi guys,
I think the need for a init script is rising, some
functionalities that I think would make sense in the init script:
# Execution Profile (add a new command line parameter for this
aswell?)
- define or customize execution profiles: basically set
plugin convention values to a value that makes sense for the
profile.
- state the default execution profile (developer workstation /
ci server/ others? )
I'm not sure what this means exactly. What is the use case for
this? An example?
workstation -> run tests without code coverage / ci server -> runt
tests with code coverage
Shouldn't this go in the build file? It looks like something specific to
the build, not something specific to the user.
It does feel like there's something missing. Often (always?) you want to
modify the project in some way from the command line when you run a
build - to change some convention value, skip some tasks or artifacts,
add in some additional tasks, apply additional plugins, run or skip
certain tests, and so on. Often the same set of modifications is applied
repeatedly, not just by a given user, but all users of the build.
It definitely would be nice to be able to define these somewhere - in
code, rather than as a complex arrangement of command-line options, and
somewhere that they can be shared by all users of a build. We can make
them (whatever we call them) first-class citizens of the domain model,
with an identity. Then we can do things like document them in the
project reports, and generate synthetic tasks to run them.
# Java Homes - define the java homes that are installed
locally and set the default source/target compatibilities for
the java home.
This would be useful. Even more useful, from my point of view,
would be if Gradle auto-detected the various JREs and JDKs on the
user's system (as best we can) and made them available to the build.
I'm not sure how that would work, how would you declare a dependency
to these found jdk's?
Exactly the same way you'd declare a dependency on an explicitly defined
jdk.
what when the same jdk is found in multiple locations?
Exactly the same thing we do when the same library is found in multiple
locations.
I think it would be usefull to be able to declare a dependency on a
specific jdk -> compile java([org:'com.sun',group:'java',version:'1.5')?
Absolutely. It should be possible to do this.
# Define default configurations/ repositories / dependencies /
publishers
Doesn't this stuff belong in the build file?
I'm taking my job situation as an example here, we have an internal
nexus with a some internal repositories and some that serve as proxy
for repos on the internet, this is a nice setup but causes a bunch of
repetition in our builds
addMavenStyleRepo('internal-third-party','http://internal-server/repositories/thirdparty','http://internal-server/repositories/thirdparty')
// internal repo for stuff that is not available in other repositories
addMavenStyleRepo('internal-releases','http://internal-server/repositories/releases','http://internal-server/repositories/releases')
// internal module releases
addMavenStyleRepo('internal-maven2','http://internal-server/repositories/central','http://internal-server/repositories/central')
// proxy for http://repo1.maven.org/maven2/
// + others when needed
and for the publishing always the deployer jar stuff + declare the
release and snapshot repo with username / password
I would like to be able to define a set of resolvers for releases and
one for snapshots so when for example running in a ci-server-snapshot
execution profile the internal snapshot repos are used, and when in
another profile the release repos are used. so as to remove the need
to specify the same repos for resolving/publishing in every build.
It sounds like we're talking about some way to reuse configuration
across multiple builds for a given organisation, rather than some
user-specific configuration. Certainly nothing in your example above is
user-specific.
Putting this type of configuration in a user init script is problematic
for a few reasons:
- You can't easily change control it.
- You can't easily deploy updates to every user who needs this configuration
- You add an additional set-up cost when new users are added. This is, I
think, an important factor for open source project.
- It is harder for a user to run builds from multiple organisations.
- The build script is no longer a self-contained description of the
build - there's an implicit dependency on some other configuration
applied by the user, which will need to be documented and so forth.
Interestingly, we already have a mechanism for configuration reuse:
plugins. I think the solution to this problem involves making it easier
to deploy plugins within an organisation. Some possibilities:
- make it possible to define a plugin as a .gradle file.
- make it easy to fetch and apply a plugin from a variety of locations:
a URL, VCS, a repository, etc.
- provide a plugin plugin to take care of the deployment of plugins in
whatever form.
At work, we have solved this problem using plugins, and it works very well.
Also as asked on the user-list when dealing with a lot of different
repos to publish to the use of properties for the authentication
details are limited at best, when specifing the in one place in the
init script outside the build without properties I think that would
make it somewhat easier to manage such a scenario.
Authentication details are a good candidate for including in a user init
script.
# Define template build scripts, basically what we do for
multiproject builds with allprojects/subprojects but named so
they can be pulled in with something like
useTemplate('my-java-layout')
What is the use case for this?
When people use a different project layout they are currently forced
to specify where there source/resource directories are in every build
this would remove such repitition; also when they change to our
default the changes required to the build files would be minimal.
Sounds like the same problem as above: making it easier to share
configuration across multiple builds in the same organisation.
As always, comments other ideas more than welcome.
I think an init script would be a good thing to have. I would
start with something simple and general, and optimise for common
use cases later. For example, if the init script could receive the
BuildListener events, then it could perform pretty much any
customisation it wants:
I hadn't thought of using the BuildListener events for this, I was
thinking more in the direction of something that would be executed
after loading the gradle.properties and before any settings/build
scripts are evaluated, and used as basis for a bunch of
configuration/settings.
This could certainly be made an event on BuildListener.
Adam
