gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Access to Maven settings for BSF Gump build
Date Wed, 31 Mar 2010 18:34:25 GMT
On 31/03/2010, Jörg Schaible <joerg.schaible@gmx.de> wrote:
> Hi Brett,
>
>  Brett Randall wrote:
>
>
> > On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible <joerg.schaible@gmx.de>
>  > wrote:
>  >> sebb wrote:
>  >>
>  >>> On 30/03/2010, Jörg Schaible <joerg.schaible@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-unsubscribe@gump.apache.org
>  >> For additional commands, e-mail: general-help@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.

Huh? What does the last phrase mean?

> So the result of the retroweaver is a perfect artifact.

There is a META-INF directory, but it does not contain any Maven properties etc.

>
>  > 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-unsubscribe@gump.apache.org
>  For additional commands, e-mail: general-help@gump.apache.org
>
>

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


Mime
View raw message