This pull request is an example of Maven support for SlidingMenu which can serve as a starting point for a discussion on Maven support. There are several challenges supporting Maven for SlidingMenu:
Removed unused crittercism import to compile using Maven
SlidingFragmentActivity needs to inherit SherlockFragmentActivity in …
…order to compile example app.
Added Maven support
I read on developer.android.com that the use of MapActivity is now unnecessary; Activity now has whatever you were looking to MapActivity for.
Yes, if using the new Maps API bundled with Play Services Framework. If using that you don't really need any Maps-specific code in SlidingMenu afaik.
+1, maven support is the one thing I need
@jfeinstein10 what's your opinion on this?
I'd really appreciate it if you could remove ActionBarSherlock from the pom file. In practice, it's bad to release a library that depends on another library. Other than that, I'll definitely merge it!
I agree with @alfthomas that there should be some kind of core slidingmenu package so we can support the base android activities, the base sherlock activities or the roboguice activities. I might have time to work on a generic solution tomorrow.
Moved ActionBarSherlock and Maps support into separate jar libraries …
…in order for users of the slidingmenu-core library to choose which features they need themselves.
I just refactored this into separate modules now.
Hopefully this was what you were looking for @jfeinstein10 and @benoitdion
That looks good. It should make it easy to extend to support roboguice or event roboguice-sherlock.
@jfeinstein10 when/if you accept this pull request, could you also release an initial version of the library to sonatype?
Can't comment on the .classpath files as I am an IntelliJ user too.
@jfeinstein10: any update on accepting the pull request?
Keep in mind there is still some work remaining for @jfeinstein10 registering and setting up for deployment to the Sonatype OSS repository.
They have a pretty good guide for it up at https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide and you can have a look at the ActionBarSherlock repo to see a project with similar structure is using the Sonatype repo to handle release and deployment.
This is true, but the pull request is updated, we can still clone it locally and mvn clean install it to add it to our local repository for the time being right?
mvn clean install
Yes, @unkzdomain that will install it locally and you could also deploy it to a company Maven proxy like Sonatype Nexus if you're using one, making it available to other developers, build servers etc. in your company using the same proxy without having to install it manually to every local repository.
However, at the time there are no tags in the SlidingMenu repo so there really doesn't exist any specific versions of SlidingMenu to build. You just build from the master branch and make up a version number. This can be confusing when trying to figure out if a specific issue is fixed in the version you're using or not.
@alfthomas - when I try to do a mvn clean install in the root directory, it complains that it Could not find artifact com.google.android.maps:maps:jar:16_r3 in central (http://repo1.maven.org/maven2) -- but I only need ABS support, not Maps. Is there a way I can skip the SlidingMenu Maps Support part?
Could not find artifact com.google.android.maps:maps:jar:16_r3 in central (http://repo1.maven.org/maven2)
@jfeinstein10 - Is there any reason this hasn't been merged and added to SonaType yet?
Because I don't know what SonaType is? I thought everybody put their stuff on Maven Central.
I don't really use Maven, but if somebody could guide me a little more, that'd be great.
The Sonatype OSS Repository is a repository provided by Sonatype for any open-source project that wants to get its artifacts into Central. Once you confirm that everything is good with Sonatype, they'll let you sync to Central automatically.
I don't really have any experience with setting up a project to sync with Sonatype other than reading the link that @alfthomas posted, so you might need to ask him for more help if you need it.
+1 - This is key to have this implemented. I may create a slidingmenusherlock lib once its done. That way we can just include both in a POM and presto, actionbar and sliding menu all through pom inclusion.
@unkzdomain The error about the maps artifact is because it is not available in any public repositories. If you don't need maps support you could open the parent pom.xml and remove library-maps-support from the list of modules before building. If you need it, the easiest way to deploy it is using https://github.com/mosabua/maven-android-sdk-deployer
@jfeinstein10 The Sonatype OSS repository allows syncing to Maven Central. I've not used it myself, but the guide at https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide looks very detailed. I know ActionBarSherlock uses this repository.
+1 to this issue
Would also be interrested in seeing this project and also the slidingmenusherlocklib available in maven central :)
@jfeinstein10, any chance you will consider parts of this if I create a new pull request based on the current master?
I understand why you pulled the simpler pull request, but as long as the library directly depends on ABS one is basically screwed if not wanting to use ABS, i.e. don't care about pre-ICS. I don't know which platforms other people are developing their Android apps for, but going forward we no longer care about pre-ICS as we see around 85% of user sessions from ICS+ nowadays.
Also, master is not currently building the example project with Maven.
+1 to alfthomas' post.
I don't use maven but I agree with alfthomas that relying on providing support for pre-ics is becoming a lot less of an issue. In our app we made a early decision to forsake pre-ICS devices in favor of being able to take advantage of all of the features of the newer versions. In my case it easy to remove the need for the compatibility library and such (except after the pointer fix) but again, I don't use maven.
Yeah, and I'm not saying SlidingMenu should drop support for ABS, but it should really be optional. :)
@alfthomas yeah, I would definitely consider pulling it. Again, I don't want this library to depend on ABS of course :)
Closing this now because it is out of date.