You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jason Chaffee (JIRA)" <ji...@codehaus.org> on 2009/03/15 05:52:13 UTC
[jira] Created: (MARTIFACT-35) Allow the ability to "plugin" or
"inject" different versioning implementations
Allow the ability to "plugin" or "inject" different versioning implementations
------------------------------------------------------------------------------
Key: MARTIFACT-35
URL: http://jira.codehaus.org/browse/MARTIFACT-35
Project: Maven Artifact
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Jason Chaffee
Currently, maven's versioning for snapshot builds is ${timestamp}-${build.number}. However, it is often the case that companies have their own versioning requirements or conventions and there are different models for versioning such as OSGI, etc. For example, eclipse plugin versioning proposal has the following:
the major segment indicates breakage in the API
the minor segment indicates "externally visible" changes
the service segment indicates bug fixes and the change of development stream
the qualifier segment indicates a particular build
This may result their snapshot builds take the the form of 1.2.1.v20050506 or 1.2.1.34 depending on they wanted to represent the qualifier segment. They could use the timestamp in the form "v20050506" or they could use a build number "34".
Also, many times companies would like to utilize the build number in the final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a release is done. Instead of making the final artifact 1.2.1, they may wish to make the final artifact 1.2.1.34 or 1.2.1-34.
I think it would be ok for maven to only actually implement their default strategy, but I think allowing a different implementation to be injected based on the user's needs would be extremely valuable.
Another option is change the way <version> works in the pom. Instead of entering a string, perhaps it could have child elements such as the following:
<version>
<major>1</major>
<minor>2</minor>
<service>1</service>
<qualifer>${project.build.number}</qualifer>
<separator>.</separator>
</version>
Note: qualifer may be the same notion as classifier. However, it would be nice to be able to specify to use a "." or a "-" or a "_" separator based on whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or
"inject" different versioning implementations
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169604#action_169604 ]
Jason van Zyl commented on MARTIFACT-35:
----------------------------------------
It was already discussed on the list. And I would -1 anyone trying to allow this type of variant. We will end up having to maintain it and all the problems with interactions between different projects that have incommensurate schemes. You have the source code so you can "fix" whatever you need to and you can support it.
> Allow the ability to "plugin" or "inject" different versioning implementations
> ------------------------------------------------------------------------------
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is ${timestamp}-${build.number}. However, it is often the case that companies have their own versioning requirements or conventions and there are different models for versioning such as OSGI, etc. For example, eclipse plugin versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or 1.2.1.34 depending on they wanted to represent the qualifier segment. They could use the timestamp in the form "v20050506" or they could use a build number "34".
> Also, many times companies would like to utilize the build number in the final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a release is done. Instead of making the final artifact 1.2.1, they may wish to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default strategy, but I think allowing a different implementation to be injected based on the user's needs would be extremely valuable.
> Another option is change the way <version> works in the pom. Instead of entering a string, perhaps it could have child elements such as the following:
> <version>
> <major>1</major>
> <minor>2</minor>
> <service>1</service>
> <qualifer>${project.build.number}</qualifer>
> <separator>.</separator>
> </version>
> Note: qualifer may be the same notion as classifier. However, it would be nice to be able to specify to use a "." or a "-" or a "_" separator based on whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or
"inject" different versioning implementations
Posted by "Jason Chaffee (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169606#action_169606 ]
Jason Chaffee commented on MARTIFACT-35:
----------------------------------------
I can understand where you are coming from that you might end up having to support it, but couldn't this simply be a product of a good API and implementation that allows users to take the code and inject their own implementation? Maybe what I am asking for more than anything is an easy way to "fix" the code to enable this, because it is anything but easy to do with the 2.x implementation. Maybe mercury will allow for this? I don't know.
Also, perhaps my ideas/comments in the original comment are not the correct way to go about ultimately supporting this, but I was hoping by filing an issue it would create some dialogue.
I will try to figure it out on my own.
> Allow the ability to "plugin" or "inject" different versioning implementations
> ------------------------------------------------------------------------------
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is ${timestamp}-${build.number}. However, it is often the case that companies have their own versioning requirements or conventions and there are different models for versioning such as OSGI, etc. For example, eclipse plugin versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or 1.2.1.34 depending on they wanted to represent the qualifier segment. They could use the timestamp in the form "v20050506" or they could use a build number "34".
> Also, many times companies would like to utilize the build number in the final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a release is done. Instead of making the final artifact 1.2.1, they may wish to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default strategy, but I think allowing a different implementation to be injected based on the user's needs would be extremely valuable.
> Another option is change the way <version> works in the pom. Instead of entering a string, perhaps it could have child elements such as the following:
> <version>
> <major>1</major>
> <minor>2</minor>
> <service>1</service>
> <qualifer>${project.build.number}</qualifer>
> <separator>.</separator>
> </version>
> Note: qualifer may be the same notion as classifier. However, it would be nice to be able to specify to use a "." or a "-" or a "_" separator based on whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or
"inject" different versioning implementations
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl closed MARTIFACT-35.
----------------------------------
Resolution: Won't Fix
We will gravitate toward a single standard. We don't need to support N variants.
> Allow the ability to "plugin" or "inject" different versioning implementations
> ------------------------------------------------------------------------------
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is ${timestamp}-${build.number}. However, it is often the case that companies have their own versioning requirements or conventions and there are different models for versioning such as OSGI, etc. For example, eclipse plugin versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or 1.2.1.34 depending on they wanted to represent the qualifier segment. They could use the timestamp in the form "v20050506" or they could use a build number "34".
> Also, many times companies would like to utilize the build number in the final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a release is done. Instead of making the final artifact 1.2.1, they may wish to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default strategy, but I think allowing a different implementation to be injected based on the user's needs would be extremely valuable.
> Another option is change the way <version> works in the pom. Instead of entering a string, perhaps it could have child elements such as the following:
> <version>
> <major>1</major>
> <minor>2</minor>
> <service>1</service>
> <qualifer>${project.build.number}</qualifer>
> <separator>.</separator>
> </version>
> Note: qualifer may be the same notion as classifier. However, it would be nice to be able to specify to use a "." or a "-" or a "_" separator based on whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or
"inject" different versioning implementations
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169607#action_169607 ]
Jason van Zyl commented on MARTIFACT-35:
----------------------------------------
Mercury allows for any implementation, but Mercury is not Maven. Mercury was designed to support any arbitrary system. That does not mean we want to allow these arbitrary capabilities in Maven. In fact we don't. Allowing arbitrary version schemes requires a lot of work in Maven to support. Everything would need to support it and your clients need to really understand the real cost of wanting something different. I ardently believe that we don't need N version systems. One decent one like OSGi is a good start and we can help improve that one.
> Allow the ability to "plugin" or "inject" different versioning implementations
> ------------------------------------------------------------------------------
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is ${timestamp}-${build.number}. However, it is often the case that companies have their own versioning requirements or conventions and there are different models for versioning such as OSGI, etc. For example, eclipse plugin versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or 1.2.1.34 depending on they wanted to represent the qualifier segment. They could use the timestamp in the form "v20050506" or they could use a build number "34".
> Also, many times companies would like to utilize the build number in the final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a release is done. Instead of making the final artifact 1.2.1, they may wish to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default strategy, but I think allowing a different implementation to be injected based on the user's needs would be extremely valuable.
> Another option is change the way <version> works in the pom. Instead of entering a string, perhaps it could have child elements such as the following:
> <version>
> <major>1</major>
> <minor>2</minor>
> <service>1</service>
> <qualifer>${project.build.number}</qualifer>
> <separator>.</separator>
> </version>
> Note: qualifer may be the same notion as classifier. However, it would be nice to be able to specify to use a "." or a "-" or a "_" separator based on whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or
"inject" different versioning implementations
Posted by "Jason Chaffee (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169603#action_169603 ]
Jason Chaffee commented on MARTIFACT-35:
----------------------------------------
I wasn't suggesting supporting N variants. I was suggesting allowing users the ability to supply their own variant. Maven would only have to support their own variant. Basically, I am suggesting a better design/API that allows a company to inject their own implementation without the internal workings of maven dependent on what the actual format is. This is simply good engineering.
Also, why close the but so quickly...since it has only been a matter of minutes no one else will have the chance to see it, vote on it, or make their own judgements if it is worth while.
This contributes to the feeling that the maven team isn't really listening to the users and what they really want in a build system. This request isn't personally coming from me, but from two different companies that have asked me to "fix" maven's versioning system because it simply does not work for them and they cannot change the way they do it for certain reasons.
> Allow the ability to "plugin" or "inject" different versioning implementations
> ------------------------------------------------------------------------------
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is ${timestamp}-${build.number}. However, it is often the case that companies have their own versioning requirements or conventions and there are different models for versioning such as OSGI, etc. For example, eclipse plugin versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or 1.2.1.34 depending on they wanted to represent the qualifier segment. They could use the timestamp in the form "v20050506" or they could use a build number "34".
> Also, many times companies would like to utilize the build number in the final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a release is done. Instead of making the final artifact 1.2.1, they may wish to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default strategy, but I think allowing a different implementation to be injected based on the user's needs would be extremely valuable.
> Another option is change the way <version> works in the pom. Instead of entering a string, perhaps it could have child elements such as the following:
> <version>
> <major>1</major>
> <minor>2</minor>
> <service>1</service>
> <qualifer>${project.build.number}</qualifer>
> <separator>.</separator>
> </version>
> Note: qualifer may be the same notion as classifier. However, it would be nice to be able to specify to use a "." or a "-" or a "_" separator based on whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or
"inject" different versioning implementations
Posted by "Jason Chaffee (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169611#action_169611 ]
Jason Chaffee commented on MARTIFACT-35:
----------------------------------------
Ok, this is the dialogue I was hoping for. :)
Again, I fully understand not wanting to allow arbitrary version schemes...I really do. I have even tried to convince the powers to be use the current maven versioning system. However, sometimes it is very hard to convince people it is the right way to go as they are "stuck" in what they are used to and have known. However, it is much easier to convince them to use OSGI or a standard like that as they already trying to get their particular industry to move towards OSGI. Therefore, if maven moves to using a documented standard versioning nomenclature I think that will solve their problem.
> Allow the ability to "plugin" or "inject" different versioning implementations
> ------------------------------------------------------------------------------
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is ${timestamp}-${build.number}. However, it is often the case that companies have their own versioning requirements or conventions and there are different models for versioning such as OSGI, etc. For example, eclipse plugin versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or 1.2.1.34 depending on they wanted to represent the qualifier segment. They could use the timestamp in the form "v20050506" or they could use a build number "34".
> Also, many times companies would like to utilize the build number in the final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a release is done. Instead of making the final artifact 1.2.1, they may wish to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default strategy, but I think allowing a different implementation to be injected based on the user's needs would be extremely valuable.
> Another option is change the way <version> works in the pom. Instead of entering a string, perhaps it could have child elements such as the following:
> <version>
> <major>1</major>
> <minor>2</minor>
> <service>1</service>
> <qualifer>${project.build.number}</qualifer>
> <separator>.</separator>
> </version>
> Note: qualifer may be the same notion as classifier. However, it would be nice to be able to specify to use a "." or a "-" or a "_" separator based on whatever format your company abides by.
--
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