[jira] (MNG-5459) failure to resolve pom artifact from snapshotVersion in maven-metadata.xml

2013-04-04 Thread Claudio Bley (JIRA) 
Claudio Bley created MNG-5459:
-

 Summary: failure to resolve pom artifact from snapshotVersion in 
maven-metadata.xml
 Key: MNG-5459
 URL: https://jira.codehaus.org/browse/MNG-5459
 Project: Maven 2 & 3
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 3.0.5, 3.1.x
Reporter: Claudio Bley
 Attachments: mvn-snapshot-resolve-fix.diff

We're using Artifactory on the server side, and ivy / sbt to publish artifacts  
upstream.

After publishing several -SNAPSHOT versions of a project, trying to use it from 
Maven, resulted in a warning and ultimately a build failure because it cannot 
determine the dependencies:

{code}[WARNING] The POM for com.foo:bar:jar:0.4.0-20130404.093655-3 is missing, 
no dependency information available{code}

This is the corresponding maven-metadata-snapshots.xml:
{code:xml}

  com.foo
  bar
  0.4.0-SNAPSHOT
  

  20130404.090532
  2

20130404093657

  
pom
0.4.0-20130404.090532-2
20130404090532
  
  
jar
0.4.0-20130404.093655-3
20130404093655
  

  

{code}

As you can see, the  for the jar artifact and the pom artifact differ:

0.4.0-20130404.093655-3
0.4.0-20130404.090532-2

Apparently, artifactory optimizes the case when an artifact doesn't change; it 
does not create a new file, but just links to the existing one.

Maven, however, takes a shortcut and makes the erroneous assumption that the 
values for pom and jar artifact always match up.

The attached patch fixes this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir

2013-04-04 Thread Anthony Whitford (JIRA) 

[ 
https://jira.codehaus.org/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323238#comment-323238
 ] 

Anthony Whitford commented on MSHADE-124:
-

And shouldn't the default location be under {{project.build.directory}} instead 
of {{basedir}}?  Then {{mvn clean}} would be more effective, and the _Maven 
Release_ plugin wouldn't give an error saying, "_Cannot prepare the release 
because you have local modifications._"

> Need better plan for getting dependency-reduced-pom.xml out of basedir
> --
>
> Key: MSHADE-124
> URL: https://jira.codehaus.org/browse/MSHADE-124
> Project: Maven 2.x Shade Plugin
>  Issue Type: Bug
>Affects Versions: 1.7.1
>Reporter: Benson Margulies
>Assignee: Benson Margulies
> Fix For: 2.0
>
>
> MSHADE-123 reported that putting the d-r-p into some location other
> than 'basedir' causes 'basedir' to follow it around, which can break builds.
> This is hard to fix, given the core maven definition of basedir as 'the dir 
> containing the pom' with no option to change it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir

2013-04-04 Thread Anthony Whitford (JIRA) 

[ 
https://jira.codehaus.org/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323237#comment-323237
 ] 

Anthony Whitford commented on MSHADE-124:
-

If this was fixed, why does the documentation still warn about this?

See:  
http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation

> Need better plan for getting dependency-reduced-pom.xml out of basedir
> --
>
> Key: MSHADE-124
> URL: https://jira.codehaus.org/browse/MSHADE-124
> Project: Maven 2.x Shade Plugin
>  Issue Type: Bug
>Affects Versions: 1.7.1
>Reporter: Benson Margulies
>Assignee: Benson Margulies
> Fix For: 2.0
>
>
> MSHADE-123 reported that putting the d-r-p into some location other
> than 'basedir' causes 'basedir' to follow it around, which can break builds.
> This is hard to fix, given the core maven definition of basedir as 'the dir 
> containing the pom' with no option to change it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSHADE-128) Too many warnings "We have duplicates"

2013-04-04 Thread Bob Tiernay (JIRA) 

[ 
https://jira.codehaus.org/browse/MSHADE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323234#comment-323234
 ] 

Bob Tiernay commented on MSHADE-128:


Bump (in the most polite manner possible :)

