TestNG 5.3 is not available in the central Maven repo

[jimisola]

Hi,

The latest version of TestNG is not available in the central Maven
repo (repo1.maven.org).
I would have expected that since there is a TestNG plugin for Maven as
well.

It would be of great help if someone in the TestNG team could deploy
the 5.3 release.

Regards,
Jimisola

[Alexandru Popescu]

Afaik the 5.3 doesn't play well with maven2 yet. I am sure Jesse (our
maven guy) will push a new version as soon as he has something
working.

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

> Regards,
> Jimisola
>
>
> >
>

[jimisola]

Ok. I did not know that. TestNG 5.3 was a request from one of my
co-workers. I understood it as if 5.3 has some advantages over 5.1.

(Jesse, if you read this I'd appreciate if you could say when you think
you'll have a new version out that works with Maven.)

Regards,
Jimisola

[Steve Loughran]

On 03/12/06, Alexandru Popescu <the.mindstor...@gmail.com> wrote:
>
> On 12/3/06, jimisola <jimi...@gmail.com> wrote:
> >
> > Hi,
> >
> > The latest version of TestNG is not available in the central Maven
> > repo (repo1.maven.org).
> > I would have expected that since there is a TestNG plugin for Maven as
> > well.
> >
> > It would be of great help if someone in the TestNG team could deploy
> > the 5.3 release.
> >
>
> Afaik the 5.3 doesn't play well with maven2 yet. I am sure Jesse (our
> maven guy) will push a new version as soon as he has something
> working.
>

Its still good for all OSS projects to push out their artifacts to the
ibiblio repo, even if M2 doesnt work with it. Both Ivy and SmartFrog
can pull artifacts down from the repo, and Ivy is now in incubation
under apache as the ant-centric way to get stuff from the same
repository, even (mostly) using the same metadata.

-steve

[Cédric Beust ♔]

On 12/3/06, Alexandru Popescu <the.mindstor...@gmail.com> wrote:

Afaik the 5.3 doesn't play well with maven2 yet. I am sure Jesse (our
maven guy) will push a new version as soon as he has something
working.

And by the way, I would love it if somebody accepted to co-own this with Jesse.  Maven support for TestNG has become very popular, and it worries me that only Jesse knows how to maintain the repository...

--
Cédric

[Alexandru Popescu]

I was offering myself in a couple of times... with the only condition
to have some initial description of what has been done and where to
look for. I am still strong on this. The most complaints I have heard
about TestNG were about its maven support and I would definitely like
to make it as stable as the rest of it (no offense Jesse).

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

> --
> Cédric
>
> >
>

[David Bernard]

+1 to add TestNG 5.3 on ibiblio with or without maven support

Because maven users could integrate testng into an maven project :
* to allow create there own plugin
* to allow call to from antrun plugin

Both solution are not perfect but better than nothing. (no surefire
support or not able to access the repository with surefire-2.8-SNAPSHOT
behind the firewall (case of my previous customer))

FYI :

Recently, I need the the TestNG report into a maven build. Because I
use TestNG to drive Fit test and the TestNG report to access the
resulting html of Fit.

To do it, I use the TestNG anttask from maven:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>test</phase>
<configuration>
<tasks>
<condition property="testng.haltOnFailure" else="false">
<not>
<equals arg1="${maven.test.failure.ignore}" arg2="true"
/>
</not>
</condition>
<taskdef resource="testngtasks"
classpathref="maven.test.classpath" />
<testng classpathref="maven.test.classpath"
outputDir="${project.build.directory}/site/testng"
sourcedir="${basedir}/src/test/java"
haltOnfailure="${testng.haltOnFailure}">
<jvmarg
value="-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl"
/>
<xmlfileset dir="${basedir}/src/test/resources"
includes="testng.xml" />
</testng>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>

[Andreas Guther]

David,

I think everyone agrees that ibiblio should have all TestNG versions. There is no reason not to put TestNG on the ibiblio server.  This is independent from any Surefire issue.  My understanding is that it is more a deployment and access rights issue that keeps us from having the latest TestNG version on the server in a timely manner.

Andreas

