Hi Brett,

Brett Randall wrote:

> On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible <joerg.schai...@gmx.de>
> wrote:
>> sebb wrote:
>>
>>> On 30/03/2010, Jörg Schaible <joerg.schai...@gmx.de> wrote:

[snip]

>>>> The question is, why do you install with Ant at all? Simply drop that
>>>> goal,
>>>> use the build-helper plugin to attach the artifact and you're done
>>>> *and* it will be automatically deployed then also.
>>>>
>>>
>>> Sounds great - I did not know about that Maven feature.
>>
>>> I'll give it a try.
>>
>> Hehe, that explains it ;-)
>>
>> With the build helper you can turn any file into a separate artifact -
>> useful e.g. for XML schemas and the like.
>>
>> At least this will ensure that the bsf-engines will be deployed next time
>> also and the process is transparent for Gump.
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
>> For additional commands, e-mail: general-h...@gump.apache.org
>>
>>
> 
> This is a good outcome and the build is now green on Gump.  I hadn't
> thought of using build-helper but that's a decent option.
> 
> I actually had this working on my local with a different approach
> initially suggested by Sebb - changing the primary artifact to jar
> packaging (from pom), then changing the retroweaver execution/output
> so that it fed the merged/weaved classes back into the Maven paths, so
> the normal execution of jar:jar picked them back up and the resulting
> primary artifact was packaged (and later deployed) as normal by Maven.
>  Using build-helper will result in the jar continuing to be built by
> Retroweaver rather than being packaged by Maven.  This probably
> doesn't matter - the JAR just won't look like a Maven JAR, contain the
> metadata etc.

Actually there is not really a "Maven JAR". It simply the default 
configuration for Maven's archiver to add the metadata, we turned that off 
everywhere in the office. So the result of the retroweaver is a perfect 
artifact.

> The reason I hadn't published this is that I thought I had made a
> change that was effecting the binary output - I now suspect that each
> time Retroweaver runs it produces different binary output (class
> files) as checked by md5sum, so my solution was probably OK.

I'd bet that the retroweaver will produce everytime the same thing. However, 
md5sums (ans sha1sum) is generated by the deploy plugin automatically and 
will always validate the deployed jar itself.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Reply via email to