Ok, so the magic line is "repositories['mavenInstaller'].with {"
If I remove the tests classifier and use my original block:
> install {
> * repositories.mavenInstaller { *
> tests = addFilter('tests') { artifact, file -> artifact.name ==~
> '.*-tests' }
> main = addFilter('main') { artifact, file -> !(artifact.name ==~
> '.*-tests') }
> }
> }
>
I get the following error:
> Execution failed for task ':install'.
> Cause: Could not publish configurations [configuration ':archives'].
> Cause: A POM cannot have multiple artifacts with the same type and
> classifier. Already have MavenArtifact foo:jar:jar:null, trying to add
> MavenArtifact foo:jar:jar:null.
>
But if I change the install block to:
> install {
> * repositories['mavenInstaller'].with { *
> tests = addFilter('tests') { artifact, file -> artifact.name ==~
> '.*-tests' }
> main = addFilter('main') { artifact, file -> !(artifact.name ==~
> '.*-tests') }
> }
> }
>
It works fine.
Why does repositories.mavenInstaller { ... } behave differently from
repositories['mavenInstaller'].with { ... } ?
Thank you for your help.
- Adrian
PS I know this is bad project organization. I'm trying to convert a massive
legacy project, so I don't (yet) have the luxury of restructuring things
properly.
On Sun, Jul 17, 2011 at 10:41 PM, Luke Daley <[email protected]>wrote:
>
> On 14/07/2011, at 11:37 PM, Adrian Abraham wrote:
>
> > I'm familiar with that thread, and it's what allowed me to get to where I
> am now.
> >
> > I've attached a sample project demonstrating the problem and my current
> (imperfect) solution. Foo and Bar are two separate projects (no master
> here). Bar main depends on Foo, and Bar tests depends on both Foo main and
> Foo tests.
> >
> > When "gradle install" is run from Foo, three artifacts get created in the
> local Maven repository: foo, foo-tests, and foo-testsonly. You'll note that
> the files in both foo and foo-tests are identical (except for the names),
> and that the Maven metadata is present. As far as dependencies go, this
> works OK, even if it is wasteful. However, the sources jars are a problem,
> since the Idea plugin automatically uses jars with a "sources" classifier.
> Since I have to use "testsources" as the classifier for the test sources,
> the Idea plugin doesn't pick it up.
> >
> > I included foo-testsonly to demonstrate the problem with Maven metadata.
> You'll notice that, in the Maven repository, only the tests jars are present
> - no Maven metadata is generated. (However, I think I've found a bug. If you
> run "gradle install" twice, foo-onlytests actually gets populated with every
> jar and with the Maven metadata.)
> >
> > Ideally, I think Foo's main source and binary archives should go into
> foo/foo (with no classifier and the "sources" classifier, respectively),
> Foo's tests source and binary archive should go into foo/foo-tests (with no
> classifier and the "sources" classifier, respectively), and both foo and
> foo-tests should have Maven metadata generated.
> >
> > Thank you for your help.
>
> I had a look at the project. I think the core of your problem comes from
> misuse of the 'tests' classifier, but I admit that it may be my
> misunderstanding of the semantics that maven imposes on this particular
> classifier.
>
> The last chapter at
> http://maven.apache.org/guides/mini/guide-attached-tests.html, hints to
> just how 'loose' classifiers are really.
>
> In general, if an artifact is to be used as a build dependency you should
> avoid assigning it a classifier as it just causes too many problems. In this
> case, your “tests” jar is not like a traditional tests jar because you want
> it to functional as a build dependency for another project. I wouldn't trust
> the classifier mechanism for anything beyond a convention for IDEs to follow
> to get the source and tests for an artifact behind the scenes.
>
> To this end, I think you'd be best off restructuring the project.
>
> You could factor out the code utility code in foo tests that you need in
> bar's tests into it's own module. But, I get the impression that you also
> want to run foo's tests as bar's test, something like a TCK. In this case, I
> would consider publishing the tests as a separate standalone artifact.
>
> I've attached a version of your sample that does this. Take a look and let
> me know in what way this doesn't meet your requirements and we can go from
> there.
>
> --
> Luke Daley
> Principal Engineer, Gradleware
> http://gradleware.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