[Alexandru Popescu]

On 12/4/06, Andreas Guther <andreas...@gmail.com> wrote:
> David,
>
> I think everyone agrees that ibiblio should have all TestNG versions. There
> is no reason not to put TestNG on the ibiblio server. This is independent
> from any Surefire issue. My understanding is that it is more a deployment
> and access rights issue that keeps us from having the latest TestNG version
> on the server in a timely manner.
>
> Andreas
>

Can this process be scripted (in Ant :-) )? If so just pass me the
details and I will make sure that we have the necessary targets to
trigger the publish process.

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

>
>

[Hani Suleiman]

This certainly is trivial, uploading new releases to ibiblio is no
big deal at all, and we have infrastructure at opensymphony to do
this automatically I believe. I'll look into what's needed to have
this kick in for tng. From what I remember, all you need to do is
upload the jar to a directory at opensymphony's server and it'll
automatically be synced up to ibiblio within 4 hours.

[David Bernard]

May be help at :
* http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
* http://www.apache.org/dev/release-publishing.html#repo-step-by-step

[Alexandru Popescu]

On 12/4/06, David Bernard <dwa...@free.fr> wrote:
>

All I can say: OMG! Maven is easy????

[Alexandru Popescu]

I was re-reading this thread a couple of times and I think I have
reached a conclusion that will make things extremely easy (as it is
supposed to be):

1/ we need to figure out a process - automatic - to push our releases
on maven repositories

2/ if we replace the maven-surefire stuff from out todo list and rely
on maven-ant then everything should become extremely simple: no
parallel patches, no additional code. I am not seeing any advantage in
having this additional work done on our side and also on our user side
(configure additional repositories, use snapshot plugins, etc.). David
Bernard has provided a good example of TestNG usage with the maven-ant
plugin, and this should become the supported direction.

Please let me know if you have other suggestions and ideas.

[Andreas Guther]

I guess since we do not own the Maven Surefire it makes sense to provide "our" thing based on Maven.  If the Surefire team is short on resources it might make sense to provide an alternative.

I think it still makes  sense to support the Maven Surefire team.  Surefire has currently two Test Providers, JUnit and TestNG.  Well, one could argue that the JUnit team does not seem to support the Maven Surefire project, but on the other hand JUnit is not so fast moving and to my understanding JUnit 4 support is not planed for Surefire yet.  And I think this is the difference.  I think supporting Maven is worth wile the effort.

It might be easy for us to provide the ant solution, but it becomes not easier for the Maven user.  If I have to configure Ant usage of if I have to work on my settings is not a big difference.  But I would prefer the Maven pure solution over the Ant integration one. 

Of course since I am a big Maven fan and user, I am a bit biased and selfish.  I simply think that the TestNG team has the best knowledge about the changes within TestNG and the differences that have to be managed in the Surefire components.  I am more than happy to join Jesse and help him in his work on the patches and tests for Surefire.

If we continue this path, we should make sure that all that is needed to support Jesse is part of the TestNG SVN.

Andreas

[David Bernard]

using ant run isn't perfect compared to surefire:
* more xml code to write
* less integration:
* if the developer call the goal 'site', it must use the
-Dmaven.test.failure.ignore=true to avoid the end of the process if
some test failed
* look and field of the report, but access to the output of report,
organization by group

Surefire integration is good, but surefire doesn't release as often as
TestNG.
May be create a (minimal) testng-maven-plugin could be a better
solution for future.

For information publishing (jar,...) on ibiblio is a facility for user,
but you could publish the jar and pom.xml on any public http server
that follow the maven2 repository layout (eg:
testng.org/maven2-repo/org/testng/testng/5.3/...). In this case
publishing is easy. (I'll publish testng 5.3 on my own public
repository)

[Andreas Guther]

I think if we share the burden of supporting and patching Surefire and if we organize that as a project either under TestNG or aside, we should be able to provide timely patches at least on the howardlewisship server.  It is a bit unfortunately that we use this high SNAPSHOT version. We should have used the same as the current Maven Surefire plug-in is using.

We should also be able to provide tests that verify if a specific path is applied to Surefire or not.

