[jira] (SUREFIRE-829) junit | Support inheritance while running test cases belonging to a particular category/group
[ https://jira.codehaus.org/browse/SUREFIRE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gayathri Muralidharan updated SUREFIRE-829: --- Attachment: SUREFIRE-829-common-junit48-new.patch Attaching the new patch file as the previous patch was stale (didnt contain the change mentioned by Robert) Thanks, Gayathri junit | Support inheritance while running test cases belonging to a particular category/group - Key: SUREFIRE-829 URL: https://jira.codehaus.org/browse/SUREFIRE-829 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Reporter: Gayathri Muralidharan Attachments: SUREFIRE-829-common-junit48-new.patch, SUREFIRE-829-common-junit48.patch We have a parent class which is extended by all the unit test cases (multi module maven based project) It would be great if surefire plugin config looks for the category in parent class as well. This will avoid redundant @Category(UnitTestCategory.class) annotations, as we expect all unit test cases to extend the corresponding base class and the base class will alone be annotated with @Category(UnitTestCategory.class) Please let me know if this can be achieved by any other config. Thanks, Gayathri -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-829) junit | Support inheritance while running test cases belonging to a particular category/group
[ https://jira.codehaus.org/browse/SUREFIRE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294489#comment-294489 ] Gayathri Muralidharan commented on SUREFIRE-829: And similar changes need to be made to maven failsafe plugin as well. Thanks, Gayathri junit | Support inheritance while running test cases belonging to a particular category/group - Key: SUREFIRE-829 URL: https://jira.codehaus.org/browse/SUREFIRE-829 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Reporter: Gayathri Muralidharan Attachments: SUREFIRE-829-common-junit48-new.patch, SUREFIRE-829-common-junit48.patch We have a parent class which is extended by all the unit test cases (multi module maven based project) It would be great if surefire plugin config looks for the category in parent class as well. This will avoid redundant @Category(UnitTestCategory.class) annotations, as we expect all unit test cases to extend the corresponding base class and the base class will alone be annotated with @Category(UnitTestCategory.class) Please let me know if this can be achieved by any other config. Thanks, Gayathri -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-829) junit | Support inheritance while running test cases belonging to a particular category/group
[ https://jira.codehaus.org/browse/SUREFIRE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294489#comment-294489 ] Gayathri Muralidharan edited comment on SUREFIRE-829 at 3/19/12 3:00 AM: - Can you please review the patch : https://jira.codehaus.org/secure/attachment/59255/SUREFIRE-829-common-junit48-new.patch Thanks, Gayathri was (Author: muralidh): And similar changes need to be made to maven failsafe plugin as well. Thanks, Gayathri junit | Support inheritance while running test cases belonging to a particular category/group - Key: SUREFIRE-829 URL: https://jira.codehaus.org/browse/SUREFIRE-829 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Reporter: Gayathri Muralidharan Attachments: SUREFIRE-829-common-junit48-new.patch, SUREFIRE-829-common-junit48.patch We have a parent class which is extended by all the unit test cases (multi module maven based project) It would be great if surefire plugin config looks for the category in parent class as well. This will avoid redundant @Category(UnitTestCategory.class) annotations, as we expect all unit test cases to extend the corresponding base class and the base class will alone be annotated with @Category(UnitTestCategory.class) Please let me know if this can be achieved by any other config. Thanks, Gayathri -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-34) Add google +1 button support
[ https://jira.codehaus.org/browse/MSKINS-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi closed MSKINS-34. Resolution: Fixed fixed on trunk, issue can be marked as resolved Add google +1 button support Key: MSKINS-34 URL: https://jira.codehaus.org/browse/MSKINS-34 Project: Maven Skins Issue Type: New Feature Components: Fluido Skin Affects Versions: fluido-1.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Similar to MSKINS-33, but related to Google +1 [button|http://www.google.com/webmasters/+1/button/] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-52) reentrant locking in DefaultIndexingContent flawed
Milos Kleint created MINDEXER-52:
Summary: reentrant locking in DefaultIndexingContent flawed
Key: MINDEXER-52
URL: https://jira.codehaus.org/browse/MINDEXER-52
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.1.2
Reporter: Milos Kleint
Priority: Critical
DefaultIndexingContent.java contains the following pattern:
{code:java}
public IndexReader getIndexReader()
throws IOException
{
lock();
try
{
return indexReader;
}
finally
{
unlock();
}
}
{code}
together with installBottleWarmer() method that spawns a concurrent thread that
performs warmup operations, it makes it impossible to access the indexReader
instance safely. A correct approach would be to wrap the entire operation with
the indexreader in the mutex lock, not the the accessor method.
please see http://netbeans.org/bugzilla/show_bug.cgi?id=204706 and
http://statistics.netbeans.org/exceptions/detail.do?id=180712 for examples when
this approach is failing. it's fairly rare but keeps on reoccuring, all access
(searching, indexing) from netbeans is protected by a mutex and happens
exclusively. I'm assuming that the installBottleWarmer() thread is the one
iterfering with our access occasionally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-34) Add google +1 button support
[ https://jira.codehaus.org/browse/MSKINS-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi updated MSKINS-34: - Fix Version/s: fluido-1.2 Add google +1 button support Key: MSKINS-34 URL: https://jira.codehaus.org/browse/MSKINS-34 Project: Maven Skins Issue Type: New Feature Components: Fluido Skin Affects Versions: fluido-1.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: fluido-1.2 Similar to MSKINS-33, but related to Google +1 [button|http://www.google.com/webmasters/+1/button/] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-718) Support packaging 'bundle' from org.apache.felix:maven-bundle-plugin
Dan Tran created MECLIPSE-718: - Summary: Support packaging 'bundle' from org.apache.felix:maven-bundle-plugin Key: MECLIPSE-718 URL: https://jira.codehaus.org/browse/MECLIPSE-718 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.9 Environment: windows, unix Reporter: Dan Tran packaging=bundle is the same as 'jar' packaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-718) Support packaging 'bundle' from org.apache.felix:maven-bundle-plugin
[ https://jira.codehaus.org/browse/MECLIPSE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294522#comment-294522 ] Dan Tran commented on MECLIPSE-718: --- I am not able to figure out the location of source to make this change, any suggestion is appricated. To test this, one can check out apache-karaf and use maven-eclipse-plugin to generate eclipse project files Support packaging 'bundle' from org.apache.felix:maven-bundle-plugin Key: MECLIPSE-718 URL: https://jira.codehaus.org/browse/MECLIPSE-718 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.9 Environment: windows, unix Reporter: Dan Tran packaging=bundle is the same as 'jar' packaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-128) SCM properties being replaced during release:perform
[
https://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-128.
---
Resolution: Fixed
Assignee: Robert Scholte (was: Brett Porter)
Fixed in [rev.1302692|http://svn.apache.org/viewvc?rev=1302692view=rev]
For those interested: the main reason why the release-pom was okay and the
next-dev-pom not is because the release.pom was based on the originalModel of
the MavenProject. The next-dev-pom uses the releases.properties, which used to
contain the resolved properties. After analyzing this it seems that these
property values are only used for rewriting the next-dev-pom.
So I've changed this, so the unresolved values are stored.
I've released a 2.3-SNAPSHOT for those who want to try this fix.
It would be nice if some could confirm this fix and that nothing is broken by
this adjustment.
SCM properties being replaced during release:perform
Key: MRELEASE-128
URL: https://jira.codehaus.org/browse/MRELEASE-128
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
Reporter: Craig Dickson
Assignee: Robert Scholte
Priority: Critical
Labels: properties
Fix For: 2.3
Attachments: after-release-perform-pom.xml,
after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
original-pom.xml
The scm section of a pom in CVS for a pom archetype project looks like this
prior to executing release:prepare :
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
/scm
Then after executing release:prepare, the pom in CVS looks like this (new
tag tag is only difference):
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
tagR-1_7/tag
/scm
Then after executing release:perform, the pom looks like this in CVS:
scm
connectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/connection
developerConnectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/developerConnection
urlhttp://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom/url
/scm
Notice that the properties that were there for the base URLs for CVS and
ViewCVS have been replaced with literal values.
No other properties in the POM are being replaced
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-602) Multiple Assemblies Causes Infinite Loop\Recursion
Shaun created MASSEMBLY-602: --- Summary: Multiple Assemblies Causes Infinite Loop\Recursion Key: MASSEMBLY-602 URL: https://jira.codehaus.org/browse/MASSEMBLY-602 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.3, 2.2.2, 2.2.1, 2.2, 2.2-beta-5, 2.2-beta-3 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows [also, maven 2] Reporter: Shaun I have a custom assembly.xml on a project that also has a parent pom. In the parent pom, we specify: appendAssemblyIdtrue/appendAssemblyId As the default assembly (jar-with-dependencies-and-sources) is fine for 99% of our projects, however, in this instance, I need the custom assembly. However, the parent pom dicates: appendAssemblyIdfalse/appendAssemblyId Causing this error: Exception in thread main java.lang.StackOverflowError at sun.nio.cs.SingleByteEncoder.encodeArrayLoop(SingleByteEncoder.java:91) at sun.nio.cs.SingleByteEncoder.encodeLoop(SingleByteEncoder.java:130) at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:544) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:252) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:190) at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:111) at java.io.PrintStream.write(PrintStream.java:476) at java.io.PrintStream.print(PrintStream.java:619) at org.apache.maven.cli.PrintStreamLogger.info(PrintStreamLogger.java:110) at org.codehaus.plexus.logging.AbstractLogger.info(AbstractLogger.java:51) at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:464) at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:467) at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:467) I believe this error to be related to PLXUTILS-148 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
