Re: Just the JARs
On Wed, 2 Jan 2002 13:56, Craig R. McClanahan wrote: This simple notion -- and my putting together a Jakarta release HOWTO -- is why I opened this particular thread. The license issue is well taken. I think it would be a good practice for us to include a license in all of our JARs. Even when we don't distribute them seperately ourselves, they are intended to be distributed seperately by our licensees. Point noted. How about including a copy of the LICENSE file in the META-INF subdirectory of each JAR file produced by an Apache project? +1 -- Cheers, Pete --- Therefore it can be said that victorious warriors win first, and then go to battle, while defeated warriors go to battle first, and then seek to win. - Sun Tzu, the Art Of War --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
At 18:56 01.01.2002 -0800, Craig R. McClanahan wrote: On Tue, 1 Jan 2002, Ted Husted wrote: Date: Tue, 01 Jan 2002 14:54:30 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Just the JARs Geir Magnusson Jr. wrote: Putting aside *all* the stuff we are talking about for a moement, and looking at the simple notion of just having release jars available w/o docs, source, etc I don't think this is a bad idea :) However Any license issues? Wouldn't we want to package the jar w/ a license ? This simple notion -- and my putting together a Jakarta release HOWTO -- is why I opened this particular thread. The license issue is well taken. I think it would be a good practice for us to include a license in all of our JARs. Even when we don't distribute them seperately ourselves, they are intended to be distributed seperately by our licensees. Point noted. How about including a copy of the LICENSE file in the META-INF subdirectory of each JAR file produced by an Apache project? Good suggestion. Log4j-1.2.jar will contain a LICENSE.txt file in the META-INF subdirectory. Regards, Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
Craig R. McClanahan wrote: How about including a copy of the LICENSE file in the META-INF subdirectory of each JAR file produced by an Apache project? +1 -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 10:39 AM, Ted Husted [EMAIL PROTECTED] wrote: Does anyone have a page regarding how to make a Jakarta release? I'd like to put one together and post it with the other guideline materials. I tried to make a dist target for helping with a release. The target makes source and binary distributions and can be found in the BCEL, XmlRpc and Fulcrum. I was going to add this target to the build file that Berin offered the Alexandria project. With dependency information I've been adding to the gump descriptors it would be possible to combine a standard target for building release bundles with that dependency information to produce whatever we felt was the desired result for a release. Maybe we could take this over to the alexandria list? I've noticed that a few releases now include the JARs as a seperate download. Personally, I think that's a good idea, since more and more products have inter-dependancies. Would we want to suggest that as a standard practice? This could save a lot of effort and bandwidth, since now you often have to download a 3mb archive when all you want is a 150k JAR. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Just the JARs
What would be nice would be to have a JJAR/CJAN project coupled with GUMP. This application would have both an Ant task (for developers) to retrieve versions of dependent jars (latest or specified version or date) and a GUI/Applet in the download area so that end user could use it to download dependent jars. What is needed is : 1/ a repository for the jars where GUMP would copy nightly builds and where releases would be put 2/ dependency information (what Jason is building or what the Commons JJAR project has) so that dependent jars can be easily downloaded I think it might be a good idea for JJAR/CJAN to be a subproject of Alexandria. -Vincent -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 15:52 To: Jakarta General List Subject: Re: Just the JARs On 1/1/02 10:39 AM, Ted Husted [EMAIL PROTECTED] wrote: Does anyone have a page regarding how to make a Jakarta release? I'd like to put one together and post it with the other guideline materials. I tried to make a dist target for helping with a release. The target makes source and binary distributions and can be found in the BCEL, XmlRpc and Fulcrum. I was going to add this target to the build file that Berin offered the Alexandria project. With dependency information I've been adding to the gump descriptors it would be possible to combine a standard target for building release bundles with that dependency information to produce whatever we felt was the desired result for a release. Maybe we could take this over to the alexandria list? I've noticed that a few releases now include the JARs as a seperate download. Personally, I think that's a good idea, since more and more products have inter-dependancies. Would we want to suggest that as a standard practice? This could save a lot of effort and bandwidth, since now you often have to download a 3mb archive when all you want is a 150k JAR. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:general- [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
I think Lucene is already doing something very similar. Except that the JARs are just put in with the other builds. Perhaps we can just recommend that everyone follow suit. http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/ http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/ People could then just provide hyperlinks to the appropriate build directories (say in a build.html file next to the build.xml), and let people choose what they want to download. A front-end application that made all of our products more accessible would also be a Good Thing, and something I would like to do some time. But if were to publish some recommendations now, and lead by example, I think things could get much easier for us all without much effort. I'm not suggesting we all run around and post JARs for the old releases, but as new releases are issued, we might want to follow Lucene's example (among others). -Ted. Vincent Massol wrote: What would be nice would be to have a JJAR/CJAN project coupled with GUMP. This application would have both an Ant task (for developers) to retrieve versions of dependent jars (latest or specified version or date) and a GUI/Applet in the download area so that end user could use it to download dependent jars. What is needed is : 1/ a repository for the jars where GUMP would copy nightly builds and where releases would be put 2/ dependency information (what Jason is building or what the Commons JJAR project has) so that dependent jars can be easily downloaded I think it might be a good idea for JJAR/CJAN to be a subproject of Alexandria. -Vincent -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 15:52 To: Jakarta General List Subject: Re: Just the JARs On 1/1/02 10:39 AM, Ted Husted [EMAIL PROTECTED] wrote: Does anyone have a page regarding how to make a Jakarta release? I'd like to put one together and post it with the other guideline materials. I tried to make a dist target for helping with a release. The target makes source and binary distributions and can be found in the BCEL, XmlRpc and Fulcrum. I was going to add this target to the build file that Berin offered the Alexandria project. With dependency information I've been adding to the gump descriptors it would be possible to combine a standard target for building release bundles with that dependency information to produce whatever we felt was the desired result for a release. Maybe we could take this over to the alexandria list? I've noticed that a few releases now include the JARs as a seperate download. Personally, I think that's a good idea, since more and more products have inter-dependancies. Would we want to suggest that as a standard practice? This could save a lot of effort and bandwidth, since now you often have to download a 3mb archive when all you want is a 150k JAR. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:general- [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Just the JARs
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 18:39 To: Jakarta General List Subject: Re: Just the JARs I think Lucene is already doing something very similar. Except that the JARs are just put in with the other builds. Perhaps we can just recommend that everyone follow suit. http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/ http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/ I'm not sure what you mean. I've had a look and the dependent jars are _not_ put with the gump build (or the release build). The only jar there is is the junit one but if you look at the GUMP definition of Lucene (http://jakarta.apache.org/builds/gump/latest/module_jakarta-lucene.html ) you'll find that it depends on xerces, ant and javacc, which are not included. People could then just provide hyperlinks to the appropriate build directories (say in a build.html file next to the build.xml), and let people choose what they want to download. I agree that it would be nice if the GUMP results were put somewhere publicly accessible (they may be but I have no idea where). However, the second step is to automatically fetch the correct dependent jars (and possibly in a validated working state, proved by unit testing of each project). A front-end application that made all of our products more accessible would also be a Good Thing, and something I would like to do some time. But if were to publish some recommendations now, and lead by example, I think things could get much easier for us all without much effort. yep, but also an Ant task (like the one in JJAR) for project developers. I'm not suggesting we all run around and post JARs for the old releases, but as new releases are issued, we might want to follow Lucene's example (among others). I guess this is currently done for most projects, isn't it (I mean that GUMP nightly builds are put in http://jakarta.apache.org/builds/) ? What I have done in Cactus, but I'm not sure it is the right way is to package an Ant distribution containing all the needed tasks/dependent jars to build the Cactus project / run Cactus tests in a project, using Ant. We also package the dependent jars in the release and nightly builds. -Vincent -Ted. Vincent Massol wrote: What would be nice would be to have a JJAR/CJAN project coupled with GUMP. This application would have both an Ant task (for developers) to retrieve versions of dependent jars (latest or specified version or date) and a GUI/Applet in the download area so that end user could use it to download dependent jars. What is needed is : 1/ a repository for the jars where GUMP would copy nightly builds and where releases would be put 2/ dependency information (what Jason is building or what the Commons JJAR project has) so that dependent jars can be easily downloaded I think it might be a good idea for JJAR/CJAN to be a subproject of Alexandria. -Vincent -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 15:52 To: Jakarta General List Subject: Re: Just the JARs On 1/1/02 10:39 AM, Ted Husted [EMAIL PROTECTED] wrote: Does anyone have a page regarding how to make a Jakarta release? I'd like to put one together and post it with the other guideline materials. I tried to make a dist target for helping with a release. The target makes source and binary distributions and can be found in the BCEL, XmlRpc and Fulcrum. I was going to add this target to the build file that Berin offered the Alexandria project. With dependency information I've been adding to the gump descriptors it would be possible to combine a standard target for building release bundles with that dependency information to produce whatever we felt was the desired result for a release. Maybe we could take this over to the alexandria list? I've noticed that a few releases now include the JARs as a seperate download. Personally, I think that's a good idea, since more and more products have inter-dependancies. Would we want to suggest that as a standard practice? This could save a lot of effort and bandwidth, since now you often have to download a 3mb archive when all you want is a 150k JAR. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:general- [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail
Re: Just the JARs
Ted Husted wrote: I think Lucene is already doing something very similar. Except that the JARs are just put in with the other builds. Perhaps we can just recommend that everyone follow suit. http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/ I post the contents of those directories. I certainly can do that for every project that gump tracks. And separate things out any way that people find sensible. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 12:57 PM, Vincent Massol [EMAIL PROTECTED] wrote: What would be nice would be to have a JJAR/CJAN project coupled with GUMP. This application would have both an Ant task (for developers) to retrieve versions of dependent jars (latest or specified version or date) and a GUI/Applet in the download area so that end user could use it to download dependent jars. What is needed is : 1/ a repository for the jars where GUMP would copy nightly builds and where releases would be put 2/ dependency information (what Jason is building or what the Commons JJAR project has) so that dependent jars can be easily downloaded I think it might be a good idea for JJAR/CJAN to be a subproject of Alexandria. I disagree. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 2:00 PM, Vincent Massol [EMAIL PROTECTED] wrote: -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 18:39 To: Jakarta General List Subject: Re: Just the JARs I think Lucene is already doing something very similar. Except that the JARs are just put in with the other builds. Perhaps we can just recommend that everyone follow suit. http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/ http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/ I'm not sure what you mean. I've had a look and the dependent jars are _not_ put with the gump build (or the release build). The only jar there is is the junit one but if you look at the GUMP definition of Lucene (http://jakarta.apache.org/builds/gump/latest/module_jakarta-lucene.html ) you'll find that it depends on xerces, ant and javacc, which are not included. People could then just provide hyperlinks to the appropriate build directories (say in a build.html file next to the build.xml), and let people choose what they want to download. I agree that it would be nice if the GUMP results were put somewhere publicly accessible (they may be but I have no idea where). However, the second step is to automatically fetch the correct dependent jars (and possibly in a validated working state, proved by unit testing of each project). You don't want to use the results of Gump for JJAR. Gump isn't bulding releases - it's building CVS-tree-du-jour... There is no reason to believe anything built by Gump works. I hope I'm just confused on what you are advocating. A front-end application that made all of our products more accessible would also be a Good Thing, and something I would like to do some time. But if were to publish some recommendations now, and lead by example, I think things could get much easier for us all without much effort. yep, but also an Ant task (like the one in JJAR) for project developers. I'm not suggesting we all run around and post JARs for the old releases, but as new releases are issued, we might want to follow Lucene's example (among others). I guess this is currently done for most projects, isn't it (I mean that GUMP nightly builds are put in http://jakarta.apache.org/builds/) ? What I have done in Cactus, but I'm not sure it is the right way is to package an Ant distribution containing all the needed tasks/dependent jars to build the Cactus project / run Cactus tests in a project, using Ant. We also package the dependent jars in the release and nightly builds. -Vincent -Ted. Vincent Massol wrote: What would be nice would be to have a JJAR/CJAN project coupled with GUMP. This application would have both an Ant task (for developers) to retrieve versions of dependent jars (latest or specified version or date) and a GUI/Applet in the download area so that end user could use it to download dependent jars. What is needed is : 1/ a repository for the jars where GUMP would copy nightly builds and where releases would be put 2/ dependency information (what Jason is building or what the Commons JJAR project has) so that dependent jars can be easily downloaded I think it might be a good idea for JJAR/CJAN to be a subproject of Alexandria. -Vincent -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 15:52 To: Jakarta General List Subject: Re: Just the JARs On 1/1/02 10:39 AM, Ted Husted [EMAIL PROTECTED] wrote: Does anyone have a page regarding how to make a Jakarta release? I'd like to put one together and post it with the other guideline materials. I tried to make a dist target for helping with a release. The target makes source and binary distributions and can be found in the BCEL, XmlRpc and Fulcrum. I was going to add this target to the build file that Berin offered the Alexandria project. With dependency information I've been adding to the gump descriptors it would be possible to combine a standard target for building release bundles with that dependency information to produce whatever we felt was the desired result for a release. Maybe we could take this over to the alexandria list? I've noticed that a few releases now include the JARs as a seperate download. Personally, I think that's a good idea, since more and more products have inter-dependancies. Would we want to suggest that as a standard practice? This could save a lot of effort and bandwidth, since now you often have to download a 3mb archive when all you want is a 150k JAR. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:general- [EMAIL PROTECTED] -- jvz. Jason van Zyl http
Re: Just the JARs
Vincent Massol wrote: I'm not sure what you mean. I've had a look and the dependent jars are _not_ put with the gump build (or the release build). I mean that if we all start offering our JARs as a separate download, like Lucene and some others are doing, then people who need these JARs can get them without downloading the entire distribution. Once that happens, someone could build an automated process on top of that. Or, even without an automated process, you can just provide a hyperlink to the download direcory and let people choose whether they want the JAR or the distribution. Right now, most often, you have to download a 3mb archive just to get a 150kb JAR. I'm just thinking of doing a page about How to make a Jakarta release, and thought we might suggest this as a convention. If we start suggesting this now, then by the time we get through the next release cycle, we would all have JARs out where an automated process can get at them. (Or where they can at least be quickly downloaded the old-fasioned way.) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Just the JARs
Vincent Massol wrote: I agree that it would be nice if the GUMP results were put somewhere publicly accessible (they may be but I have no idea where). However, the second step is to automatically fetch the correct dependent jars (and possibly in a validated working state, proved by unit testing of each project). To date, I've been posting binaries in an ad-hoc fashion. Some projects have explicitly requested that binaries NOT be posted. Others prefer to build their nightly binaries in their own way. If there is consensus on what is desired, I will see what I can do. - Sam Ruby P.S. Gump is well aware of what dependent jars were used to execute the build (including any unit tests, if present). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 2:33 PM, Ted Husted [EMAIL PROTECTED] wrote: Vincent Massol wrote: I'm not sure what you mean. I've had a look and the dependent jars are _not_ put with the gump build (or the release build). I mean that if we all start offering our JARs as a separate download, like Lucene and some others are doing, then people who need these JARs can get them without downloading the entire distribution. Once that happens, someone could build an automated process on top of that. Or, even without an automated process, you can just provide a hyperlink to the download direcory and let people choose whether they want the JAR or the distribution. Right now, most often, you have to download a 3mb archive just to get a 150kb JAR. I'm just thinking of doing a page about How to make a Jakarta release, and thought we might suggest this as a convention. If we start suggesting this now, then by the time we get through the next release cycle, we would all have JARs out where an automated process can get at them. (Or where they can at least be quickly downloaded the old-fasioned way.) Putting aside *all* the stuff we are talking about for a moement, and looking at the simple notion of just having release jars available w/o docs, source, etc I don't think this is a bad idea :) However Any license issues? Wouldn't we want to package the jar w/ a license ? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
Geir Magnusson Jr. wrote: I agree that it would be nice if the GUMP results were put somewhere publicly accessible (they may be but I have no idea where). However, the second step is to automatically fetch the correct dependent jars (and possibly in a validated working state, proved by unit testing of each project). You don't want to use the results of Gump for JJAR. Gump isn't bulding releases - it's building CVS-tree-du-jour... There is no reason to believe anything built by Gump works. I believe that the operative words were validated working state, proved by unit testing of each project. To pick a random example... the http://jakarta.apache.org/gump/ is produced by anakia . Which version of anakia? The one built by gump. How am I confident that it is going to work? For starters, there is the unit tests of velocity itself. Then there are other projects which use velocity that build and unit test successfully. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
Geir Magnusson Jr. wrote: Putting aside *all* the stuff we are talking about for a moement, and looking at the simple notion of just having release jars available w/o docs, source, etc I don't think this is a bad idea :) However Any license issues? Wouldn't we want to package the jar w/ a license ? This simple notion -- and my putting together a Jakarta release HOWTO -- is why I opened this particular thread. The license issue is well taken. I think it would be a good practice for us to include a license in all of our JARs. Even when we don't distribute them seperately ourselves, they are intended to be distributed seperately by our licensees. Point noted. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 2:43 PM, Sam Ruby [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: I agree that it would be nice if the GUMP results were put somewhere publicly accessible (they may be but I have no idea where). However, the second step is to automatically fetch the correct dependent jars (and possibly in a validated working state, proved by unit testing of each project). You don't want to use the results of Gump for JJAR. Gump isn't bulding releases - it's building CVS-tree-du-jour... There is no reason to believe anything built by Gump works. I believe that the operative words were validated working state, proved by unit testing of each project. That still doesn't mean anything other than the CVS-du-jour is self-consistent with it's own unit tests, and says nothing about behavior expected by something dependent upon it. To pick a random example... the http://jakarta.apache.org/gump/ is produced by anakia . Which version of anakia? The one built by gump. How am I confident that it is going to work? For starters, there is the unit tests of velocity itself. Then there are other projects which use velocity that build and unit test successfully. That's fine. That still is no guarantee that the functionality can be depended upon. I mean, what gump really tells you is that the API contracts of a project that are used by dependent projects are being preserved (because you can build using the gump-produced jars), but there are no functional contracts that you can dependably test. Further, you don't have a provably complete API contract test because you depend on other projects, which I bet just use a subset, to tell you if something changed. (Food for thought for Gump moving forward, I guess...) So it wouldn't be right to base JJAR fetches of those jars - except when you specify the non-released latest. (JJAR lets you choose which version of a jar you want...) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 2:54 PM, Ted Husted [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Putting aside *all* the stuff we are talking about for a moement, and looking at the simple notion of just having release jars available w/o docs, source, etc I don't think this is a bad idea :) However Any license issues? Wouldn't we want to package the jar w/ a license ? This simple notion -- and my putting together a Jakarta release HOWTO -- is why I opened this particular thread. The license issue is well taken. I think it would be a good practice for us to include a license in all of our JARs. Even when we don't distribute them seperately ourselves, they are intended to be distributed seperately by our licensees. Point noted. It was more of a question than a point :) I was painting a bathroom (sort of like a bike shed, but my wife dictated the color :) and started wondering about binary distribution issues... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Just the JARs
-Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 19:24 To: Jakarta General List Subject: Re: Just the JARs On 1/1/02 12:57 PM, Vincent Massol [EMAIL PROTECTED] wrote: What would be nice would be to have a JJAR/CJAN project coupled with GUMP. This application would have both an Ant task (for developers) to retrieve versions of dependent jars (latest or specified version or date) and a GUI/Applet in the download area so that end user could use it to download dependent jars. What is needed is : 1/ a repository for the jars where GUMP would copy nightly builds and where releases would be put 2/ dependency information (what Jason is building or what the Commons JJAR project has) so that dependent jars can be easily downloaded I think it might be a good idea for JJAR/CJAN to be a subproject of Alexandria. I disagree. You have the right ... ;-) But why ? My rationale was that the goal of GUMP as I understand it now, is to ensure that all projects play well with each other in term of compatibility. It seems natural to extend it so that it can also be asked to retrieve all dependent jars for a given project. -Vincent P.S.: I said Alexandria instead of GUMP in my previous post but I'm not cleat on the relations between these 2 in the future ... :-) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 3:08 PM, Vincent Massol [EMAIL PROTECTED] wrote: -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 19:26 To: Jakarta General List Subject: Re: Just the JARs You don't want to use the results of Gump for JJAR. Gump isn't bulding releases - it's building CVS-tree-du-jour... There is no reason to believe anything built by Gump works. I hope I'm just confused on what you are advocating. For me, GUMP is doing much more than building the CVS-tree-du-jour, whatever this means. It is building releases every day of all projects and produces project outputs. But is that what it does? I don't think so. As I understand it, it takes the CVS HEAD from each project and builds - the purpose being to be an early warning system to detect when API's change through alteration of interfaces or classes. CVS HEAD is generally not considered the current release of a given project, but the ongoing development efforts of the project. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
Geir Magnusson Jr. wrote: My rationale was that the goal of GUMP as I understand it now, is to ensure that all projects play well with each other in term of compatibility. It seems natural to extend it so that it can also be asked to retrieve all dependent jars for a given project. Not to me. Gump to me is an early warning tool to ensure API stability across dependent projects, and must, by definition, always work on the current bleeding edge of all projects. It must do this because once you test a set of released versions, nothing changes :) So gump doesn't even have the dependent jars for the released versions - it uses more bleeding edge jars it makes itself to satisfy the dependencies. Gump can and does use jars checked into cvs: http://jakarta.apache.org/builds/gump/latest/cvsjars.html Gump can and does use jars installed on the machine: http://jakarta.apache.org/builds/gump/latest/packages.html Many of the nightly builds for various subprojects are published based on what gump produces in the manner desired by the communities for these subprojects. Many of these include in bundled form the jars referenced by the build. For more information on what the goal of Gump is (or more precisely, why it was written), please see http://jakarta.apache.org/gump/why.html - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 6:04 PM, Sam Ruby [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: My rationale was that the goal of GUMP as I understand it now, is to ensure that all projects play well with each other in term of compatibility. It seems natural to extend it so that it can also be asked to retrieve all dependent jars for a given project. Not to me. Gump to me is an early warning tool to ensure API stability across dependent projects, and must, by definition, always work on the current bleeding edge of all projects. It must do this because once you test a set of released versions, nothing changes :) So gump doesn't even have the dependent jars for the released versions - it uses more bleeding edge jars it makes itself to satisfy the dependencies. Gump can and does use jars checked into cvs: http://jakarta.apache.org/builds/gump/latest/cvsjars.html Ok - these seem to be jars you can't or don¹t want to build yourself? Gump can and does use jars installed on the machine: http://jakarta.apache.org/builds/gump/latest/packages.html Which appear to be things you can't build either. I don't understand what you are trying to say here. Many of the nightly builds for various subprojects are published based on what gump produces in the manner desired by the communities for these subprojects. Many of these include in bundled form the jars referenced by the build. But a nightly build isn't a release, right? Wasn't this discussion motivated by Ted looking into getting projects to offer release build jars alone w/o the whole source/docs distro to make for convenient downlaod? For more information on what the goal of Gump is (or more precisely, why it was written), please see http://jakarta.apache.org/gump/why.html That's good. Here's your summary : * It is easier to get a patch accepted against the most current version of a project than some previous baseline. * It is much more effective to express your opinion on a change that will affect you before that change is released than afterwards. So since this is indeed the goal of gump ( actually, I think they are reasons rather than a goal...) then I think that my understanding relative to this discussion is correct, isn't it? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
AFAIK, all the Jakarta sub-projects try to ensure (but cannot guarantee) that the nightly builds remain usuable. The idea being you build and test it on your own machine before committing it to the CVS. Of course, since we are human and our tests are imperfect, the nigthly builds sometimes break. But I believe that is the exception rather than the rule, especially for products that already have a release under their belt. I believe we all hope and expect that a good number of people will be putting the nightly builds to use, so we know if what we are developing is working for everyone else. My only point is that some products are developing against another product's nightly build, and to build product A you need the JAR from product B's nightly build. So, in addition of providing JARs alongside the formal releases, I would say it's a good idea to provide nightly JARs alongside the nightly builds, so long as it is not difficult to make this part of the automatic process. -Ted. Vincent Massol wrote: I would say it depends on the project and the meaning you give to the word release. For the Cactus project, a nightly build produces exactly the same files as a release and can be used with a great deal of confidence. The only difference with a release is that a release has a goal, i.e. we have voluntarily decided that when such and such features are put in, then it would warrant a release. I like to use GUMP for 2 purposes : * Early detection of contentions with dependent projects, * Automated builds/integration, leading to a daily release (in the agile way). Users are encouraged to use the nightly builds and not wait for releases. It may be different for other projects though but I tend to like this philosophy ... :-) [snip] -Vincent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 7:12 PM, Ted Husted [EMAIL PROTECTED] wrote: AFAIK, all the Jakarta sub-projects try to ensure (but cannot guarantee) that the nightly builds remain usuable. The idea being you build and test it on your own machine before committing it to the CVS. Of course, since we are human and our tests are imperfect, the nigthly builds sometimes break. But I believe that is the exception rather than the rule, especially for products that already have a release under their belt. I believe we all hope and expect that a good number of people will be putting the nightly builds to use, so we know if what we are developing is working for everyone else. Error isn't the only issue - I think that the projects have the right to do whatever they want with their CVS HEAD. Gump tells them that they are straying from previous API commitments if that's the case, or functionality changes or whatever... The nightly (for many, anyway) is just a convenience for those that are unable to get the CVS tree (because of corporate firewall policy) or don't want to (for whatever reason). My only point is that some products are developing against another product's nightly build, and to build product A you need the JAR from product B's nightly build. Yep - that's a good thing - I am long overdue for committing my JJAR changes, and would be happy to add CVS HEAD as a version choice when available, to be supplied by gump. That's a great thing. However, I will continue the riff that released versions are important and different. So, in addition of providing JARs alongside the formal releases, I would say it's a good idea to provide nightly JARs alongside the nightly builds, so long as it is not difficult to make this part of the automatic process. Yep - it shouldn't be hard with JJAR if Sam puts things in the same place all the time - after all, it's always going to be the same version... -Ted. Vincent Massol wrote: I would say it depends on the project and the meaning you give to the word release. For the Cactus project, a nightly build produces exactly the same files as a release and can be used with a great deal of confidence. The only difference with a release is that a release has a goal, i.e. we have voluntarily decided that when such and such features are put in, then it would warrant a release. I like to use GUMP for 2 purposes : * Early detection of contentions with dependent projects, * Automated builds/integration, leading to a daily release (in the agile way). Users are encouraged to use the nightly builds and not wait for releases. It may be different for other projects though but I tend to like this philosophy ... :-) [snip] -Vincent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
Geir Magnusson Jr. wrote: However, I will continue the riff that released versions are important and different. Just curious, why does the December 9th release of jakarta-velocity contain a milestone version of commons-collections.jar dated May 11th, when there was a release of commons-collections dated July 14? I'll leave it to others to decide whether this is important, or merely different. Meanwhile, if there are any byproducts of the things I build from public cvs that other find useful, I will endeavor to support their requests. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 8:43 PM, Sam Ruby [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: However, I will continue the riff that released versions are important and different. Just curious, why does the December 9th release of jakarta-velocity contain a milestone version of commons-collections.jar dated May 11th, when there was a release of commons-collections dated July 14? Because I made a mistake in not updating the collections jar for that release. Thanks for pointing that out. It will be corrected. I'll leave it to others to decide whether this is important, or merely different. I'll be the first to say that it's important to me (as I can't speak for others), and will be corrected ASAP. Meanwhile, if there are any byproducts of the things I build from public cvs that other find useful, I will endeavor to support their requests. Why does it appear that it is not wanted? I'm confused... I was just pointing out that keeping the distinction between 'released' and 'gump' is important. Both are useful, and in Vincent's case, they seem to be equivalent, but not in all cases here in Jakarta. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On Tue, 1 Jan 2002, Ted Husted wrote: Date: Tue, 01 Jan 2002 14:54:30 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Just the JARs Geir Magnusson Jr. wrote: Putting aside *all* the stuff we are talking about for a moement, and looking at the simple notion of just having release jars available w/o docs, source, etc I don't think this is a bad idea :) However Any license issues? Wouldn't we want to package the jar w/ a license ? This simple notion -- and my putting together a Jakarta release HOWTO -- is why I opened this particular thread. The license issue is well taken. I think it would be a good practice for us to include a license in all of our JARs. Even when we don't distribute them seperately ourselves, they are intended to be distributed seperately by our licensees. Point noted. How about including a copy of the LICENSE file in the META-INF subdirectory of each JAR file produced by an Apache project? -Ted. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