Andreas

On 12/4/06, David Bernard <dwa...@free.fr> wrote:

using ant run isn't perfect compared to surefire:
* more xml code to write
* less integration:
   * if the developer call the goal 'site', it must use the
-Dmaven.test.failure.ignore=true to avoid the end of the process if
some test failed
   * look and field of the report, but access to the output of report,
organization by group

Surefire integration is good, but surefire doesn't release as often as
TestNG.
May be create a (minimal) testng-maven-plugin could be a better
solution for future.

For information publishing (jar,...) on ibiblio is a facility for user,
but you could publish the jar and pom.xml on any public http server
that follow the maven2 repository layout (eg:

testng.org/maven2-repo/org/testng/testng/5.3/... ). In this case

[Hani Suleiman]

On Dec 4, 2006, at 11:48 AM, Andreas Guther wrote:

> I think if we share the burden of supporting and patching Surefire
> and if we organize that as a project either under TestNG or aside,
> we should be able to provide timely patches at least on the
> howardlewisship server.

I don't think this is a good solution. We should everything we can to
avoid this.

[Andreas Guther]

Of course, we should do that.  I have enough on my plate already and I am not looking for adding more than absolutely necessary.  But as a Maven user I think I could give something back to the project that way.

Andreas

[Alexandru Popescu]

On 12/4/06, David Bernard <dwa...@free.fr> wrote:
>

> using ant run isn't perfect compared to surefire:
> * more xml code to write

in a side by side comparison it is longer with 3-4 lines at most.

> * less integration:
> * if the developer call the goal 'site', it must use the
> -Dmaven.test.failure.ignore=true to avoid the end of the process if
> some test failed

doesn't look so serious to me

> * look and field of the report, but access to the output of report,
> organization by group
>

Not sure what you mean by the above. Can you please explain?

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

> Surefire integration is good, but surefire doesn't release as often as

[Alexandru Popescu]

On 12/4/06, Andreas Guther <andreas...@gmail.com> wrote:

> I think if we share the burden of supporting and patching Surefire and if we
> organize that as a project either under TestNG or aside, we should be able
> to provide timely patches at least on the howardlewisship server. It is a
> bit unfortunately that we use this high SNAPSHOT version. We should have
> used the same as the current Maven Surefire plug-in is using.
>
> We should also be able to provide tests that verify if a specific path is
> applied to Surefire or not.
>
> Andreas
>

I would probably agree with you but: we need to maintain a set of
patches for different plugin version and different testng versions. I
would say that this is a huge effort. While, through maven ant things
seem pretty easy and on our side there is nothing special we must do.

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

>

[Alexandru Popescu]

On 12/4/06, Alexandru Popescu <the.mindstor...@gmail.com> wrote:

> On 12/4/06, Andreas Guther <andreas...@gmail.com> wrote:
> > I think if we share the burden of supporting and patching Surefire and if we
> > organize that as a project either under TestNG or aside, we should be able
> > to provide timely patches at least on the howardlewisship server. It is a
> > bit unfortunately that we use this high SNAPSHOT version. We should have
> > used the same as the current Maven Surefire plug-in is using.
> >
> > We should also be able to provide tests that verify if a specific path is
> > applied to Surefire or not.
> >
> > Andreas
> >
>
> I would probably agree with you but: we need to maintain a set of
> patches for different plugin version and different testng versions. I
> would say that this is a huge effort. While, through maven ant things
> seem pretty easy and on our side there is nothing special we must do.
>

Add to this that then we depend on the release lifecycle of the
surefire-plugin. Frankly speaking, the less we depend on external
stuff the easier is for us.

[David Bernard]

> > * look and field of the report, but access to the output of report,
> > organization by group
> >
>
> Not sure what you mean by the above. Can you please explain?

The html report generated by surefire (see
http://maven.apache.org/plugins/maven-surefire-report-plugin/usage.html)
display result as a flat list, not a hierarchy (group and test inside
the group) like the TestNG html output.

I'd published on my public repository testng-5.3 (the jar are from the
testng-5.3.zip from testng.org) and the pom, is the one from ibiblio
with version 5.1 replace by 5.3.
For information Jesse add a comment into the pom about how to publish
on ibiblio.

