I'm not entirely sure I understand what this configuration does. When
you say 'promote' you're talking about a process internal to Hudson that
allows us to use that RC in other Hudson builds, right? ...for instance,
to test CXF on Hudson using that promoted RC? It's not promoting in the
sense of spinning a staged release, though, or doing any SCM commits or
anything?
I'm also a little hazy on the RC versioning problem you mentioned. Is
this to allow us to host multiple RCs in the Hudson instance for some
reason?
Just to outline what I'm doing here:
I'm using project build scenarios like CXF-in-Hudson just far enough to
understand how to reproduce the error reliably. Then, I'm using that to
write an integration test that's self-contained and as simple as
possible, so we can re-create the issue in a controlled environment (not
sensitive to Hudson updates, for instance), and finally verifying that
the fix (which usually can happen once I understand how to write the IT)
actually fixes the issue...that is, in the previous build/RC the bug is
present, in the build with the new code, it's not.
Once I've done this, I add the new IT into the core-integration-tests
project (up to now, it's in its own archetype-generated project, to keep
testing simple), and run through all the ITs.
When I have all of the known bugs for that RC fixed, I usually look for
as many other platforms/environments as I can find in which to run the
ITs, just to verify that I haven't broken something in a
platform-specific way. I've been sensitized to this since starting the
RC process, so this is a little less likely to be a problem, which is
why I hold off until I think everything looks good to do this step.
I'm not sure where the Hudson builds of the RCs fit into all of this,
except occasionally to help understand how to replicate the error, or to
provide another data point in the IT runs toward the end of one of these
RC cycles...if you can help me understand that, I can probably make
better use of them.
Thanks,
-john
Jason van Zyl wrote:
John,
Now in the 2.0.x panel there is now a way to do an RC, promote it, and
then use it in the community test projects.
So the process would be:
1. Build the RC
http://ci.sonatype.org/view/Maven%202.0.x/job/Maven%202.0.10-RC/
2. If that's cool, then promote the distribution
http://ci.sonatype.org/view/Maven%202.0.x/job/Promote%202.0.x%20RC/
3. Then you can run the community projects
Some things you need to be aware of:
1. If you bump to the next RC, you need to change the version the
promotion script points to. You change that in the promotion job. It's
pretty brain dead, it just moves a distribution in the hudson home
directory from XXX-SNAPSHOT to XXX. I am pointing all the community
builds at the XXX version. So the SNAPSHOT-XXX is promoted to XXX and
then I have installations configured in Hudson.
2. We need to create a new Maven installation when we bump the RC
version. So in this case for the 2.0.10-RC7 I have an installation and
when we make 2.0.10-RC8 if we need to we have to make an installation.
Anyway, we can smoke test as many projects as we can get a hold of.
On 12-Aug-08, at 8:53 AM, John Casey wrote:
Hi Daniel, Mauro,
In either of these cases, can anyone give me some specific steps (and
the project SVN URL, if possible) to reproduce the problem? I tried
running 'mvn clean source:jar' last night on maven-project and
maven-model, but apparently that's too simplistic to reproduce the
problem...all of the sources were present.
I'd like to open another JIRA for this, but I need more to go on
before I can come up with a description for the ticket that makes any
real sense.
Thanks,
-john
Mauro Talevi wrote:
Daniel Kulp wrote:
John,
Performance is a bit better, but in a multi-project reactor build,
the source jars are now all "wrong". None of the source ends up in
the jars. Just the "extra" things from the remote-resources.
Yes - I can confirm that. In fact, another symptom of this is
running cobertura. The coverage report is produced, but when
clicking on any class it shows an error because it cannot find the
java source.
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]