RE: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
Nothing immediate pops into my head, but what if you could hook your CI system to monitor these external xsds and use that to trigger the build? The only way to stop the build currently is via the enforcer plugin, you could make a custom rule...but it would be seen to the CI as a build failure. -Original Message- From: les.hazlew...@anjinllc.com [mailto:les.hazlew...@anjinllc.com] On Behalf Of Les Hazlewood Sent: Wednesday, February 25, 2009 5:56 PM To: users@maven.apache.org Subject: Conditional plugin execution based on build time behavior - Maven profiles not sufficient? 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
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
On Wed, Feb 25, 2009 at 3:56 PM, Les Hazlewood l...@hazlewood.com wrote: 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). How about having something outside the build process do the monitoring, and kick off a build only when it sees a change? Your CI server probably has a way to force a build with a program or script. You could still run the monitoring process in the build server if that's important, it would just be a separate build. The full project build wouldn't happen on a schedule, but only when requested. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
Not sure if this works in 2.x (it should, I know it works in 3.x) but I'll make an enforcer rule, or small plugin in the validate phase, which will detect the changed. Based on the outcome set the skip deploy option programmatically. Not the most efficient as the build will still happen but the JAR will not get deployed and the build won't fail. On 25-Feb-09, at 2:56 PM, 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
I _just_ saw a maven.deploy.skip property that the existing 2.4 deploy
plugin will check. I'm perfectly fine with doing what you suggest Jason,
thanks very much for the recommendation (I don't care about the minor
inefficiency in this case).
But, that property can be set programmatically via another plugin?
Maybe something like the following?
/**
* @parameter expression=${project}
*/
private MavenProject mavenProject;
...
public void execute() {
boolean shouldSkip = //determined in some way
if ( shouldSkip ) {
final Properties projectProperties = mavenProject.getProperties();
projectProperties.put( maven.deploy.skip, Boolean.TRUE);
}
...
}
Will that work?
I'm not aware of when property binding occurs - i.e. if their values can be
changed by plugins or if they're permanently set before the lifecycle starts
after reading the pom.
Thanks for any clarification - I think I'm close!
Les
On Thu, Feb 26, 2009 at 10:28 AM, Jason van Zyl jvan...@sonatype.comwrote:
Not sure if this works in 2.x (it should, I know it works in 3.x) but I'll
make an enforcer rule, or small plugin in the validate phase, which will
detect the changed. Based on the outcome set the skip deploy option
programmatically. Not the most efficient as the build will still happen but
the JAR will not get deployed and the build won't fail.
On 25-Feb-09, at 2:56 PM, 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
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
--
Simplex sigillum veri. (Simplicity is the seal of truth.)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
Hi Wendy, Thanks very much for the feedback, I certainly appreciate it. Yes, our CI server definitely supports executing a script. We could just take our logic, throw it in a groovy script, and if the .xsd files have changed, have that groovy script just kick off the maven build. I wanted to avoid this if possible - currently everything in our CI server is a nice standard Maven build. I want to avoid these kinds of permutations to avoid confusion: CI and even Maven are extremely new concepts at my company and anything to avoid the perception of complexity is a good thing :) Jason's suggestion sounds promising - can you confirm if that property can be set dynamically by another plugin? Thanks, Les On Thu, Feb 26, 2009 at 9:55 AM, Wendy Smoak wsm...@gmail.com wrote: On Wed, Feb 25, 2009 at 3:56 PM, Les Hazlewood l...@hazlewood.com wrote: 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). How about having something outside the build process do the monitoring, and kick off a build only when it sees a change? Your CI server probably has a way to force a build with a program or script. You could still run the monitoring process in the build server if that's important, it would just be a separate build. The full project build wouldn't happen on a schedule, but only when requested. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
All works fine, but you need to use version 2.4 of the deploy plugin.
Full working example is here:
http://people.apache.org/~jvanzyl/les.tgz
There's a plugin and a project that uses the plugin. Build/install the
plugin, then mvn clean deploy the test project and you'll see it
doesn't deploy.
On 26-Feb-09, at 7:59 AM, Les Hazlewood wrote:
I _just_ saw a maven.deploy.skip property that the existing 2.4
deploy
plugin will check. I'm perfectly fine with doing what you suggest
Jason,
thanks very much for the recommendation (I don't care about the minor
inefficiency in this case).
But, that property can be set programmatically via another plugin?
Maybe something like the following?
/**
* @parameter expression=${project}
*/
private MavenProject mavenProject;
...
public void execute() {
boolean shouldSkip = //determined in some way
if ( shouldSkip ) {
final Properties projectProperties = mavenProject.getProperties();
projectProperties.put( maven.deploy.skip, Boolean.TRUE);
}
...
}
Will that work?
I'm not aware of when property binding occurs - i.e. if their values
can be
changed by plugins or if they're permanently set before the
lifecycle starts
after reading the pom.
Thanks for any clarification - I think I'm close!
Les
On Thu, Feb 26, 2009 at 10:28 AM, Jason van Zyl
jvan...@sonatype.comwrote:
Not sure if this works in 2.x (it should, I know it works in 3.x)
but I'll
make an enforcer rule, or small plugin in the validate phase, which
will
detect the changed. Based on the outcome set the skip deploy option
programmatically. Not the most efficient as the build will still
happen but
the JAR will not get deployed and the build won't fail.
On 25-Feb-09, at 2:56 PM, 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
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
--
Simplex sigillum veri. (Simplicity is the seal of truth.)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
--
You are never dedicated to something you have complete
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
All works fine, but you need to use version 2.4 of the deploy plugin.
Full working example is here:
http://people.apache.org/~jvanzyl/les.tgz
There's a plugin and a project that uses the plugin. Build/install the
plugin, then mvn clean deploy the test project and you'll see it
doesn't deploy.
On 26-Feb-09, at 7:59 AM, Les Hazlewood wrote:
I _just_ saw a maven.deploy.skip property that the existing 2.4
deploy
plugin will check. I'm perfectly fine with doing what you suggest
Jason,
thanks very much for the recommendation (I don't care about the minor
inefficiency in this case).
But, that property can be set programmatically via another plugin?
Maybe something like the following?
/**
* @parameter expression=${project}
*/
private MavenProject mavenProject;
...
public void execute() {
boolean shouldSkip = //determined in some way
if ( shouldSkip ) {
final Properties projectProperties = mavenProject.getProperties();
projectProperties.put( maven.deploy.skip, Boolean.TRUE);
}
...
}
Will that work?
I'm not aware of when property binding occurs - i.e. if their values
can be
changed by plugins or if they're permanently set before the
lifecycle starts
after reading the pom.
Thanks for any clarification - I think I'm close!
Les
On Thu, Feb 26, 2009 at 10:28 AM, Jason van Zyl
jvan...@sonatype.comwrote:
Not sure if this works in 2.x (it should, I know it works in 3.x)
but I'll
make an enforcer rule, or small plugin in the validate phase, which
will
detect the changed. Based on the outcome set the skip deploy option
programmatically. Not the most efficient as the build will still
happen but
the JAR will not get deployed and the build won't fail.
On 25-Feb-09, at 2:56 PM, 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
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
--
Simplex sigillum veri. (Simplicity is the seal of truth.)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
--
You are never dedicated to something you have complete
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
Beautiful - I just tested with 2.4 and it works wonderfully. Thanks to all
who contributed to this thread!
Cheers,
Les
On Thu, Feb 26, 2009 at 11:48 AM, Jason van Zyl jvan...@sonatype.comwrote:
All works fine, but you need to use version 2.4 of the deploy plugin.
Full working example is here:
http://people.apache.org/~jvanzyl/les.tgzhttp://people.apache.org/%7Ejvanzyl/les.tgz
There's a plugin and a project that uses the plugin. Build/install the
plugin, then mvn clean deploy the test project and you'll see it doesn't
deploy.
On 26-Feb-09, at 7:59 AM, Les Hazlewood wrote:
I _just_ saw a maven.deploy.skip property that the existing 2.4 deploy
plugin will check. I'm perfectly fine with doing what you suggest Jason,
thanks very much for the recommendation (I don't care about the minor
inefficiency in this case).
But, that property can be set programmatically via another plugin?
Maybe something like the following?
/**
* @parameter expression=${project}
*/
private MavenProject mavenProject;
...
public void execute() {
boolean shouldSkip = //determined in some way
if ( shouldSkip ) {
final Properties projectProperties = mavenProject.getProperties();
projectProperties.put( maven.deploy.skip, Boolean.TRUE);
}
...
}
Will that work?
I'm not aware of when property binding occurs - i.e. if their values can
be
changed by plugins or if they're permanently set before the lifecycle
starts
after reading the pom.
Thanks for any clarification - I think I'm close!
Les
On Thu, Feb 26, 2009 at 10:28 AM, Jason van Zyl jvan...@sonatype.com
wrote:
Not sure if this works in 2.x (it should, I know it works in 3.x) but
I'll
make an enforcer rule, or small plugin in the validate phase, which will
detect the changed. Based on the outcome set the skip deploy option
programmatically. Not the most efficient as the build will still happen
but
the JAR will not get deployed and the build won't fail.
On 25-Feb-09, at 2:56 PM, 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
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
--
Simplex sigillum veri. (Simplicity is the seal of truth.)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail:
Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
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
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
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 br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