To use it :
<project>
...
<dependencies>
...
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.3</version>
<!--<classifier>jdk14</classifier>-->
<classifier>jdk15</classifier>
<scope>test</scope>
</dependency>
</dependencies>
<repositories>
...
<repository>
<id>alchim.snapshots</id>
<url>http://alchim.sf.net/download</url>
<!--<snapshots/>-->
<releases/>
</repository>
</repositories>
...
</project>

I thinks that Jesse could publish on
http://howardlewisship.com/repository/ (same place as surefire).
(From My previous customer site, I couldn't access this site (firewall
rules)).

[David Bernard]

I forgot :

to publish :
* install maven 2
* add in the ~/.m2/settings.xml (the login and password to access the
repository, in my case alchim.sf.net)
* the cmd :

mvn deploy:deploy-file -DpomFile=testng-5.3.pom
-Dfile=testng-5.3-jdk15.jar -Dre
positoryId=alchim.sf.net
-Durl=scp://alchim.sf.net/home/groups/a/al/alchim/htdoc
s/download -Dclassifier=jdk15
mvn deploy:deploy-file -DpomFile=testng-5.3.pom
-Dfile=testng-5.3-jdk14.jar -Dre
positoryId=alchim.sf.net
-Durl=scp://alchim.sf.net/home/groups/a/al/alchim/htdoc
s/download -Dclassifier=jdk14

[Alexandru Popescu]

On 12/4/06, David Bernard <dwa...@free.fr> wrote:
>

