I can see a few options.
The best solution is to find some way to get your CI server to detect
the XSD changes as a trigger for the build instead.
From a Maven point of a view, you might be looking at building a
"conditional deploy" plugin. Extending the current one and providing
limited (if any) arguments should not make this a difficult task - and
the plugin itself would check if it needs to deploy, then call back to
the original deploy plugin using Java code.
A more generic alternative might be to enhance the deploy plugin to
(optionally) not deploy anything if the checksum matches the previous
snapshot.
A slightly different approach if you don't want to muck with the
deploy plugin would be a plugin that is run standalone, checks for the
updated XSD, and if found runs the build up to the given phase (by re-
running Maven, basically in the same way as the reactor plugin).
Hope this helps!
- Brett
On 26/02/2009, at 9:56 AM, Les Hazlewood wrote:
Hi folks,
Here's what I'm trying to achieve:
I have a build that must run every 5 minutes or so in a Continuous
Integration server. It must do this because it downloads
information that
exists outside of a Maven artifact repository or any build
environment and
must regularly check to see if information has changed. If the
information
source has changed in any way, my Maven build must create a new
SNAPSHOT
.jar to reflect the change.
If the information doesn't change, a new .jar should never be
created or
deployed to the repository. This is to avoid uploading a new
snapshot .jar
every 5 minutes to the repository, and consequently having
developers all
download this snapshot as a dependency every time they build (yuck).
Is there a way to pre-emptively stop a build in order to prevent
the .jar
from being created/installed/deployed? I don't want to fail the
build,
because this case is not a failure - the build would have correctly
stopped
short the lifecycle specifically because the .jar should not be
created.
This behavior would exclude standard Maven profiles as a solution as I
understand them because they're only activated based on some
condition when
the build starts. The knowledge of if a build should be 'short
circuited'
would only be available after this plugin finished executing.
------
Now, here's my very specific use case of why I'd like to do this
(but should
probably work generically as described above), in case you're curious:
My plugin downloads .xsd files from well-known locations (not maven
repositories), auto-generates .java (and then .class) files
representing
these .xsd files, creates a .jar file and deploys this .jar to a maven
repository. Other applications consume this 'Java XSD stubs' .jar
to call
web services and are quite happy, but they should automatically be
updated
if the .XSD contracts change, so they can eagerly adapt to these
points of
change, in true Continuous Integration fashion.
But I only want the .jar to be created and deployed to the maven
repository
if one or more of the downloaded .xsd files are different compared
to the
last time the build was executed. If the files don't change between
5-minute cycles (verified by downloading them and comparing to the
previously retrieved files), nothing should happen
Everything is working except for the part where I pre-emptively exit
the
build, but without Failing the build.
Anyone have any ideas?
Thanks SO much for feedback!
Cheers,
Les
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
