[ http://jira.codehaus.org/browse/MRELEASE-124?page=comments#action_66246 ] 

Brett Porter commented on MRELEASE-124:
---------------------------------------

I think this is still a good default behaviour (As timestamps can get removed 
in the future where releases are less likely to).

However, I'd be ok with an allowTimestampedSnapshots flag.

I'd probably suggest 1) or 2) are better solutions though. We should consider 
'vendor' releases in the versioning scheme in Maven 2.1 which would make this 
easier.

> Impossible to depend on a deployed snapshot
> -------------------------------------------
>
>          Key: MRELEASE-124
>          URL: http://jira.codehaus.org/browse/MRELEASE-124
>      Project: Maven 2.x Release Plugin
>         Type: Bug

>     Versions: 2.0-beta-4
>     Reporter: Mike Perham
>     Priority: Critical

>
>
> I have a SNAPSHOT of the war plugin that I built and deployed to fix a 
> blocker for us (MWAR-39) that has not been released.  In my POM, I refer to 
> it like this:
>     <build>
>       <plugins>
>         <plugin>
>           <artifactId>maven-war-plugin</artifactId>
>           <version>2.0.1-20060525.222101-1</version>
> I did this specifically so the release plugin would not think it was a 
> SNAPSHOT so I could release the module.  But when I do try to release, I get 
> this error:
> [INFO] Can't release project due to non released dependencies :
>     
> org.apache.maven.plugins:maven-war-plugin:maven-plugin:2.0.1-SNAPSHOT:runtime
> in project 'UDDI WAR' (com.webify.fabric:fabric-uddi-web:war:1.1.0-SNAPSHOT)
> This is because in ArtifactUtils.isSnapshot, it specifically disallows the 
> version pattern created by the deploy plugin.
> So consider my usecase: I'm Joe Corporate, a user who needs a war bug fix in 
> their build process ASAP.  I build and deploy the latest war plugin to my 
> internal repo and reference that explicit timestamp version in my build 
> process.  Now I can understand why you disallow this because if I try to 
> build outside of our corporate walls, it will not work.  But I can't use the 
> release plugin to release either because it requires me to check the modified 
> POMs into my SCM and the war plugin is in Apache's SCM and I can't check into 
> it.
> There's only two hack workarounds I can think of: 1) explicitly reversion the 
> jar to not include SNAPSHOT or the specific timestamp pattern. 2) Check the 
> war plugin into our own SCM and release from there, effectively forking the 
> code.
> Your thoughts?  How can we fix bugs in the build process locally and still 
> use the release plugin?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to