Contributers are always welcome... we're busy people so if we sound abrupt, please do not take offense.
* create a patch for your changes, based off the latest head. * ensure that your patch includes integration tests * ensure that your patch does not introduce un-necessary formatting changes, i.e. only change what you have to change * If possible, I would split the patches per goal, * create a jira for each patch. * pester the developers -Stephen 2009/12/7 Michael Spaulding <[email protected]> > Dear Stephen, > > My name in Michael Spaulding. I work as a Software Architect at NetJets, > Inc. in the US. We are in the process of adopting Maven as part of our build > framework. > > As part of the adoption process, I've been looking at the Maven versions > plugin to help us with dependency management. While the plugin is extremely > useful out of the box, there's some additional functionality that we need. > I've gone ahead and implemented the new functionality on top of the versions > code base. I was thinking, though, that it might be good to try to integrate > the functionality back into the main code base because others might find > this functionality useful. For example, I've implemented the following new > mojos: > > * increment: Increments the version number of the project, sort of like the > set goal. Allows you to specify which segment you'd like incremented and > whether to add "SNAPSHOT" to the new version. > Have you considered the maven release plugin? > > * remove-snapshot: Removes SNAPSHOT from the project's version number. > If you are using the maven release plugin then you don't need this. It is generally bad to have mutable source code checked out with a non-SNAPSHOT version... so if you are not using the maven release plugin to do your releases you have to be very careful. for that reason I am mostly against allowing people to easily change their code to a non-SNAPSHOT version. I would want to see a very strong use case before I would be prepared to add such a goal > * use-specific-version: Updates dependencies to a specific version number. > This can be used to implement bulk updates to a family of dependencies that > share a common group id, for example. > Sounds good. > > Also, I've added flags to the use-latest* mojos similar to the > use-latest-snapshot mojo parameters that allow you to specify whether or not > the major/minor/incremental version segment should be updated. > I thought these flags were already there... but then again I could be wrong! > > I'll be honest, though, that I've never before contributed to an open > source project like this, so I'm a little bit lost/intimiated by the > process. I was hoping you might be able to provide some assistance as to the > proper way to propose my changes and get them approved and integrated. > > Thanks, > Michael Spaulding > > >
