On Sunday 28 March 2010 01:34:26, Adam Murdoch wrote:
> On 27/03/10 5:43 PM, Geronimo M. H. wrote:
> > Hello,
> >
> > I'm using this working copy-definition
> > copy {
> > from artifacts
> > into artDir
> > }
> >
> > now I'd like to change the task to a file-based processing like I use
> > with dependencies:
> >
> > for(file in configurations.runtime) {
> > ...
> > }
> >
> > whatever I tried failed, so I had a look at DefaultArtifactHandler - but
> > I did not find a hint to proceed ...
> >
> > So how can I access the artifact as a File-instance?
>
> Assuming you're after the artifacts the build produces, you can do
> something like:
>
> for (file in configurations.archives.allArtifactFiles) {
> }
Great ;)
I found out (from gradles javadoc), that Configurations have
a "getAllArtifacts", but I did not succeed to get the filename out of it.
Then I learned, that the configurations is a Set of defined Configurations
like "comile" or "runtime", but I did not know about the "archives"
Configuration.
> copy {
> from configurations.archives.allArtifactFiles
> into artifactsDir
> }
That step is natural after knowing the above access variant.
I tried the opposite - build a loop from a copy-statement, but I failed.
> That is, the Configuration class provides access to both the incoming
> files for dependencies and the outgoing files for artifacts. Which, to
> me, is kind of odd.
That design is not that odd, but the access patterns, that aren't related to
the methods from Configuration-class are.
The "methodMissing" is really groovy, but it's pretty hard to find unknown
access patterns ...
> After the 0.9 release, we're planning to split
> Configuration into the dependency bits and the artifact bits, so that
> instead, you'd do something like:
>
> for ( file in dependencies.runtime ) { ... } // get the runtime
> dependencies
>
> for (file in artifacts.archives ) { ... } // get the archive artifacts
That usage-pattern would be great - no matter whether you split Configuration
or not.
The point is - when you are at the stage to go beyond the samples of the
userguide - is the access-pattern guessable or not, do I have a chance to
find it out from javadoc or by digging the sources ...
Well, after all, the access to artifact-pattern was triggered by the problems,
I have with the gradles internal cache behaviour (see "How to deal with
project-Jarfiles?")
As I already wrote, I have several top-level (multiproject-)projects, which
are organized as follows:
Framework
libFW-Prj-1
libFW-Prj-2
assistantApp
Application-1
libApp1
Application
Installer
Application-2
libApp2
Application
Installer
The point, that I haven't solved already is the handling of the
cross-dependencies.
The assistantApp of Framework depends on the libFW-Prj-1 and -2 of Framework.
Each libFW-Prj has its own testcases and the assistantApp has testCases, which
depend on the testclasses from libFW-Prj-1 and -2
Both Application-1 and -2 depend on the Framework and the
Application-1/Application depends on Application-1/libApp1 and
Framework/libFW-Prj-1
The Installer should become a fat jar, that includes all jars from Framework
as well as the jars from libApp- and Application- subprojects - so it depends
on all uploadArchives-tasks of the other subprojects.
I think, the dependencies are not that trivial. Running i.e. the tests depends
on the published artifact of the dependant libProject and the build-process
depends on tests. So I'm looking for a way to update the libraries.
Each subproject has an "updateArchives"-task enriched by a copy-action, that
copies the jar to the directory, where the installer get's build from.
The dependency of Framework/libFW-Prj-2 to Framework/libFW-Prj-1 is not a
problem, as I can use the project-entry in dependency section.
My problems start with Application-1/libProject, as it uses standard-entry:
compile group: 'Framework', name: 'libFW-Prj-1', version: '0.1.+'
The problem is, that gradle does not use the version in archive-filename for
libFW-Prj-1 and -2 and all libraries are cached. The classpath of
Application-1/libApp1 contains an entry to libFW-Prj-1 from internal cache,
so whenever I fix a bug from framework, I have to remove my libraries from
gradle cache.
Currently I do that MANUALLY, but that's not handy, nor desired.
So what can I do to solve the dependencies in a gradle way?
> Anyway, we will discuss this further on the dev list before we start to
> make changes here.
Is it Ok to join the dev-list (and participate in discussions) being a
gradle-newbie(-user) or is that list for the gradle team-members only?
kind regards
Geronimo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
