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. > > - 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). > > > - 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. 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.
