On 23-Sep-08, at 9:39 PM, John Casey wrote:
Would it be feasible to bundle these stub plugins into a zip
artifact that can be released into the central repository, then
retrieved, unzipped, and referenced (via <repository> and
<pluginRepository>) in the tests? This might make it cleaner to keep
it out of the hands of normal users...
The other thing to think about is the fact that we're going to have
to be ready for snapshot-repository cleanups like what happened a
few weeks ago. This scenario will mean we'll need to re-deploy these
plugins plus new snapshots of the *real* versions of these plugins.
Just some food for thought.
I think that you need to release the support work and reference them
in tests so that a particular test doesn't fluctuate based on changes
in a particular framework or support plugin. Once an IT has been
written against a set of versions of supporting dependencies then you
can't change those versions without invalidating the IT because you
then have no point of control. We also can't change the IT once it's
been written and we deem it sufficient.
We need to release all those support plugins anything else related to
the ITs.
-john
Benjamin Bentmann wrote:
Hi,
I just had an interesting chat on IRC about some pitfall that I
feel is worth to share so that others know about this, too.
Somebody wondered why his Maven builds were suddenly prepending
[MAVEN-CORE-IT-LOG]
to the log output, for instance during invocation of "clean:clean".
The origin of this output was one of the stub plugins that I
recently wrote for the core ITs (r697428). These stub plugins are
intended to check the lifecycle bindings and hence have by design
the same groupId and artifactId as the real plugins, i.e. in terms
of Maven coordinates these stubs are very close to the real
plugins. The only difference is the version which is set to 0.1-
stub-SNAPSHOT.
To enable people to run the IT suite without prior building of the
support module, I deployed these stubs to the snapshot repo. This
in turn updated the repo metadata to list the stub version as
"latest".
Now, users that haven't locked down their plugin versions but
depend on LATEST and had the snapshot repo enabled got the stub
plugins. Apart from a log message and creating a touch file in
"target", these stubs do nothing so the build is effectively dead.
To avoid unnecessary confusion for users that don't follow best
practices yet, I will deploy new snapshots of the original plugins
to have the real/production snapshot be marked as latest. Of
course, that's not a permanent cure but would have to be performed
after every deploy of a stub snapshot. Please let me know if you
feel this potential threat needs more attention.
So, just that everybody knows the details in case more users report
problems with their builds.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
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
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
