Jars as Source

[ryan.campbell]

In the system module there is a need to unjar getopt & log4j and recombine them into other artifacts. This is also done in security and perhaps in aspects. It seems like we should support this as a first-class construct.

So this is another source, just like src/main or a resource:

<source-artifact id="log4j.jar"/>

which extracts the jar contents to output/log4j.jar/* .

They could then be included in an artifact like any compiled class:

 <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>

[adrian.brock]

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

[ryan.campbell]

I thought you wouldn't like this part....

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?

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 :-)

[adrian.brock]

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.

[ryan.campbell]

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

[ryan.campbell]

Obviously, there is no need for the source-jar element, and we aren't exploding the jars into output/log4j.jar/.