You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Mike Perham (JIRA)" <ji...@codehaus.org> on 2006/05/30 21:02:43 UTC

[jira] Created: (MRELEASE-124) Impossible to depend on a deployed snapshot

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


[jira] Updated: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Tuomas Kiviaho (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tuomas Kiviaho updated MRELEASE-124:
------------------------------------

    Attachment: maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch

Patched against revision 552741

> Impossible to depend on a deployed snapshot
> -------------------------------------------
>
>                 Key: MRELEASE-124
>                 URL: http://jira.codehaus.org/browse/MRELEASE-124
>             Project: Maven 2.x Release Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-4
>            Reporter: Mike Perham
>            Priority: Critical
>         Attachments: maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, releasePluginIgnoreSnapshot.patch
>
>
> 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

        

[jira] Commented: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Brian Topping (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MRELEASE-124?page=comments#action_77982 ] 
            
Brian Topping commented on MRELEASE-124:
----------------------------------------

I should add this patch is against revision 465377.  

> Impossible to depend on a deployed snapshot
> -------------------------------------------
>
>                 Key: MRELEASE-124
>                 URL: http://jira.codehaus.org/browse/MRELEASE-124
>             Project: Maven 2.x Release Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-4
>            Reporter: Mike Perham
>            Priority: Critical
>         Attachments: releasePluginIgnoreSnapshot.patch
>
>
> 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

        

[jira] Commented: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Mike Perham (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MRELEASE-124?page=comments#action_66268 ] 

Mike Perham commented on MRELEASE-124:
--------------------------------------

Interesting.  I can put the timestamp build in a <pluginManagement> section of a parent POM, release that and then use it in a WAR module which can be released.

> 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


[jira] Commented: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Tuomas Kiviaho (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104908 ] 

Tuomas Kiviaho commented on MRELEASE-124:
-----------------------------------------

John Casey has written a plugin that could automate unique versioning <http://www.commonjava.org/~jdcasey/maven-misc/plugins/snapshot-pin-maven-plugin.zip>. Blog at <http://blogs.sonatype.com/john/2007/08/14/1187117747444.html>. Wether this plugin cover parent version of pom also along with dependencies is unknown to me.

> Impossible to depend on a deployed snapshot
> -------------------------------------------
>
>                 Key: MRELEASE-124
>                 URL: http://jira.codehaus.org/browse/MRELEASE-124
>             Project: Maven 2.x Release Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-4
>            Reporter: Mike Perham
>            Priority: Critical
>         Attachments: maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, releasePluginIgnoreSnapshot.patch, ReleaseUtils.rev552741.patch
>
>
> 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

        

[jira] Commented: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
    [ 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


[jira] Closed: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brett Porter closed MRELEASE-124.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0-beta-7

applied, thanks for that!

> Impossible to depend on a deployed snapshot
> -------------------------------------------
>
>                 Key: MRELEASE-124
>                 URL: http://jira.codehaus.org/browse/MRELEASE-124
>             Project: Maven 2.x Release Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-4
>            Reporter: Mike Perham
>            Assignee: Brett Porter
>            Priority: Critical
>             Fix For: 2.0-beta-7
>
>         Attachments: maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, releasePluginIgnoreSnapshot.patch, ReleaseUtils.rev552741.patch
>
>
> 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

        

[jira] Updated: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Tuomas Kiviaho (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tuomas Kiviaho updated MRELEASE-124:
------------------------------------

    Attachment: ReleaseUtils.rev552741.patch

> Impossible to depend on a deployed snapshot
> -------------------------------------------
>
>                 Key: MRELEASE-124
>                 URL: http://jira.codehaus.org/browse/MRELEASE-124
>             Project: Maven 2.x Release Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-4
>            Reporter: Mike Perham
>            Priority: Critical
>         Attachments: maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, releasePluginIgnoreSnapshot.patch, ReleaseUtils.rev552741.patch
>
>
> 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

        

[jira] Updated: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Brian Topping (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MRELEASE-124?page=all ]

Brian Topping updated MRELEASE-124:
-----------------------------------

    Attachment: releasePluginIgnoreSnapshot.patch

Patch with test case for new allowTimestampedSnapshots flag.

> Impossible to depend on a deployed snapshot
> -------------------------------------------
>
>                 Key: MRELEASE-124
>                 URL: http://jira.codehaus.org/browse/MRELEASE-124
>             Project: Maven 2.x Release Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-4
>            Reporter: Mike Perham
>            Priority: Critical
>         Attachments: releasePluginIgnoreSnapshot.patch
>
>
> 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

        

[jira] Updated: (MRELEASE-124) Impossible to depend on a deployed snapshot

Posted by "Tuomas Kiviaho (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tuomas Kiviaho updated MRELEASE-124:
------------------------------------

    Attachment: maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch

> Impossible to depend on a deployed snapshot
> -------------------------------------------
>
>                 Key: MRELEASE-124
>                 URL: http://jira.codehaus.org/browse/MRELEASE-124
>             Project: Maven 2.x Release Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-4
>            Reporter: Mike Perham
>            Priority: Critical
>         Attachments: maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, releasePluginIgnoreSnapshot.patch
>
>
> 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