mutable CVS User
Hi,
I would like to have a mutable user of the cvs-connection, since the changes
are done of different users. So I tried to do it like this:
scm
connectionscm:cvs:pserver:${CVS_USER}@CVS-URL/connection
/scm
The ${CVS_USER} is a property in settings.xml. This works fine for the first
time, but when doing mvn release:clean release:prepare maven substitutes the
CVS_USER for the current user and checks the pom in like this:
scm
connectionscm:cvs:pserver:user@CVS-URL/connection
/scm
Is there another way to have the CVS user mutable?
Thanks in advance,
Franz
--
View this message in context:
http://www.nabble.com/mutable-CVS-User-tp17823535p17823535.html
Sent from the Maven - SCM mailing list archive at Nabble.com.
Re: mutable CVS User
Personnally, when I used cvs, I prefered to used ext protocol with ssh
because the pserver isn't independant of the user.
If you can't migrate to ext protocol (just need a ssh access on the cvs
server), you don't have an other solution that the one you use. You can
report a bug on the release plugin to fix it (
http://jira.codehaus.org/browse/MRELEASE)
Emmanuel
On Fri, Jun 13, 2008 at 3:33 PM, fma-001 [EMAIL PROTECTED] wrote:
Hi,
I would like to have a mutable user of the cvs-connection, since the
changes
are done of different users. So I tried to do it like this:
scm
connectionscm:cvs:pserver:${CVS_USER}@CVS-URL/connection
/scm
The ${CVS_USER} is a property in settings.xml. This works fine for the
first
time, but when doing mvn release:clean release:prepare maven substitutes
the
CVS_USER for the current user and checks the pom in like this:
scm
connectionscm:cvs:pserver:user@CVS-URL/connection
/scm
Is there another way to have the CVS user mutable?
Thanks in advance,
Franz
--
View this message in context:
http://www.nabble.com/mutable-CVS-User-tp17823535p17823535.html
Sent from the Maven - SCM mailing list archive at Nabble.com.
[result] Release Wagon 1.0 beta 3
+1 (binding): Brett, John, Emmanuel, Brian other +1: James I'll proceed with the release On 04/06/2008, at 5:08 PM, Brett Porter wrote: Hi The Wagon 1.0-beta-3 candidate has been staged. This release includes 59 fixes. You can take a look at the release notes here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335styleName=Htmlversion=12544 While the binaries, including the sources, signatures and checksums, can be downloaded here: http://people.apache.org/~brett/staged-releases-wagon The tag is: http://svn.apache.org/repos/asf/maven/wagon/tags/wagon-1.0-beta-3 Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... The vote will be open for 72 hours. Thanks, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for Maven Project 2.1
Hi Shane, This looks like a pretty positive step. Is the code on your branch for MNG-3536 an implementation of this? How far along is it? I have some questions. Bear in mind it's late on Friday, so I may just be a bit slow :) - how many classes is the typical model assembly going to take? Given how frequently they are run - the addition of ModelProperty and ModelContainer objects in addition to the domain model classes could be quite a lot? - how are maps handled by #collection? - it'd be good to keep the URI we currently use for the model as a base - what happens when you have a collection in a collection? eg project/ build/pluginManagement/plugins/plugin/dependencies/dependency/ exclusions#collection - the removal of reflection seems positive - though this is effectively done by the data source implementation of queryFor now - right? So we'd generate one of them for the domain model? - should system property policy be context policy instead? - the definition of profiles was covered quite briefly - is this the same behaviour as present? This has become possibly the most complicated part of the current builder and worth visiting in more detail. - what does 2. For (A), (C-F), : values... mean? What is (a), (C-F) referring to? - I found the *management rules (3 and 4) to be incomplete - they only refer to merging in missing versions based on a/g id. Dependencies have additional ID components, and there are other elements in the container that need to merge. I think you can drop the does not contain a version part, and essentially join the most specialised *management container with the same coordinate (g:a for plugin, g:a:c:t for dependency) last - how does this interpolation relate to John's proposal? Do we need to interpolate plugin configuration only at execution time? - how does this change in the method of interpolation relate to the population of plugin configuration in the first place - given that still uses the original expression evaluator for things outside the project? - are we disposing of the inherited flag for plugins? - for the latter rules: (7) why do we allow multiple extension versions? (8) why delete the whole plugin container if a version differs? (10) what are the rules for configuration under an execution / plugin? Or is this still left up to the plugin manager to merge? - how do the URIs relate to the eventual XML marshalling, particularly in the case of extending the model? - how does the versioning work? If the URIs have a different base, won't they refuse to join any elements under this approach? Or is it expected to transform v1 to v2 first, then process them all as v2? One thing I'd be interested to see is why each bit was introduced in terms of problems we're solving. Cheers, Brett On 07/06/2008, at 7:44 AM, Shane Isbell wrote: I've created proposal for the maven-project module in 2.1: http://docs.codehaus.org/display/MAVENUSER/Maven+Project Thanks, Shane -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Dynamic POM Build Section
Hi John, I haven't looked at the code, but angling at it purely from the proposal... it does make sense - the problem in the related issues is forking lifecycles. In general, under the current structure, keeping the pre-interpolated model and applying that after forking would make sense. This solution effectively ensures that. That said, this solution does sound a bit heavy handed. Even though we have a bunch of ITs, something about this feels like it might break something else. Do you have any thoughts on areas of risk outside what the ITs already cover? Cheers, Brett On 12/06/2008, at 2:17 AM, John Casey wrote: Hi everyone, As I'm sure you've noticed from the discussion on this list and my commit logs, I've been working to solve a problem between concrete interpolation of the POM at project-construction time and the need to update plugin configurations to reflect changing state in the project instance as the build progresses. The full proposal is here: http://docs.codehaus.org/display/MAVEN/Dynamic+POM+Build+Sections And the relevant JIRAs are mainly: - MNG-3530 - MNG-3355 though there are others that doubtless touch on this problem. The upshot is that our approach of trying to interpolate the entire POM into a concrete version of itself when the project instance is constructed is misguided. We've always done this to some degree or other, with build paths being a notably varying aspect of this in past releases. The issues surrounding build paths have been mainly concerned with the difficulty of handling the alignment of relative paths with the project base directory prior to making these paths available as interpolation values. However, it's currently possible for any part of the POM to be modified by a plugin. This is an obvious threat to the declarative nature of the POM in some respects, since it seems intuitive that having setArtifacts() and setDependencies() methods on the project class should mean that a plugin can add these things legitimately. In reality, this couldn't be a worse idea, since it affects Maven's ability to report and manage these dependencies - not to mention the basic need to have a dependency set that is static and expressed for your project - is compromised by such an action. So, it makes sense to say that at least part of the POM should be purely declarative, and set in stone once the project instance is created. On the other hand, in order to support necessary build-time functionality, the build section must be free from this constraint. If the clover plugin can't reset the project.build.directory, project.build.outputDirectory, and so forth, how can it do its work without polluting the main set of classes which will be included in the project's output artifact? Therefore, this proposal suggests the following: mask out the build section of the POM from initial interpolation, with the exception of plugin coordinates and extensions (this is necessary to allow Maven's core components to formulate the build process properly). Then, before each plugin executes, re-interpolate only this build section using up-to-date information from the project information. Finally, in order to accommodate modifications to the project's build section itself - which is the whole point of this exercise, after all - back-propagate changes to this section into the original, uninterpolated build section for inclusion in future plugin executions. The proposal above is detailed on the Maven wiki at the link above. The wiki page also includes links to relevant MNG issues, and the location of the feature branch I've already modified to perform in exactly the way I've mentioned. All tests are passing on this branch, so I'd like to get input from other developers on this and hopefully get it merged back to the main 2.0.x branch for inclusion in 2.0.10 before it goes stale. Let me know what you think. -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
A non-binding +1, I'm all for world-class artifact resolution! Mark 2008/6/13 Jason van Zyl [EMAIL PROTECTED]: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 Raphaël 2008/6/13 Jason van Zyl [EMAIL PROTECTED]: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
canvasing opinions about a 2.1 alpha release
I went through the unscheduled bunch of issues looking for reported 2.1 regressions this morning, and in what probably makes a clear statement about my sanity, cleaned up a number of the 180 issues and scheduled some for 2.0.x / 2.1 depending on their type (for those that couldn't be closed out). I expect I missed a few duplicates, etc. What remains for 2.1-alpha-1 is just the list of regressions, minor updates, and backwards compatibility documentation (39 issues in total, though some may be related): * http://tinyurl.com/5fuwcm * http://tinyurl.com/6k49gt I believe we should start to knock these off, and prepare for an alpha release as is, and wanted to see what others thought. To cover the inevitable questions: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. The only thing I care about right now is getting a release out that - to the best of our knowledge - doesn't have any regressions from 2.0.x. This is really a necessary platform before making further, bigger changes. The sooner it gets out, the more time the current changes will have to be exposed before a final 2.1 release. - Why not add new feature X first? There are a bunch of good things going on (I count 8 active feature branches). As good as each is, none are ready to be merged on to trunk today, and the time until they are ready is not predictable. Releasing first doesn't harm the acceptance of these, or ability to make those changes. We just need more exposure to the changes that have already been made, and to narrow down the potential sources of regressions. So, thoughts? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: canvasing opinions about a 2.1 alpha release
On Fri, Jun 13, 2008 at 11:28 AM, Brett Porter [EMAIL PROTECTED] wrote: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. [...] best of our knowledge - doesn't have any regressions from 2.0.x. This is really a necessary platform before making further, bigger changes. I know that the roadmap is different, but if I could choose, then I'd be clearly in favor of using this alpha release as the baseline of a new stable release. As you wrote above, there *already are* more than enough good reasons to switch from 2.0 to 2.1 and its been quite some time since the last stable branch. The further, bigger changes could, IMO, be moved to 2.2. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: canvasing opinions about a 2.1 alpha release
Brett Porter wrote: I believe we should start to knock these off, and prepare for an alpha release as is, and wanted to see what others thought. To cover the inevitable questions: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. I would even make a 2.1-beta-1. Betas are by definition stable but not final - and should not be treated as RCs. Alphas on the other hand tend to less trusted by users - who are more reluctant to try them out or use them in commercial projects. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1, have only heard good things about oleg :) On Fri, Jun 13, 2008 at 4:13 AM, Raphaël Piéroni [EMAIL PROTECTED] wrote: +1 Raphaël 2008/6/13 Jason van Zyl [EMAIL PROTECTED]: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 2008/6/13 Jason van Zyl [EMAIL PROTECTED]: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: canvasing opinions about a 2.1 alpha release
Mauro Talevi wrote: Brett Porter wrote: I believe we should start to knock these off, and prepare for an alpha release as is, and wanted to see what others thought. To cover the inevitable questions: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. I would even make a 2.1-beta-1. Betas are by definition stable but not final - and should not be treated as RCs. Alphas on the other hand tend to less trusted by users - who are more reluctant to try them out or use them in commercial projects. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm definitely in favor of a 2.1 release, but I think it should remain an alpha and not switch to beta. A beta release is normally supposed to be feature complete [1], and as Brett said there are several feature branches that may be merged into 2.1 before the GA release. It's probably better that uses won't trust the alpha release quite as much, because I'm guessing there will be problems that haven't been found yet. So it probably shouldn't be used for production builds/releases yet. [1]http://en.wikipedia.org/wiki/Software_release_life_cycle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: canvasing opinions about a 2.1 alpha release
It's definitely alpha. There are so many variances at this point it can't go out as a beta. On 13-Jun-08, at 7:11 AM, Paul Gier wrote: Mauro Talevi wrote: Brett Porter wrote: I believe we should start to knock these off, and prepare for an alpha release as is, and wanted to see what others thought. To cover the inevitable questions: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. I would even make a 2.1-beta-1. Betas are by definition stable but not final - and should not be treated as RCs. Alphas on the other hand tend to less trusted by users - who are more reluctant to try them out or use them in commercial projects. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm definitely in favor of a 2.1 release, but I think it should remain an alpha and not switch to beta. A beta release is normally supposed to be feature complete [1], and as Brett said there are several feature branches that may be merged into 2.1 before the GA release. It's probably better that uses won't trust the alpha release quite as much, because I'm guessing there will be problems that haven't been found yet. So it probably shouldn't be used for production builds/releases yet. [1]http://en.wikipedia.org/wiki/Software_release_life_cycle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: canvasing opinions about a 2.1 alpha release
I would _love_ to do an alpha release before we get into further refactoring efforts. I use 2.1 as my default now, and while I don't venture too far afield into EAR, EJB, or other project types, I believe it's at least stable enough for an alpha-1. Obviously, there is an endless wishlist we could put into 2.1, but even if we do intend to hold 2.1-final off for the end of that list, we should let the existing, large changes soak into the community for awhile to see what's broken that we missed. Also, keep in mind that NetBeans, Eclipse, and IDEA are all using snapshots of 2.1 already. I know there are plenty of issues in those projects - some relating to their respective codebases, and many relating to Maven itself - but the fact that we have multiple releases each making more progress toward stability, and built on 2.1, means it's time to get an alpha out. Now, if we were to move in this direction, do we need to think about a codefreeze branch, to help chase out the lingering problems, so as to avoid slowing down parallel progress on trunk? Considering the diversity of motivations in this group, I don't think it's wise to try to put everyone on the exact same task of cleaning up 2.1-alpha-1 for release...nor is it strictly necessary. If we have a codefreeze branch, we can do the minimal updates to get alpha-1 out, porting these back to trunk as well, do the release from that branch, then leave it dormant or remove it until the next alpha release. Thoughts? -john Brett Porter wrote: I went through the unscheduled bunch of issues looking for reported 2.1 regressions this morning, and in what probably makes a clear statement about my sanity, cleaned up a number of the 180 issues and scheduled some for 2.0.x / 2.1 depending on their type (for those that couldn't be closed out). I expect I missed a few duplicates, etc. What remains for 2.1-alpha-1 is just the list of regressions, minor updates, and backwards compatibility documentation (39 issues in total, though some may be related): * http://tinyurl.com/5fuwcm * http://tinyurl.com/6k49gt I believe we should start to knock these off, and prepare for an alpha release as is, and wanted to see what others thought. To cover the inevitable questions: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. The only thing I care about right now is getting a release out that - to the best of our knowledge - doesn't have any regressions from 2.0.x. This is really a necessary platform before making further, bigger changes. The sooner it gets out, the more time the current changes will have to be exposed before a final 2.1 release. - Why not add new feature X first? There are a bunch of good things going on (I count 8 active feature branches). As good as each is, none are ready to be merged on to trunk today, and the time until they are ready is not predictable. Releasing first doesn't harm the acceptance of these, or ability to make those changes. We just need more exposure to the changes that have already been made, and to narrow down the potential sources of regressions. So, thoughts? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 -john Jason van Zyl wrote: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: canvasing opinions about a 2.1 alpha release
If we don't include the new artifact code, the we need to fix several issues related to reresolving artifacts multiple times. On Jun 13, 2008, at 5:28 AM, Brett Porter [EMAIL PROTECTED] wrote: I went through the unscheduled bunch of issues looking for reported 2.1 regressions this morning, and in what probably makes a clear statement about my sanity, cleaned up a number of the 180 issues and scheduled some for 2.0.x / 2.1 depending on their type (for those that couldn't be closed out). I expect I missed a few duplicates, etc. What remains for 2.1-alpha-1 is just the list of regressions, minor updates, and backwards compatibility documentation (39 issues in total, though some may be related): * http://tinyurl.com/5fuwcm * http://tinyurl.com/6k49gt I believe we should start to knock these off, and prepare for an alpha release as is, and wanted to see what others thought. To cover the inevitable questions: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. The only thing I care about right now is getting a release out that - to the best of our knowledge - doesn't have any regressions from 2.0.x. This is really a necessary platform before making further, bigger changes. The sooner it gets out, the more time the current changes will have to be exposed before a final 2.1 release. - Why not add new feature X first? There are a bunch of good things going on (I count 8 active feature branches). As good as each is, none are ready to be merged on to trunk today, and the time until they are ready is not predictable. Releasing first doesn't harm the acceptance of these, or ability to make those changes. We just need more exposure to the changes that have already been made, and to narrow down the potential sources of regressions. So, thoughts? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 --jason On Jun 13, 2008, at 9:30 PM, John Casey wrote: +1 -john Jason van Zyl wrote: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph- based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pom user-configured goal+phase aliases
Just had a thought, would be nice if the pom exposed someway to define aliases for a set of goals/phases. This would allow project specific names to be used to invoke a set of standard maven phases or a set of plugins. Like I might want o have a release alias, which actually invokes: mvn clean release:prepare release:preform Or a rebuild alias which actually invokes: mvn clean install With pom configuration something like: 8 project build goalAliases goalAlias namerebuild/name goals goalclean/goal goalinstall/goal /goals /goalAlias /goalAliases /build /project 8 Just a thought... --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 Arnaud On Fri, Jun 13, 2008 at 5:01 PM, Jason Dillon [EMAIL PROTECTED] wrote: +1 --jason On Jun 13, 2008, at 9:30 PM, John Casey wrote: +1 -john Jason van Zyl wrote: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 - Fabrice [EMAIL PROTECTED] On Fri, Jun 13, 2008 at 2:20 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
Looks like we're good to go here. Oleg already has a CLA on file, so I will put his account request through. On 13-Jun-08, at 10:02 AM, Fabrice Bellingard wrote: +1 - Fabrice [EMAIL PROTECTED] On Fri, Jun 13, 2008 at 2:20 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 [non-binding] Jason van Zyl wrote: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pom user-configured goal+phase aliases
To me, it seems to detract from the intent of having a well known set of phases so once you know maven, you can pick up any maven build. It reeks of scripting... -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, June 13, 2008 11:11 AM To: Maven Developers List Subject: Pom user-configured goal+phase aliases Just had a thought, would be nice if the pom exposed someway to define aliases for a set of goals/phases. This would allow project specific names to be used to invoke a set of standard maven phases or a set of plugins. Like I might want o have a release alias, which actually invokes: mvn clean release:prepare release:preform Or a rebuild alias which actually invokes: mvn clean install With pom configuration something like: 8 project build goalAliases goalAlias namerebuild/name goals goalclean/goal goalinstall/goal /goals /goalAlias /goalAliases /build /project 8 Just a thought... --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pom user-configured goal+phase aliases
I made something similar to help setup on my project : running mvn -Psetup execute all required goals to prepare the developer env, in my case a fast build (skipTests=true, compiler fail=false) + eclipse:eclipse This is done using a custom setup profile, that set default goal, some properties and the required plugins. Nico. 2008/6/13 Brian E. Fox [EMAIL PROTECTED]: To me, it seems to detract from the intent of having a well known set of phases so once you know maven, you can pick up any maven build. It reeks of scripting... -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, June 13, 2008 11:11 AM To: Maven Developers List Subject: Pom user-configured goal+phase aliases Just had a thought, would be nice if the pom exposed someway to define aliases for a set of goals/phases. This would allow project specific names to be used to invoke a set of standard maven phases or a set of plugins. Like I might want o have a release alias, which actually invokes: mvn clean release:prepare release:preform Or a rebuild alias which actually invokes: mvn clean install With pom configuration something like: 8 project build goalAliases goalAlias namerebuild/name goals goalclean/goal goalinstall/goal /goals /goalAlias /goalAliases /build /project 8 Just a thought... --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DISCUSS] The documentation for Maven Ant Tasks
Hi I'm in the process of converting the Ant builds, at my day job, to use Maven Ant tasks for dependency management. This is my first contact with Maven Ant tasks so I gave the doc a thorough reading and made some corrections and alterations. The doc is currently only one page [1] and is part of the maven site. The page is very long and tries to cover everything there is to know about the Ant tasks. Unfortunately it doesn't cover everything, as I've seen going through the user list trying to find answers. So I'd like to make some changes to the documentation. 1. Move the docs from maven site to the Ant tasks, in subversion. 2. Split up the current one page into several more focused pages. 3. Create a reference section, similar in function to the documentation for Ant, to make it easier for Ant (=non-Maven) users to find their way. Thoughts, ideas, criticism? For 3 I thought I'd have a look at how Ant currently generates its own documentation. One possibility would be to use annotations and create a Maven plugin to extract those along with Javadoc to create general documentation for Ant tasks (not just the Maven Ant tasks). This would work similarly to how the plugin-plugin works on Maven plugins. Is this a feasible approach or just a waste of time? [1] http://maven.apache.org/ant-tasks.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Doxia Tools version 1.0.1
I need one more vote for this one... Dennis Lundberg wrote: Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14366 There are still 1 issue left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761status=1component=13263 Staging repo: http://people.apache.org/~dennisl/staging-repo/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DISCUSS] The documentation for Maven Ant Tasks
Sounds like a good idea to me. -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2008 6:51 PM To: Maven Developers List Subject: [DISCUSS] The documentation for Maven Ant Tasks Hi I'm in the process of converting the Ant builds, at my day job, to use Maven Ant tasks for dependency management. This is my first contact with Maven Ant tasks so I gave the doc a thorough reading and made some corrections and alterations. The doc is currently only one page [1] and is part of the maven site. The page is very long and tries to cover everything there is to know about the Ant tasks. Unfortunately it doesn't cover everything, as I've seen going through the user list trying to find answers. So I'd like to make some changes to the documentation. 1. Move the docs from maven site to the Ant tasks, in subversion. 2. Split up the current one page into several more focused pages. 3. Create a reference section, similar in function to the documentation for Ant, to make it easier for Ant (=non-Maven) users to find their way. Thoughts, ideas, criticism? For 3 I thought I'd have a look at how Ant currently generates its own documentation. One possibility would be to use annotations and create a Maven plugin to extract those along with Javadoc to create general documentation for Ant tasks (not just the Maven Ant tasks). This would work similarly to how the plugin-plugin works on Maven plugins. Is this a feasible approach or just a waste of time? [1] http://maven.apache.org/ant-tasks.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1 Rahul Jason van Zyl wrote: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Doxia Tools version 1.0.1
+1 Vincent 2008/6/8 Dennis Lundberg [EMAIL PROTECTED]: Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14366 There are still 1 issue left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761status=1component=13263 Staging repo: http://people.apache.org/~dennisl/staging-repo/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: canvasing opinions about a 2.1 alpha release
On 14/06/2008, at 12:58 AM, Brian Fox wrote: If we don't include the new artifact code, the we need to fix several issues related to reresolving artifacts multiple times. Thanks Brian. Are these already issues in JIRA? I didn't spot them in my search. Cheers, Brett On Jun 13, 2008, at 5:28 AM, Brett Porter [EMAIL PROTECTED] wrote: I went through the unscheduled bunch of issues looking for reported 2.1 regressions this morning, and in what probably makes a clear statement about my sanity, cleaned up a number of the 180 issues and scheduled some for 2.0.x / 2.1 depending on their type (for those that couldn't be closed out). I expect I missed a few duplicates, etc. What remains for 2.1-alpha-1 is just the list of regressions, minor updates, and backwards compatibility documentation (39 issues in total, though some may be related): * http://tinyurl.com/5fuwcm * http://tinyurl.com/6k49gt I believe we should start to knock these off, and prepare for an alpha release as is, and wanted to see what others thought. To cover the inevitable questions: - Why release now? 163 fixes, 32 months since 2.0. 'Nuff said. The only thing I care about right now is getting a release out that - to the best of our knowledge - doesn't have any regressions from 2.0.x. This is really a necessary platform before making further, bigger changes. The sooner it gets out, the more time the current changes will have to be exposed before a final 2.1 release. - Why not add new feature X first? There are a bunch of good things going on (I count 8 active feature branches). As good as each is, none are ready to be merged on to trunk today, and the time until they are ready is not predictable. Releasing first doesn't harm the acceptance of these, or ability to make those changes. We just need more exposure to the changes that have already been made, and to narrow down the potential sources of regressions. So, thoughts? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