> Too many warnings "We have duplicates"
> --
>
> Key: MSHADE-128
> URL: https://jira.codehaus.org/browse/MSHADE-128
> Project: Maven 2.x Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 1.7.1
>Reporter: Raffaele
>Assignee: Benson Margulies
> Attachments: pom.xml, warning-we-have-duplicates.patch
>
>
> When creating an uberjar, sometimes the same class is present in two or more 
> dependencies' JARs. For each class, maven-shade-plugin issues a WARNING We 
> have a duplicate in.
> This is annoying and can muddle newcomers up (like myself), because it's not 
> clear how to fix.
> I don't know if a programmatic solution to these warnings could exist: maybe 
> it will always require human interaction. However, it's better to point users 
> in the right direction and not spit out thousands of useless warnings.
> Attached is a pom which triggers thousands of warnings and a patch with a 
> prettier (and hopefully more useful) output like
> [WARNING] bcprov-jdk14-138.jar, bcprov-jdk14-1.38.jar define 1292 
> overlappping classes:
> [WARNING]   - org.bouncycastle.asn1.ocsp.ResponderID
> [WARNING]   - org.bouncycastle.crypto.params.DSAPublicKeyParameters
> [WARNING]   - org.bouncycastle.crypto.engines.DESEngine
> [WARNING]   - org.bouncycastle.jce.provider.JCEElGamalPrivateKey
> [WARNING]   - org.bouncycastle.jce.provider.JCEStreamCipher$Skipjack_CFB8
> [WARNING]   - org.bouncycastle.jce.provider.JCESecretKeyFactory
> [WARNING]   - org.bouncycastle.i18n.filter.UntrustedInput
> [WARNING]   - org.bouncycastle.asn1.x9.X962NamedCurves$5
> [WARNING]   - org.bouncycastle.jce.X509KeyUsage
> [WARNING] maven-shade-plugin has detected that some .class files
> [WARNING] are present in two or more JARs. When this happens, only
> [WARNING] one single version of the class is copied in the uberjar.
> [WARNING] Usually this is not harmful and you can skeep these
> [WARNING] warnings, otherwise try to manually exclude artifacts
> [WARNING] based on mvn dependency:tree -Ddetail=true and the above
> [WARNING] output
> [WARNING] See http://docs.codehaus.org/display/MAVENUSER/Shade+Plugin

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency

2013-04-04 Thread Andreas Gudian (JIRA) 

 [ 
https://jira.codehaus.org/browse/SUREFIRE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Gudian updated SUREFIRE-968:


Description: 
When running multiple test suites in parallel, Surefire prints summaries of 
ongoing test counts, but it is not at all clear which results are being 
summarized. E.g. with {{forkCount=1C}}:

{code:none}
Running CoreJellyTest
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Running org.jvnet.hudson.test.MockFolderTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
Running hudson.bugs.DateConversionTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
Running hudson.bugs.LoginRedirectTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
…
{code}

It is impossible to tell which results correspond to which test, since there is 
no way to know which test will finish first. At best you can guess based on the 
number of test case methods known to be in each class.

The {{Tests run}} summary line should give the suite name.

  was:
When running multiple test suites in parallel, Surefire prints summaries of 
ongoing test counts, but it is not at all clear which results are being 
summarized. E.g. with {{forkCount=1C}}:

{code:none}
Running CoreJellyTest
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Running org.jvnet.hudson.test.MockFolderTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
Running hudson.bugs.DateConversionTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
Running hudson.bugs.LoginRedirectTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
…
{code}

It is impossible to tell which results correspond to which test, since there is 
no way to know which test will finish first. At best you can guess based on the 
number of test case methods known to be in each class.

The {{Tests run}} summary line should give the suite name.

 Issue Type: Improvement  (was: Bug)

> Test summary line does not indicate what was being run when using concurrency
> -
>
> Key: SUREFIRE-968
> URL: https://jira.codehaus.org/browse/SUREFIRE-968
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Affects Versions: 2.14
> Environment: Ubuntu, JDK 7
>Reporter: Jesse Glick
>Assignee: Andreas Gudian
>Priority: Minor
> Fix For: 2.15
>
>
> When running multiple test suites in parallel, Surefire prints summaries of 
> ongoing test counts, but it is not at all clear which results are being 
> summarized. E.g. with {{forkCount=1C}}:
> {code:none}
> Running CoreJellyTest
> Running org.jvnet.hudson.main.AppTest
> Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
> Running org.jvnet.hudson.test.MemoryAssertTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
> Running org.jvnet.hudson.test.MockFolderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
> Running hudson.bugs.DateConversionTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
> Running hudson.bugs.LoginRedirectTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
> Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
> Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
> …
> {code}
> It is impossible to tell which results correspond to which test, since there 
> is no way to know which test will finish first. At best you can guess based 
> on the number of test case methods known to be in each class.
> The {{Tests run}} summary line should give the suite name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-973) add properties to classpathDependencyExcludes and additionalClasspathElements parameters

