On 28 March 2011 16:16, Brian Pontarelli <[email protected]> wrote:
> > On Mar 26, 2011, at 2:20 PM, Stuart McCulloch wrote: > > On 26 March 2011 16:48, Brian Pontarelli <[email protected]> wrote: > >> I'm looking at the 3.0 artifacts in Maven Central and wanted to clarify >> somethings: >> >> - Why is there a dependency on org.sonatype.sisu.inject:cglib? >> Isn't this jarjar'd into Guice? >> > > It's an optional dependency - there needs to be some dependency to get > cglib onto the classpath so it can then be jarjar'd. Optional dependencies > are used during compilation, but aren't pulled onto your classpath when you > depend on the final artifact. Also the optionality of this dependency is set > by a build property, which is on by default, to allow people to build > binaries without jarjar'ing if they happen to want that. > > The contents of the sisu cglib jar match the cglib jar in Guice trunk > (itself a snapshot of cglib from 20090111) - when there's an official cglib > release we'll use that. > > > Gotcha. I didn't even look at the profiles. What prevents you from marking > the dependency optional or provided and skipping the profile? It seems like > the released state of the library is for CGLIB to be optional/provided. > Plus, most external tools won't look at the profile to determine that > information. > We can't mark it as provided, because that implies it will be provided by a container at runtime - whereas it is actually embedded. Marking it as optional is the recommended approach when shading/jarjar'ing is involved. We use a profile+property to allow the jarjar'ing to be turned off as a convenience, this can be useful when developing with Eclipse and you need hot-code-replace debugging (just easier when you're working directly off source and no packaging steps are involved). But anything scraping pom metadata from Maven Central should be prepared to resolve the "effective" pom (as Maven does) - otherwise they're definitely going to trip over things like inherited dependencies, property interpolation, and profiles. Thankfully a lot of the libraries used to do this are available outside of Maven (such as https://docs.sonatype.org/display/AETHER/Home). > > - Why doesn't the artifactId for javax.inject:javax.inject follow >> the javax api standard? It should be inject-api >> > > Because that just happens to be the artifactId used by the javax.inject > release > > > Right. Hehe. I got that much. > > > ( but looking at the artifacts under > http://repo1.maven.org/maven2/javax/there doesn't seem to be any such > standard wrt. artifactId ) > > > There is. It is the form > > <module>-api > > This is consistent with servlet-api, jsp-api, sip-api, javaee-api, jsf-api, > el-api, jsr250-api, jdo-api, jdo2-api, jsr181-api, persistence-api (you get > the idea). > but not "javax/j2ee/j2ee", "javax/enterprise/cdi-api", "javax/help/javahelp", "javax/media/jai_core", "javax/faces/jsf-api"... I'm not saying having a standard convention is bad, but I haven't seen it written down anywhere - at the very least it should probably be part of the JCP process then people would automatically know what javax coordinates to use for their dependencies on Maven Central. Of course for every rule there will be exceptions, such as when a group contains multiple API artifacts or when acronyms like JAAS are involved. > > >> - Why is the version number of javax.inject simply 1 rather than >> 1.0 or 1.0.0? >> > > Again, because that happens to be the version used by the javax.inject > release: > > http://repo1.maven.org/maven2/javax/inject/javax.inject/1/ > > You'll need to take up the group/artifact/version details with the > javax.inject team (or whoever uploaded that artifact) > > > Again got that much. hehe. My question is more of a why limit the version > number. It doesn't seem intuitive or standard to the other javax releases. > They all follow the x.y and x.y.z patterns. > FWIW, 1 is equivalent to 1.0 and 1.0.0 in Maven (and OSGi) ... convention is to use 3 digits, but it's not enforced there's also some background discussion about the version at http://groups.google.com/group/atinject-observer/browse_thread/thread/f1d19cfdf7b5eec2 > My questions are really just about good clean meta-data. I didn't check out > the POM for the RC releases because I was using Savant. Now I'm updating the > Savant repository to the latest version of Guice and wrote a script to pull > the Maven artifacts and POMs and convert them (as much as possible). That's > when I noticed and asked about these things. > > -bp > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > -- Cheers, Stuart -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
