Re: Maven core contributors validator their changes against the integration tests
For those who work on Win7, a pretty equivalent batch script: https://gist.github.com/pcompieta/0b202e9ce57e490c84c4 Unfortunately, i found no pull request at the moment to test it as a whole (#22 is open but already committed to master), but i tried all pieces separately and it should work as expected - feedbacks are welcome. Hope it helps Paolo Compieta On Mon, Jun 2, 2014 at 4:50 AM, Jason van Zyl wrote: > Hi, > > There have been a lot of great patches for Maven core recently which is a > pleasant surprise. Unfortunately it's not readily apparent to contributors > what is required to accept a patch into core. Not only must the unit tests > pass, but the integration tests must pass as well. Our integration tests > catch most things and we're in a state where much of what should be tested > in the unit tests are only captured in the integration tests. This is not a > horrible thing in and of itself but it makes it fairly time consuming to > test for non-core developers. I don't think most people even know we have > an integration test suite or where they are. > > While not perfect, until we have automation to validate changes, I created > a shell script to help those making changes to core more easily see if > their changes have broken anything: > > https://gist.github.com/jvanzyl/16da25976f8ad27293fa > > If you have made a pull request, this script will apply your PR as a patch > to master, build Maven and then use the just-built Maven to run the > integration tests. If this script succeeds it becomes an order of magnitude > easier to review the change knowing nothing is broken. This is not to say > your patch will be immediately accepted if everything passes but it helps > contributors to know nothing is broken which makes looking at a patch far > more appealing to the core developers. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > A party which is not afraid of letting culture, > business, and welfare go to ruin completely can > be omnipotent for a while. > > -- Jakob Burckhardt > > > > > > > > > >
Re: Thought: write some doc about how not to use snapshots?
On Thu, Aug 25, 2011 at 3:40 PM, Benson Margulies wrote: > On Thu, Aug 25, 2011 at 8:59 AM, Jesse Glick > wrote: > > On 08/25/2011 07:34 AM, Benson Margulies wrote: > >> > >> I discovered yesterday that one team had taken this idea to its local > >> extreme, and were just using release versions, no -SNAPSHOTS at all. > > > I can confirm this: we are using snapshot version (but i could also say "no snapshot at all") during development; while publishing only non-snapshots. In fact, I spent 6 months training up collegues on maven's way of development.. and the only thing they couldn't really digest was publishing/downloading SNAPSHOT version to share things (and waiting for maven to check for the latest SNAPSHOT on the company's repo): they went simply SCM-updating and rebuilding (once) all those 5/10/15 upstream modules when they needed to be working on the very latest. To a certain extent, this could be a good simplification: when using SNAPSHOTS from a mainstream project, some degree of synchronization emerges between different teams to choose between using the last stable, the last snapshot or even a few-days-old version; whilst publishing SNAPs only allow to share the very-last. Using the company repo to share snapshots costs (pom configuration, ci, update checks during builds, disk space, etc.), and could be not always necessary or justified with respect to a rough/simplier "build unstables, download stables" approach. > > > > > By the way it would seem safer if Maven refused to overwrite an artifact > in > > the local repository that had been retrieved from a remote repository (as > > recorded by _maven.repositories), or conversely to download even an > > apparently newer remote update when there was already a locally built > > artifact. However this would prevent you from running e.g. 'svn co > > http://svn.apache.org/repos/asf/maven/maven-3/tags/maven-3.0.3 . && mvn > > install' if you already happened to have > > > ~/.m2/repository/org/apache/maven/maven-plugin-api/3.0.3/maven-plugin-api-3.0.3.jar > > for unrelated reasons. Perhaps a nonfatal warning could be issued when it > > looks like locally built and remotely downloaded artifacts might be > > colliding. > +1 for the warning it'd help discover locally forgotten "overwrites" > > A published "best practices" document on this topic would be very much > appreciated, > The conversation is already a bit aged - has anything been created since then? Is any help needed? A small real example or even notes in the main documentation could be not so hard to write, based on current experiences. > > since the existing references leave this to your imagination. > Can you point to the exact page(s) in maven doc? PC
Re: Transitive release notes from Jira ?
On Thu, Jul 7, 2011 at 12:16 PM, Kristian Rosenvold < kristian.rosenv...@gmail.com> wrote: > > any way to get the "proper" transitive diff between version X and Y in > jira that can be used in creating release notes ? > > Kristian > This idea got stuck in my head: I think such functionality would save really much time in every projects and company. Just created https://jira.atlassian.com/browse/JRA-27503 as a New Feature Request - feel free to comment/vote. Paolo
