You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Ben Speakmon <bs...@apache.org> on 2007/06/16 07:35:25 UTC
advice for fixing commons-email breakage
Hi all,
I've been making changes to commons-email recently and gump is unhappy. I've
looked into it and asked for advice on commons-dev, and now I'd like to ask
the experts
commons-email now depends on two things not in gump. The new dependencies
are only used during test runs (they simulate an SMTP server) and are NOT
required for clients. After reading the docs it seems straightforward enough
to build them, but there are a few problems:
1) I want only a specific version of the test dependencies and don't really
care if upstream changes break my code (and users won't care either)
2) the build system for commons-email is maven 2, but using it in gump seems
unsupported
3) the build for my new dependencies is compiled under 1.5 and then
translated using retroweaver to produce 1.4-compatible jars; commons-email
only requires 1.4 to build
Given that commons-email is going to be maven 2 from here on out, the maven
1 file will likely go away soon since it seems silly to maintain ant, m1,
and m2.
How would you recommend I proceed given these issues?
Thanks!
--Ben
Re: advice for fixing commons-email breakage
Posted by Ben Speakmon <bs...@apache.org>.
Leo et al.,
I've decided to check the jars into my svn and have them pulled out by
project elements. This seems like the solution with the least deal of bother
for all. If other projects were using these libraries, it'd be worth the
effort to set them up; for now, being only test dependencies of one little
commons project, this will work okay.
Thanks for your help!
--Ben
On 6/16/07, Leo Simons <ma...@leosimons.com> wrote:
>
> On Jun 16, 2007, at 7:35 AM, Ben Speakmon wrote:
> > commons-email now depends on two things not in gump. The new
> > dependencies
> > are only used during test runs (they simulate an SMTP server) and
> > are NOT
> > required for clients. After reading the docs it seems
> > straightforward enough
> > to build them, but there are a few problems:
> >
> > 1) I want only a specific version of the test dependencies and
> > don't really
> > care if upstream changes break my code (and users won't care either)
>
> Ok. In that case you can opt to have an 'installed binary'. Simply
> put the jar/artifact/whatever somewhere in your SVN and define it in
> gump, but then don't specify the build for it. There's many examples
> for how to do this, at random for example, look at how xstream refers
> to woodstox:
>
> http://svn.apache.org/repos/asf/gump/metadata/project/xstream.xml
>
> > 2) the build system for commons-email is maven 2, but using it in
> > gump seems
> > unsupported
>
> Maven2 builds are sort-of "second class citizens" in gump, since gump
> cannot control the maven2 dependency management the way we'd like to.
> But it is supported these days; see
>
> https://svn.apache.org/repos/asf/gump/metadata/project/jakarta-
> bcel.xml
>
> for an example descriptor.
>
> > 3) the build for my new dependencies is compiled under 1.5 and then
> > translated using retroweaver to produce 1.4-compatible jars;
> > commons-email
> > only requires 1.4 to build
>
> Ah, that could be a tricky one. But gump builds are all using java 5
> now though,
>
> http://vmgump.apache.org/gump/public/index.html
>
> so if you have a java-5-only build that doesn't use retroweaver you
> could make gump use that one. Alternatively, follow the approach
> explained above and have the retroweaved binaries in SVN.
>
> > Given that commons-email is going to be maven 2 from here on out,
> > the maven
> > 1 file will likely go away soon since it seems silly to maintain
> > ant, m1,
> > and m2.
>
> Sounds like you want to move to use <mvn> in the gump descriptor.
>
> > How would you recommend I proceed given these issues?
>
> I hope this helps!
>
>
> cheers,
>
>
> Leo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
Re: advice for fixing commons-email breakage
Posted by Leo Simons <ma...@leosimons.com>.
On Jun 16, 2007, at 7:35 AM, Ben Speakmon wrote:
> commons-email now depends on two things not in gump. The new
> dependencies
> are only used during test runs (they simulate an SMTP server) and
> are NOT
> required for clients. After reading the docs it seems
> straightforward enough
> to build them, but there are a few problems:
>
> 1) I want only a specific version of the test dependencies and
> don't really
> care if upstream changes break my code (and users won't care either)
Ok. In that case you can opt to have an 'installed binary'. Simply
put the jar/artifact/whatever somewhere in your SVN and define it in
gump, but then don't specify the build for it. There's many examples
for how to do this, at random for example, look at how xstream refers
to woodstox:
http://svn.apache.org/repos/asf/gump/metadata/project/xstream.xml
> 2) the build system for commons-email is maven 2, but using it in
> gump seems
> unsupported
Maven2 builds are sort-of "second class citizens" in gump, since gump
cannot control the maven2 dependency management the way we'd like to.
But it is supported these days; see
https://svn.apache.org/repos/asf/gump/metadata/project/jakarta-
bcel.xml
for an example descriptor.
> 3) the build for my new dependencies is compiled under 1.5 and then
> translated using retroweaver to produce 1.4-compatible jars;
> commons-email
> only requires 1.4 to build
Ah, that could be a tricky one. But gump builds are all using java 5
now though,
http://vmgump.apache.org/gump/public/index.html
so if you have a java-5-only build that doesn't use retroweaver you
could make gump use that one. Alternatively, follow the approach
explained above and have the retroweaved binaries in SVN.
> Given that commons-email is going to be maven 2 from here on out,
> the maven
> 1 file will likely go away soon since it seems silly to maintain
> ant, m1,
> and m2.
Sounds like you want to move to use <mvn> in the gump descriptor.
> How would you recommend I proceed given these issues?
I hope this helps!
cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org