Re: Changing manifest task to accept classpath by reference and nested element!
On 2009-02-12, pedro surf pedros...@gmail.com wrote: I believe changing the manifest task to accept a classpathref as a parameter or a nested element would be a great change that would increase the readability of the build and reduce the amount of code necessary to do a simple (and usual) task. I'd probably go for a nested element and allow it to be an arbitrary file system based resource collection instead of a reference to a path - that way you coud even define the classpath inline if you don't need it anywhere else. I don´t know if this change is already in the plans of the ant team, Not that I was aware of it. but if not I would like to do it. However I´ve never worked in a open source project, so any help (best practices, code reviews, ...) would be great. Different projects take different approaches. The one I think has worked best for Ant is to discuss the feature itself, potentially including some implementation details, on this list. And when it is time to actually write code you open an enhancement request in Bugzilla and attach your changes as a patch (unified diff or svn diff against the current Subversion trunk of Ant preferred). Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java
On Thu, Feb 12, 2009 at 4:35 PM, jgl...@apache.org wrote:
+private static final byte[] PACKAGE_INFO_CLASS_HEADER = {
+(byte) 0xca, (byte) 0xfe, (byte) 0xba, (byte) 0xbe, 0x00, 0x00, 0x00,
+0x31, 0x00, 0x07, 0x07, 0x00, 0x05, 0x07, 0x00, 0x06, 0x01, 0x00,
0x0a,
+0x53, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x46, 0x69, 0x6c, 0x65, 0x01,
0x00,
+0x11, 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x2d, 0x69, 0x6e,
0x66,
+0x6f, 0x2e, 0x6a, 0x61, 0x76, 0x61, 0x01
+};
+private static final byte[] PACKAGE_INFO_CLASS_FOOTER = {
+0x2f, 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x2d, 0x69, 0x6e,
0x66,
+0x6f, 0x01, 0x00, 0x10, 0x6a, 0x61, 0x76, 0x61, 0x2f, 0x6c, 0x61,
0x6e,
+0x67, 0x2f, 0x4f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x02, 0x00, 0x00,
0x01,
+0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00,
0x03,
+0x00, 0x00, 0x00, 0x02, 0x00, 0x04
+};
What Java version is this fake class in?
I suppose it doesn't matter much, as it's meant to be replaced, right?
Just curuous. --DD
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java
good idea!
On 2009-02-12, jgl...@apache.org wrote:
private void lookForPackageInfos(File srcDir, File[] newFiles) {
for (int i = 0; i newFiles.length; i++) {
File f = newFiles[i];
if (!f.getName().equals(package-info.java)) {
continue;
should that test better be case-insensitive?
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java
The version is 1.5 - and it is not meant to be replaced!
Peter
On Fri, Feb 13, 2009 at 3:04 PM, Dominique Devienne ddevie...@gmail.com wrote:
On Thu, Feb 12, 2009 at 4:35 PM, jgl...@apache.org wrote:
+private static final byte[] PACKAGE_INFO_CLASS_HEADER = {
+(byte) 0xca, (byte) 0xfe, (byte) 0xba, (byte) 0xbe, 0x00, 0x00,
0x00,
+0x31, 0x00, 0x07, 0x07, 0x00, 0x05, 0x07, 0x00, 0x06, 0x01, 0x00,
0x0a,
+0x53, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x46, 0x69, 0x6c, 0x65, 0x01,
0x00,
+0x11, 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x2d, 0x69, 0x6e,
0x66,
+0x6f, 0x2e, 0x6a, 0x61, 0x76, 0x61, 0x01
+};
+private static final byte[] PACKAGE_INFO_CLASS_FOOTER = {
+0x2f, 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x2d, 0x69, 0x6e,
0x66,
+0x6f, 0x01, 0x00, 0x10, 0x6a, 0x61, 0x76, 0x61, 0x2f, 0x6c, 0x61,
0x6e,
+0x67, 0x2f, 0x4f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x02, 0x00, 0x00,
0x01,
+0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00,
0x03,
+0x00, 0x00, 0x00, 0x02, 0x00, 0x04
+};
What Java version is this fake class in?
I suppose it doesn't matter much, as it's meant to be replaced, right?
Just curuous. --DD
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java
Stefan Bodewig wrote:
if (!f.getName().equals(package-info.java)) {
continue;
should that test better be case-insensitive?
Should it? I don't know. It seemed to work on XP as is. Would someone really
specifically create a file PACKAGE-INFO.JAVA? Windows does at least preserve
case, after all.
To Dominique - yes this should be the equivalent of compiling a package-info.java containing only SOURCE annotations using JDK 5. (JDK 5 javac creates it as an
ACC_INTERFACE, by the way. JDK 6 adds ACC_ABSTRACT, and -target 6 besides using the newer bytecode version further adds ACC_SYNTHETIC, but it is otherwise the same.) The
bytecode is loaded at runtime in case some code requests the java.lang.Package.
It would be good to get feedback on whether this trick works for the cases users have brought up and introduces no problems. The only drawback I know about is the
creation of an extra class file, though it is small and this only happens for a package-info.java with no annotations, which is probably a very small proportion of
realistic source bases.
Arguably javac itself should be changed to always generate package-info.class, which would address the issue not just for Ant but also for Maven and any other tools which
invoke javac for incremental builds. There is no apparent correct behavior - JLS 3 talks briefly about package-info.java but the proposed changes to the JVM spec ch. 4
for JDK 5 do not seem to mention package-info.class at all.
If the package name includes national characters, these are parsed essentially according to what File.absolutePath reports. It would be possible to parse
package-info.java using the declared encoding, but the placing of the package-info.class to be written would still be at the mercy of the filesystem, so this would not
seem to be an improvement. javac itself seems to use the declared encoding only for parsing the text contents of files, still relying on the filesystem to locate and
store files with possibly non-ASCII paths. For a Unicode-safe environment (such as Linux with the normal ext3 LC_ALL=UTF-8) this should not be an issue.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
