Re: [TC4] jakarta-regexp.jar
On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote: On Thu, Jul 19, 2001 at 10:58:21PM -0700, Craig R. McClanahan wrote: On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote: Do you have a position on including a jakarta-regexp.jar (or a jakarta-regexp-1.2.jar or a jakarta-regexp-1.3-dev.jar) directly in jakarta-tomcat-4.0/lib so we can build it without synching and building jakarta-regexp? I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that have been discussed at length on this and other lists in the past. Storing JAR files is evil, because it creates dependencies on those particular versions of the JAR files and you cannot reliably recreate a release purely from sources. The dependencies are already there, and always will be. The only difference is that at present, the actual jars can slip out from under you at any time (which actually just happened to me -- while you weren't looking, jakarta-regexp changed the name of their jar file which broke your build). Having seen *way* too many people get burned by loading binaries into CVS (usually caused by API changes in the projects you depend on, plus the resultant inability to reliably recreate an old version from sources), I'm unalterably opposed to putting JAR files into CVS except in extreme circumstances (i.e. sealing violations). People who have known me in open source projects for a while will quickly realize how unusual that position is for me -- about most things I'm much more easygoing. But I will not willingly participate in any project that uses checked in JARs as a standard practice. I've gotten (and seen on others) too many scars from that behavior to find it acceptable. Craig
RE: [TC4] jakarta-regexp.jar
on 7/19/01 7:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
P.S. I'd like to propose that jakarta-regexp project name all their
jars jakarta-regexp.jar no matter what version they are. This doesn't
affect the decision here.
-1
Until we have a CJAN, I like version numbers on jar files.
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
Why could still use symlink as I do in my RPM :)
ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar
Re: [TC4] jakarta-regexp.jar
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
Why could still use symlink as I do in my RPM :)
ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar
Yes, these are all possible solutions, but I'd prefer it if there
weren't a problem in the first place. Easily editing a file or
making a symlink is one more step that a local user can mess up.
(user = developer, I know, but it's an open source project; it should
be as simple as possible for people to fix bugs etc.)
Anyway, nevermind. I see I'm not going to make headway here. :-)
- A
--
Alex Chaffee mailto:[EMAIL PROTECTED]
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: [TC4] jakarta-regexp.jar
[EMAIL PROTECTED] wrote:
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
Why could still use symlink as I do in my RPM :)
ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar
Yes, these are all possible solutions, but I'd prefer it if there
weren't a problem in the first place. Easily editing a file or
making a symlink is one more step that a local user can mess up.
(user = developer, I know, but it's an open source project; it should
be as simple as possible for people to fix bugs etc.)
Anyway, nevermind. I see I'm not going to make headway here. :-)
-1 For putting jar files in cvs ;-)
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: [TC4] jakarta-regexp.jar
on 7/19/01 10:58 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that have been discussed at length on this and other lists in the past. Storing JAR files is evil, because it creates dependencies on those particular versions of the JAR files and you cannot reliably recreate a release purely from sources. In the case of Catalina, I'm against it since you have setup a system of defining things in the build.properties file and requiring people to already download a ton of other stuff anyway. The next logical step is to use Geir's JJAR (look in the jakarta-commons-sandbox) to automatically download the right .jar files for you. Actually, Jon's suggestion is the right answer. Craig McClanahan I'm going to print that quote (taken entirely out of context) out and frame it next to my JSP Sucks article. :-) http://jakarta.apache.org/~jon/jdj_julycover.jpg -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: [TC4] jakarta-regexp.jar
on 7/20/01 1:29 AM, GOMEZ Henri [EMAIL PROTECTED] wrote: Why could still use symlink as I do in my RPM :) ln -s jakarta-regexp-1.2.jar jakarta-regexp.jar Doesn't work on winblows. -jon
Re: [TC4] jakarta-regexp.jar
On Fri, 20 Jul 2001, Jon Stevens wrote: The next logical step is to use Geir's JJAR (look in the jakarta-commons-sandbox) to automatically download the right .jar files for you. Actually, Jon's suggestion is the right answer. Craig McClanahan I'm going to print that quote (taken entirely out of context) out and frame it next to my JSP Sucks article. :-) http://jakarta.apache.org/~jon/jdj_julycover.jpg -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: [TC4] jakarta-regexp.jar
On Fri, 20 Jul 2001, Jon Stevens wrote: on 7/19/01 10:58 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that have been discussed at length on this and other lists in the past. Storing JAR files is evil, because it creates dependencies on those particular versions of the JAR files and you cannot reliably recreate a release purely from sources. In the case of Catalina, I'm against it since you have setup a system of defining things in the build.properties file and requiring people to already download a ton of other stuff anyway. The next logical step is to use Geir's JJAR (look in the jakarta-commons-sandbox) to automatically download the right .jar files for you. Yep. Actually, Jon's suggestion is the right answer. Craig McClanahan I'm going to print that quote (taken entirely out of context) out and frame it next to my JSP Sucks article. :-) http://jakarta.apache.org/~jon/jdj_julycover.jpg That's why I even autographed it for you :-) -jon Craig
Re: [TC4] jakarta-regexp.jar
on 7/19/01 7:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
P.S. I'd like to propose that jakarta-regexp project name all their
jars jakarta-regexp.jar no matter what version they are. This doesn't
affect the decision here.
-1
Until we have a CJAN, I like version numbers on jar files.
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
-jon
Re: [TC4] jakarta-regexp.jar
On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote:
Do you have a position on including a jakarta-regexp.jar (or a
jakarta-regexp-1.2.jar or a jakarta-regexp-1.3-dev.jar) directly in
jakarta-tomcat-4.0/lib so we can build it without synching and
building jakarta-regexp?
I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that
have been discussed at length on this and other lists in the past.
Storing JAR files is evil, because it creates dependencies on those
particular versions of the JAR files and you cannot reliably recreate a
release purely from sources.
Once I get the beta 6 release out (the release notes will tell you how
busy we've been :-), I will focus on cleaning up the build processes and
docs for jakarta-tomcat-4.0 and jakarta-servletapi-4, and initiating
conversations about what to do with jakarta-tomcat-connectors code that is
included in a Tomcat release.
Likewise for servlet.jar / jakarta-servletapi-4.
Note that the project already contains an ant.jar and a jaxp.jar and
crimson.jar, and that works just fine :-)
Tomcat 4 doesn't have an ant.jar. And the only reason it has jaxp.jar and
crimson.jar is because the stupid actual release has sealed JARs, which
*totally* screws up class loading. As soon as there's a JAXP release that
removes this restriction, these files are gone.
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
Yeah, mine and everyone else's in the world who wants to build it.
One less step is one less step that can go wrong.
Actually, Jon's suggestion is the right answer. Developers working from
source should have *absolute* control over which versions of dependent
software they build with.
--
Alex Chaffee mailto:[EMAIL PROTECTED]
Craig McClanahan
Re: [TC4] jakarta-regexp.jar
On Thu, Jul 19, 2001 at 10:58:21PM -0700, Craig R. McClanahan wrote:
On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote:
Do you have a position on including a jakarta-regexp.jar (or a
jakarta-regexp-1.2.jar or a jakarta-regexp-1.3-dev.jar) directly in
jakarta-tomcat-4.0/lib so we can build it without synching and
building jakarta-regexp?
I'm positive Jon will be +1 for this :-), but I'm very -1 for reasons that
have been discussed at length on this and other lists in the past.
Storing JAR files is evil, because it creates dependencies on those
particular versions of the JAR files and you cannot reliably recreate a
release purely from sources.
The dependencies are already there, and always will be. The only
difference is that at present, the actual jars can slip out from under
you at any time (which actually just happened to me -- while you
weren't looking, jakarta-regexp changed the name of their jar file
which broke your build).
As for building from pure source, that argument is a lot less
compelling when your object code is platform-independent Java. Sure,
it made sense not to depend on statically linked OS-specific object
code, but I can't think of a good reason not to depend on a JAR. It's
no worse than depending on a GIF.
Likewise for servlet.jar / jakarta-servletapi-4.
Note that the project already contains an ant.jar and a jaxp.jar and
crimson.jar, and that works just fine :-)
Tomcat 4 doesn't have an ant.jar.
My mistake.
And the only reason it has jaxp.jar and
crimson.jar is because the stupid actual release has sealed JARs, which
*totally* screws up class loading. As soon as there's a JAXP release that
removes this restriction, these files are gone.
And as soon as someone screws up JAXP again, it'll break again, and
require a bugfix release of the *source* of Catalina just to allow it
to build.
Or what about the developer who's installed an incompatible JAXP
wasting his time and the list's bandwidth when it could have been
averted by shipping the version of JAXP on which Catalina is
dependent... (That's until JAXP is core and stable and works, none
of which are actually true yet, AFAIK.)
The problem you are having can be easily resolved by simply editing your
local jakarta-turbine-4.0/build.properties or your
${user.home}/build.properties
Yeah, mine and everyone else's in the world who wants to build it.
One less step is one less step that can go wrong.
Actually, Jon's suggestion is the right answer. Developers working from
source should have *absolute* control over which versions of dependent
software they build with.
My solution doesn't prevent you from overriding the checked-in version
with one of your own. I was thinking more that out of the box, it
would work, but that if you have your own jar you can edit
build.properties and retain *absolute* control. But until you need to
do that, there's less to set up before running build. That is...
One less step is one less step that can go wrong.
:-)
--
Alex Chaffee mailto:[EMAIL PROTECTED]
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
