2009/3/13 Adam Murdoch <[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
>
> # 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? what when the same jdk 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')?
>
>
> Also interesting would be to make it possible to run the build for a
>> number of java versions jdk15/jdk16/..., would make sense to add a synthetic
>> subgroup inside a project e.g.: projectA/jdk15/test so it is easy to run
>> taks of the build for a specific jdk version: gradle jdk15/test. So multiple
>> groups on top of the build tasks and the only difference is the java
>> dependency.
>>
>>
> This is an interesting idea. You could generalise it to running the build
> for a set of different 'platforms' where 'platform' could be any combination
> of Java, Groovy, app server, c compiler, whatever.
>
I agree this would be more usefull as a more general concept.
>
>
> # 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.
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.
>
>
> # 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.
>
>
> 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. But I like your idea,
that would allow for more customizations.
>
> onBuildStarted { StartParameter param ->
> ... do some custom logging configuration ...
> }
>
> onProjectsLoaded { Build build ->
> ... register some JDKs ...
> ... set username and password for a particular repository ...
> ... apply some plugin to a project ...
> ... add some custom tasks to a project ...
> ... etc ...
> }
>
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