2013-04-04 Thread Andreas Gudian (JIRA) 

 [ 
https://jira.codehaus.org/browse/SUREFIRE-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Gudian updated SUREFIRE-973:


Fix Version/s: (was: 2.14.1)
   2.15

> add properties to classpathDependencyExcludes and additionalClasspathElements 
> parameters
> 
>
> Key: SUREFIRE-973
> URL: https://jira.codehaus.org/browse/SUREFIRE-973
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.14
>Reporter: Milos Kleint
> Fix For: 2.15
>
> Attachments: surefire.patch
>
>
> currently classpathDependencyExcludes and additionalClasspathElements 
> parameters don't have properties defined to declare on cmd line. The attached 
> patch includes them.
> I would like to use these properties in Netbeans. With multiple projects 
> enabling Compile on Save feature, I would need these properties to replace 
> outside project's jar artifacts from local repository with their project's 
> output directory dynamically.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-833) Support for annotated JUnit @Category

2013-04-04 Thread Andreas Gudian (JIRA) 

 [ 
https://jira.codehaus.org/browse/SUREFIRE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Gudian updated SUREFIRE-833:


Fix Version/s: (was: 2.14.1)
   2.15

> Support for annotated JUnit @Category
> -
>
> Key: SUREFIRE-833
> URL: https://jira.codehaus.org/browse/SUREFIRE-833
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Junit 4.x support
>Affects Versions: 2.12
>Reporter: Jan Goyvaerts
> Fix For: 2.15
>
> Attachments: SUREFIRE-833-spraguep-2.patch, 
> SUREFIRE-833-spraguep.patch
>
>
> The current implementation of Surefire seems to look for explicit @Category 
> annotations in the test classes. And will only consider those. Suppose I'd 
> like to add a more concise annotation for this:
> @Category(IntegrationTests.class) <== JUnit @Category
> @Target({ElementType.TYPE})
> @Retention(RetentionPolicy.RUNTIME)
> @Documented
> public @interface IntegrationTest {}
> Annotating my test class with @IntegrationTest does not work. Although I 
> think it looks much better than repeating everywhere in my code 
> "@Category(com.foo.bar.IntegrationTests.class)". For which I add an 
> additional dependency in the interface class btw.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency

2013-04-04 Thread Andreas Gudian (JIRA) 

 [ 
https://jira.codehaus.org/browse/SUREFIRE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Gudian closed SUREFIRE-968.
---

   Resolution: Fixed
Fix Version/s: (was: 2.14.1)
   2.15

> Test summary line does not indicate what was being run when using concurrency
> -
>
> Key: SUREFIRE-968
> URL: https://jira.codehaus.org/browse/SUREFIRE-968
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.14
> Environment: Ubuntu, JDK 7
>Reporter: Jesse Glick
>Assignee: Andreas Gudian
>Priority: Minor
> Fix For: 2.15
>
>
> When running multiple test suites in parallel, Surefire prints summaries of 
> ongoing test counts, but it is not at all clear which results are being 
> summarized. E.g. with {{forkCount=1C}}:
> {code:none}
> Running CoreJellyTest
> Running org.jvnet.hudson.main.AppTest
> Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
> Running org.jvnet.hudson.test.MemoryAssertTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
> Running org.jvnet.hudson.test.MockFolderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
> Running hudson.bugs.DateConversionTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
> Running hudson.bugs.LoginRedirectTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
> Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
> Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
> …
> {code}
> It is impossible to tell which results correspond to which test, since there 
> is no way to know which test will finish first. At best you can guess based 
> on the number of test case methods known to be in each class.
> The {{Tests run}} summary line should give the suite name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency

2013-04-04 Thread Andreas Gudian (JIRA) 

 [ 
https://jira.codehaus.org/browse/SUREFIRE-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Gudian reassigned SUREFIRE-968:
---

Assignee: Andreas Gudian

> Test summary line does not indicate what was being run when using concurrency
> -
>
> Key: SUREFIRE-968
> URL: https://jira.codehaus.org/browse/SUREFIRE-968
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.14
> Environment: Ubuntu, JDK 7
>Reporter: Jesse Glick
>Assignee: Andreas Gudian
>Priority: Minor
> Fix For: 2.15
>
>
> When running multiple test suites in parallel, Surefire prints summaries of 
> ongoing test counts, but it is not at all clear which results are being 
> summarized. E.g. with {{forkCount=1C}}:
> {code:none}
> Running CoreJellyTest
> Running org.jvnet.hudson.main.AppTest
> Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
> Running org.jvnet.hudson.test.MemoryAssertTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
> Running org.jvnet.hudson.test.MockFolderTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
> Running hudson.bugs.DateConversionTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
> Running hudson.bugs.LoginRedirectTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
> Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
> Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
> …
> {code}
> It is impossible to tell which results correspond to which test, since there 
> is no way to know which test will finish first. At best you can guess based 
> on the number of test case methods known to be in each class.
> The {{Tests run}} summary line should give the suite name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (DOXIA-484) pegdown dependency is 3 revisions out of date

2013-04-04 Thread Malachi de AElfweald (JIRA) 

[ 
https://jira.codehaus.org/browse/DOXIA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323200#comment-323200
 ] 

Malachi de AElfweald commented on DOXIA-484:


Yeah I saw that. It looked like it tried to concatenate all their tests into 
one file.  I managed to finagle that into happening, but the tests didn't pass.

Is there maybe a better option?  Should we modify existing test to pass the new 
code?

> pegdown dependency is 3 revisions out of date
> -
>
> Key: DOXIA-484
> URL: https://jira.codehaus.org/browse/DOXIA-484
> Project: Maven Doxia
>  Issue Type: Improvement
>  Components: Module - Markdown
>Affects Versions: 1.3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Maven home: /usr/local/maven
> Java version: 1.6.0_41, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.5.0-25-generic", arch: "amd64", family: "unix"
>Reporter: Malachi de AElfweald
>Priority: Minor
>
> From the CHANGELOG
> {noformat}
> Version 1.2.1 (2011-11-27)
> --
> - Upgraded to parboiled 1.1.4
> - Added support for caption on tables (thx to Geoffrey Picron)
> Version 1.2.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.1.3
> - Implemented parsing timeout, closes #42
> - Fixed IndexOutOfBoundsException in ToHtmlSerializer, closes #39
> - Changed parser to not swallow backslash before non-special characters, 
> fixes #35
> - Added test for fenced code blocks containing an empty line, closes #61
> - Migrated all tests from TestNG to specs2
> - Switched build tool from Apache Buildr to SBT
> Version 1.1.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.0.2
> - Introduced LinkRenderer layer for easy customization of HTML link rendering
> - Added support for [[Wiki-style]] links, thx to Brett Porter
> - Fixed #27 (Missing emphasis when paragraph has multiple lines)
> - Fixed #28 (Parser not fully extensible)
> - Fixed #32, #33 (HTML tags with attribute names containing underscores are 
> not recognized as tags, thx to Edward Samson)
> - Fixed #34 (Pathologically slow parsing when strong and italics emphasis are 
> applied together)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (DOXIA-484) pegdown dependency is 3 revisions out of date

2013-04-04 Thread Kristian Rosenvold (JIRA) 

[ 
https://jira.codehaus.org/browse/DOXIA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323199#comment-323199
 ] 

Kristian Rosenvold commented on DOXIA-484:
--

This is about where I stopped ;) It seems like the pegdown project itself has a 
routine to generate the file with all the tests. It did not work the first time 
I tried; which is when I quietly gave up ;)

