You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Les Hazlewood <le...@hazlewood.com> on 2009/02/25 23:56:14 UTC
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?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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.hazlewood@anjinllc.com [mailto:les.hazlewood@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?
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Conditional plugin execution based on build time behavior - Maven
profiles not sufficient?
Posted by Les Hazlewood <le...@hazlewood.com>.
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 <ws...@gmail.com> wrote:
> On Wed, Feb 25, 2009 at 3:56 PM, Les Hazlewood <le...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Conditional plugin execution based on build time behavior - Maven
profiles not sufficient?
Posted by Wendy Smoak <ws...@gmail.com>.
On Wed, Feb 25, 2009 at 3:56 PM, Les Hazlewood <le...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Conditional plugin execution based on build time behavior - Maven
profiles not sufficient?
Posted by Les Hazlewood <lh...@apache.org>.
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 <jv...@sonatype.com>wrote:
> 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<http://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 <jvanzyl@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
Posted by Jason van Zyl <jv...@sonatype.com>.
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
> <jv...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
Posted by Jason van Zyl <jv...@sonatype.com>.
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
> <jv...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Conditional plugin execution based on build time behavior - Maven
profiles not sufficient?
Posted by Les Hazlewood <le...@hazlewood.com>.
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 <jv...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Conditional plugin execution based on build time behavior - Maven profiles not sufficient?
Posted by Jason van Zyl <jv...@sonatype.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org