You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Tim Dawson <td...@is.com> on 2001/03/06 10:00:26 UTC
RE: [PATCH] building too hard!
I agree 100% -- #3 is a GREAT approach. Relying on the classpath is quite
dangerous, and the defaults specified are probably very infrequently used.
We should also probably movfe to ANT 1.3 now that it is released, so that we
can make use of its ability to get environment variables directly out of the
environment, and then we can do away with the build.sh and build.bat files
-- and use ANT directly!
-- Tim
-----Original Message-----
From: Pierre Delisle [mailto:pierre.delisle@sun.com]
Sent: Tuesday, February 27, 2001 6:32 PM
To: taglibs-user@jakarta.apache.org; taglibs-dev@jakarta.apache.org;
jeff@socialchange.net.au
Subject: Re: [PATCH] building too hard!
Jeff,
Totally agree with you regarding the complexity of the build process
of jakarta-taglibs. Thanks for documenting what you went through
to make the community aware of the current flaws.
Here is my .02 on how I believe we could fix the issues
you raised in a clean and consistent way.
Comments please...
-- Pierre
----
I think that the major issue in the current build process
is that we have three different types of assumptions regarding
how 'required' jar files are accessed so that the build
process can be successfull:
1) Library already in the developer's classpath
This is the current assumption for a JAXP compliant parser.
2) Environment variable can *optionally* be set to access the
jar file. If it is not set, a default value is used which assumes
that the 'taglibs' build directory structure includes this
other apache project.
This is the current assumption for:
ANT_HOME ../jakarta-ant
BSF_JAR ../xml-xalan/bsf.jar
BSFENGINES_JAR ../xml-xalan/bsfengines.jar
SERVLET_JAR ../jakarta-servletapi/lib/servlet.jar
XALAN_JAR ../xml-xalan/xalan.jar
XERCES_JAR ./.xml-xalan/xerces.jar
3) Environment variable *must* be set to access the library.
This is the case for JAVA_HOME to get access to tools.jar.
Please note that execution of ant is done using 'java' (and
not $JAVA_HOME/bin/java).
To make it much easier for "off the shelf" builds to succeed
for everyone (whithout event having to read the README),
I would personally like to see us enforce access
to 'core' jar files with 3).
I.e. environment variables must be set to access the 'core' jar files.
[No assumptions on the developer's classpath (*not* 1), as well as
no assumptions on a build directory structure (*not 2)].
If the env variable associated with a required jar file is not
specified, then the build stops with an explicit error message
telling the user how to get access to the 'missing' project.
For example:
ERROR: You must set ANT_HOME to point at your 'ant' installation
directory.
The library $ANT_HOME/dist/ant.jar will be added to the classpath
of the build process. You may download a binary distribution of
'ant' at the following url: ..."
With respect to 'non-core' jar files, i.e. jar files that are only required
for specific taglibs, I'd suggest a warning message telling the developer
that specific taglibraries won't be built because the specific environment
variable is not set. For example:
WARNING: Tag libraries 'x', 'y', and 'z' require access to the
'REGEXP' installation directory. Since environment variable
'REGEXP_HOME' is not specified, these tag-libararies will not
be built. You may download a binary distribution of
'regexp' at the following url: ..."
This would allow us to have a clean "self-documented" build process.
Comments?
RE: [SUBMIT/PRESUBMIT] calendar taglib
Posted by Christoph Wilhelms <Ch...@t-online.de>.
I forgot: The taglib is tested with Tomcat 3.2.1 and Mozilla 0.8 and MS IE
5.5 under Win2k - should run in Netscape/MS Browser 4.0+!
Another feature:
* the view of the picker-window is customizable via .css!
Ok, all for now! ;-)
Gheers,
Chris
[SUBMIT/PRESUBMIT] calendar taglib
Posted by Christoph Wilhelms <Ch...@t-online.de>.
Hi!
I am contirbuting on Ant for about half a year now, but I am new to
jakarta-taglibs, so HELLO taglib-dev :-)!
I have attached my first functional, own taglib! It is something between the
"datetime" and the "input" taglib. I did not really know where to put, and
so I initially created an own package "calendar".
To show what it is like, I have atached a little jpg. It frovides a little
button or link besides an input-field. If jou click the link a little frame
pops up displaying a calendar showing the month/year of the day entered in
the input-filed. Now you can select a new date by selecting month and year
and clicking on a day. The calendar is fully dynamic (javaScript :-(...).
This calendar provides some funktionallity now:
* Pick a date comfortable
* I18n support (some manual work is todo)
* dynamic javaScript
* "simple" JavaScript date-parser
* externalized Strings
* parsing can be done by "datetime"
Ok! I would be very happy if anyone can take a look at it (it is just a
pre-submit by now) and tell me what I have to do to get a "commit" on this
little taglib - at least if you want it to become part of "taglibs" :-?!
Some things I can do in the meantime:
* Html-Manual of the tags.
* Ant-Build XML
I have some problems to compile the taglibs-project using ant. Can you tell
me wich API jars in wich versions I should use!?! Aditionally I am interesed
which IDE's you are using. I am unsing IBM VAJava for fat-client apps and
for jakarta projects I am using netbeans.
Ok, finally I have to say that this was A LOT OF work! I hope you REALLY
like it ;-)
Greetings,
Chris
Re: [PATCH] building too hard!
Posted by Pierre Delisle <pi...@sun.com>.
Jeff Turner wrote:
> How about using the preset CLASSPATH as a fallback, to be relied on only after
> printing a dire warning? Eg, one could have the following system (taking Ant as
> an example):
>
> if $ANT_JAR set && `$ANT_JAR` exists:
> use it
> elseif $ANT_HOME set && `$ANT_HOME/lib/ant.jar` exists:
> use $ANT_HOME/lib/ant.jar
> else:
> print dire warning
> if sensible default (../jakarta-ant/lib/ant.jar) exists:
> append it to user-specified classpath
> else:
> print even direr warning
> use user-specified classpath and hope they included ant.jar
>
> This makes clear to the user that setting an env variable is preferable, but
> doesn't *force* them to. In truth, this involves just 3 additions to the
> current system:
I see your point that some developers might be annoyed with having to set
these env variables. However I bet the majority of them would
eventually set these environment variables just to get rid of the
*even direr warning* that would show up everytime they build :-)
> 1) Introduces a new variable, $<package>_JAR (eg $ANT_JAR). Why bother? Because
> notice that how we get from the more general $<project>_HOME to the jar is
> hardcoded ("/lib/"), and therefore possibly wrong (eg, between source and binary
> distros).
>
> 2) Prints a warning each time an expectation is violated.
>
> 3) Checks whether jars exist before using them (using "exists" keyword for
> .bat, and "-e" test in .sh)
>
> Does this seem sensible?
Definitely.
> Anyway, I'll modify build.(sh|bat) again to reflect the above scheme, and post
> here so people can review the real thing.
>
> > We should also probably movfe to ANT 1.3 now that it is released, so that we
> > can make use of its ability to get environment variables directly out of the
> > environment, and then we can do away with the build.sh and build.bat files
> > -- and use ANT directly!
>
> No build scripts would be *very* cool :)
++1.
And from the latest posting from Tim, it looks like this is doable.
Tim Dawson wrote:
> I'd be happy to do the revisions to the build.xml files, but
> I'll have to mail it to someone with checkin capability. I'd probably update
> one and send it out to see if people agreed with the direction.
This would be awesome. I'll be happy to review (as many others I'm sure).
Please post to the list.
> how hard would it be on the community to do the upgrade? everybody would
> have to upgrade or they woudln't be able to build.
We could coordinate this as follows:
- Agree on a new build standard (following discussions on build.xml
to be submitted by Tim)
- Assign a coordinator for the new build procedure
(if Tim is interested, we could vote him as a committer. If no one
else volunteers, I could do it)
- have each taglib owner update their build.xml locally
(coordinator and other committers could pickup the ones that won't
be done by their owners)
- have all build.xml sent to the coordinator by a specific date
- coordinator tests the full build procedure and makes required changes
- coordinator commits to the tree.
[Or if coordinator does not mind, he could handle all modifications to the
taglibs himself]
Looking forward to the new build.xml!
-- Pierre
Re: [PATCH] building too hard!
Posted by Pierre Delisle <pi...@sun.com>.
Jeff Turner wrote:
> How about using the preset CLASSPATH as a fallback, to be relied on only after
> printing a dire warning? Eg, one could have the following system (taking Ant as
> an example):
>
> if $ANT_JAR set && `$ANT_JAR` exists:
> use it
> elseif $ANT_HOME set && `$ANT_HOME/lib/ant.jar` exists:
> use $ANT_HOME/lib/ant.jar
> else:
> print dire warning
> if sensible default (../jakarta-ant/lib/ant.jar) exists:
> append it to user-specified classpath
> else:
> print even direr warning
> use user-specified classpath and hope they included ant.jar
>
> This makes clear to the user that setting an env variable is preferable, but
> doesn't *force* them to. In truth, this involves just 3 additions to the
> current system:
I see your point that some developers might be annoyed with having to set
these env variables. However I bet the majority of them would
eventually set these environment variables just to get rid of the
*even direr warning* that would show up everytime they build :-)
> 1) Introduces a new variable, $<package>_JAR (eg $ANT_JAR). Why bother? Because
> notice that how we get from the more general $<project>_HOME to the jar is
> hardcoded ("/lib/"), and therefore possibly wrong (eg, between source and binary
> distros).
>
> 2) Prints a warning each time an expectation is violated.
>
> 3) Checks whether jars exist before using them (using "exists" keyword for
> .bat, and "-e" test in .sh)
>
> Does this seem sensible?
Definitely.
> Anyway, I'll modify build.(sh|bat) again to reflect the above scheme, and post
> here so people can review the real thing.
>
> > We should also probably movfe to ANT 1.3 now that it is released, so that we
> > can make use of its ability to get environment variables directly out of the
> > environment, and then we can do away with the build.sh and build.bat files
> > -- and use ANT directly!
>
> No build scripts would be *very* cool :)
++1.
And from the latest posting from Tim, it looks like this is doable.
Tim Dawson wrote:
> I'd be happy to do the revisions to the build.xml files, but
> I'll have to mail it to someone with checkin capability. I'd probably update
> one and send it out to see if people agreed with the direction.
This would be awesome. I'll be happy to review (as many others I'm sure).
Please post to the list.
> how hard would it be on the community to do the upgrade? everybody would
> have to upgrade or they woudln't be able to build.
We could coordinate this as follows:
- Agree on a new build standard (following discussions on build.xml
to be submitted by Tim)
- Assign a coordinator for the new build procedure
(if Tim is interested, we could vote him as a committer. If no one
else volunteers, I could do it)
- have each taglib owner update their build.xml locally
(coordinator and other committers could pickup the ones that won't
be done by their owners)
- have all build.xml sent to the coordinator by a specific date
- coordinator tests the full build procedure and makes required changes
- coordinator commits to the tree.
[Or if coordinator does not mind, he could handle all modifications to the
taglibs himself]
Looking forward to the new build.xml!
-- Pierre
Re: [PATCH] building too hard!
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Mar 06, 2001 at 03:00:26AM -0600, Tim Dawson wrote:
> I agree 100% -- #3 is a GREAT approach. Relying on the classpath is quite
> dangerous, and the defaults specified are probably very infrequently used.
Well.. please don't get me wrong, I hate classpaths as much as the next
battle-scarred programmer, but I suspect that *forcing* people to set env
variables would annoy some.
For instance, jakarta-taglib's external dependencies are:
1) Ant
2) JAXP
3) JAXP-compliant parser (xerces)
4) Xalan (for the <style> elements).
I would tentatively suggest that many developers have 1, 2 and 3 permanently
set in a global classpath, because Ant and JAXP (and hence Xerces) are validly
"cross-project" jars. Having to set 3 extra env variables is just going to
annoy these people. It only takes one -1 vote to kill a proposal ;)
How about using the preset CLASSPATH as a fallback, to be relied on only after
printing a dire warning? Eg, one could have the following system (taking Ant as
an example):
if $ANT_JAR set && `$ANT_JAR` exists:
use it
elseif $ANT_HOME set && `$ANT_HOME/lib/ant.jar` exists:
use $ANT_HOME/lib/ant.jar
else:
print dire warning
if sensible default (../jakarta-ant/lib/ant.jar) exists:
append it to user-specified classpath
else:
print even direr warning
use user-specified classpath and hope they included ant.jar
This makes clear to the user that setting an env variable is preferable, but
doesn't *force* them to. In truth, this involves just 3 additions to the
current system:
1) Introduces a new variable, $<package>_JAR (eg $ANT_JAR). Why bother? Because
notice that how we get from the more general $<project>_HOME to the jar is
hardcoded ("/lib/"), and therefore possibly wrong (eg, between source and binary
distros).
2) Prints a warning each time an expectation is violated.
3) Checks whether jars exist before using them (using "exists" keyword for
.bat, and "-e" test in .sh)
Does this seem sensible?
Anyway, I'll modify build.(sh|bat) again to reflect the above scheme, and post
here so people can review the real thing.
> We should also probably movfe to ANT 1.3 now that it is released, so that we
> can make use of its ability to get environment variables directly out of the
> environment, and then we can do away with the build.sh and build.bat files
> -- and use ANT directly!
No build scripts would be *very* cool :)
--Jeff
PS: Btw, Pierre, I replied with great enthusiasm to your original reply, but mail
server problems prevented it (and a repost) getting to the list :/ So..
<insert enthusiasm and intense agreement here> :)
also,
<insert grandiose visions of a unified jakarta build procedure here> ;)
> -- Tim
>
>
> -----Original Message-----
> From: Pierre Delisle [mailto:pierre.delisle@sun.com]
> Sent: Tuesday, February 27, 2001 6:32 PM
> To: taglibs-user@jakarta.apache.org; taglibs-dev@jakarta.apache.org;
> jeff@socialchange.net.au
> Subject: Re: [PATCH] building too hard!
>
>
> Jeff,
>
> Totally agree with you regarding the complexity of the build process
> of jakarta-taglibs. Thanks for documenting what you went through
> to make the community aware of the current flaws.
>
> Here is my .02 on how I believe we could fix the issues
> you raised in a clean and consistent way.
>
> Comments please...
>
> -- Pierre
>
> ----
> I think that the major issue in the current build process
> is that we have three different types of assumptions regarding
> how 'required' jar files are accessed so that the build
> process can be successfull:
>
> 1) Library already in the developer's classpath
>
> This is the current assumption for a JAXP compliant parser.
>
> 2) Environment variable can *optionally* be set to access the
> jar file. If it is not set, a default value is used which assumes
> that the 'taglibs' build directory structure includes this
> other apache project.
>
> This is the current assumption for:
>
> ANT_HOME ../jakarta-ant
> BSF_JAR ../xml-xalan/bsf.jar
> BSFENGINES_JAR ../xml-xalan/bsfengines.jar
> SERVLET_JAR ../jakarta-servletapi/lib/servlet.jar
> XALAN_JAR ../xml-xalan/xalan.jar
> XERCES_JAR ./.xml-xalan/xerces.jar
>
> 3) Environment variable *must* be set to access the library.
>
> This is the case for JAVA_HOME to get access to tools.jar.
>
> Please note that execution of ant is done using 'java' (and
> not $JAVA_HOME/bin/java).
>
>
> To make it much easier for "off the shelf" builds to succeed
> for everyone (whithout event having to read the README),
> I would personally like to see us enforce access
> to 'core' jar files with 3).
>
> I.e. environment variables must be set to access the 'core' jar files.
> [No assumptions on the developer's classpath (*not* 1), as well as
> no assumptions on a build directory structure (*not 2)].
>
> If the env variable associated with a required jar file is not
> specified, then the build stops with an explicit error message
> telling the user how to get access to the 'missing' project.
> For example:
>
> ERROR: You must set ANT_HOME to point at your 'ant' installation
> directory.
> The library $ANT_HOME/dist/ant.jar will be added to the classpath
> of the build process. You may download a binary distribution of
> 'ant' at the following url: ..."
>
> With respect to 'non-core' jar files, i.e. jar files that are only required
> for specific taglibs, I'd suggest a warning message telling the developer
> that specific taglibraries won't be built because the specific environment
> variable is not set. For example:
>
> WARNING: Tag libraries 'x', 'y', and 'z' require access to the
> 'REGEXP' installation directory. Since environment variable
> 'REGEXP_HOME' is not specified, these tag-libararies will not
> be built. You may download a binary distribution of
> 'regexp' at the following url: ..."
>
> This would allow us to have a clean "self-documented" build process.
> Comments?
--
Re: [PATCH] building too hard!
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Mar 06, 2001 at 03:00:26AM -0600, Tim Dawson wrote:
> I agree 100% -- #3 is a GREAT approach. Relying on the classpath is quite
> dangerous, and the defaults specified are probably very infrequently used.
Well.. please don't get me wrong, I hate classpaths as much as the next
battle-scarred programmer, but I suspect that *forcing* people to set env
variables would annoy some.
For instance, jakarta-taglib's external dependencies are:
1) Ant
2) JAXP
3) JAXP-compliant parser (xerces)
4) Xalan (for the <style> elements).
I would tentatively suggest that many developers have 1, 2 and 3 permanently
set in a global classpath, because Ant and JAXP (and hence Xerces) are validly
"cross-project" jars. Having to set 3 extra env variables is just going to
annoy these people. It only takes one -1 vote to kill a proposal ;)
How about using the preset CLASSPATH as a fallback, to be relied on only after
printing a dire warning? Eg, one could have the following system (taking Ant as
an example):
if $ANT_JAR set && `$ANT_JAR` exists:
use it
elseif $ANT_HOME set && `$ANT_HOME/lib/ant.jar` exists:
use $ANT_HOME/lib/ant.jar
else:
print dire warning
if sensible default (../jakarta-ant/lib/ant.jar) exists:
append it to user-specified classpath
else:
print even direr warning
use user-specified classpath and hope they included ant.jar
This makes clear to the user that setting an env variable is preferable, but
doesn't *force* them to. In truth, this involves just 3 additions to the
current system:
1) Introduces a new variable, $<package>_JAR (eg $ANT_JAR). Why bother? Because
notice that how we get from the more general $<project>_HOME to the jar is
hardcoded ("/lib/"), and therefore possibly wrong (eg, between source and binary
distros).
2) Prints a warning each time an expectation is violated.
3) Checks whether jars exist before using them (using "exists" keyword for
.bat, and "-e" test in .sh)
Does this seem sensible?
Anyway, I'll modify build.(sh|bat) again to reflect the above scheme, and post
here so people can review the real thing.
> We should also probably movfe to ANT 1.3 now that it is released, so that we
> can make use of its ability to get environment variables directly out of the
> environment, and then we can do away with the build.sh and build.bat files
> -- and use ANT directly!
No build scripts would be *very* cool :)
--Jeff
PS: Btw, Pierre, I replied with great enthusiasm to your original reply, but mail
server problems prevented it (and a repost) getting to the list :/ So..
<insert enthusiasm and intense agreement here> :)
also,
<insert grandiose visions of a unified jakarta build procedure here> ;)
> -- Tim
>
>
> -----Original Message-----
> From: Pierre Delisle [mailto:pierre.delisle@sun.com]
> Sent: Tuesday, February 27, 2001 6:32 PM
> To: taglibs-user@jakarta.apache.org; taglibs-dev@jakarta.apache.org;
> jeff@socialchange.net.au
> Subject: Re: [PATCH] building too hard!
>
>
> Jeff,
>
> Totally agree with you regarding the complexity of the build process
> of jakarta-taglibs. Thanks for documenting what you went through
> to make the community aware of the current flaws.
>
> Here is my .02 on how I believe we could fix the issues
> you raised in a clean and consistent way.
>
> Comments please...
>
> -- Pierre
>
> ----
> I think that the major issue in the current build process
> is that we have three different types of assumptions regarding
> how 'required' jar files are accessed so that the build
> process can be successfull:
>
> 1) Library already in the developer's classpath
>
> This is the current assumption for a JAXP compliant parser.
>
> 2) Environment variable can *optionally* be set to access the
> jar file. If it is not set, a default value is used which assumes
> that the 'taglibs' build directory structure includes this
> other apache project.
>
> This is the current assumption for:
>
> ANT_HOME ../jakarta-ant
> BSF_JAR ../xml-xalan/bsf.jar
> BSFENGINES_JAR ../xml-xalan/bsfengines.jar
> SERVLET_JAR ../jakarta-servletapi/lib/servlet.jar
> XALAN_JAR ../xml-xalan/xalan.jar
> XERCES_JAR ./.xml-xalan/xerces.jar
>
> 3) Environment variable *must* be set to access the library.
>
> This is the case for JAVA_HOME to get access to tools.jar.
>
> Please note that execution of ant is done using 'java' (and
> not $JAVA_HOME/bin/java).
>
>
> To make it much easier for "off the shelf" builds to succeed
> for everyone (whithout event having to read the README),
> I would personally like to see us enforce access
> to 'core' jar files with 3).
>
> I.e. environment variables must be set to access the 'core' jar files.
> [No assumptions on the developer's classpath (*not* 1), as well as
> no assumptions on a build directory structure (*not 2)].
>
> If the env variable associated with a required jar file is not
> specified, then the build stops with an explicit error message
> telling the user how to get access to the 'missing' project.
> For example:
>
> ERROR: You must set ANT_HOME to point at your 'ant' installation
> directory.
> The library $ANT_HOME/dist/ant.jar will be added to the classpath
> of the build process. You may download a binary distribution of
> 'ant' at the following url: ..."
>
> With respect to 'non-core' jar files, i.e. jar files that are only required
> for specific taglibs, I'd suggest a warning message telling the developer
> that specific taglibraries won't be built because the specific environment
> variable is not set. For example:
>
> WARNING: Tag libraries 'x', 'y', and 'z' require access to the
> 'REGEXP' installation directory. Since environment variable
> 'REGEXP_HOME' is not specified, these tag-libararies will not
> be built. You may download a binary distribution of
> 'regexp' at the following url: ..."
>
> This would allow us to have a clean "self-documented" build process.
> Comments?
--