> pegdown dependency is 3 revisions out of date
> -
>
> Key: DOXIA-484
> URL: https://jira.codehaus.org/browse/DOXIA-484
> Project: Maven Doxia
>  Issue Type: Improvement
>  Components: Module - Markdown
>Affects Versions: 1.3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Maven home: /usr/local/maven
> Java version: 1.6.0_41, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.5.0-25-generic", arch: "amd64", family: "unix"
>Reporter: Malachi de AElfweald
>Priority: Minor
>
> From the CHANGELOG
> {noformat}
> Version 1.2.1 (2011-11-27)
> --
> - Upgraded to parboiled 1.1.4
> - Added support for caption on tables (thx to Geoffrey Picron)
> Version 1.2.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.1.3
> - Implemented parsing timeout, closes #42
> - Fixed IndexOutOfBoundsException in ToHtmlSerializer, closes #39
> - Changed parser to not swallow backslash before non-special characters, 
> fixes #35
> - Added test for fenced code blocks containing an empty line, closes #61
> - Migrated all tests from TestNG to specs2
> - Switched build tool from Apache Buildr to SBT
> Version 1.1.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.0.2
> - Introduced LinkRenderer layer for easy customization of HTML link rendering
> - Added support for [[Wiki-style]] links, thx to Brett Porter
> - Fixed #27 (Missing emphasis when paragraph has multiple lines)
> - Fixed #28 (Parser not fully extensible)
> - Fixed #32, #33 (HTML tags with attribute names containing underscores are 
> not recognized as tags, thx to Edward Samson)
> - Fixed #34 (Pathologically slow parsing when strong and italics emphasis are 
> applied together)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-106) Remember the Dry Run Status

