Well, targeting the 1.3 class file definition won't prevent it from using the rt.jar in your 1.5 JDK... thus possible compiling against an API that is in 1.3. In fact, this is not the case and I tried it... but just pointing it out.
-----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, June 12, 2005 7:58 PM To: Jakarta Commons Developers List Subject: Re: maven.compile.source was: [vote] Release Commons Jelly 1.0 based on RC3 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Colebourne wrote: | Brett Porter wrote: | |> | Some jar files are build with JDK1.5 (according to the manifest). commons-jelly-1.0.jar/commons-jelly-tags-xml-1.1.jar. |> |> But compiled for JDK 1.3, as Simon mentioned. | | | See my digester mail on this topic. IMHO, using the flag is insufficient. Are you saying it will bind to something identical code would bind to differently on JDK 1.3, or code that compiles on 1.5 may not run on 1.3 because it also wouldn't compile there? If it is the former, do you have a fragment of code that exhibits this? You mentioned append(StringBuffer), but I can't think why it would bind to that unless you passed it a string buffer. In the latter case, admittedly, it is safer to compile against the runtime you are targetting, as it will fail if you have used something you weren't supposed to. But if you know it does compile on that JDK, then it would be safe to compile on any. You can use Maven to compile on a different JDK than that running the app, using the maven.compile.executable property: http://maven.apache.org/reference/plugins/java/properties.html | |> | A nice to have would be the conversion to windows line endings of some files. At least the README and LICENSE at the top level would be nice. |> |> done | | | RC4 still has unix line endings in the zips for README and LICENSE. But this won't stop a release. That must be in the source, I guess I only did it for the binary distribution. Also, on your point about "maven site" not working on the source tree, "maven xdoc" would to generate the documentation without reports, which is probably what I'd want users to run, but it is not as well known of. We should include the other files. I won't block the release on these, so I'll add them both to JIRA. Thanks, Brett -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCrMvrOb5RoQhMkRMRAnDAAJ9jnaGQ+1+xU0XULZp1WmQs7fsVaACgs/B/ 6x8Zk5QsN/mJIHfhEUM4S6I= =qh+J -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
