[JBoss-dev] [Design of JBoss Build System] - Re: Jars as Source
As I mentioned at JbossWorld, I was able implement this using zipfileset. | artifactdef artifact=log4j-boot.jar | include input=log4j.jar |include pattern=org/apache/log4j/*/ |include pattern=org/apache/log4j/config/*/ |include pattern=org/apache/log4j/helpers/*/ |include pattern=org/apache/log4j/or/*/ |include pattern=org/apache/log4j/spi/*/ | /include | /artifactdef | becomes: | zipfileset src=C:\projects\jboss-head\thirdparty\apache-log4j\lib\log4j.jar |include name=org/apache/log4j/*/ | include name=org/apache/log4j/config/*/ | include name=org/apache/log4j/helpers/*/ | include name=org/apache/log4j/or/*/ | include name=org/apache/log4j/spi/*/ | /zipfileset | | It is incremental, based on the timestamps of the files *in* log4j-boot.jar. It also seems quite performant when it does run-- no need for bypass testing. If you include a jar as input, but add no include (or exclude) subelements, the entire jar will be added to the archive -- unexploded. One thing zipfilset also gives us is the prefix attribute, which will be useful for doing things like wars when I get to them. See http://jira.jboss.com/jira/browse/JBBUILD-19 View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3869235#3869235 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3869235 --- 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=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: Jars as Source
Obviously, there is no need for the source-jar element, and we aren't exploding the jars into output/log4j.jar/. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3869237#3869237 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3869237 --- 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=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: Jars as Source
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=bbop=viewtopicp=3867678#3867678 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=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=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: Jars as Source
I thought you wouldn't like this part [EMAIL PROTECTED] wrote : |Your solution would reproduce the old behaviour. | I see your point regarding the incremental build. Shouldn't I be able to replicate the functionality of the existing system/build.xml using uptodate? Or at the very worst, set unjar.overwrite=false? [EMAIL PROTECTED] wrote : | However, I'd prefer it if it where a bit more transparent, rather than | having to declare an artifical artifact. | I'm confused by what you mean by artificial artifact? Are you referring to the source-artifact element? I don't think this is artificial -- the jar is an input that needs to be treated in a special way, much like a resource. I like the natural syntax of what you propose, but it is unclear to me where/when the unjarring takes place. Wouldn't it need to be done in some temporary space so that the element could be expanded to include it? Would the Source class have this responsibility? I apologize for the questions, but I went down a path (potentially the wrong one) and you are pointing in the opposite direction :-) View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3867682#3867682 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3867682 --- 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=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: Jars as Source
Your first responsibilty is to reproduce the old build so we can get on with using the new build. I just feel the source-artificat definition is a hack, it is a way to hook something into ant as a marker for where you do the unpacking. My syntax more clearly expresses what the developer is trying to achieve without having to deal with the logistics of unpacking the jar (an implementation detail). The unpacked jar is neither source (an input to the build) or an artificat (an output of the build). It is just an intermediate construct due to the inability of ant to build one jar from the contents of another. You can ignore my asthetic points, in the interest of getting the build finished. We can revisit it later. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3867683#3867683 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3867683 --- 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=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
