On Thursday 08 February 2007 05:07, Rupert Smith wrote: > So what to do? Shall I just write a copy of the API from scratch and put it > under javax.security.sasl in much the same way that geronimo have with the > JMS API?
You can go this route, but only if you plan on getting the TCK for JSR28 and making it pass. The javax.* stuff needs to pass the TCK before it's releasable. Geronimo goes through a lot of work to validate everything in geronimo specs before they are released. > Or, do I need to write some sort of wrapper API and factory to > choose between Sun SASL on 1.5 and homebrew SASL on 1.4? That's probably the easiest/quickest way to go. Alternatively, just check if SASL is not available and just point the user at the URL to download it from. Dan > > On 2/8/07, Cliff Schmidt <[EMAIL PROTECTED]> wrote: > > On 2/7/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > On Wednesday 07 February 2007 10:26, Rupert Smith wrote: > > > > I've noticed that recently a lot of Sun API jars have become > > > > available > > > > on > > > > > > the Maven repository (Look under http://www.ibiblio.org/maven2/javax/ > > > > ). > > > > > > This includes the JMS 1.1 API, for which we are currently using the > > > > one > > > > > > found under org.apache.geronimo.specs. > > > > > > Actually, the jar isn't there. Just a pom that if you use it, it says > > > download it from..... > > > > > > > Sun jars under maven have always > > > > been a bit of a problem because for licencing reasons they couldn't > > > > be included in the repository. Now it seems that many of them are, > > > > presumably > > > > > > because of Java itself becoming open sourced? > > > > > > I'd like to clear this up a bit.... > > > > > > Many of the older Sun jars are appearing in the maven repository > > > because > > > > Sun > > > > > itself is having them put there. (Actually, they've setup their own > > > > maven > > > > > repository as well:https://maven-repository.dev.java.net/repository/ > > > > ) The > > > > > license on them still doesn't change. The license would prevent > > > anyone other than Sun from putting them there, but since Sun put it > > > there, > > > > that's > > > > > OK. > > > > > > For the newer CDDL based code, those can be submitted by anyone so > > > those > > > > are > > > > > appearing as well. > > > > > > The issue is the older non-cddl based jars (most are BCL) (JMS jar > > > falls > > > > into > > > > > this category). Those need to be submitted by Sun. However, BCL > > > code cannot be shipped with an Apache project anyway. Thus, if > > > they're > > > > uploaded > > > > > to maven or not doesn't change the fact that qpid cannot ship it. > > > > > > > If it is acceptable, I'd like to submit a request to get this JSR28 > > > > jar > > > > > > added to the maven repository too, and to use it. > > > > > > IANAL, but getting it submitted to the maven repository should be fine > > > > (I > > > > > think). You would still need legal/Cliff to make sure it's ok to > > > ship > > > > with > > > > > the distributions. It's not on the list of accepted licenses: > > > > > > http://people.apache.org/~cliffs/3party.html#criteriaandcategories > > > > One of the criteria to allow incorporating a third-party component > > into an ASF distribution is that the license meet the Open Source > > Definition. The SCSL does not meet the OSD. You might want to check > > with Sun and make sure they aren't planning on relicensing it under > > the CDDL. > > > > Cliff -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