> > > * look and field of the report, but access to the output of report,
> > > organization by group
> > >
> >
> > Not sure what you mean by the above. Can you please explain?
>
> The html report generated by surefire (see
> http://maven.apache.org/plugins/maven-surefire-report-plugin/usage.html)
> display result as a flat list, not a hierarchy (group and test inside
> the group) like the TestNG html output.
>

But this can be achieved quite easy from TestNG core (pluging a
special reporter), so I don't think this is essential.

Considering the above arguments, I would say that the only advantage
of surefire over ant is that it may be shorter with 4-5 lines. Is it
worth the effort needed for maintaining the surefire plugin? Frankly
speaking I don't think so.

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

> I'd published on my public repository testng-5.3 (the jar are from the

[Alexandru Popescu]

On 12/4/06, David Bernard <dwa...@free.fr> wrote:
>

Thanks. But I am only interested in pushing the jar through Ant.
TestNG will not need maven (neither for build, nor for anything else).

[Andreas Guther]

Alex,

I do not think we are dependent in any way on Surefire.  This is more a "supporting a major build player in the Open Source communite" thing.  And lots of people are interested in using TestNG with Maven 2.  I think we should be able to play by the Maven Surefire team rules.  Using a 2.8-SNAPSHOT version is rather confusing if Maven is working towards 2.3.

Andreas

[Alexandru Popescu]

On 12/4/06, Andreas Guther <andreas...@gmail.com> wrote:
> Alex,
>
> I do not think we are dependent in any way on Surefire. This is more a
> "supporting a major build player in the Open Source communite" thing. And
> lots of people are interested in using TestNG with Maven 2. I think we
> should be able to play by the Maven Surefire team rules. Using a
> 2.8-SNAPSHOT version is rather confusing if Maven is working towards 2.3.
>

Oke. I have chatted with Jesse about this and here is a reduced TODO list:

1/ use Jesse's patches available on the
http://jira.opensymphony.com/browse/TESTNG-122 upon the surefire,
maven-surefire-plugin
2/ completely move the code to use only public TestNG API (guaranteed
to work in the long run)
3/ create a set of patches to be pushed in those maven projects
4/ ask a new release from those releases.

hope this clarifies things,

[Hani Suleiman]

Yes, but if the surefire people are as lazy and ineffectual as they
seem to be, it looks like a doomed proposition to get that side of
things working.

Ultimately I think what Alex is driving at is that we need to
minimise our reliance on external people who have no obligation or
commitment to sort out issues. In some cases this is unavoidable, but
we should always try to minimise that. A dependency like the one we
have on surefire seems like a bad recipe, since all it does is hurt
us and give a bad impression.

Basically, what we need is X number of people to take responsibility
for the various bits of this process all the way through. To do so
successfully we also need to all have a clear idea on what's broken
now, given that this maven saga has been going on for months and it's
still not entirely obvious who should be blamed, otherwise we'll be
exactly at this point in a couple of months and will have this debate
yet again.

Surefire integration is the ideal, I agree, but only if we have some
measure of control over it, and can regularly make releases or nag
someone to do so.

[Alexandru Popescu]

On 12/4/06, Hani Suleiman <ha...@formicary.net> wrote:
>

> Yes, but if the surefire people are as lazy and ineffectual as they
> seem to be, it looks like a doomed proposition to get that side of
> things working.
>
> Ultimately I think what Alex is driving at is that we need to
> minimise our reliance on external people who have no obligation or
> commitment to sort out issues. In some cases this is unavoidable, but
> we should always try to minimise that. A dependency like the one we
> have on surefire seems like a bad recipe, since all it does is hurt
> us and give a bad impression.
>
> Basically, what we need is X number of people to take responsibility
> for the various bits of this process all the way through. To do so
> successfully we also need to all have a clear idea on what's broken
> now, given that this maven saga has been going on for months and it's
> still not entirely obvious who should be blamed, otherwise we'll be
> exactly at this point in a couple of months and will have this debate
> yet again.
>
> Surefire integration is the ideal, I agree, but only if we have some
> measure of control over it, and can regularly make releases or nag
> someone to do so.
>

I am gonna put all my efforts into making this work and making it as
stable as possible. The only things that I am really worried about:

1/ I may hit a dead-end due to whatever surefire limitation
2/ we will still need to wait for a new release from the maven parts.

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

> On Dec 4, 2006, at 1:22 PM, Andreas Guther wrote:

[jimisola]

Hi everyone!

First of all, I just want to say that I am delighted to see the
response in this thread. I've haven't used TestNG before nor been a
part of its community, so this was very positive for me.

That said, there seem to be two different discussions:

1. Why is TestNG jar(s) not deployed to the Central Maven Repo? (note
that ibiblio is no longer Maven's Central Repository:
http://blogs.maven.org/jvanzyl/2006/10/05/1160062688005.html)

2. TestNG and Maven integration

On 1) my opinion is that the jar(s) always should be deployed to the
central repository. Whether this version actually works with Maven or
not is irrelevant since other tools, such as Ivy, use the repository as
well. The actual deployment is VERY easy. When situations like this
come up I usually deploy the jar(s) to our internal repo and also
notify the project (here: TestNG). But, there are people who don't have
an internal repository since it requires some infrastructure.

On 2) I've seen the solution with antrun and that is a not a long-term
solution to me - it is simply a workaround. TestNG should be run by a
Maven plugin - preferably surefire. We all know that surefire has it's
limitations and have had it's bugs (AspectJ with surefire is one).
But, it is of essence - I believe - to work these things out as one, as
a team, as a community, instead of creating new plugins etc. Join
forces, work together and make surefire TestNG friendly. People are
already familiar with surefire, so focus on helping the surefire team.
It does not have to be by submitting patches, being a resource for
questions on TestNG might very well be enough for the surefire team.

Regards,
Jimisola

[jimisola]

Alexandru Popescu wrote:
> I am gonna put all my efforts into making this work and making it as
> stable as possible. The only things that I am really worried about:
>
> 1/ I may hit a dead-end due to whatever surefire limitation
> 2/ we will still need to wait for a new release from the maven parts.
>
> ./alex
> --
> .w( the_mindstorm )p.
> TestNG co-founder
> EclipseTestNG Creator

Alexandru,

