K, sounds good. Thanks,
-john
Jason van Zyl wrote:
On 12-Aug-08, at 10:59 AM, John Casey wrote:
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?
promote == mv $HOME/apache-maven-2.0.10-RC7-SNAPSHOT
$HOME/apache-maven-2.0.10-RC7
The community builds use the promoted version while build can still
occur on the branch and run ITs. Intended so they don't interfere.
Promotion is a simple moving out of way.
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?
The simple promote script just needs to know what versions to move
around. The script just takes a version as the only parameter. So you
have to change the invocation of the promote script in the promote job
when we rev up the version.
This model just lets you build a new RC, move it out of way, and the
community builds will use this out of the way version. So you can
continue working on the branch while the community builds churn away. If
we got 20 projects it's not unlikely that they take a few hours. In the
meantime you might have fixed some things so I didn't want to roadblock
your testing while the community builds were happening.
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
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]
