Re: [m2] deployment of Jetty 6
On Oct 28, 2005, at 7:21 AM, Jason van Zyl wrote: On Thu, 2005-10-27 at 21:35 -0700, David Jencks wrote: On Oct 26, 2005, at 3:30 AM, Greg Wilkins wrote: Ideally, I think apache should branch all the standard javax stuff into a project of it's own. That way tomcat, jetty and geronimo would all be siblings and there would be no cross dependancies and versioning could be correctly done. +1 Several geronimo developers have discussed this as well but we haven't had time to gather support from the other apache projects bundling specs such as tomcat, axis, pluto, etc etc etc. Where do you think the best place might be to organize something like this? A separate TLP where all the projects could get involved? yes I think that we will still need to include more versioning information than the spec version, such as groupIdorg.apache.specs/groupId artifactIdservlet-2.4/artifactId versionId1.0/versionId Just as you have needed to modify spec code when problems appear, at geronimo we've recently found some problems in e.g. jacc, which has been passing the tck for months and months. So, I think we need the ability to fix bugs within a spec version. So if some project were formed that housed all the specs the same project would house (privately) the TCKs? I assume fixes to the specs would be infrequent but would require the running of the TCK for each change. well, i think we'd all have to cooperate to make sure all relevant tck tests passed before a particular spec version was released. Most of the tck tests are not directly tests of the spec classes, and not all behavior is completely specified and not all specified behavior is tested for. But, obviously, the relevant tck passing is a precondition for release. Since such a small part of the tcks are relevant to the specs I doubt trying to tie them together would be useful. There may be other issues as well: the apache copy of j2ee tck relevant material is housed in a separate svn repo to (at least) make access control easier. thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] deployment of Jetty 6
David Jencks wrote: On Oct 26, 2005, at 3:30 AM, Greg Wilkins wrote: Brett Porter wrote: . . . Ideally, I think apache should branch all the standard javax stuff into a project of it's own. That way tomcat, jetty and geronimo would all be siblings and there would be no cross dependancies and versioning could be correctly done. +1 Several geronimo developers have discussed this as well but we haven't had time to gather support from the other apache projects bundling specs such as tomcat, axis, pluto, etc etc etc. Sorry for being a few days late, but you've got Pluto's support. . .let us know what we can do to help. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] deployment of Jetty 6
On Thu, 2005-10-27 at 21:35 -0700, David Jencks wrote: On Oct 26, 2005, at 3:30 AM, Greg Wilkins wrote: Ideally, I think apache should branch all the standard javax stuff into a project of it's own. That way tomcat, jetty and geronimo would all be siblings and there would be no cross dependancies and versioning could be correctly done. +1 Several geronimo developers have discussed this as well but we haven't had time to gather support from the other apache projects bundling specs such as tomcat, axis, pluto, etc etc etc. Where do you think the best place might be to organize something like this? A separate TLP where all the projects could get involved? I think that we will still need to include more versioning information than the spec version, such as groupIdorg.apache.specs/groupId artifactIdservlet-2.4/artifactId versionId1.0/versionId Just as you have needed to modify spec code when problems appear, at geronimo we've recently found some problems in e.g. jacc, which has been passing the tck for months and months. So, I think we need the ability to fix bugs within a spec version. So if some project were formed that housed all the specs the same project would house (privately) the TCKs? I assume fixes to the specs would be infrequent but would require the running of the TCK for each change. thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] deployment of Jetty 6
Brett Porter wrote: I think you should just leave them out of your repository, and leave it up to Geronimo/Tomcat to deploy them into the repo (which they do now, I think). Neither geronimo or tomcat has a properly named m2 repository yet. They alos version the servlet.jar with their own versioning scheme (eg 5.0.28 from tomcat). I really don't want Jetty to depend on either of these projects. I also want the ability to modify the source of javax.servlet classes if need be (this has been required in the past). So I'd prefer to continue bundling the javax.servlet jars in the jetty m2 repository.It is named according to the m2 guidelines, versioned corrected (as 2.4) and is under the jetty GroupId so there is no confusion as to their source. Ideally, I think apache should branch all the standard javax stuff into a project of it's own. That way tomcat, jetty and geronimo would all be siblings and there would be no cross dependancies and versioning could be correctly done. cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] deployment of Jetty 6
I think you should just leave them out of your repository, and leave it up to Geronimo/Tomcat to deploy them into the repo (which they do now, I think). Cheers, Brett On 10/21/05, Greg Wilkins [EMAIL PROTECTED] wrote: Jason van Zyl wrote: We have standard names for SUN JARs: http://maven.apache.org/maven2/guides/mini/guide-coping-with-sun- jars.html Following those is recommended. I will do so. Note that Jetty includes the source - and thus the binaries of the javax.servlet API.But these are sourced from the apache geronimo project and are copyright apache and under the apache 2.0 license. will it be a problem that Jetty is providing these jars in the same groupId as other projects? cheers - 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]
[m2] deployment of Jetty 6
Hi all (and congrads on the 2.0 release), we're moving Jetty 6 over to use m2 and I have lots of questions about deployment. As well as questions, I would not mind a sanity check on what we have done. Firstly naming! The groupId I'm using is org.mortbay.jetty In m1 it appears that the group id is just jetty and this has been moved to the current m2 repository. Should I stick with jetty as the groupId or continue to use org.mortbay.jetty as per new conventions? The modules/artifacts that I have are: project - pom - the top level project pom (should this be called jetty ??) javax.servlet - jar - probably could get from elsewhere, but nice to build with Jetty... just in case. jetty.util- jar - utility classes for Jetty (can be used without the Jetty server) jetty - jar - the server itself start - jar - the jar to start jetty from the command line test - war - a test web application. Are all these reasonable names? How are m1 and m2 repositories to be merged? Will it be sufficient to start publishing only Jetty 6 in a m2 repository or will I have to rename and merge in Jetty 4 and 5 jars to the m2 repository? Will jars I publish with m2 be available to m1 users? Who do I talk to about getting the maven2 repository on jetty.mortbay.org replicated to ibiblio? It is now a sibling directory in the rsync account on that machine. cheers all - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] deployment of Jetty 6
On Thu, 2005-10-20 at 17:50 +0200, Greg Wilkins wrote: Hi all (and congrads on the 2.0 release), we're moving Jetty 6 over to use m2 and I have lots of questions about deployment. As well as questions, I would not mind a sanity check on what we have done. Firstly naming! The groupId I'm using is org.mortbay.jetty In m1 it appears that the group id is just jetty and this has been moved to the current m2 repository. Should I stick with jetty as the groupId or continue to use org.mortbay.jetty as per new conventions? Use the new conventions. The modules/artifacts that I have are: project - pom - the top level project pom (should this be called jetty ??) javax.servlet - jar - probably could get from elsewhere, but nice to build with Jetty... just in case. jetty.util- jar - utility classes for Jetty (can be used without the Jetty server) jetty - jar - the server itself start - jar - the jar to start jetty from the command line test - war - a test web application. We have standard names for SUN JARs: http://maven.apache.org/maven2/guides/mini/guide-coping-with-sun- jars.html Following those is recommended. Are all these reasonable names? How are m1 and m2 repositories to be merged? Will it be sufficient to start publishing only Jetty 6 in a m2 repository or will I have to rename and merge in Jetty 4 and 5 jars to the m2 repository? We convert the m1 repository every 4 hours into m2 format so getting things in m2 style is just fine with us. It's much better information so we can make the necessary m1 information from it. Will jars I publish with m2 be available to m1 users? Yes. Who do I talk to about getting the maven2 repository on jetty.mortbay.org replicated to ibiblio? It is now a sibling directory in the rsync account on that machine. We can sort that out offline. You've already got an m1 repo so setting up an m2 repo will be no problem. cheers all - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
