Nearing 1.0.0.RC2: Feedback requested

[habuma]

We're planning to push Spring Social 1.0.0.RC2 early next week (if all goes well, on Monday). RC2 fixes a handful of bugs discovered since RC1 and also includes a few minor enhancements. As with RC1, we will release Spring Social Core, Spring Social Facebook and Spring Social Twitter as 1.0.0.RC2.

We invite you to take a look at the latest snapshots and let us know if there's anything out of sorts that should be addressed before 1.0.0.RC2. Reply to this post if you have any feedback, problems, or suggestions.

Thank you all very much for participating in Spring Social!

[rickcr]

Not sure if the showcase falls into the RC2 feedback, but something seems odd here in the showcase source. I built my IDEA project for the Social Showcase project with 'mvn idea:idea.' It creates a dependency on the 3.0.5.RELEASE core jar.

The SocialConfig class uses import org.springframework.core.env.Environment;
which doesn't seem to exist in 3.0.5.RELEASE (I even downloaded the source code and that package env doesn't exist in the 3.0.5.RELEASE core jar.)

Oddly the project builds fine with mvn so not sure what's going on there. I'm guessing somehow the project actually builds off some dependency on core3.1 which maybe has that env package?

[habuma]

That is peculiar. It imports into Eclipse fine. The 'mvn eclipse:eclipse' goal generates a .classpath file with the right Spring version. M2Eclipse imports it into Eclipse correctly. And, of course, it builds fine. But 'mvn idea:idea' picks up Spring 3.0.5.RELEASE.

This would seem to be a quirk with the Idea Maven plugin, but I can't say for sure--I'm not an Idea user and, in fact, tonight might be the first time I've ever run 'mvn idea:idea'. It would appear that the Idea plugin is picking up 3.1.0.M2 when it is explicitly asked for in the pom and 3.0.5.RELEASE when something else has a transitive dependency on that version.

One way to fix this is to exclude the Spring dependencies from the Spring Security dependencies (I tried it...it works). But that's an extreme approach and results in a lot of noise in pom.xml. I'll think it over and look for a more elegant way. If anyone reading this has any ideas (no pun intended), let us know.

[rickcr]

Since you end up needing spring-core on the classpath for that Environment class to be picked up, why not just add the dependency to spring-core in the pom.xml? (instead of relying on it getting picked up as some transitive dependency)

This did the trick for me and I'm thinking maybe it should be defined anyway:

<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-core</artifactId>
	<version>${org.springframework-version}</version>
</dependency>

[habuma]

That's a good suggestion and I'll certainly consider it. Even then, the spring-aop and spring-beans dependencies are being pulled in as 3.0.5--so I'd need to do something similar for them.

I still wonder why the Idea plugin is inconsistent with everything else in this matter.

[rickcr]

I still wonder why the Idea plugin is inconsistent with everything else in this matter.

If you run mvn dependency:tree -Dverbose
You'll see a lot of "omitted for duplicate" and "omitted for conflict with 3.1.0.M"
Looks like the idea plugin doesn't do the omitting of 3.0.5 (I do tend to think though that if you are relying on a spring-core jar that the dependency should be defined anyway so it makes it clear to the user looking at the pom which spring-core.jar is being used.)