You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2005/06/06 02:10:22 UTC
[jira] Created: (MNG-449) plugin development without release use case
plugin development without release use case
-------------------------------------------
Key: MNG-449
URL: http://jira.codehaus.org/browse/MNG-449
Project: Maven 2
Type: Bug
Components: maven-artifact
Versions: 2.0-alpha-2
Reporter: Brett Porter
Fix For: 2.0-alpha-3
currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-449) plugin development without release use case
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
John Casey updated MNG-449:
---------------------------
Remaining Estimate: 3 hours
Original Estimate: 10800
need to write a new mojo for the plugin-plugin to update the version in the plugin registry when a plugin is installed...also, need to workup an IT to specifically test -cpl AND --check-plugin-latest.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-3
>
> Original Estimate: 3 hours
> Remaining: 3 hours
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Reopened: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
Brett Porter reopened MNG-449:
------------------------------
doesn't actually fix it. the plugin resolver tries to resolve RELEASE still (as it should), and doesn't know to try LATEST. IT could possibly try LATEST if RELEASE was not resolvable... but that only helps when starting out.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-1
>
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-449) plugin development without release use case
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
John Casey closed MNG-449:
--------------------------
Resolution: Fixed
added the updateRegistry mojo to the install phase for updating the plugin-registry.xml iff it's enabled.
the -cpl issue was actually caused by another issue (the one with RELEASE landing in the resolved version after failing to find a release version of the plugin).
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-3
>
> Original Estimate: 3 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-449) plugin development without release use case
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=comments#action_47878 ]
John Casey commented on MNG-449:
--------------------------------
I don't understand. I just tested this, and after installing maven-projecthelp-plugin - with the plugin registry enabled - the new projecthelp entry was in fact recorded.
As for -cpl, it should be working again. Without it, there's no way it0013 and it0020 will work as-is...they will require some sort of hackery with <defaultGoal/> and a multi-module build in order to make this feature testable from the it0000 series.
What exactly is it you want me to do here? Checking LATEST will result in normal users potentially getting snapshot plugin versions (ie. unstable), so I don't think that's a great way to go. On the other hand, some people (namely plugin devs) will want to be able to use the snapshot versions of plugins, so sticking with RELEASE doesn't really work either. I'm not sure what would happen if we allowed a locally installed -SNAPSHOT version to persist (ie. will it resolve the snapshot updates on the remote repo?), but one thing is sure about that: the developer would have to run an install on that plugin at least once, in order to get the entry into the plugin registry (or hand-edit).
All of the above seems pretty nuanced and more than a little unintuitive to me. I think, since -cpl is currently working and NOT the default, we should just leave it alone. We have bigger fish to fry when it comes to plugin usage, IMO.
For example, executing a plugin within the same build in which it was installed/built (esp. when that build is a reactored build, which it is likely to be).
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-4
>
> Original Estimate: 3 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
Brett Porter updated MNG-449:
-----------------------------
Description:
currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
was:
currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
Fix Version: (was: 2.0-beta-1)
2.0-beta-2
Complexity: Intermediate
Environment:
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Fix For: 2.0-beta-2
>
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=comments#action_46638 ]
Brett Porter commented on MNG-449:
----------------------------------
note also that -cpl doesn't appear to be working.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Fix For: 2.0-beta-2
>
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Reopened: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
Brett Porter reopened MNG-449:
------------------------------
sorry to whine again....
"this is really annoying. we need to make it such that any invocation of "m2 install" makes that plugin the default"
sorry, I didn't mean to fix -cpl. To be honest, I'd rather remove it, or perhaps make it the default? Will that unnecessarily query the remote repo?
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-3
>
> Original Estimate: 3 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
Brett Porter closed MNG-449:
----------------------------
Assign To: John Casey (was: Brett Porter)
Resolution: Fixed
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-1
>
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-449) plugin development without release use case
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=comments#action_47744 ]
John Casey commented on MNG-449:
--------------------------------
sorry, that issue was MNG-832.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-3
>
> Original Estimate: 3 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=comments#action_40627 ]
Brett Porter commented on MNG-449:
----------------------------------
the latter may be necessary anyway, for a use case of library development when using unbounded versions when dependency mediation is in play. Perhaps the best thing to do is to update on local install, if the local version is > the current release version.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Fix For: 2.0-alpha-3
>
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-449) plugin development without release use case
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
John Casey closed MNG-449:
--------------------------
Resolution: Fixed
Should now be fixed. I updated the CLI code to fix disabling of the plugin registry, and forced resolution of LATEST metadata during the version resolution process.
NOTE: LATEST metadata resolution isn't enabled unless you use '--check-plugin-latest' or put in <usePluginLatest/> in settings.xml.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-1
>
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=comments#action_47927 ]
Brett Porter commented on MNG-449:
----------------------------------
or perhaps setting the release metadata on plugin installation, since it is only local? risky for deploy though, only want that if they are actually releasing.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-4
>
> Original Estimate: 3 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Reopened: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
Brett Porter reopened MNG-449:
------------------------------
Assign To: (was: John Casey)
this is really annoying. we need to make it such that any invocation of "m2 install" makes that plugin the default
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Fix For: 2.0-beta-2
>
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=comments#action_47926 ]
Brett Porter commented on MNG-449:
----------------------------------
but our plugin snapshot repos are separate, so users won't get them unless they configure it, so I don't see any harm in switching to -cpl, as long as that doesn't cause more frequent update checks.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-4
>
> Original Estimate: 3 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-449) plugin development without release use case
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
John Casey closed MNG-449:
--------------------------
Resolution: Fixed
removed -cpl and -npl (no plugin latest?) and made plugin version resolution primarily based on LATEST metadata, with RELEASE used as a backup.
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-4
>
> Original Estimate: 3 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
Brett Porter updated MNG-449:
-----------------------------
Fix Version: (was: 2.0-beta-3)
2.0-beta-4
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-beta-4
>
> Original Estimate: 3 hours
> Time Spent: 2 hours
> Remaining: 0 minutes
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-449) plugin development without release use case
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-449?page=all ]
Brett Porter updated MNG-449:
-----------------------------
Fix Version: (was: 2.0-alpha-3)
2.0-beta-1
> plugin development without release use case
> -------------------------------------------
>
> Key: MNG-449
> URL: http://jira.codehaus.org/browse/MNG-449
> Project: Maven 2
> Type: Bug
> Components: maven-artifact
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Fix For: 2.0-beta-1
>
>
> currently, a plugin used from the command line or a POM without a version uses the latest release. This is inconvenient and confusing when you are developing a plugin as you need to do the first install with -DupdateReleaseInfo to get it to use your version.
> There needs to be a better way to do this. It may be solved by existing issues relating to the RELEASE and plugin version management. If not, then another alternative might need to be considered, like local installation triggering a RELEASE update.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org