I've never liked this shenanigans. Unpacking and repacking jar is slow and not very incremental.
It also breaks any digital signing that may have been added to the jars (although in the examples you quote there is none) and loses the manifest information. There was once a part of the build where it would jar everything up (wars inside sars), copy them to the installation directory, then unjar everything to a temporary location before replacing the jared version with an unpacked deployment. Because of the move/delete it was never going to be incremental the timestamps changed on every build. Your solution would reproduce the old behaviour. However, I'd prefer it if it where a bit more transparent, rather than having to declare an artifical artifact. I think it is mainly a question of syntax recognition: | <artifactdef artifact="log4j-boot.jar"> | <include input="log4j.jar"> | <include pattern="org/apache/log4j/*"/> | means you want to include contents from the jar | <artifactdef artifact="something.sar"> | <include input="another.jar"> | means you want to include the jar in the sar View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3867678#3867678 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3867678 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