Share your concern in somewhat ways (being dependent on others is never
a good thing :)).
I just posted the url to this thread and a short background story in
Maven IRC channel (irc://irc.codehaus.org/maven) and I got some
response:

"I suggest that they start by stating what's missing"

So, what issues are there with TestNG and Maven. I don't have a clue
myself and therefore don't feel like acting as a middle man

I think that the first step is to contact the Maven Team about surefire
(surefire is a Maven core plugin) and get some sort of assurance on
acceptance of (working) patches. I find it hard to believe that they
would not appreciate some help on the TestNG issues. I'd recommend the
IRC channel or the mailing list.

Regards,
Jimisola

[jimisola]

The IRC log from the Maven channel where I discussed it shortly should
show up soon at this link:
http://dev.rectang.com/logs/codehaus/%23maven/ (search for TestNG)

Jimisola

[Steve Loughran]

On 04/12/06, Hani Suleiman <ha...@formicary.net> wrote:
>
> This certainly is trivial, uploading new releases to ibiblio is no
> big deal at all, and we have infrastructure at opensymphony to do
> this automatically I believe. I'll look into what's needed to have
> this kick in for tng. From what I remember, all you need to do is
> upload the jar to a directory at opensymphony's server and it'll
> automatically be synced up to ibiblio within 4 hours.

Yes, currently the repository is a bit too wide open wrt who can add
artifacts, or more importantly, there is no metadata validation
whatsoever, yet a rule of 'never change a published artifact or MD'
which is enforced not just in repository policy, but in the
implementations of both maven2 and Ivy, which assume that once
something is downloaded, there's no need ever to check the repository
again.

The things you need to publish are
-a POM file. You can <echo> CDATA to create this on the fly, including
version markers of what your dependencies are.
-MS5 and sha1 checksums, using <checksum>

Before any one does a publish, I'd like to review the proposed POM.
random things imported from libraries seventeen hops away is the bane
of anyone handing off repo management to tools, and I now have a vague
idea what causes trouble (look at commons-logging 1.1 for an example
of what not to do)

If Hani can't publish it, a bugrep on the Maven-Evangelisation JIRA
will do it; I think I only have the rights to publish bits of Apache's
code.

What I can help with the ant targets to automate this. I need to do it
for our work project and something simpler would be good to practice
on. At work, I've just moved to Ivy, which has an (as yet
undocumented) task to create a POM from your ivy dependencies. I have
yet to play with this, to assess its quality or value.

-steve

[Steve Loughran]

On 04/12/06, jimisola <jimi...@gmail.com> wrote:
>

>
> 2. TestNG and Maven integration
>
>

> On 2) I've seen the solution with antrun and that is a not a long-term
> solution to me - it is simply a workaround. TestNG should be run by a
> Maven plugin - preferably surefire. We all know that surefire has it's
> limitations and have had it's bugs (AspectJ with surefire is one).
> But, it is of essence - I believe - to work these things out as one, as
> a team, as a community, instead of creating new plugins etc. Join
> forces, work together and make surefire TestNG friendly. People are
> already familiar with surefire, so focus on helping the surefire team.
> It does not have to be by submitting patches, being a resource for
> questions on TestNG might very well be enough for the surefire team.
>

If you can work with the other teams, and your release schedules are
both in sync, then its much better to collaborate. They can understand
Maven, so you dont have to.

The big disadvantage of this is release cycles; unless you do
synchronised releases they may have to support old maven versions, or
there is a lag between you shipping and maven support. This is similar
to the problem Ant has with JUnit 4; Junit4 broke ant 1.6.5's task,
which is fixed in Ant1.7 but its been a while coming, which has
annoyed people. Furthermore, and this primarily annoys the JUnit team,
the Ant team refuses to add JUnit 4 specific features on the grounds
of preserving backwards compatibility with java 1.3 and the like is
considered a good thing. To add extra entertainment to this, JUnit 4
comes out of IBM so the eclipse team have embraced it, but netbeans
wont touch it until Ant does. So Ant is the bottleneck. Or as the team
likes to put it, "We're a backwards compatible bottleneck"

If you do your own thing, you get to be in sync with testng, but may
have to deal with different versions of maven instead. Which may hurt
just as bad, and you've just taken on extra maintenance and support
costs.

