Replies in line... > -----Original Message----- > From: Paul B. Henson [mailto:[email protected]] > Sent: Friday, August 2, 2013 12:10 PM > To: [email protected] > Subject: Re: [cas-user] service manager application authorization via LDAP > > On 8/1/2013 10:54 PM, Misagh Moayyed wrote: > > Thanks for catching the typo. I updated the wiki. > > Cool. In the example, it lists "${spring.security.ldap.version}" for the version, > but the built will fail unless that is defined somewhere. I suppose for > someone with maven experience that will be obvious, but before my crash > course yesterday ;) I would have just copied it literally and ended up with: >
Right. Thanks for the feedback. I'll make a few edits to clarify that. > Is there any way for the cas pom configuration to define > versions that are inherited by the local pom? Otherwise, you have to go > figure out what version of spring the version of cas you are building uses, and > what version of spring.security.ldap is appropriate for it. Ideally a user would > just have to add a dependency and not worry about coordinating the > version. In the local pom, you probably could create a <parent> element that refers to the CAS pom. With that, you should be able to inherit settings. > Yes, that is the case. Perhaps I'm mistaken, but I didn't think it was possible > for a given java application to use more than one version of a given class? So > if two different versions of the same jar exist, it's going to use whichever one > it finds first? I'd be hesitant to generally classify that in terms of a "first come, first serve" strategy. That more has to do with how the runtime environment loads the JARs and how Java components are loaded and resolved by the "classpath loader". > > If that is true, isn't it rather broken to build a war with multiple versions of > the same jar? It seems maven should complain rather than letting somebody > go install a war with potentially undefined behavior. It's certainly a problem, and it's something to carefully account for. Depending on the runtime environment and how it resolves the JAR file, the app might work and starttup with the right JAR file taking over, or you might run into issues such as the one you were faced with. Maven is usually pretty good about resolving the dependency tree. The challenge is working with Maven overlays. You're meddling with an already pre-built WAR file that contains a bunch of dependencies and JAR files in it, and my experience has been that Maven has a hard time processing or becoming aware of those dependencies in the downloaded WAR unless you explicitly tweak the configuration to teach it so. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
