DO NOT REPLY [Bug 32649] - ant-produced jar files don't match those produced by java.util.jar.JarOutputStream
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32649. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32649 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 03:43 --- Hi-- as an update. The responsible parties (some from Java, some from Solaris) are talking about this issue, and reviewing the case materials which document the interface contract between Java and Solaris. It appears that this won't get resolved completely until one of the parties returns from vacation, on 1/10/2005. So my estimate of a week was too optimistic. So: we'll have an update sometime in January. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32649] - ant-produced jar files don't match those produced by java.util.jar.JarOutputStream
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32649. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32649 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 05:53 --- We can handle a delay, after all, we have no schedule for the next release. One question: are you trying to look for a magic number at an offset in the binary, or are you parsing the zip file? A magic number pattern is most like classic unix exe lookup, but is inordinately brittle against different legitimate layouts of ZIP files. You should really be recognising the PK DWORD at the beginning of the file and say 'this is a zip, lets look inside it *using the zip algorithm* and see if it has a manifest. Presence of a valid manifest is what should really determine if a jar is executable. If that aint there, you wont know which class to execute, etc, etc. Since we do produce valid manifests if asked to, that should all work. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] ChangeLogParser - hiding field
Jesse Glick wrote:
Just jumping in here... :-)
Feel free ;)
kj wrote:
-class ChangeLogParser {
+public class ChangeLogParser {
No really, just habit - company standards where I've worked in past etc.
Did your company produce Java components with publicly visible APIs
they were committed to preserving indefinitely? Seriously, making and
keeping a decent Java API is *hard* and almost no good style for
programmers books give you workable recommendations. I've been
working on NetBeans core APIs for several years and often regret some
method that seemed harmless four years ago and was made public without
careful planning. Not to mention the mess that is javax.swing.**
Javadoc that it is too late to fix.
No, I've never worked on a true API project before.
Generally, assume everything should be private and final unless you
know how it should be called or overridden. In practice, static
methods are usually not much of a burden to maintain public; instance
methods and constructors more so; and nonfinal classes are very hard
to maintain compatibly, since there is a huge amount of runtime
semantics which subclasses typically rely on and which has to be
documented explicitly and probably can never be changed.
Good rule of thumb.
I suppose it could expose the class more than was intended, but again
the only real rationale for this was that I was looking at the class and
it's completely automatic (for me) to specify an exact access modifier
for everything as shows your exact intentions.
For a top-level class, lack of a written access modifier *is* the one
and only way to specify that it should be package-private, which is
the most restrictive mode for it. When writing a new class, start with
static final class Foo {}
I've read many times that declaring a class as final is a farily
dangerous thing to do with code. Once you've made a class final people
are stuck with what you decided at a particular moment was the right way
to do things. Can you truly know that the class will never have to
change in the future? That's a tough call to make.
or for a nested class
private static final class Foo {}
and go from there. It is just unfortunate that the Java language has
unsafe defaults for these modifiers.
Thanks for the pointers. As an aside, I'm very happy to have decided to
get involved (no matter how little) in an open source project. The
amount of extra knowlegde that I'm gaining from just reading the mailing
list and bug-reports and scanning the code for possible fixes etc is
immense. I'm not by any means a Java guru, but I do consider myself to
be pretty good at Java - and within my company, I almost certainly am
(aren't all developers ego-maniacs?)
But here I feel like a complete novice, practically every day I'm
learning something new about a particular idiosyncratic aspect of Java -
which is great! I'm trying to convice one of my ex-colleagues to get
involved on one of the jakarta projects (he's thinking of James as he
currently uses it), and I can definitely say that one of the benefits is
the amount that you learn (or can learn) from other developers.
So thanks for your thoughts, they've given me much to think about.
Kev
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32649] - ant-produced jar files don't match those produced by java.util.jar.JarOutputStream
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32649. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32649 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 08:37 --- (In reply to comment #8) We can handle a delay, after all, we have no schedule for the next release. One question: are you trying to look for a magic number at an offset in the binary, or are you parsing the zip file? A magic number pattern is most like classic unix exe lookup, but is inordinately brittle against different legitimate layouts of ZIP files. You should really be recognising the PK DWORD at the beginning of the file and say 'this is a zip, lets look inside it *using the zip algorithm* and see if it has a manifest. Presence of a valid manifest is what should really determine if a jar is executable. If that aint there, you wont know which class to execute, etc, etc. Since we do produce valid manifests if asked to, that should all work. Thanks for your patience. The algorithm as it stands is as follows: The kernel decides to use the 'javaexec' file executor based on magic number (same as with ELF and interpreted files, like #!... ). Based on the magic number (PK\003\004), the javaexec module is invoked. My reading of the code is as follows: 1. Read the 30 byte file header. 2. Look for 'PK\003\004' at the beginning. If not, fail. 3. Let XOFF = 30 (file header size) + Size of the first file's name (stored at offset 26). So, if the first file is META-INF/, XOFF = 9. 4. Let XOFF_END = XOFF + Size of the first file's extension. Normally this would be zero, but in this case, the jar tool seems to set it in the archive to '4'. 5. Scan the buffer starting at XOFF and ending at XOFF_END for the byte pattern: 0xcafe. If not found, fail. 6. Find and invoke the Java runtime environment on the file. I can only assume that the answer to: why not scan the whole file for the manifest file is that this would be rather expensive, although I'm not sure. If you mean that we should also unzip the manifest file and parse it-- I think the answer is that we try not to sink that level of complexity into the kernel. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SCP Task - Problems with directories
Hi there, Mike Dikan has reported us that there is a problem in scp task in transferring directories to sshd from OpenSSH 3.9, at http://sourceforge.net/mailarchive/message.php?msg_id=10325346 and here is a patch for that problem, http://sourceforge.net/mailarchive/message.php?msg_id=10344277 Thanks, -- ymnk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Define common project properties and tasks
Phil Weighill-Smith wrote: I'm not trying to rain on anyone's parade, but have you considered... It seems to me that there are as many completely different ways of using Ant as there are projects in this world. If you were to supply a standard build script, ready for customization, what input file structure would it expect? What language would be compiled (if any)? What distribution structure should be created and what files should be used to populate it? What configuration control system should be accessed to obtain the input files (if any)? What common properties would exist? etc. Actually, I have not seen *that* many java project structures. I mean, there is a source dir, a build dir, a tests dir... While I agree that there is some commonality across many Java projects (in that Java has a packaging mechanism that utilizes directories etc. and that these projects commonly produce one or more JAR files) it seems to me that this approach would either be too restrictive on the type of project that could utilize it or that so much customization would be required as to negate the usefulness of it. Netbeans thinks otherwise, and in fact *does* include a basic build. All IDEs have their layout, and tons of projects have used it without customizations. Perhaps better to provide some more sophisticated example build scripts covering the use of Ant on client side and server (multi-JAR) Java projects (and other languages if any contributions could be taken for these). I'd especially like to see examples that: * split the build into several sections (perhaps using subant) in order to generate multiple, tree dependent JARs (i.e. one JAR depends on another but there are no cyclic dependencies) * utilize something like XSLT to generate Ant scripts from simple XML files that define the inter-dependencies within such a multi-part build * use a repository accessor (along the lines of the get libraries stuff that has recently been discussed a lot on this list) to obtain dependency JARs from other projects Krysalis Centipede did this years ago, but the project failed. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Define common project properties and tasks
It seems to me that there are as many completely different ways of using Ant as there are projects in this world. If you were to supply a standard build script, ready for customization, what input file structure would it expect? What language would be compiled (if any)? What distribution structure should be created and what files should be used to populate it? What configuration control system should be accessed to obtain the input files (if any)? What common properties would exist? etc. Actually, I have not seen *that* many java project structures. I assume from that comment you're limiting the sample builds to simple, Java only projects? What properties and targets are you thinking of being supplied? I mean, there is a source dir, a build dir, a tests dir... We may do things differently to everyone else (though this is the second time I've seen this type of project decomposition structure in a build) but we have the concept of subsystems in our build as our source base is fairly large... Each subsystem has up to four source directories (hand-coded API and implementation code plus the option for auto-generated API and implementation code) and up to two test directories (unit and integration test). Each subsystem also has a build directory that contains two generated source class structures (API and implementation separately) and two generated test class structures (unit and integration). Each subsystem has its own build.xml (which imports a standard set of subsystem build targets that can be overridden or augmented as required for the given subsystem, e.g. to generate code from an XML schema etc.). There is then an over-all product build.xml (which imports a standard set of product build targets that again can be overridden or augmented as required, e.g. to create the JARs from the subsystem outputs). Subsystems can depend on each other and on external resources such as JARs etc., based on simple to use XML files that are used to just-in-time generate Ant scripts that not only fetch the external resources from a repository but also define the build and runtime classpaths. You could argue that we have a standard build (since we have standard subsystem and product build imports) but I'm quite sure that a lot of what we do is specific to our environment (e.g. how and why we interact with our SCM - AccuRev - during the build process). While I agree that there is some commonality across many Java projects (in that Java has a packaging mechanism that utilizes directories etc. and that these projects commonly produce one or more JAR files) it seems to me that this approach would either be too restrictive on the type of project that could utilize it or that so much customization would be required as to negate the usefulness of it. Netbeans thinks otherwise, and in fact *does* include a basic build. All IDEs have their layout, and tons of projects have used it without customizations. One wonders just how scalable this basic build is (having not seen it I can't pass any further comment). Perhaps better to provide some more sophisticated example build scripts covering the use of Ant on client side and server (multi-JAR) Java projects (and other languages if any contributions could be taken for these). I'd especially like to see examples that: * split the build into several sections (perhaps using subant) in order to generate multiple, tree dependent JARs (i.e. one JAR depends on another but there are no cyclic dependencies) * utilize something like XSLT to generate Ant scripts from simple XML files that define the inter-dependencies within such a multi-part build * use a repository accessor (along the lines of the get libraries stuff that has recently been discussed a lot on this list) to obtain dependency JARs from other projects Krysalis Centipede did this years ago, but the project failed. Shame. Possibly because its of most use to large developments like ours which are perhaps fewer and further between? Phil :n. -- Phil Weighill-Smith [EMAIL PROTECTED] Volantis Systems
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17934 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 16:17 --- I think roundUp=false should the default for the war target, since this is likely to be needed for precompiled JSPs. true can remain the default for the zip and jar targets. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