What's best is to remember this is all OSS, with compatible licenses.
Users of surefire need to get on maven-dev or wherever it is worked on
and help implement the stuff. Its the fastest way to get something
working, and building up a good relationship between teams. The latter
is good on a purely selfish note: if you want to get something fixed
in maven it will be easier if you can mail Brett, Jason or similar,
and have them answer you on the basis they value your own
contributions.

-Steve

[Alexandru Popescu]

Are you saying that you already have this working? Or that your would
like to experiment with it? If you can send out a patch then it would
be appreciated.

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

> -steve
>
> >
>

[Steve Loughran]

On 04/12/06, Alexandru Popescu <the.mindstor...@gmail.com> wrote:
>
> Are you saying that you already have this working? Or that your would
> like to experiment with it?

1. I spent many months with the m2 ant tasks, trying to use them to
manage repositories. They are hard to use, very unreliable and dont
integrate well with Ant.

2. I moved to Ivy recently, and think it is great, even though it has
a few quirks. I've rolled our work project to it, and the forthcoming,
Ant in Action book.

3. I have not yet published stuff to the ibiblio repository. I know
all the steps, just never practised them. I did, during the (1)
period, publish stuff to local repositories:

Creating poms

To create POMs, my project either copies a template with inline
expansions, or creates a stub using Ant 1.7's echoxml:

<target name="m2-copy-pom" depends="init-m2" if="project.haspom">
<copy file="${project.pom}" tofile="${target.pom}" >
<!-- we expand ant properties here. -->
<filterchain>
<expandproperties/>
</filterchain>
</copy>
</target>

<!-- inline creation of a very minimal (zero dependency) pom -->
<target name="m2-make-pom" depends="init-m2" unless="project.haspom">
<echo message="Creating Pom ${target.pom}" level="verbose"/>
<echoxml file="${target.pom}">
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>${m2.groupID}</groupId>
<artifactId>${m2.artifact.name}</artifactId>
<packaging>jar</packaging>
<version>${artifact.version}</version>
</project>
</echoxml>
</target>

The ant1.6 equivalent is:

<macrodef name="m2-makepom">
<attribute name="artifact"/>
<attribute name="target"/>
<sequential>
<echo message="Creating Pom @{target}" level="verbose"/>
<echo file="@{target}"><![CDATA[<project>
<modelVersion>4.0.0</modelVersion>
<groupId>${m2.groupID}</groupId>
<artifactId>@{artifact}</artifactId>
<packaging>jar</packaging>
<version>${Version}</version>
</project>
]]></echo>
</sequential>
</macrodef>

To checksum an artifact,

<macrodef name="sha1">
<attribute name="file"/>
<sequential>
<checksum file="@{file}" algorithm="md5"/>
<checksum file="@{file}" algorithm="sha1"/>
</sequential>
</macrodef>

I use it like this; it adds .sha1 and .md5 files alongside the originals:

<sha1 file="${smartfrog.jar}" />
<sha1 file="${smartfrog.pom}" />

That's all you need to create a pom with minimal dependencies and the
checksums. As to publishing it, that's where things get complex, as
you are in a semi-manual process.

Maven2 does have this fully automated, but there are some issues here
-only people with access rights to an rsync source can do it. That's
apache, opensymphony, codehaus, some others.
-there's a common tendency to accidentally publish artifacts during
the beta , which creates problems.
-the publish-during-build process actually violates Apache release
processes, that expect the management team to test and audit the
artifacts before making them public.

I'm experimenting with using Ivy to create the POM files from its own
metadata, as part of my own project's release process. I have nothing
to use there.

> If you can send out a patch then it would
> be appreciated.

I know, but I cannot deny you the opportunity to fiddle with your own
build.xml files. You dont want me editing them, really. I break things
for a living. Big things.

-steve

[Alexandru Popescu]

On 12/4/06, Steve Loughran <steve.l...@gmail.com> wrote:
>

Oh yes... I haven't said: edit our build.xml and break it, but rather:
do you have a real patch or not? :-).

[Steve Loughran]

No. I'm sorry, but I havent sat down and tried to build testng or go
near making patches to the source. not yet. The code snippets I posted
earlier are the usable fragments from my existing build file, which
someone could use where appropriate.