2013-04-04 Thread Dave Roberge (JIRA) 

 [ 
https://jira.codehaus.org/browse/MRELEASE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Roberge updated MRELEASE-106:
--

Attachment: 0002-MRELEASE-106-Provided-reasonable-failure-message-whe.patch

I implemented a new perform phase to check whether dry run was set to true when 
preparing release. This patch is dependent on the previous patch file.

I attempted to write an integration test using the invoker plugin, but 
discovered it may not be possible because the build fails. From what I could 
tell, the plugin is meant to verify successful builds. If anyone has a 
suggestion for how I might go about writing an integration test for this, I'm 
happy to look into it.

> Remember the Dry Run Status
> ---
>
> Key: MRELEASE-106
> URL: https://jira.codehaus.org/browse/MRELEASE-106
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0-beta-4
> Environment:  Release plugin snapshot 20060509.101136-3, Subversion
>Reporter: Bob Allison
>Priority: Minor
>  Labels: contributers-welcome
> Fix For: Backlog
>
> Attachments: 0001-MRELEASE-106-Remember-the-dry-run-status.patch, 
> 0002-MRELEASE-106-Provided-reasonable-failure-message-whe.patch
>
>
> When doing a dry run of a release, make note of that in the 
> release.properties file so that a reasonable "failure" can occur if the user 
> tries to perform the release.  Also, this flag might be used to allow a 
> non-dry-run prepare to occur without needing to do a clean in between (maybe 
> also not need to prompt but reuse the same answers as in the dry run).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (DOXIA-484) pegdown dependency is 3 revisions out of date

2013-04-04 Thread Malachi de AElfweald (JIRA) 

[ 
https://jira.codehaus.org/browse/DOXIA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323195#comment-323195
 ] 

Malachi de AElfweald commented on DOXIA-484:


Sorry, I haven't had a chance to work on it.  The tests are the real problem 
for me.  What is the correct process for updating the list of tests?

> pegdown dependency is 3 revisions out of date
> -
>
> Key: DOXIA-484
> URL: https://jira.codehaus.org/browse/DOXIA-484
> Project: Maven Doxia
>  Issue Type: Improvement
>  Components: Module - Markdown
>Affects Versions: 1.3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Maven home: /usr/local/maven
> Java version: 1.6.0_41, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-oracle/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.5.0-25-generic", arch: "amd64", family: "unix"
>Reporter: Malachi de AElfweald
>Priority: Minor
>
> From the CHANGELOG
> {noformat}
> Version 1.2.1 (2011-11-27)
> --
> - Upgraded to parboiled 1.1.4
> - Added support for caption on tables (thx to Geoffrey Picron)
> Version 1.2.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.1.3
> - Implemented parsing timeout, closes #42
> - Fixed IndexOutOfBoundsException in ToHtmlSerializer, closes #39
> - Changed parser to not swallow backslash before non-special characters, 
> fixes #35
> - Added test for fenced code blocks containing an empty line, closes #61
> - Migrated all tests from TestNG to specs2
> - Switched build tool from Apache Buildr to SBT
> Version 1.1.0 (2011-10-05)
> --
> - Upgraded to parboiled 1.0.2
> - Introduced LinkRenderer layer for easy customization of HTML link rendering
> - Added support for [[Wiki-style]] links, thx to Brett Porter
> - Fixed #27 (Missing emphasis when paragraph has multiple lines)
> - Fixed #28 (Parser not fully extensible)
> - Fixed #32, #33 (HTML tags with attribute names containing underscores are 
> not recognized as tags, thx to Edward Samson)
> - Fixed #34 (Pathologically slow parsing when strong and italics emphasis are 
> applied together)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-241) Need a tagByProject that works like commitByProject

