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 <[email protected]>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 <[email protected] >> >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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> > 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: [email protected] > For additional commands, e-mail: [email protected] > >
