How to avoid duplicate classes for product flavors?

[John Isturiz]

I am trying to set up my project so that when build my free and paid apks with gradle, the paid version overrides a class containing constants.

However when I try to build them, I get this: 

"{path to my class.java}: error: duplicate class: {class name}"

I have the default class and respective contents under src/ and then what I want to override it with under src/flavor/java/ (previously tried just src/flavor/).

What is the proper way to have various classes and avoid duplicate class error?

[Xavier Ducrohet]

You shouldn't have the class in the main source set.

Instead you have 2 versions of the class in src/free/java and src/paid/java

When you introduce flavors you cannot build without selecting one, so the class will always be available in all builds (as long as it's present in all the flavor source sets)

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[John Isturiz]

Ah, yes, that makes sense. Thank you for the quick reply. 

I suppose I was just trying to keep one instance in the main source set to make it easy to work in Eclipse.

[John Isturiz]

Hey Xavier,

I did put two different instances of the class, 1 in src/free/java and 1 in src/paid/java...

Still said duplicate class error. I did a find "class name" and it only came up in those two locations. Am I missing anything?

On Monday, March 18, 2013 1:36:28 PM UTC-5, John Isturiz wrote:

[John Isturiz]

Hey Xavier,

It was because under src/ we had _full, _trial, com, main.... mainly to keep eclipse happy.

But I swapped it to what gradle expects src/main/java/com... and it now works as expected.

Thanks again.

On Monday, March 18, 2013 1:36:28 PM UTC-5, John Isturiz wrote:

[Rainer Burgstaller]

John, Xavier

how do you manage this with Eclipse? If you remove it from the src folder then eclipse will no longer compile, no?

I have a similar problem, where I have some constant definitions file which contains definitions for the names of my content providers, ...

It is difficult to extract those into resources since I need them also to be referenced in annotations, etc.

So I would like to have a common "default" Constants.java in the main source base (the one that eclipse would use) and a "debug" Constants.java for debug builds.

Any suggestions on how to support this?

thanks

- Rainer

[John Isturiz]

Rainer,

I had the same problem with content provider constants....

Under your src folder you will need three folders. Something like "main", "default", and "debug".

Inside main will be everything except your constants.java, which will be found under default and debug (with their respective differences).

Then inside project->properties->Java Build Path, add the default folder to your source.

Let me know if this gives you any trouble.

[Xavier Ducrohet]

This kind of thing is not really compatible with Eclipse.

When we have proper Gradle support in Eclipse, we'll have a pop up menu like in Studio to choose the variant to work on and it'll enable/disable src folders.

In the meantime you'd have to do this manually (which is not very practical).

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Burgstaller Rainer]

Johns solution should do the trick as long as I stop doing my main builds with ant. So that should be good enough for now. 

Will post again in case I run into trouble. 

However I guess there could be a bunch of cases where an override logic would be beneficial, otherwise you end up duplicating code in case you have some standard files that you want to override for certain build types or flavors. 

Is that something you had under consideration?

Cheers

Rainer

Sent on the go

You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/BEv7gqCu8M0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

[Xavier Ducrohet]

Not at the moment.

We'd have to look for all existing files in the source folder and build an include/exclude list to send to the compiler. It's doable but we don't have plans for this yet.

[Raj Parakh]

Hi,

This is a very old thread : 2013 - facing the same problem and see no effective solution on various forums as yet.

The app I am working on has multiple flavors (city-wise flavors - with modification in activities).

When a new flavor  is implemented - few activities for the new program vary from those existing in the main (or "common" ) folder. 

Currently the activity which was common to all previous implementations needs to be copied (thereby creating duplicate versions of same file) to respective flavor's src folders OR lot of  "common folders" (all combinations of flavors) need to be created.

When number of flavors exceeds 15 - code maintainability takes a hit.

Do not wish to have logic of flavor detection and choosing activities in java file.

1. Has the override logic been implemented / any plans around it? 

2. Any simpler way of implementing override mechanism in the current set up?

cheers,

Raj