2013-04-04 Thread Erik Petzold (JIRA) 

[ 
https://jira.codehaus.org/browse/MRELEASE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323192#comment-323192
 ] 

Erik Petzold commented on MRELEASE-241:
---

I also have a directory structure in svn, which I cannnot change. It is a flat 
project layout, where the projects are living in different svn locations.

{noformat} 
root
 |-folder1
 | |-trunk
 | |   |-project1
 | |   |   |-pom.xml
 | |   |-submodule1
 | |   |   |-pom.xml
 | |-branches
 | |-tags
 |
 |-folder2
   |-trunk
   |   |-submodule2
   |   |   |-pom.xml
   |   |-submodule3
   |   |   |-pom.xml
   |-branches
   |-tags
{noformat} 

I think thats basically the same like the ohers had.

The Problem is, that the tag for submodule2 and submodule3 is not set 
correctly, even if the tag base is correct (there is only one tag-"action" in 
folder1).

For me it is not important if the commitByProject setting is used for this, or 
if a new setting tagByProject is created. But I need this in an official 
release, not a selfmade version with the patch.

Will this be solved in the next versions or will this stay the way it is (this 
ticket is open for a long time until now).

> Need a tagByProject that works like commitByProject
> ---
>
> Key: MRELEASE-241
> URL: https://jira.codehaus.org/browse/MRELEASE-241
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.0-beta-6
>Reporter: Tim McCune
> Fix For: Backlog
>
> Attachments: AbstractReleasePhase.java, 
> maven-release-2.0-beta-7-cfs.patch, maven-release-2.0-beta-7-cfs.zip, 
> releaseExample.tar.gz
>
>
> We have kind of an odd project layout because some of our developers only use 
> Eclipse for CVS, which doesn't handle shared poms that are not part of an 
> actual project very well.  As a result, we have a project structure that 
> looks something like this:
> |-- a
> |   `-- z
> |   |-- pom.xml
> |   `-- src
> |   `-- main
> |   `-- java
> |   `-- Test.java
> `-- poms
> |-- a
> |   `-- pom.xml
> `-- pom.xml
> Where poms/pom.xml is the top-level shared pom, poms/a/pom.xml is its child, 
> and a/z/pom.xml is a child of poms/a/pom.xml.
> We have never got the release:prepare goal to work successfully on this 
> project.  I discovered the commitByProject configuration property, which got 
> us a lot further when I set it to true.  However, now there is a problem with 
> the CVS tag that it creates, because it runs "cvs tag" in the working 
> directory, and only once, instead of once for each project.  We need that 
> tagging to work the same as the committing, where it executes the tag command 
> once for each pom.  I'm attaching a sample project that demonstrates the 
> problem when you run "mvn release:prepare" on it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira