Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <328828200.1236033536538.JavaMail.jira@brutus>
Date: Mon, 2 Mar 2009 14:38:56 -0800 (PST)
From: "Michael Dick (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-949) Allow override of Surefire test
 excludes from cmdline
In-Reply-To: <181901521.1236023216226.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OPENJPA-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678138#action_12678138 ] 

Michael Dick commented on OPENJPA-949:
--------------------------------------

Just MHO : 

1. I like Don's patch. It's much easier to edit a single file than it is to pore through pom.xml. I never would have thought of using the groovy plugin that way. 

2. I think a property that may be overridden by something in settings.xml is probably a better approach. Settings.xml is never committed so there's no chance of an accidental commit going unnoticed. We currently exclude a lot of tests though so the property would have to be rather large and surefire / maven may have trouble with them in a single property. 
$ mvn -Dopenjpa.excludedTests=org/apache/openjpa/persistence/kernel/TestPMMemory.java,org/apache/openjpa/persistence/jpql/clause/TestSomething.java,org/apache/openjpa/datacache/TestSomethingElse.java, . . . , { new exclusions go here }

3. I'm ambivalent re @AllowFailure. In concept it's a nice idea, but I don't like the idea that svn revision 101 might pass a certain test and revision 120 regresses it and we'd never know. It also seems to take a lot of time to run tests that don't impact whether the build is "good". 

4. I might be in the minority about @AllowFailure. :-)

5. Pinaki's comments about having the maven build process restore the filter file are great if you're doing the build on your system. If you do it on TeamCity then having maven restore the file won't do you any good. TeamCity will restore the copy on the TeamCity server but the commit comes from the client. So you'll have to manually revert the file or do your own local build.

6. The best current solution might be to take Don's patch and make the exclusions filename a property. Different profiles use different (local and unversion controlled) exclusion files. Local users make their own exclusion file at least until we reduce the number or come up with a shorter list. 


> Allow override of Surefire test excludes from cmdline
> -----------------------------------------------------
>
>                 Key: OPENJPA-949
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-949
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: build / infrastructure
>            Reporter: Donald Woods
>            Assignee: Donald Woods
>            Priority: Minor
>             Fix For: 2.0.0
>
>         Attachments: OPENJPA-949-trunk-20090302.patch
>
>
> Allow users to provide their own Surefire excludes list through an external file.
> This can be accomplished by using the gmaven-plugin and some Groovy code.
> The default set of excludes will still be provided and used by default in the builds, but will be moved to src/test/resources/excludes.xml.
> Users can provide their own version of excludes file by:
> mvn -DsurefireExcludesFile=<filename>
> where <filename> could be a local file like:
> -DsurefireExcludesFile=/tmp/excludes.xml
> or from a network share like:
> -DsurefireExcludesFile=/mnt/public/openjpa-persistence-jdbc/excludes.xml

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.