Conflict with HoloEverywhere library.

[HenriqueRocha]

Add 'psts' attribute prefix to avoid conflict in dividerPadding attribute when using this lib together with HoloEverywhere library.
Added prefix to all attributes to make them look all the same, instead of adding the prefix only to dividerPadding.
My project was failing to compile because HoloEverywhere was giving this error:
attrs.xml:24: error: Attribute "dividerPadding" has already been defined

[ghost]

Won't merge this. I don't want that every user who doesn't use HoloEverywhere has to write these prefixes.

You can:

• open the same pull request for HoloEverywhere (they will say the same I think)
• just change this locally for your project only

[rgeldmacher]

+1
There is a conflict with support-v7-appcompat for the following attributes:
dividerPadding
textAllCaps

support-v7-appcompat contains the new actionbar compat, which probably more and more people will be switching to as a google maintained alternative for actionbarsherlock.

[juancferrer]

Consider merging this.
I'm using only support-v7-appcompat, no actionbarsherlock, no HoloEverywhere, no other library, and I'm getting a conflict on 'dividerPadding', and 'textAllCaps', just like @rgeldmacher and @igorglotov

[jaayb]

Same here as far as the support-v7-appcompat library. Had to abandon actionbarsherlock because of conflicts with the googlecast sdk as well.

[rrbrambley]

Same here. Using support-v7-appcompat.

[matthiasbruns]

Same here

[LOG-TAG]

Same here
/res/values/attrs.xml:10: error: Attribute "dividerPadding" has already been defined
/res/values/attrs.xml:15: error: Attribute "textAllCaps" has already been defined

Using support-v7-appcompat.

But we can fix the bug in lib by changing above mentioned fix by AndroidPIT, and don't forget to change the

    app:pstsDividerColor="#00000000"
    app:pstsIndicatorColor="#FF33B5E6"
    app:pstsTabPaddingLeftRight="14dip"
    app:pstsUnderlineColor="#FF33B5E6" 

in the fragment_quick_contact.xml in example project !

[Bersam]

any solution for this? i have problem with support-v7-appcompat, too.

[igorglotov]

You can try to apply this pull request #37
Should work then.

[matt-oakes]

This is something which is really needed. At the minute it's holding me back on migrating to maven cleanly.

[HenriqueRocha]

@matto1990 Why don't you fork the project, do the change you need and use your forked version? By the way, since you haven't moved to Maven yet, move to Gradle instead. You can fork the project and apply my commit d9e32fa from the comments above.

[matt-oakes]

I've done that, but it's annoying that this version, which is in the android ark repository is not compatible with such a common and official library.

I am moving directly to gradle, but gradle uses the maven repositories for dependencies.

[HenriqueRocha]

HoloEverywhere is not that common and is not an official library.

[matt-oakes]

Exactly the same issues are seen when you're using the android-support-v7 library from Google.

[Turnsole]

+1 to what matto said, except I'm using the v4 support lib.

[kenyee]

+1. I hit the same issue. Please rename the attributes and merge.

I also had a problem importing the library into Eclipse..it kept coming in as a Gradle project instead of an Android Library because the git code includes the .gradle, .settings, .classpath, and .project files. Those aren't needed so I had to delete them first. The Gradle plugin is also 0.5.x instead of 0.4.x...the old one tied to Gradle 1.6.
I can fork it, merge the patch, and stuff it into Maven Central to share w/ everyone, but it doesn't seem like that's the right thing to do, so I'm just going to patch my local copy for now... :-P

[matt-oakes]

Agreed. It's such a hood library that I don't want to form it just to make
it compatible with Android support libraries.
On 12 Dec 2013 21:31, "kenyee" notifications@github.com wrote:

+1. I hit the same issue. Please rename the attributes and merge.

I also had a problem importing the library into Eclipse..it kept coming in
as a Gradle project instead of an Android Library because the git code
includes the .gradle, .settings, .classpath, and .project files. Those
aren't needed so I had to delete them first. The Gradle plugin is also
0.5.x instead of 0.4.x...the old one tied to Gradle 1.6.
I can fork it, merge the patch, and stuff it into Maven Central to share
w/ everyone, but it doesn't seem like that's the right thing to do, so I'm
just going to patch my local copy for now... :-P

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2#issuecomment-30463902
.