Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Obviously a very late reply to this, but I'd like to suggest that you ask glassfish to publish these to the java.net repository. It's very easy for them to do, Kohsuke looks after it, and we are planning to sync it in automatically. https://maven-repository.dev.java.net/ - Brett Wayne Fay wrote: I'm hoping we can update the Sun Licensing Journey and get some javax.* apis published in Maven repository without requiring special permission from Sun now that Project Glassfish is publishing many of them under the CDDL license which very clearly *allows* distribution. I know there is an effort to introduce click to agree to license functionality in Maven in the near future, so certain Jars that require agreeing to a license etc before being downloaded can still be accommodated as downloadable dependencies in Maven. This is a great idea and I don't want to detract from it. I glanced at Glassfish CVS and noticed the following apis immediately: javax.activation v1.1 javax.connector v1.5 javax.enterprise.deploy javax.ejb v2.1 javax.security.jacc javax.jms v1.1 javax.management.j2ee javax.persistence v3.0 javax.transaction The Geronimo project is already publishing a few of these, but not all. I don't want to duplicate any efforts, so we'd want to limit it to the currently-unpublished APIs only -- specifically transaction and persistence come to mind but I'm sure some others would go in as well. Another api I'd like to add would be jdbc-stdext (javax.sql) but I can't find it in Glassfish at this point. It might be there and I just don't see it, in which case it would be added too. Since the code is coming from Glassfish, we'd probably want to put it in net.java.glassfish (?). Without Sun's explicit permission and perhaps even co-operation with the effort, I'd hesitate putting them in javax.*. But we could update the javax.* poms to reflect a dependency on the net.java.glassfish files. Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Comments? Thanks. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Excellent, I'll go that route. Wayne On 3/6/06, Brett Porter [EMAIL PROTECTED] wrote: Obviously a very late reply to this, but I'd like to suggest that you ask glassfish to publish these to the java.net repository. It's very easy for them to do, Kohsuke looks after it, and we are planning to sync it in automatically. https://maven-repository.dev.java.net/ - Brett Wayne Fay wrote: I'm hoping we can update the Sun Licensing Journey and get some javax.* apis published in Maven repository without requiring special permission from Sun now that Project Glassfish is publishing many of them under the CDDL license which very clearly *allows* distribution. I know there is an effort to introduce click to agree to license functionality in Maven in the near future, so certain Jars that require agreeing to a license etc before being downloaded can still be accommodated as downloadable dependencies in Maven. This is a great idea and I don't want to detract from it. I glanced at Glassfish CVS and noticed the following apis immediately: javax.activation v1.1 javax.connector v1.5 javax.enterprise.deploy javax.ejb v2.1 javax.security.jacc javax.jms v1.1 javax.management.j2ee javax.persistence v3.0 javax.transaction The Geronimo project is already publishing a few of these, but not all. I don't want to duplicate any efforts, so we'd want to limit it to the currently-unpublished APIs only -- specifically transaction and persistence come to mind but I'm sure some others would go in as well. Another api I'd like to add would be jdbc-stdext (javax.sql) but I can't find it in Glassfish at this point. It might be there and I just don't see it, in which case it would be added too. Since the code is coming from Glassfish, we'd probably want to put it in net.java.glassfish (?). Without Sun's explicit permission and perhaps even co-operation with the effort, I'd hesitate putting them in javax.*. But we could update the javax.* poms to reflect a dependency on the net.java.glassfish files. Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Comments? Thanks. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
If the bundles I've uploaded are acceptable, perhaps we can move forward with this issue? If they are not, please let me know what else needs changing, and I'll take care of it right away... http://jira.codehaus.org/browse/MAVENUPLOAD-759 If this is all OK, I'd be happy to do the same for the other APIs (create poms, bundles, etc). I'd like to see all these APIs made available in Maven repo if at all possible, actual code, not just links to external sites. And this Glassfish/CDDL angle seems to be a good route to achieve that. Also, if you'd like, I can include sources (suggested but not required by ibiblio upload guide). I don't believe I did this with the Persistence and Transaction jars previously uploaded to Jira but I can repackage those, too. I just don't want this issue to fall off the radar, if I can avoid it... Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Yes all of that was included in the parent. I will upload it now. (Of course, the Glassfish site isn't responding right now, so you can't verify the License url, the SCM, etc.) Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: groupid has to be net.java.dev.glassfish Info required http://maven.apache.org/guides/mini/guide-ibiblio-upload.html is not present (url, scm,...), is it in the parent pom? where's the parent pom? On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: I just uploaded Persistence and Transaction bundles to JIRA. http://jira.codehaus.org/browse/MAVENUPLOAD-759 Take a look. As I said before, there are no differences between the class files in these bundles and those being distributed by Glassfish. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Glassfish packages all the J2ee stack modules in a single javaee.jar. But I doubt you want to force everyone to download the 1.2mb javaee.jar file when they only need 1 or 2 apis... That's why I only compared class files -- unpacked the javaee.jar file, grabbed the persistence and transaction subdirs, and compared to mine generated from source. There are no differences between these class files. I will proceed with pom/Maven, and respond again later today... Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Give it a try to one of the projects, generate the pom, build it with maven and post here the differencies. With that info we'd be able to make a decision. On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Sorry, that's tag SJSAS-9_0-B32G-BETA-10_Feb_2006 ! This corresponds to the most recent Milestone build 5 of the Glassfish project. So I just checked out from CVS, compiled, and compared my generated binaries (classes only) to those provided by Glassfish for the persistence-api and transaction-api modules only. As far as SFV is concerned, these are identical files/directories. This is as we expected, but we needed to confirm it. So the binaries (Sun binary license) being delivered by Glassfish are identical to the source files (CDDL licensed). So... given this, what's the next step? I can revert my entire local CVS root to the B32G build, compile all the APIs, create the appropriate POMs (assuming we can make a decision on groupId and artifactId), and create bundles for all these Glassfish APIs, if we agree on this approach. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
I'm trying to checkout and build with your poms: - the scm url is wrong mvn scm:checkout fails - you're putting the poms you made under CDDL license??? On 3/2/06, Wayne Fay [EMAIL PROTECTED] wrote: If the bundles I've uploaded are acceptable, perhaps we can move forward with this issue? If they are not, please let me know what else needs changing, and I'll take care of it right away... http://jira.codehaus.org/browse/MAVENUPLOAD-759 If this is all OK, I'd be happy to do the same for the other APIs (create poms, bundles, etc). I'd like to see all these APIs made available in Maven repo if at all possible, actual code, not just links to external sites. And this Glassfish/CDDL angle seems to be a good route to achieve that. Also, if you'd like, I can include sources (suggested but not required by ibiblio upload guide). I don't believe I did this with the Persistence and Transaction jars previously uploaded to Jira but I can repackage those, too. I just don't want this issue to fall off the radar, if I can avoid it... Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Yes all of that was included in the parent. I will upload it now. (Of course, the Glassfish site isn't responding right now, so you can't verify the License url, the SCM, etc.) Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: groupid has to be net.java.dev.glassfish Info required http://maven.apache.org/guides/mini/guide-ibiblio-upload.html is not present (url, scm,...), is it in the parent pom? where's the parent pom? On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: I just uploaded Persistence and Transaction bundles to JIRA. http://jira.codehaus.org/browse/MAVENUPLOAD-759 Take a look. As I said before, there are no differences between the class files in these bundles and those being distributed by Glassfish. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Glassfish packages all the J2ee stack modules in a single javaee.jar. But I doubt you want to force everyone to download the 1.2mb javaee.jar file when they only need 1 or 2 apis... That's why I only compared class files -- unpacked the javaee.jar file, grabbed the persistence and transaction subdirs, and compared to mine generated from source. There are no differences between these class files. I will proceed with pom/Maven, and respond again later today... Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Give it a try to one of the projects, generate the pom, build it with maven and post here the differencies. With that info we'd be able to make a decision. On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Sorry, that's tag SJSAS-9_0-B32G-BETA-10_Feb_2006 ! This corresponds to the most recent Milestone build 5 of the Glassfish project. So I just checked out from CVS, compiled, and compared my generated binaries (classes only) to those provided by Glassfish for the persistence-api and transaction-api modules only. As far as SFV is concerned, these are identical files/directories. This is as we expected, but we needed to confirm it. So the binaries (Sun binary license) being delivered by Glassfish are identical to the source files (CDDL licensed). So... given this, what's the next step? I can revert my entire local CVS root to the B32G build, compile all the APIs, create the appropriate POMs (assuming we can make a decision on groupId and artifactId), and create bundles for all these Glassfish APIs, if we agree on this approach. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Actually I just copied their existing maven.xml and modified for M2, so I left the CDDL there. No, I don't care about that, so I'll remove it. The entire dev.java.net site was down when I was working on this the other day, so the SCM urls are not correct. Will update. Thanks. Wayne On 3/2/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I'm trying to checkout and build with your poms: - the scm url is wrong mvn scm:checkout fails - you're putting the poms you made under CDDL license??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
What has to do maven.xml with pom.xml ? On 3/2/06, Wayne Fay [EMAIL PROTECTED] wrote: Actually I just copied their existing maven.xml and modified for M2, so I left the CDDL there. No, I don't care about that, so I'll remove it. The entire dev.java.net site was down when I was working on this the other day, so the SCM urls are not correct. Will update. Thanks. Wayne On 3/2/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I'm trying to checkout and build with your poms: - the scm url is wrong mvn scm:checkout fails - you're putting the poms you made under CDDL license??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Project Glassfish is currently using multiple build tools including ant, maven1, etc. Each module has its own method of building. Their m1 project.xml for the persistence-api module was called maven.xml and I used it as the basis for my pom.xml file. So the CDDL license etc was just leftover. As for the SCM connection... I don't currently use SCM in any of my Maven2 projects, that's all handled offline in other tools for now, so I took some time and figured it out.. I got a working scm:checkout just now. I'll upload this updated persistence-api bundle (includes updated pom, source, and binary jar) to Jira and wait for more comments from Carlos et al. Hopefully this bundle is more along the lines of what you were expecting... http://jira.codehaus.org/browse/MAVENUPLOAD-759 Wayne On 3/2/06, Carlos Sanchez [EMAIL PROTECTED] wrote: What has to do maven.xml with pom.xml ? On 3/2/06, Wayne Fay [EMAIL PROTECTED] wrote: Actually I just copied their existing maven.xml and modified for M2, so I left the CDDL there. No, I don't care about that, so I'll remove it. The entire dev.java.net site was down when I was working on this the other day, so the SCM urls are not correct. Will update. Thanks. Wayne On 3/2/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I'm trying to checkout and build with your poms: - the scm url is wrong mvn scm:checkout fails - you're putting the poms you made under CDDL license??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Wayne Fay wrote: Here's the complete list of javax apis included with Glassfish, based on a 233mb source code CVS checkout... javax.activation javax.servlet.jsp.jstl javax.resource (connector) javax.enterprise.deploy (deployment) javax.ejb javax.security.jacc javax.jms javax.mail javax.management.j2ee javax.persistence javax.servlet.jsp (jsr-152, JSP 2.0) javax.servlet.http (jsr-154, Servlet 2.4) javax.servlet.jsp (jsr-245, JSP 2.1) javax.transaction Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Obviously, verifying all the class files from the binary distribution vs what I compile out of CVS will be a bit of a chore. Don't suppose anyone has a method for comparing the contents of two file system trees? I can extract the class files from their distribution, build from source myself, and compare the file sizes etc assuming I can find a simple comparison process. If you can't think of a unix one liner to do it (I can't), you could use Ant to copy the entire directory tree using the isdifferent selector, which does byte-for-byte checking on files the same length -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Wayne Fay wrote: Don't suppose anyone has a method for comparing the contents of two file system trees? I can extract the class files from their distribution, build from source myself, and compare the file sizes etc assuming I can find a simple comparison process. well I'm not sure what system you are sitting on, bet there exist many different diff applications for either linux and windows anyway, what I'm using the most for file comparisment is kdiff3 which from according to the site works on amny different linux distros, windows and osx.. http://kdiff3.sourceforge.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Sorry, that's tag SJSAS-9_0-B32G-BETA-10_Feb_2006 ! This corresponds to the most recent Milestone build 5 of the Glassfish project. So I just checked out from CVS, compiled, and compared my generated binaries (classes only) to those provided by Glassfish for the persistence-api and transaction-api modules only. As far as SFV is concerned, these are identical files/directories. This is as we expected, but we needed to confirm it. So the binaries (Sun binary license) being delivered by Glassfish are identical to the source files (CDDL licensed). So... given this, what's the next step? I can revert my entire local CVS root to the B32G build, compile all the APIs, create the appropriate POMs (assuming we can make a decision on groupId and artifactId), and create bundles for all these Glassfish APIs, if we agree on this approach. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Give it a try to one of the projects, generate the pom, build it with maven and post here the differencies. With that info we'd be able to make a decision. On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Sorry, that's tag SJSAS-9_0-B32G-BETA-10_Feb_2006 ! This corresponds to the most recent Milestone build 5 of the Glassfish project. So I just checked out from CVS, compiled, and compared my generated binaries (classes only) to those provided by Glassfish for the persistence-api and transaction-api modules only. As far as SFV is concerned, these are identical files/directories. This is as we expected, but we needed to confirm it. So the binaries (Sun binary license) being delivered by Glassfish are identical to the source files (CDDL licensed). So... given this, what's the next step? I can revert my entire local CVS root to the B32G build, compile all the APIs, create the appropriate POMs (assuming we can make a decision on groupId and artifactId), and create bundles for all these Glassfish APIs, if we agree on this approach. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Glassfish packages all the J2ee stack modules in a single javaee.jar. But I doubt you want to force everyone to download the 1.2mb javaee.jar file when they only need 1 or 2 apis... That's why I only compared class files -- unpacked the javaee.jar file, grabbed the persistence and transaction subdirs, and compared to mine generated from source. There are no differences between these class files. I will proceed with pom/Maven, and respond again later today... Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Give it a try to one of the projects, generate the pom, build it with maven and post here the differencies. With that info we'd be able to make a decision. On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Sorry, that's tag SJSAS-9_0-B32G-BETA-10_Feb_2006 ! This corresponds to the most recent Milestone build 5 of the Glassfish project. So I just checked out from CVS, compiled, and compared my generated binaries (classes only) to those provided by Glassfish for the persistence-api and transaction-api modules only. As far as SFV is concerned, these are identical files/directories. This is as we expected, but we needed to confirm it. So the binaries (Sun binary license) being delivered by Glassfish are identical to the source files (CDDL licensed). So... given this, what's the next step? I can revert my entire local CVS root to the B32G build, compile all the APIs, create the appropriate POMs (assuming we can make a decision on groupId and artifactId), and create bundles for all these Glassfish APIs, if we agree on this approach. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
I just uploaded Persistence and Transaction bundles to JIRA. http://jira.codehaus.org/browse/MAVENUPLOAD-759 Take a look. As I said before, there are no differences between the class files in these bundles and those being distributed by Glassfish. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Glassfish packages all the J2ee stack modules in a single javaee.jar. But I doubt you want to force everyone to download the 1.2mb javaee.jar file when they only need 1 or 2 apis... That's why I only compared class files -- unpacked the javaee.jar file, grabbed the persistence and transaction subdirs, and compared to mine generated from source. There are no differences between these class files. I will proceed with pom/Maven, and respond again later today... Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Give it a try to one of the projects, generate the pom, build it with maven and post here the differencies. With that info we'd be able to make a decision. On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Sorry, that's tag SJSAS-9_0-B32G-BETA-10_Feb_2006 ! This corresponds to the most recent Milestone build 5 of the Glassfish project. So I just checked out from CVS, compiled, and compared my generated binaries (classes only) to those provided by Glassfish for the persistence-api and transaction-api modules only. As far as SFV is concerned, these are identical files/directories. This is as we expected, but we needed to confirm it. So the binaries (Sun binary license) being delivered by Glassfish are identical to the source files (CDDL licensed). So... given this, what's the next step? I can revert my entire local CVS root to the B32G build, compile all the APIs, create the appropriate POMs (assuming we can make a decision on groupId and artifactId), and create bundles for all these Glassfish APIs, if we agree on this approach. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
groupid has to be net.java.dev.glassfish Info required http://maven.apache.org/guides/mini/guide-ibiblio-upload.html is not present (url, scm,...), is it in the parent pom? where's the parent pom? On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: I just uploaded Persistence and Transaction bundles to JIRA. http://jira.codehaus.org/browse/MAVENUPLOAD-759 Take a look. As I said before, there are no differences between the class files in these bundles and those being distributed by Glassfish. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Glassfish packages all the J2ee stack modules in a single javaee.jar. But I doubt you want to force everyone to download the 1.2mb javaee.jar file when they only need 1 or 2 apis... That's why I only compared class files -- unpacked the javaee.jar file, grabbed the persistence and transaction subdirs, and compared to mine generated from source. There are no differences between these class files. I will proceed with pom/Maven, and respond again later today... Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Give it a try to one of the projects, generate the pom, build it with maven and post here the differencies. With that info we'd be able to make a decision. On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Sorry, that's tag SJSAS-9_0-B32G-BETA-10_Feb_2006 ! This corresponds to the most recent Milestone build 5 of the Glassfish project. So I just checked out from CVS, compiled, and compared my generated binaries (classes only) to those provided by Glassfish for the persistence-api and transaction-api modules only. As far as SFV is concerned, these are identical files/directories. This is as we expected, but we needed to confirm it. So the binaries (Sun binary license) being delivered by Glassfish are identical to the source files (CDDL licensed). So... given this, what's the next step? I can revert my entire local CVS root to the B32G build, compile all the APIs, create the appropriate POMs (assuming we can make a decision on groupId and artifactId), and create bundles for all these Glassfish APIs, if we agree on this approach. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Yes all of that was included in the parent. I will upload it now. (Of course, the Glassfish site isn't responding right now, so you can't verify the License url, the SCM, etc.) Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: groupid has to be net.java.dev.glassfish Info required http://maven.apache.org/guides/mini/guide-ibiblio-upload.html is not present (url, scm,...), is it in the parent pom? where's the parent pom? On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: I just uploaded Persistence and Transaction bundles to JIRA. http://jira.codehaus.org/browse/MAVENUPLOAD-759 Take a look. As I said before, there are no differences between the class files in these bundles and those being distributed by Glassfish. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Glassfish packages all the J2ee stack modules in a single javaee.jar. But I doubt you want to force everyone to download the 1.2mb javaee.jar file when they only need 1 or 2 apis... That's why I only compared class files -- unpacked the javaee.jar file, grabbed the persistence and transaction subdirs, and compared to mine generated from source. There are no differences between these class files. I will proceed with pom/Maven, and respond again later today... Wayne On 2/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Give it a try to one of the projects, generate the pom, build it with maven and post here the differencies. With that info we'd be able to make a decision. On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: Sorry, that's tag SJSAS-9_0-B32G-BETA-10_Feb_2006 ! This corresponds to the most recent Milestone build 5 of the Glassfish project. So I just checked out from CVS, compiled, and compared my generated binaries (classes only) to those provided by Glassfish for the persistence-api and transaction-api modules only. As far as SFV is concerned, these are identical files/directories. This is as we expected, but we needed to confirm it. So the binaries (Sun binary license) being delivered by Glassfish are identical to the source files (CDDL licensed). So... given this, what's the next step? I can revert my entire local CVS root to the B32G build, compile all the APIs, create the appropriate POMs (assuming we can make a decision on groupId and artifactId), and create bundles for all these Glassfish APIs, if we agree on this approach. Wayne On 2/28/06, Wayne Fay [EMAIL PROTECTED] wrote: On 2/28/06, Steve Loughran [EMAIL PROTECTED] wrote: Oh, this nice. javax.persistence especially. I've been doing some EJB3 stuff and that is a sore point. JTA too. Since you expressed an interest in persistence and transaction, I focused efforts on those two modules. I pulled down the Glassfish CVS code, compiled into classes, and compared to the classes delivered by Glassfish distribution using SFV (its like MD5 for a group of files/directories). Found my compiled classes had a number of differences including new files. Realized I was using CVS head rather than tag SJAS-9_0-B32G-BETA-10_Feb_2006. So now I'm pulling the tag code from CVS, will repeat the compile and compare steps, and report back shortly... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Wayne Fay wrote: However, the CDDL source code license ensures we **can** download the proper source, build/unit test, package, bundle with poms, and deploy **those** executables from the repo. This is an important difference. That's why I originally said: Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Any more comments? :-) That would be progress. One thing to check is how much difference is there between a JAR made that way and a released JAR. In an ideal world. apart from manifest data, there would be no difference. But if there is a difference, there is a risk that something wont work, and then who is left fielding the problems? Maybe the artifacts should be published with a groupId that indicates it was rebuilt or something, so that glassfish-rebuilt-jta-1.0.3.jar is clearly different from jta-1.0.3.jar. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
This is exactly why I said we might not want to distribute as javax.*. I am definitely concerned about ongoing maintenance etc. Ideally we'd get the Glassfish project themselves to build the Jars and submit to Maven repo. They are using Ant and Maven1 for their build process, so they are familiar with the Maven repo concept. I will compile the sources, compare each to the binaries distributed by Glassfish, and report back later today... Wayne On 2/27/06, Steve Loughran [EMAIL PROTECTED] wrote: Wayne Fay wrote: However, the CDDL source code license ensures we **can** download the proper source, build/unit test, package, bundle with poms, and deploy **those** executables from the repo. This is an important difference. That's why I originally said: Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Any more comments? :-) That would be progress. One thing to check is how much difference is there between a JAR made that way and a released JAR. In an ideal world. apart from manifest data, there would be no difference. But if there is a difference, there is a risk that something wont work, and then who is left fielding the problems? Maybe the artifacts should be published with a groupId that indicates it was rebuilt or something, so that glassfish-rebuilt-jta-1.0.3.jar is clearly different from jta-1.0.3.jar. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Here's the complete list of javax apis included with Glassfish, based on a 233mb source code CVS checkout... javax.activation javax.servlet.jsp.jstl javax.resource (connector) javax.enterprise.deploy (deployment) javax.ejb javax.security.jacc javax.jms javax.mail javax.management.j2ee javax.persistence javax.servlet.jsp (jsr-152, JSP 2.0) javax.servlet.http (jsr-154, Servlet 2.4) javax.servlet.jsp (jsr-245, JSP 2.1) javax.transaction Obviously, verifying all the class files from the binary distribution vs what I compile out of CVS will be a bit of a chore. Don't suppose anyone has a method for comparing the contents of two file system trees? I can extract the class files from their distribution, build from source myself, and compare the file sizes etc assuming I can find a simple comparison process. Wayne On 2/27/06, Wayne Fay [EMAIL PROTECTED] wrote: This is exactly why I said we might not want to distribute as javax.*. I am definitely concerned about ongoing maintenance etc. Ideally we'd get the Glassfish project themselves to build the Jars and submit to Maven repo. They are using Ant and Maven1 for their build process, so they are familiar with the Maven repo concept. I will compile the sources, compare each to the binaries distributed by Glassfish, and report back later today... Wayne On 2/27/06, Steve Loughran [EMAIL PROTECTED] wrote: Wayne Fay wrote: However, the CDDL source code license ensures we **can** download the proper source, build/unit test, package, bundle with poms, and deploy **those** executables from the repo. This is an important difference. That's why I originally said: Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Any more comments? :-) That would be progress. One thing to check is how much difference is there between a JAR made that way and a released JAR. In an ideal world. apart from manifest data, there would be no difference. But if there is a difference, there is a risk that something wont work, and then who is left fielding the problems? Maybe the artifacts should be published with a groupId that indicates it was rebuilt or something, so that glassfish-rebuilt-jta-1.0.3.jar is clearly different from jta-1.0.3.jar. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Can you provide the urls where the jars can be downloaded and the url of the license so we can take a look? If everything is ok and they are the official reference implementations they can go under javax.* On 2/25/06, Wayne Fay [EMAIL PROTECTED] wrote: I'm hoping we can update the Sun Licensing Journey and get some javax.* apis published in Maven repository without requiring special permission from Sun now that Project Glassfish is publishing many of them under the CDDL license which very clearly *allows* distribution. I know there is an effort to introduce click to agree to license functionality in Maven in the near future, so certain Jars that require agreeing to a license etc before being downloaded can still be accommodated as downloadable dependencies in Maven. This is a great idea and I don't want to detract from it. I glanced at Glassfish CVS and noticed the following apis immediately: javax.activation v1.1 javax.connector v1.5 javax.enterprise.deploy javax.ejb v2.1 javax.security.jacc javax.jms v1.1 javax.management.j2ee javax.persistence v3.0 javax.transaction The Geronimo project is already publishing a few of these, but not all. I don't want to duplicate any efforts, so we'd want to limit it to the currently-unpublished APIs only -- specifically transaction and persistence come to mind but I'm sure some others would go in as well. Another api I'd like to add would be jdbc-stdext (javax.sql) but I can't find it in Glassfish at this point. It might be there and I just don't see it, in which case it would be added too. Since the code is coming from Glassfish, we'd probably want to put it in net.java.glassfish (?). Without Sun's explicit permission and perhaps even co-operation with the effort, I'd hesitate putting them in javax.*. But we could update the javax.* poms to reflect a dependency on the net.java.glassfish files. Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Comments? Thanks. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Here's the Glassfish project website: https://glassfish.dev.java.net/ More specifically, you can download the most recent Milestone5-b32g build here: https://glassfish.dev.java.net/downloads/12Feb06.html Its about 60mb packaged as Jar. That download page contains the following text, with links to licenses: Several different software components including source and binary, support the GlassFish project. The source components are released under the Common Development and Distribution License (CDDL) v1.0 whereas the binary components are covered under the binary license. You must agree to these licenses as part of installation before viewing and/or using the code. If you read the CDDL, it says: https://glassfish.dev.java.net/public/CDDLv1.0.html 3.5. Distribution of Executable Versions. You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. Then if you read their binary license, it says: https://glassfish.dev.java.net./public/BinariesLicense.html 1. Definitions. Software means all the portions of the GlassFish distribution provided by Sun only in binary code form, and including any updates or error corrections or documentation provided by Sun under this Agreement. 2. Permitted Uses. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software's documentation, Sun grants you a non-exclusive, non-transferable, limited license without fees to (a) reproduce and use internally the Software for the purposes of developing or running GlassFish or modified versions of GlassFish. (b) reproduce and distribute the Software (and also portions of Software identified as Redistributable in the documentation accompanying Software), provided that you (i) distribute the Software or Redistributables bundled as part of, and for the sole purpose of running, GlassFish or modified versions of GlassFish; Due to the differences in these licenses, and the fact that we certainly DO NOT intend to distribute their software for the sole purpose of running Glassfish, I don't believe we can simply download the milestone build, extract the Jars, bundle them with poms and distribute them via Maven. However, the CDDL source code license ensures we **can** download the proper source, build/unit test, package, bundle with poms, and deploy **those** executables from the repo. This is an important difference. That's why I originally said: Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Any more comments? :-) Wayne On 2/25/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Can you provide the urls where the jars can be downloaded and the url of the license so we can take a look? If everything is ok and they are the official reference implementations they can go under javax.* On 2/25/06, Wayne Fay [EMAIL PROTECTED] wrote: I'm hoping we can update the Sun Licensing Journey and get some javax.* apis published in Maven repository without requiring special permission from Sun now that Project Glassfish is publishing many of them under the CDDL license which very clearly *allows* distribution. I know there is an effort to introduce click to agree to license functionality in Maven in the near future, so certain Jars that require agreeing to a license etc before being downloaded can still be accommodated as downloadable dependencies in Maven. This is a great idea and I don't want to detract from it. I glanced at Glassfish CVS and noticed the following apis immediately: javax.activation v1.1 javax.connector v1.5 javax.enterprise.deploy javax.ejb v2.1 javax.security.jacc javax.jms v1.1 javax.management.j2ee javax.persistence v3.0 javax.transaction The Geronimo project is already publishing a few of these, but not all. I don't want to duplicate any efforts, so we'd want to limit it to the currently-unpublished APIs only -- specifically transaction and persistence come to mind but I'm sure some others would go in as well. Another api I'd like to add would be jdbc-stdext (javax.sql) but I can't find it in Glassfish at this point. It might be there and I just don't see it, in which case it would be added too. Since the code is coming from Glassfish, we'd probably want to put it in net.java.glassfish (?). Without Sun's explicit permission and
