Ok, I've discovered a few more things about the Maven installer.
No matter what I do, I ALWAYS end up with the following files:
> $MAVEN_HOME/repository/foo/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.pom
> $MAVEN_HOME/repository/foo/foo/1.0-SNAPSHOT/maven-metadata-local.xml
> $MAVEN_HOME/repository/foo/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.jar
> $MAVEN_HOME/repository/foo/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT-tests.jar
> $MAVEN_HOME/repository/foo/foo/maven-metadata-local.xml
>
If I add
> pom { groupId = 'FOO' }
>
Then in addition to the above files, I also get
> $MAVEN_HOME/repository/FOO/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.pom
> $MAVEN_HOME/repository/FOO/foo/1.0-SNAPSHOT/maven-metadata-local.xml
> $MAVEN_HOME/repository/FOO/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.jar
> $MAVEN_HOME/repository/FOO/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT-tests.jar
> $MAVEN_HOME/repository/FOO/foo/maven-metadata-local.xml
>
If I add
> filter { artifact, file -> artifact.name == 'foo' }
>
I end up with all the "foo" files plus the following FOO files:
> $MAVEN_HOME/repository/FOO/foo/1.0-SNAPSHOT
> $MAVEN_HOME/repository/FOO/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.pom
> $MAVEN_HOME/repository/FOO/foo/1.0-SNAPSHOT/maven-metadata-local.xml
> $MAVEN_HOME/repository/FOO/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.jar
> $MAVEN_HOME/repository/FOO/foo/maven-metadata-local.xml
>
In other words, only "foo-tests" disappears, exactly as expected. However,
if I change the filter to
> filter { artifact, file -> artifact.name == 'foo-tests' }
>
I end up with all the "foo" files plus the following FOO file:
>
> $MAVEN_HOME/repository/FOO/foo-tests/1.0-SNAPSHOT/foo-tests-1.0-SNAPSHOT-tests.jar
>
No Maven metadata or POM files are generated.
I have similar results when fiddling with addFilter(), but I thought that
filter() made for a clearer example.
So, to recap:
- I can't seem to get rid of anything from the default "foo/foo" artifact
directory
- If I include the main archive, then Maven generates its metadata for
other (FOO/foo) artifacts
- If I don't include the main artifact, no Maven metadata is generated
for other (FOO/foo) artifacts
I haven't tried this with the Maven deployer, but I'm assuming the behavior
is the same.
- Adrian
On Tue, Jul 12, 2011 at 7:31 AM, Adrian Abraham <[email protected]>wrote:
> That bug may be related to what I'm experiencing, but it's not the same.
> The bug report explicitly says "given util-1.0-testutil.jar is
> *not*resolvable" - but in my case, both archives
> *are* resolvable.
>
> I'd be perfectly happy to create a different artifact, but I haven't been
> able to figure out the right way to do it.
>
> The best I've been able to come up with is
>
>> task jarTests(type: Jar, dependsOn: testClasses) {
>> classifier = 'tests'
>> appendix = 'tests'
>>
>> from sourceSets.test.classes
>> }
>>
>> artifacts {
>> archives jarTests
>> }
>>
>> install {
>> repositories.mavenInstaller {
>> addFilter('tests') { artifact, file -> println artifact.name;
>> artifact.name ==~ '.*-tests'}
>> }
>>
>
> This sort of works - it creates a new "foo-tests" artifact with
> foo-tests-1.0-SNAPSHOT-tests.jar. However, it still installs the file under
> "foo" as foo-1.0-SNAPSHOT-tests.jar, and it fails to create a POM for the
> "foo-tests" artifact.
>
> Before anyone asks, if I remove the classifier, it breaks. Since it's still
> placing the tests archive into the foo artifact, if I remove the classifier,
> there's a conflict.
>
> I know that if I remove jarTests from the archives configuration that it
> won't get installed into the foo artifact. How do I still get it installed
> into the foo-tests artifact, and how do I generate the POM for it?
>
> Thank you,
> Adrian
>
>
> On Mon, Jul 11, 2011 at 7:13 PM, Szczepan Faber <[email protected]>wrote:
>
>> Hey
>>
>> Yes, it's a bug: http://issues.gradle.org/browse/GRADLE-1442
>>
>> In your case the workaround is to produce a different artifact. It is
>> more natural approach anyway IMHO.
>>
>> Cheers!
>> Szczepan
>>
>> On Mon, Jul 11, 2011 at 10:31 PM, Merlyn Albery-Speyer
>> <[email protected]> wrote:
>> > Hmm.
>> >
>> > All: Is this a known bug?
>> >
>> > On Jul 11, 2011 12:37 PM, "Adrian Abraham" <[email protected]>
>> wrote:
>> >> Merlyn,
>> >>
>> >> I've changed the dependencies block to:
>> >>
>> >>> dependencies {
>> >>> compile group: 'foo', name: 'foo', version: '1.0-SNAPSHOT'
>> >>> testCompile group: 'foo', name: 'foo', version: '1.0-SNAPSHOT'
>> >>> testCompile group: 'foo', name: 'foo', version: '1.0-SNAPSHOT',
>> >>> classifier: 'tests'
>> >>> testCompile group: 'junit', name: 'junit', version: '4.8.2'
>> >>> }
>> >>>
>> >>
>> >> I'm getting the exact same behavior as before. Whichever dependency
>> comes
>> >> second is the one which is put on the classpath.
>> >>
>> >> - Adrian
>> >>
>> >> On Mon, Jul 11, 2011 at 2:57 PM, Merlyn Albery-Speyer <
>> >> [email protected]> wrote:
>> >>
>> >>> Hi Adrian, when you use dependencies with classifiers you need to use
>> the
>> >>> more verbose form that and provide the classifier like so:
>> >>>
>> >>> .... classifier: "test"
>> >>> On Jul 11, 2011 11:51 AM, "Adrian Abraham" <[email protected]>
>> >>> wrote:
>> >>>
>> >
>>
>>
>>
>> --
>> Szczepan Faber
>> Principal engineer@gradleware
>> Lead@mockito
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
