[
https://issues.apache.org/jira/browse/AVRO-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986673#action_12986673
]
Scott Carey commented on AVRO-737:
----------------------------------
Odd.
OK, so avro/pom.xml creates its tests jar (avro.jar, classifier: tests) with:
{code:xml}
<plugin>
<!-- in addition to the usual jar artifact, create a -tests.jar that
contains our test classes.
this allows downstream dependencies in the build to use test
utility classes. -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
{code}
The jar builds and appears in avro/target as avro-1.5.0-SNAPSHOT-tests.jar.
Perhaps the problem is what is noted at the bottom of this page:
http://maven.apache.org/guides/mini/guide-attached-tests.html
{quote}
Note that previous editions of this guide suggested to use
<classifier>tests</classifier> instead of <type>test-jar</type>. While this
currently works for some cases, it does not properly work during a reactor
build of the test JAR module and any consumer if a lifecycle phase prior to
install is invoked. In such a scenario, Maven will not resolve the test JAR
from the output of the reactor build but from the local/remote repository.
{quote}
Does it work if you change the ipc dependency on avro-test from
<classifier>tests</classifier> to <type>test-jar<type> ? or potentially adding
that to tools? I'll have time to experiment with that later today.
> Java: Improve correlation between packages and modules
> ------------------------------------------------------
>
> Key: AVRO-737
> URL: https://issues.apache.org/jira/browse/AVRO-737
> Project: Avro
> Issue Type: Sub-task
> Components: java
> Reporter: Scott Carey
> Assignee: Scott Carey
> Fix For: 1.5.0
>
> Attachments: AVRO-737.v1.patch, AVRO-737.v2.patch, AVRO-737.v3.patch,
> migrate_avro_packages.sh
>
>
> Several packages have classes from multiple modules in the new layout.
> In general, we should avoid this. Ideally, o.a.a.ipc would only exist in the
> avro-ipc.jar for example.
> For 1.5.0, I'd like to move the easy stuff around to better correlate
> packages with modules.
> This will cause API changes we need to document. Unfortunately, moving
> classes around is not something you can do gradually. Ideally these are
> isolated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
