You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2006/11/20 03:43:02 UTC
[jira] Created: (LUCENE-718) possible build.xml addition to ensure
1.4 class compatibility
possible build.xml addition to ensure 1.4 class compatibility
-------------------------------------------------------------
Key: LUCENE-718
URL: http://issues.apache.org/jira/browse/LUCENE-718
Project: Lucene - Java
Issue Type: Improvement
Components: Other
Reporter: Hoss Man
As encountered recently, setting the "source" and "target" values for the java compiler don't acctually test that the classes/methods are 1.4 compatible -- just that the language syntax/features are...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6333296
...i've come up with one possible solution, that's really feels like a hack, but i wanted to throw it out here for comment, in a nutshell:
1) we support a new optional javac.bootclasspath property indicating with path the
compiler should use.
2) people compiling with 1.4 can ignore that property
3) anyone who has a 1.5 compiler by default, can set this proprety to point at a 1.4 copy
of the rt.jar -- which is not inlcuded (users would need to install it themselves)
4) as part of the "init" target the build file will attempt to compile a java class that is
syntactically correct in java 1.4, but utilizes a method only available in 1.5 ... if this
class compiles cleanly, the task will fail.
5) java 1.5 users that aren't concerned about submitting compatible patches back to
the comunity and don't want to hassle with a 1.4 version of rt.jar, can set
a"javac.trustbootclasspath" and go about their merry way.
The main idea here being that if someone has both JVMs installed and accidently uses the wrong one to test something before submitting a patch or committing, their build will either fail with a helpful message, or compile against the correct set of core classes anyway if they've done a small amount of setup.
Caveats to commiting this:
a) it's a hack, so i don't wnat to commit unless multiple people like it
b) at the moment, all "successful" ant executions print a confusing compiler error as right
off the bat, it would be better if we could supress that somehow.
c) the BUILD.txt should be updated accordingly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-718) possible build.xml addition to
ensure 1.4 class compatibility
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463124 ]
Hoss Man commented on LUCENE-718:
---------------------------------
i recently realized that <antcall> let's you specify the level of messages to be logged - so it might be possible to supress the "good" compile errors that way ... before i had a chance to test that, i realized a far easier way to check the classpath would be to use the <available> task to loook for a class added in java1.5 that wasn't in java1.4 ... no kludgy compilation of bogus code.
the one other big hurdle i just realized, is that as it stands the patch prevents the gdata-server from compiling ... before something like this could be commited, we'd need a way for contribs which want to use 1.5 to access the *real* bootclasspath when compiling so that people using a 1.5 JVM can specify a 1.4 rt.jar for use when compiling things by default, but can still compile 1.5 contribs cleanly.
most likely this could be done by adding some more optional params to the compile macro, and change the gdata build.xml files to pass non-default values to tose params ... but i don't really have time to play with that at the moment ... i'll go ahead and post an updated patch so people can give feedback if they are interested.
> possible build.xml addition to ensure 1.4 class compatibility
> -------------------------------------------------------------
>
> Key: LUCENE-718
> URL: https://issues.apache.org/jira/browse/LUCENE-718
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Reporter: Hoss Man
> Attachments: check.bootclasspath.patch, check.bootclasspath.patch
>
>
> As encountered recently, setting the "source" and "target" values for the java compiler don't acctually test that the classes/methods are 1.4 compatible -- just that the language syntax/features are...
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6333296
> ...i've come up with one possible solution, that's really feels like a hack, but i wanted to throw it out here for comment, in a nutshell:
> 1) we support a new optional javac.bootclasspath property indicating with path the
> compiler should use.
> 2) people compiling with 1.4 can ignore that property
> 3) anyone who has a 1.5 compiler by default, can set this proprety to point at a 1.4 copy
> of the rt.jar -- which is not inlcuded (users would need to install it themselves)
> 4) as part of the "init" target the build file will attempt to compile a java class that is
> syntactically correct in java 1.4, but utilizes a method only available in 1.5 ... if this
> class compiles cleanly, the task will fail.
> 5) java 1.5 users that aren't concerned about submitting compatible patches back to
> the comunity and don't want to hassle with a 1.4 version of rt.jar, can set
> a"javac.trustbootclasspath" and go about their merry way.
> The main idea here being that if someone has both JVMs installed and accidently uses the wrong one to test something before submitting a patch or committing, their build will either fail with a helpful message, or compile against the correct set of core classes anyway if they've done a small amount of setup.
> Caveats to commiting this:
> a) it's a hack, so i don't wnat to commit unless multiple people like it
> b) at the moment, all "successful" ant executions print a confusing compiler error as right
> off the bat, it would be better if we could supress that somehow.
> c) the BUILD.txt should be updated accordingly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-718) possible build.xml addition to ensure
1.4 class compatibility
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated LUCENE-718:
----------------------------
Attachment: check.bootclasspath.patch
> possible build.xml addition to ensure 1.4 class compatibility
> -------------------------------------------------------------
>
> Key: LUCENE-718
> URL: https://issues.apache.org/jira/browse/LUCENE-718
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Reporter: Hoss Man
> Attachments: check.bootclasspath.patch, check.bootclasspath.patch
>
>
> As encountered recently, setting the "source" and "target" values for the java compiler don't acctually test that the classes/methods are 1.4 compatible -- just that the language syntax/features are...
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6333296
> ...i've come up with one possible solution, that's really feels like a hack, but i wanted to throw it out here for comment, in a nutshell:
> 1) we support a new optional javac.bootclasspath property indicating with path the
> compiler should use.
> 2) people compiling with 1.4 can ignore that property
> 3) anyone who has a 1.5 compiler by default, can set this proprety to point at a 1.4 copy
> of the rt.jar -- which is not inlcuded (users would need to install it themselves)
> 4) as part of the "init" target the build file will attempt to compile a java class that is
> syntactically correct in java 1.4, but utilizes a method only available in 1.5 ... if this
> class compiles cleanly, the task will fail.
> 5) java 1.5 users that aren't concerned about submitting compatible patches back to
> the comunity and don't want to hassle with a 1.4 version of rt.jar, can set
> a"javac.trustbootclasspath" and go about their merry way.
> The main idea here being that if someone has both JVMs installed and accidently uses the wrong one to test something before submitting a patch or committing, their build will either fail with a helpful message, or compile against the correct set of core classes anyway if they've done a small amount of setup.
> Caveats to commiting this:
> a) it's a hack, so i don't wnat to commit unless multiple people like it
> b) at the moment, all "successful" ant executions print a confusing compiler error as right
> off the bat, it would be better if we could supress that somehow.
> c) the BUILD.txt should be updated accordingly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Resolved: (LUCENE-718) possible build.xml addition to ensure
1.4 class compatibility
Posted by "Michael Busch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Busch resolved LUCENE-718.
----------------------------------
Resolution: Won't Fix
Lucene 3.0 and JDK 1.5 are coming soon!
> possible build.xml addition to ensure 1.4 class compatibility
> -------------------------------------------------------------
>
> Key: LUCENE-718
> URL: https://issues.apache.org/jira/browse/LUCENE-718
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Reporter: Hoss Man
> Attachments: check.bootclasspath.patch, check.bootclasspath.patch
>
>
> As encountered recently, setting the "source" and "target" values for the java compiler don't acctually test that the classes/methods are 1.4 compatible -- just that the language syntax/features are...
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6333296
> ...i've come up with one possible solution, that's really feels like a hack, but i wanted to throw it out here for comment, in a nutshell:
> 1) we support a new optional javac.bootclasspath property indicating with path the
> compiler should use.
> 2) people compiling with 1.4 can ignore that property
> 3) anyone who has a 1.5 compiler by default, can set this proprety to point at a 1.4 copy
> of the rt.jar -- which is not inlcuded (users would need to install it themselves)
> 4) as part of the "init" target the build file will attempt to compile a java class that is
> syntactically correct in java 1.4, but utilizes a method only available in 1.5 ... if this
> class compiles cleanly, the task will fail.
> 5) java 1.5 users that aren't concerned about submitting compatible patches back to
> the comunity and don't want to hassle with a 1.4 version of rt.jar, can set
> a"javac.trustbootclasspath" and go about their merry way.
> The main idea here being that if someone has both JVMs installed and accidently uses the wrong one to test something before submitting a patch or committing, their build will either fail with a helpful message, or compile against the correct set of core classes anyway if they've done a small amount of setup.
> Caveats to commiting this:
> a) it's a hack, so i don't wnat to commit unless multiple people like it
> b) at the moment, all "successful" ant executions print a confusing compiler error as right
> off the bat, it would be better if we could supress that somehow.
> c) the BUILD.txt should be updated accordingly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-718) possible build.xml addition to
ensure 1.4 class compatibility
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744901#action_12744901 ]
Hoss Man commented on LUCENE-718:
---------------------------------
you realize we're going to have this same problem with 1.6 right?
> possible build.xml addition to ensure 1.4 class compatibility
> -------------------------------------------------------------
>
> Key: LUCENE-718
> URL: https://issues.apache.org/jira/browse/LUCENE-718
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Reporter: Hoss Man
> Attachments: check.bootclasspath.patch, check.bootclasspath.patch
>
>
> As encountered recently, setting the "source" and "target" values for the java compiler don't acctually test that the classes/methods are 1.4 compatible -- just that the language syntax/features are...
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6333296
> ...i've come up with one possible solution, that's really feels like a hack, but i wanted to throw it out here for comment, in a nutshell:
> 1) we support a new optional javac.bootclasspath property indicating with path the
> compiler should use.
> 2) people compiling with 1.4 can ignore that property
> 3) anyone who has a 1.5 compiler by default, can set this proprety to point at a 1.4 copy
> of the rt.jar -- which is not inlcuded (users would need to install it themselves)
> 4) as part of the "init" target the build file will attempt to compile a java class that is
> syntactically correct in java 1.4, but utilizes a method only available in 1.5 ... if this
> class compiles cleanly, the task will fail.
> 5) java 1.5 users that aren't concerned about submitting compatible patches back to
> the comunity and don't want to hassle with a 1.4 version of rt.jar, can set
> a"javac.trustbootclasspath" and go about their merry way.
> The main idea here being that if someone has both JVMs installed and accidently uses the wrong one to test something before submitting a patch or committing, their build will either fail with a helpful message, or compile against the correct set of core classes anyway if they've done a small amount of setup.
> Caveats to commiting this:
> a) it's a hack, so i don't wnat to commit unless multiple people like it
> b) at the moment, all "successful" ant executions print a confusing compiler error as right
> off the bat, it would be better if we could supress that somehow.
> c) the BUILD.txt should be updated accordingly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-718) possible build.xml addition to
ensure 1.4 class compatibility
Posted by "Michael Busch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744903#action_12744903 ]
Michael Busch commented on LUCENE-718:
--------------------------------------
Yeah, but I thought nobody worked on this for 18 months, and it doesn't seem to be a big problem. But of course feel free to reopen!
We have >250 unscheduled issues in JIRA, I wanted to start cleaning up a bit as we're almost in the code freeze phase now...
> possible build.xml addition to ensure 1.4 class compatibility
> -------------------------------------------------------------
>
> Key: LUCENE-718
> URL: https://issues.apache.org/jira/browse/LUCENE-718
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Reporter: Hoss Man
> Attachments: check.bootclasspath.patch, check.bootclasspath.patch
>
>
> As encountered recently, setting the "source" and "target" values for the java compiler don't acctually test that the classes/methods are 1.4 compatible -- just that the language syntax/features are...
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6333296
> ...i've come up with one possible solution, that's really feels like a hack, but i wanted to throw it out here for comment, in a nutshell:
> 1) we support a new optional javac.bootclasspath property indicating with path the
> compiler should use.
> 2) people compiling with 1.4 can ignore that property
> 3) anyone who has a 1.5 compiler by default, can set this proprety to point at a 1.4 copy
> of the rt.jar -- which is not inlcuded (users would need to install it themselves)
> 4) as part of the "init" target the build file will attempt to compile a java class that is
> syntactically correct in java 1.4, but utilizes a method only available in 1.5 ... if this
> class compiles cleanly, the task will fail.
> 5) java 1.5 users that aren't concerned about submitting compatible patches back to
> the comunity and don't want to hassle with a 1.4 version of rt.jar, can set
> a"javac.trustbootclasspath" and go about their merry way.
> The main idea here being that if someone has both JVMs installed and accidently uses the wrong one to test something before submitting a patch or committing, their build will either fail with a helpful message, or compile against the correct set of core classes anyway if they've done a small amount of setup.
> Caveats to commiting this:
> a) it's a hack, so i don't wnat to commit unless multiple people like it
> b) at the moment, all "successful" ant executions print a confusing compiler error as right
> off the bat, it would be better if we could supress that somehow.
> c) the BUILD.txt should be updated accordingly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-718) possible build.xml addition to ensure
1.4 class compatibility
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/LUCENE-718?page=all ]
Hoss Man updated LUCENE-718:
----------------------------
Attachment: check.bootclasspath.patch
patch with changes
> possible build.xml addition to ensure 1.4 class compatibility
> -------------------------------------------------------------
>
> Key: LUCENE-718
> URL: http://issues.apache.org/jira/browse/LUCENE-718
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Reporter: Hoss Man
> Attachments: check.bootclasspath.patch
>
>
> As encountered recently, setting the "source" and "target" values for the java compiler don't acctually test that the classes/methods are 1.4 compatible -- just that the language syntax/features are...
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6333296
> ...i've come up with one possible solution, that's really feels like a hack, but i wanted to throw it out here for comment, in a nutshell:
> 1) we support a new optional javac.bootclasspath property indicating with path the
> compiler should use.
> 2) people compiling with 1.4 can ignore that property
> 3) anyone who has a 1.5 compiler by default, can set this proprety to point at a 1.4 copy
> of the rt.jar -- which is not inlcuded (users would need to install it themselves)
> 4) as part of the "init" target the build file will attempt to compile a java class that is
> syntactically correct in java 1.4, but utilizes a method only available in 1.5 ... if this
> class compiles cleanly, the task will fail.
> 5) java 1.5 users that aren't concerned about submitting compatible patches back to
> the comunity and don't want to hassle with a 1.4 version of rt.jar, can set
> a"javac.trustbootclasspath" and go about their merry way.
> The main idea here being that if someone has both JVMs installed and accidently uses the wrong one to test something before submitting a patch or committing, their build will either fail with a helpful message, or compile against the correct set of core classes anyway if they've done a small amount of setup.
> Caveats to commiting this:
> a) it's a hack, so i don't wnat to commit unless multiple people like it
> b) at the moment, all "successful" ant executions print a confusing compiler error as right
> off the bat, it would be better if we could supress that somehow.
> c) the BUILD.txt should be updated accordingly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org