> > 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).
I'll check out some of the Maven compilers for my script. Savant and Maven are quite different that I almost always have to edit the resulting meta-data. I guess I just generally prefer meta-data to be explicit rather than compiled. > 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. Okay, let's write it down. I don't think we need to, but let's do it if it helps. Until then, we should find a commons standard and use it. >> >> - 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 It is standard in all tools that I know of (including Savant), but just wondered why the extra digit was dropped for the Inject artifacts when everything else has it. Doesn't really matter in the end, I guess I'm just more anal than most. -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.
