Multi-project build with apk and apklib fails due to duplicate R/BuildConfig on classpath

[GoogleCodeExporter]

Hi There,

I'm using version 3.6.0 and SDK Tools 22. 

I have a multi-project build with an APK and an APKLIB. The APKLIB is compiled 
and unpacked into target/unpacked, including the R and BuildConfig files. 

After this, aapt is executed in the APK project and duplicates of these APKLIB 
files are generated within my APK gen directory.

I also include ViewPagerIndicator within the project and it does not have 
R/BuildConfig files within the target/unpack directory, so I assume that the 
APKLIB within my project should not have had R/BuildConfig files generated by 
aapt.

Does this explain it well enough or shall I supply sample output?

Original issue reported on code.google.com by j.w.bax...@gmail.com on 25 May 2013 at 10:42

[GoogleCodeExporter]

To clarify - the project won't build due to compilation errors caused by the 
duplicate classes. The ViewPagerIndicator APKLIB in Maven central doesn't ship 
with these generated files, so this seems to be the issue. (I'm guessing this 
boils down to the aapt arguments)

Original comment by j.w.bax...@gmail.com on 25 May 2013 at 11:27

[GoogleCodeExporter]

It seems the problem stems from the fact that I am running package on the 
parent pom, and the apklib is therefore being compiled. As a workaround I have 
added the antrun plugin to remove the generated sources after compilation, 
before the apklib is package:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-antrun-plugin</artifactId>
                <executions>
                    <execution>
                        <phase>process-classes</phase>
                        <goals>
                            <goal>run</goal>
                        </goals>
                        <configuration>
                            <tasks>
                                <delete dir="${project.basedir}/gen" />
                            </tasks>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

I imagine a decent solution would be to modify the code that packages the 
apklib to exclude the generated source directory (assuming no other code 
generation is occuring!).

Original comment by j.w.bax...@gmail.com on 27 May 2013 at 1:43

[GoogleCodeExporter]

I'm having this issue as well. It seems that we have incomplete support for the 
<genDirectory> and <genDirectoryAidl> parameters in an apklib project. When 
these are set to non-default values, the generated files (R.java and 
BuildConfig.java) get packaged into the final apklib - whereas they do NOT get 
packaged when using the default folder under target/generated-sources. We need 
sources under <genDirectory> and <genDirectoryAidl> to be excluded from the 
apklib packaging step.

On a related note, during the "clean" phase, both <genDirectory> and 
<genDirectoryAidl> should probably get cleaned as well.

Original comment by awrichar...@gmail.com on 7 Jun 2013 at 4:36

[GoogleCodeExporter]

same here.. :(

Original comment by to.mikek...@gmail.com on 8 Jul 2013 at 2:35

[GoogleCodeExporter]

Test against 3.8.3-SNAPSHOT

If the failure stills occurs then provide a project or link to a project that 
clearly highlights the failure.

Original comment by william....@xandar.com.au on 17 Feb 2014 at 11:21

[GoogleCodeExporter]

There seem to be other issues with 3.8.3-SNAPSHOT that prevent me from testing. 
I'm able to use 3.8.2, but when I try to use the latest 3.8.3-SNAPSHOT, I get 
multiple errors along these lines:

1) No implementation for org.eclipse.aether.impl.VersionResolver was bound.
  while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem

1 error

Don't want to pollute this issue with other problems, but I'll be happy to test 
if you have any idea where this other issue is coming from.

Original comment by awrichar...@gmail.com on 19 Feb 2014 at 8:46

[GoogleCodeExporter]

Never mind - I just had to upgrade to Maven 3.1.1.

Confirmed that this issue is solved for me using 3.8.3-SNAPSHOT. Thanks!

Original comment by awrichar...@gmail.com on 19 Feb 2014 at 9:06

[GoogleCodeExporter]

Thanks for the update.

Original comment by william....@xandar.com.au on 19 Feb 2014 at 9:40

• Changed state: Verified