IBM has released Nested Archive Toolkit for Java, a tool that provides the layout details of archives, including nested or J2EE archives, so that users can open and update selected archive contents. This technology builds on existing Java APIs for accessing ZIP and JAR files. Because Nested Archive Toolkit for Java is a utility, it allows for scanning, accessing and updating selected files within a nested archive. An API is provided that allows random access to archive entries. A portion of the tool provides interchangeability between archives and directories. A command line interface provides access to most functions. Access through Java API calls is provided. An Eclipse plug-in provides a view of archives, including all raw archive data and a tree of nested archives. Nested input streams enable the scanning of nested archives without expanding to temporary storage; archive flattening allows random access to nested archive entries; and articulation points allow archives and directories to be handled interchangeably. What do you think of Nested Archive Toolkit for Java? Message was edited by: firstname.lastname@example.org
- Posted by: Greg Hamilton
- Posted on: May 17 2006 16:44 EDT
I have a deep fear about anything that makes it easier to patch JAR/WAR/RAR/EAR files, and that is it is easier for people to do hand hacking of these files before deployment. Is this bad? Yes, because it means every deployment needs a different version, and you know that before long the wrong version ends up on the wrong box, or someone forgets to do the fixup in one build. Its a shame that you do end up having to do this so often, originally for web.xml tuning, now for Java EE5 persist.xml fixup. We need better ways of configuring deployments, not easier ways to hack into EAR files. There are some good Ant apis for zip file work, incidentally, and those come with the Apache not the IBM alphaworks license. The Ant ones even handle permissions in zip files that the linux zip command can work with; no mention of that here.
We need better ways of configuring deployments, not easier ways to hack into EAR files.I totally agree. Deployables should be designed from the ground up not to depend on the target deployment environment. J2EE offers everything that you need to achieve that purpose, and specifically JNDI. JNDI is often under used, people think that it's only appropriate to lookup a datasource or a transaction manager but it can and *should* be used to lookup all the configuration parameters which depend on the deployment environment at runtime. What's more IoC containers have made it even easier lately to achieve runtime configurability. Indeed, IoC means that whatever a component depends on is injected wherever it comes from, including a runtime directory such as JNDI ;) For example, Spring leverages JNDI through the JNDIObjectFactoryBean, which though being a bit too verbose to declare, is a really clean approach. JNDI has proved clumsy when used as a J2EE COP locator implementation, but when it comes to runtime configuration, it is great ! and even greater when used together with IoC. Cédric Vidal ProxiAD http://proxiad.com
well, you can already do this with Winzip, WinRar, IZArc...