[jira] (MGPG-31) Integrate w/ Maven password encryption to avoid need to type passphrase
[
https://jira.codehaus.org/browse/MGPG-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Tran closed MGPG-31.
Resolution: Fixed
fixed at
Revision: 1647942
Author: dantran
Date: Friday, December 26, 2014 12:20:15 AM
Message:
[MGPG-31] Add ability to store passphase under settings.xml in clear or
encrypted text
Modified : /maven/plugins/trunk/maven-gpg-plugin/pom.xml
Modified : /maven/plugins/trunk/maven-gpg-plugin/src/it/settings.xml
Added :
/maven/plugins/trunk/maven-gpg-plugin/src/it/sign-with-passphase-from-maven-settings
Added :
/maven/plugins/trunk/maven-gpg-plugin/src/it/sign-with-passphase-from-maven-settings/invoker.properties
Added :
/maven/plugins/trunk/maven-gpg-plugin/src/it/sign-with-passphase-from-maven-settings/pom.xml
Added :
/maven/plugins/trunk/maven-gpg-plugin/src/it/sign-with-passphase-from-maven-settings/verify.bsh
Modified :
/maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgMojo.java
Added : /maven/plugins/trunk/maven-gpg-plugin/src/main/resources
Added : /maven/plugins/trunk/maven-gpg-plugin/src/main/resources/META-INF
Added : /maven/plugins/trunk/maven-gpg-plugin/src/main/resources/META-INF/plexus
Added :
/maven/plugins/trunk/maven-gpg-plugin/src/main/resources/META-INF/plexus/components.xml
Modified : /maven/plugins/trunk/maven-gpg-plugin/src/site/apt/usage.apt.vm
> Integrate w/ Maven password encryption to avoid need to type passphrase
> ---
>
> Key: MGPG-31
> URL: https://jira.codehaus.org/browse/MGPG-31
> Project: Maven GPG Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
> Environment: JDK 6u21, Ubuntu, Maven 3.0 RC1
>Reporter: Jesse Glick
>Assignee: Dan Tran
>Priority: Minor
> Labels: contributers-welcome
> Fix For: 1.6
>
>
> It is cumbersome to be prompted for a passphrase during both release:prepare
> and release:perform:
> {noformat}
> [INFO] --- maven-gpg-plugin:1.1:sign (sign-artifacts) @ nbm-maven-plugin
> ---
> GPG Passphrase: *
> {noformat}
> I already use http://maven.apache.org/guides/mini/guide-encryption.html (with
> a master password on an Ubuntu encrypted filesystem) so why do I need to type
> this pass phrase each time too?
> Not clear to me whether MGPG-30 already permits this. In any event, the
> plugin documentation does not seem to mention this as a use case.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIASITETOOLS-88) normalize newlines of text resources copied from skin
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359686#comment-359686
]
Michael Osipov commented on DOXIASITETOOLS-88:
--
Well, SCM is special because you can set up normalization already there. I have
found the spot. It is
[{{ScmPublishPublishScmMojo#copyAndNormalizeNewlines}}|http://maven.apache.org/plugins/maven-scm-publish-plugin/xref/org/apache/maven/plugins/scmpublish/ScmPublishPublishScmMojo.html#L195].
We could easily copy the methods and reuse them. The question is, do files in
the skin have the same encoding as siteOutputEncoding? Are
{{src/site/resources}} copied appropriately? The former could break stuff.
> normalize newlines of text resources copied from skin
> -
>
> Key: DOXIASITETOOLS-88
> URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-88
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Reporter: Herve Boutemy
>Priority: Minor
>
> text resources from skin (*.css, *.js, ...) are copied in binary form
> but since the skin jar is done on one machine and reused on multiple other
> ones, not necessarily same platform, these files can have newlines
> inconsistent with actual platform
> Notice: I don't know if this is a severe problem, as severe as
> DOXIASITETOOLS-87, where inconsistency happened inside text files
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-326) Make file encoding default to platform encoding
[ https://jira.codehaus.org/browse/MSITE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359687#comment-359687 ] Michael Osipov commented on MSITE-326: -- And that is a bug to me! > Make file encoding default to platform encoding > --- > > Key: MSITE-326 > URL: https://jira.codehaus.org/browse/MSITE-326 > Project: Maven Site Plugin > Issue Type: Wish > Components: encoding >Affects Versions: 2.0-beta-5, 2.0-beta-6 >Reporter: Herve Boutemy > > According to the [user poll about the default file > encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], > the inputEncoding should default to the platform default encoding instead of > Latin-1. Since that would be a breaking change it is left to users to vote > for this issue if they feelt it's worth to have it like that. > If the change is made, we should have the plugin output a warning when using > the platform encoding. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-263) improve minimum java requirement when m-compiler-p not explicitely configured: use default properties
[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359688#comment-359688
]
Michael Osipov commented on MPIR-263:
-
I see, you added only this: {{project.getProperties().getProperty(
"maven.compiler.target" );}}. Let's leave it for now as-is until we have a
shared component for this.
> improve minimum java requirement when m-compiler-p not explicitely
> configured: use default properties
> -
>
> Key: MPIR-263
> URL: https://jira.codehaus.org/browse/MPIR-263
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
> Components: summary
>Affects Versions: 2.6
> Environment: Maven 2.2.1 and 3.0.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.8
>
>
> If you define {{maven.compiler.target}} in the {{}} section or
> per command line, that value is not taken into account in report generation.
> The source and target version are retrieved from plugins and
> pluginsManagement configuration only.
> same as MPLUGIN-279
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5745) Add example of toolchains.xml to Maven distribution
Robert Scholte created MNG-5745:
---
Summary: Add example of toolchains.xml to Maven distribution
Key: MNG-5745
URL: https://jira.codehaus.org/browse/MNG-5745
Project: Maven
Issue Type: Bug
Reporter: Robert Scholte
Just like {{settings.xml}} add a complete example of {{toolchains.xml}} to the
distribution.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5746) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
Tibor Digana created MNG-5746: - Summary: Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html Key: MNG-5746 URL: https://jira.codehaus.org/browse/MNG-5746 Project: Maven Issue Type: Bug Components: Documentation: General Environment: GnuPG Reporter: Tibor Digana Priority: Critical Me as a new Committer had to register public GnuPG key. Few parts of this documentation were not maintained as it seems. http://maven.apache.org/developers/release/pmc-gpg-keys.html The DSA algorithm is nowadays considered not secure enough. Therefore RSA should be chosen: (1) DSA and Elgamal (default) Your selection? 1 DSA keypair will have 1024 bits. DSA Key size is nowadays too short even for RSA and should be 4096: What keysize do you want? (2048) 2048 Requested keysize is 2048 bits Password was not entered. Here we have different opinions. From my PoV no password might be ok for signature verification. The Committers use to keep their keys in .gpg folder on their private laptops and they do not distribute them in CI systems. You need a Passphrase to protect your secret key. You don't want a passphrase - this is probably a *bad* idea! I will do it anyway. You can change your passphrase at any time, using this program with the option "--edit-key". -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359689#comment-359689
]
Michael Osipov edited comment on MPIR-247 at 12/26/14 6:15 AM:
---
Yes, the try/catch was what I had in mind. IT is too much hassle for this edge
case. Though, I cannot test the try/catch it would be like this:
{code}
if ( versions.size() > 0 )
{
try {
Collections.sort( versions );
} catch (IAE e) {
if (e.getMessage().equals("...contract violation...") {
throw new IllegalStateException("Dependencies cannot be sorted due to
MNG-, please update to Maven 3.2.5 to resolve this ssue");
} else throw e;
}
artifact.setVersion( versions.get( versions.size() - 1
).toString() );
log.debug( "DependencyManagement resolved: " +
artifact.getId() );
}
{code}
was (Author: michael-o):
Yes, the try/catch was what I had in mind. IT is too much hassle for this edge
case. Though, I cannot test the try/catch it would be like this:
{code}
if ( versions.size() > 0 )
{
try {
Collections.sort( versions );
} catch (IAE e) {
if (e.getMessage().equals("...contract violation...") {
throw new IllegalStateException("Dependencies cannot be sorted due to
MNG-, please update to Maven 3.2.5 to resolve this ssue");
} else throw e;
}
artifact.setVersion( versions.get( versions.size() - 1
).toString() );
log.debug( "DependencyManagement resolved: " +
artifact.getId() );
}
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
> Labels: close-pending
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.Use
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359689#comment-359689
]
Michael Osipov commented on MPIR-247:
-
Yes, the try/catch was what I had in mind. IT is too much hassle for this edge
case. Though, I cannot test the try/catch it would be like this:
{code}
if ( versions.size() > 0 )
{
try {
Collections.sort( versions );
} catch (IAE e) {
if (e.getMessage().equals("...contract violation...") {
throw new IllegalStateException("Dependencies cannot be sorted due to
MNG-, please update to Maven 3.2.5 to resolve this ssue");
} else throw e;
}
artifact.setVersion( versions.get( versions.size() - 1
).toString() );
log.debug( "DependencyManagement resolved: " +
artifact.getId() );
}
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
> Labels: close-pending
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
>
[jira] (DOXIASITETOOLS-88) normalize newlines of text resources copied from skin
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359690#comment-359690 ] Herve Boutemy commented on DOXIASITETOOLS-88: - bq. The question is, do files in the skin have the same encoding as siteOutputEncoding? I think you nailed the most important problem, more important than newlines it would require a skins descriptor inside the packaged skin, to document the encoding used by the skin then extensions to filter newlines could be added to the skin descriptor too we already had MSITE-453 about creating a skin packaging adding a skin descriptor would complete the overall picture and would give us a place to document how to create a skin, because this is not well documented AFAIK > normalize newlines of text resources copied from skin > - > > Key: DOXIASITETOOLS-88 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-88 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Herve Boutemy >Priority: Minor > > text resources from skin (*.css, *.js, ...) are copied in binary form > but since the skin jar is done on one machine and reused on multiple other > ones, not necessarily same platform, these files can have newlines > inconsistent with actual platform > Notice: I don't know if this is a severe problem, as severe as > DOXIASITETOOLS-87, where inconsistency happened inside text files -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-326) Make file encoding default to platform encoding
[ https://jira.codehaus.org/browse/MSITE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359692#comment-359692 ] Herve Boutemy commented on MSITE-326: - it's compatibility with a time when we didn't have any strategy, then each choice was made independently, which lead to inconsistency hence this Jira issue: do we trade compatibility for consistency? > Make file encoding default to platform encoding > --- > > Key: MSITE-326 > URL: https://jira.codehaus.org/browse/MSITE-326 > Project: Maven Site Plugin > Issue Type: Wish > Components: encoding >Affects Versions: 2.0-beta-5, 2.0-beta-6 >Reporter: Herve Boutemy > > According to the [user poll about the default file > encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], > the inputEncoding should default to the platform default encoding instead of > Latin-1. Since that would be a breaking change it is left to users to vote > for this issue if they feelt it's worth to have it like that. > If the change is made, we should have the plugin output a warning when using > the platform encoding. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSKINS-92) Facebook Like iframe too narrow when in topbar
[
https://jira.codehaus.org/browse/MSKINS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated MSKINS-92:
-
Attachment: MSKINS-92.patch
Patch against https://svn.apache.org/repos/asf/maven/skins/trunk
> Facebook Like iframe too narrow when in topbar
> --
>
> Key: MSKINS-92
> URL: https://jira.codehaus.org/browse/MSKINS-92
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Francesco Chicchiriccò
>Priority: Minor
> Labels: close-pending
> Attachments: MSKINS-92.patch
>
>
> See Apache Syncope website at http://syncope.apache.org
> On the top right you can see the Facebook Like button rendered by
> {code}
> src="http://www.facebook.com/plugins/like.php?href=http://syncope.apache.org/&send=false&layout=button_count&show-faces=false&action=like&colorscheme=dark";
> scrolling="no" frameborder="0"
> style="border:none; width:80px; height:20px; margin-top: 10px;"
> class="pull-right" >
> {code}
> when changing style to
> {code}
> "border:none; width:100px; height:20px; margin-top: 10px;"
> {code}
> the right-side box is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-263) improve minimum java requirement when m-compiler-p not explicitely configured: use default properties
[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359693#comment-359693
]
Herve Boutemy commented on MPIR-263:
now we're back to understanding
then agreement
> improve minimum java requirement when m-compiler-p not explicitely
> configured: use default properties
> -
>
> Key: MPIR-263
> URL: https://jira.codehaus.org/browse/MPIR-263
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
> Components: summary
>Affects Versions: 2.6
> Environment: Maven 2.2.1 and 3.0.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.8
>
>
> If you define {{maven.compiler.target}} in the {{}} section or
> per command line, that value is not taken into account in report generation.
> The source and target version are retrieved from plugins and
> pluginsManagement configuration only.
> same as MPLUGIN-279
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359694#comment-359694
]
Herve Boutemy commented on MPIR-247:
yes
notice that adding to the message the versions that cause the issue could be
useful
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
> Labels: close-pending
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
> at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:376)
> at ja
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[ https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy moved MNG-5746 to MNGSITE-216: Complexity: (was: Intermediate) Component/s: (was: Documentation: General) Key: MNGSITE-216 (was: MNG-5746) Project: Maven Project Web Site (was: Maven) > Obsolete instructions in > http://maven.apache.org/developers/release/pmc-gpg-keys.html > - > > Key: MNGSITE-216 > URL: https://jira.codehaus.org/browse/MNGSITE-216 > Project: Maven Project Web Site > Issue Type: Bug > Environment: GnuPG >Reporter: Tibor Digana >Priority: Critical > > Me as a new Committer had to register public GnuPG key. Few parts of this > documentation were not maintained as it seems. > http://maven.apache.org/developers/release/pmc-gpg-keys.html > The DSA algorithm is nowadays considered not secure enough. Therefore RSA > should be chosen: > (1) DSA and Elgamal (default) > Your selection? 1 > DSA keypair will have 1024 bits. > DSA Key size is nowadays too short even for RSA and should be 4096: > What keysize do you want? (2048) 2048 > Requested keysize is 2048 bits > Password was not entered. Here we have different opinions. From my PoV no > password might be ok for signature verification. The Committers use to keep > their keys in .gpg folder on their private laptops and they do not distribute > them in CI systems. > You need a Passphrase to protect your secret key. > You don't want a passphrase - this is probably a *bad* idea! > I will do it anyway. You can change your passphrase at any time, > using this program with the option "--edit-key". -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[
https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNGSITE-216:
--
Description:
Me as a new Committer had to register public GnuPG key. Few parts of this
documentation were not maintained as it seems.
http://maven.apache.org/developers/release/pmc-gpg-keys.html
The DSA algorithm is nowadays considered not secure enough. Therefore RSA
should be chosen:
{noformat}(1) DSA and Elgamal (default)
Your selection? 1
DSA keypair will have 1024 bits.{noformat}
DSA Key size is nowadays too short even for RSA and should be 4096:
{noformat}What keysize do you want? (2048) 2048
Requested keysize is 2048 bits{noformat}
Password was not entered. Here we have different opinions. From my PoV no
password might be ok for signature verification. The Committers use to keep
their keys in .gpg folder on their private laptops and they do not distribute
them in CI systems.
{noformat}You need a Passphrase to protect your secret key.
You don't want a passphrase - this is probably a *bad* idea!
I will do it anyway. You can change your passphrase at any time,
using this program with the option "--edit-key".{noformat}
was:
Me as a new Committer had to register public GnuPG key. Few parts of this
documentation were not maintained as it seems.
http://maven.apache.org/developers/release/pmc-gpg-keys.html
The DSA algorithm is nowadays considered not secure enough. Therefore RSA
should be chosen:
(1) DSA and Elgamal (default)
Your selection? 1
DSA keypair will have 1024 bits.
DSA Key size is nowadays too short even for RSA and should be 4096:
What keysize do you want? (2048) 2048
Requested keysize is 2048 bits
Password was not entered. Here we have different opinions. From my PoV no
password might be ok for signature verification. The Committers use to keep
their keys in .gpg folder on their private laptops and they do not distribute
them in CI systems.
You need a Passphrase to protect your secret key.
You don't want a passphrase - this is probably a *bad* idea!
I will do it anyway. You can change your passphrase at any time,
using this program with the option "--edit-key".
> Obsolete instructions in
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> -
>
> Key: MNGSITE-216
> URL: https://jira.codehaus.org/browse/MNGSITE-216
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: GnuPG
>Reporter: Tibor Digana
>Priority: Critical
>
> Me as a new Committer had to register public GnuPG key. Few parts of this
> documentation were not maintained as it seems.
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> The DSA algorithm is nowadays considered not secure enough. Therefore RSA
> should be chosen:
> {noformat}(1) DSA and Elgamal (default)
> Your selection? 1
> DSA keypair will have 1024 bits.{noformat}
> DSA Key size is nowadays too short even for RSA and should be 4096:
> {noformat}What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits{noformat}
> Password was not entered. Here we have different opinions. From my PoV no
> password might be ok for signature verification. The Committers use to keep
> their keys in .gpg folder on their private laptops and they do not distribute
> them in CI systems.
> {noformat}You need a Passphrase to protect your secret key.
> You don't want a passphrase - this is probably a *bad* idea!
> I will do it anyway. You can change your passphrase at any time,
> using this program with the option "--edit-key".{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[
https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359695#comment-359695
]
Herve Boutemy commented on MNGSITE-216:
---
you're right: these instructions were written a long time ago and should be
updated
perhaps we could simply give links to
http://www.apache.org/dev/release-signing.html , since there is an official
Apache page now about it
> Obsolete instructions in
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> -
>
> Key: MNGSITE-216
> URL: https://jira.codehaus.org/browse/MNGSITE-216
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: GnuPG
>Reporter: Tibor Digana
>Priority: Critical
>
> Me as a new Committer had to register public GnuPG key. Few parts of this
> documentation were not maintained as it seems.
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> The DSA algorithm is nowadays considered not secure enough. Therefore RSA
> should be chosen:
> {noformat}(1) DSA and Elgamal (default)
> Your selection? 1
> DSA keypair will have 1024 bits.{noformat}
> DSA Key size is nowadays too short even for RSA and should be 4096:
> {noformat}What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits{noformat}
> Password was not entered. Here we have different opinions. From my PoV no
> password might be ok for signature verification. The Committers use to keep
> their keys in .gpg folder on their private laptops and they do not distribute
> them in CI systems.
> {noformat}You need a Passphrase to protect your secret key.
> You don't want a passphrase - this is probably a *bad* idea!
> I will do it anyway. You can change your passphrase at any time,
> using this program with the option "--edit-key".{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[
https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359696#comment-359696
]
Herve Boutemy commented on MNGSITE-216:
---
or http://www.apache.org/dev/openpgp.html#generate-key
> Obsolete instructions in
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> -
>
> Key: MNGSITE-216
> URL: https://jira.codehaus.org/browse/MNGSITE-216
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: GnuPG
>Reporter: Tibor Digana
>Priority: Critical
>
> Me as a new Committer had to register public GnuPG key. Few parts of this
> documentation were not maintained as it seems.
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> The DSA algorithm is nowadays considered not secure enough. Therefore RSA
> should be chosen:
> {noformat}(1) DSA and Elgamal (default)
> Your selection? 1
> DSA keypair will have 1024 bits.{noformat}
> DSA Key size is nowadays too short even for RSA and should be 4096:
> {noformat}What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits{noformat}
> Password was not entered. Here we have different opinions. From my PoV no
> password might be ok for signature verification. The Committers use to keep
> their keys in .gpg folder on their private laptops and they do not distribute
> them in CI systems.
> {noformat}You need a Passphrase to protect your secret key.
> You don't want a passphrase - this is probably a *bad* idea!
> I will do it anyway. You can change your passphrase at any time,
> using this program with the option "--edit-key".{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5745) Add example of toolchains.xml to Maven distribution
[
https://jira.codehaus.org/browse/MNG-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5745.
---
Resolution: Fixed
Fix Version/s: 3.2.6
Assignee: Robert Scholte
Fixed in
[71976ecf4d27866ab22177cddf982ca69936fa2f|http://git-wip-us.apache.org/repos/asf/maven/commit/71976ecf]
> Add example of toolchains.xml to Maven distribution
> ---
>
> Key: MNG-5745
> URL: https://jira.codehaus.org/browse/MNG-5745
> Project: Maven
> Issue Type: Bug
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.2.6
>
>
> Just like {{settings.xml}} add a complete example of {{toolchains.xml}} to
> the distribution.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[
https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359698#comment-359698
]
Tibor Digana commented on MNGSITE-216:
--
Yes, I agree definitely.
The page http://maven.apache.org/developers/release/pmc-gpg-keys.html can
freely point to a common page
http://www.apache.org/dev/openpgp.html#generate-key having detailed
instructions.
This would simplify the maintenance.
> Obsolete instructions in
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> -
>
> Key: MNGSITE-216
> URL: https://jira.codehaus.org/browse/MNGSITE-216
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: GnuPG
>Reporter: Tibor Digana
>Priority: Critical
>
> Me as a new Committer had to register public GnuPG key. Few parts of this
> documentation were not maintained as it seems.
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> The DSA algorithm is nowadays considered not secure enough. Therefore RSA
> should be chosen:
> {noformat}(1) DSA and Elgamal (default)
> Your selection? 1
> DSA keypair will have 1024 bits.{noformat}
> DSA Key size is nowadays too short even for RSA and should be 4096:
> {noformat}What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits{noformat}
> Password was not entered. Here we have different opinions. From my PoV no
> password might be ok for signature verification. The Committers use to keep
> their keys in .gpg folder on their private laptops and they do not distribute
> them in CI systems.
> {noformat}You need a Passphrase to protect your secret key.
> You don't want a passphrase - this is probably a *bad* idea!
> I will do it anyway. You can change your passphrase at any time,
> using this program with the option "--edit-key".{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[
https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359699#comment-359699
]
Herve Boutemy commented on MNGSITE-216:
---
only the "gpg --gen-key" section should be removed in favor of a link
the rest seems reasonably useful and easier to use for a Maven dev
do you want to try to modify the site yourself?
(I'm available on IRC if any help needed)
> Obsolete instructions in
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> -
>
> Key: MNGSITE-216
> URL: https://jira.codehaus.org/browse/MNGSITE-216
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: GnuPG
>Reporter: Tibor Digana
>Priority: Critical
>
> Me as a new Committer had to register public GnuPG key. Few parts of this
> documentation were not maintained as it seems.
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> The DSA algorithm is nowadays considered not secure enough. Therefore RSA
> should be chosen:
> {noformat}(1) DSA and Elgamal (default)
> Your selection? 1
> DSA keypair will have 1024 bits.{noformat}
> DSA Key size is nowadays too short even for RSA and should be 4096:
> {noformat}What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits{noformat}
> Password was not entered. Here we have different opinions. From my PoV no
> password might be ok for signature verification. The Committers use to keep
> their keys in .gpg folder on their private laptops and they do not distribute
> them in CI systems.
> {noformat}You need a Passphrase to protect your secret key.
> You don't want a passphrase - this is probably a *bad* idea!
> I will do it anyway. You can change your passphrase at any time,
> using this program with the option "--edit-key".{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1129) JDK 5 should be the min requirements in surefire project
[ https://jira.codehaus.org/browse/SUREFIRE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1129: --- Fix Version/s: 2.19 > JDK 5 should be the min requirements in surefire project > > > Key: SUREFIRE-1129 > URL: https://jira.codehaus.org/browse/SUREFIRE-1129 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana > Fix For: 2.19 > > > updating maven-plugin-plugin configuration with requirements.jdk=1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1129) JDK 5 should be the min requirements in surefire project
Tibor Digana created SUREFIRE-1129: -- Summary: JDK 5 should be the min requirements in surefire project Key: SUREFIRE-1129 URL: https://jira.codehaus.org/browse/SUREFIRE-1129 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven Surefire Report Plugin Affects Versions: 2.18 Reporter: Tibor Digana updating maven-plugin-plugin configuration with requirements.jdk=1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5747) DefaultMavenExecutionRequest.copy() doesn't keep useLegacyLocalRepository
Herve Boutemy created MNG-5747: -- Summary: DefaultMavenExecutionRequest.copy() doesn't keep useLegacyLocalRepository Key: MNG-5747 URL: https://jira.codehaus.org/browse/MNG-5747 Project: Maven Issue Type: Bug Affects Versions: 3.2.5 Reporter: Herve Boutemy Priority: Minor problem in code, but no precise known issue caused by this inconsistency -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5742) inconsistent classloading for extensions=true plugins
[ https://jira.codehaus.org/browse/MNG-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reopened MNG-5742: - MojoDescriptors of extensions plugins are not fully/correctly setup after this change. > inconsistent classloading for extensions=true plugins > - > > Key: MNG-5742 > URL: https://jira.codehaus.org/browse/MNG-5742 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.2.1, 3.2.5 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.2.6 > > > Maven creates two class realms for build extensions plugins. One realm is > used to contribute core extensions and the other to execute plugins goals. > The two realms have slightly different classpath, with extensions realm not > "seeing" classes from other extensions and not resolving reactor > dependencies. The two realms are mostly independent and have duplicate copies > of components, including duplicate copies of singletons. This results in > multiple invocation of singleton components in some cases. This also results > inconsistent/unexpected component wiring. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5747) DefaultMavenExecutionRequest.copy() doesn't keep useLegacyLocalRepository
[ https://jira.codehaus.org/browse/MNG-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359701#comment-359701 ] Herve Boutemy edited comment on MNG-5747 at 12/26/14 10:21 AM: --- done in [328a777c|http://git-wip-us.apache.org/repos/asf/maven/commit/328a777c] was (Author: hboutemy): donen in [328a777c|http://git-wip-us.apache.org/repos/asf/maven/commit/328a777c] > DefaultMavenExecutionRequest.copy() doesn't keep useLegacyLocalRepository > - > > Key: MNG-5747 > URL: https://jira.codehaus.org/browse/MNG-5747 > Project: Maven > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Minor > Fix For: 3.2.6 > > > problem in code, but no precise known issue caused by this inconsistency -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5748) DefaultMavenExecutionRequest.copy() doesn't keep builderId
Herve Boutemy created MNG-5748: -- Summary: DefaultMavenExecutionRequest.copy() doesn't keep builderId Key: MNG-5748 URL: https://jira.codehaus.org/browse/MNG-5748 Project: Maven Issue Type: Bug Affects Versions: 3.2.5 Reporter: Herve Boutemy problem in code, but no precise known issue caused by this inconsistency -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5747) DefaultMavenExecutionRequest.copy() doesn't keep useLegacyLocalRepository
[ https://jira.codehaus.org/browse/MNG-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-5747. -- Resolution: Fixed Fix Version/s: 3.2.6 Assignee: Herve Boutemy donen in [328a777c|http://git-wip-us.apache.org/repos/asf/maven/commit/328a777c] > DefaultMavenExecutionRequest.copy() doesn't keep useLegacyLocalRepository > - > > Key: MNG-5747 > URL: https://jira.codehaus.org/browse/MNG-5747 > Project: Maven > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Minor > Fix For: 3.2.6 > > > problem in code, but no precise known issue caused by this inconsistency -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5748) DefaultMavenExecutionRequest.copy() doesn't keep builderId
[ https://jira.codehaus.org/browse/MNG-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-5748. -- Resolution: Fixed Fix Version/s: 3.2.6 Assignee: Herve Boutemy done in [c239f6ea|http://git-wip-us.apache.org/repos/asf/maven/commit/c239f6ea] > DefaultMavenExecutionRequest.copy() doesn't keep builderId > -- > > Key: MNG-5748 > URL: https://jira.codehaus.org/browse/MNG-5748 > Project: Maven > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 3.2.6 > > > problem in code, but no precise known issue caused by this inconsistency -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1129) JDK 5 should be the min requirements in surefire project
[ https://jira.codehaus.org/browse/SUREFIRE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359703#comment-359703 ] Tibor Digana commented on SUREFIRE-1129: maven-plugin-plugin configuration fixed@2.19-SNAPSHOT in GitHub PR https://github.com/apache/maven-surefire/pull/77 The most recent sire@2.18.1 fixed in SVN repo https://svn.apache.org/repos/infra/websites/production/maven/content/surefire-archives/surefire-LATEST $ svn ci -m "[SUREFIRE-1129] JDK 5 should be the min requirements in surefire project" Sendingmaven-failsafe-plugin/plugin-info.html Sendingmaven-surefire-plugin/plugin-info.html Sendingmaven-surefire-report-plugin/plugin-info.html Committed revision 934064. > JDK 5 should be the min requirements in surefire project > > > Key: SUREFIRE-1129 > URL: https://jira.codehaus.org/browse/SUREFIRE-1129 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana > Fix For: 2.19 > > > updating maven-plugin-plugin configuration with requirements.jdk=1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1129) JDK 5 should be the min requirements in surefire project
[ https://jira.codehaus.org/browse/SUREFIRE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359703#comment-359703 ] Tibor Digana edited comment on SUREFIRE-1129 at 12/26/14 10:51 AM: --- maven-plugin-plugin configuration fixed@2.19-SNAPSHOT in GitHub PR https://github.com/apache/maven-surefire/pull/77 The most recent site@2.18.1 fixed in SVN repo https://svn.apache.org/repos/infra/websites/production/maven/content/surefire-archives/surefire-LATEST $ svn ci -m "[SUREFIRE-1129] JDK 5 should be the min requirements in surefire project" Sendingmaven-failsafe-plugin/plugin-info.html Sendingmaven-surefire-plugin/plugin-info.html Sendingmaven-surefire-report-plugin/plugin-info.html Committed revision 934064. was (Author: tibor17): maven-plugin-plugin configuration fixed@2.19-SNAPSHOT in GitHub PR https://github.com/apache/maven-surefire/pull/77 The most recent sire@2.18.1 fixed in SVN repo https://svn.apache.org/repos/infra/websites/production/maven/content/surefire-archives/surefire-LATEST $ svn ci -m "[SUREFIRE-1129] JDK 5 should be the min requirements in surefire project" Sendingmaven-failsafe-plugin/plugin-info.html Sendingmaven-surefire-plugin/plugin-info.html Sendingmaven-surefire-report-plugin/plugin-info.html Committed revision 934064. > JDK 5 should be the min requirements in surefire project > > > Key: SUREFIRE-1129 > URL: https://jira.codehaus.org/browse/SUREFIRE-1129 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana > Fix For: 2.19 > > > updating maven-plugin-plugin configuration with requirements.jdk=1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRRESOURCES-81) Unexpected behaviour when bundled resource has the same name as another file in src/main/resources
[
https://jira.codehaus.org/browse/MRRESOURCES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MRRESOURCES-81:
---
Issue Type: Bug (was: Improvement)
> Unexpected behaviour when bundled resource has the same name as another file
> in src/main/resources
> --
>
> Key: MRRESOURCES-81
> URL: https://jira.codehaus.org/browse/MRRESOURCES-81
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Priority: Minor
> Fix For: more-investigation
>
> Attachments: MRRESOURCES-81.zip
>
>
> Scenario:
> Some project bundles a file named {{META-INF/beans.xml}}.
> Another project wants to use that file for its tests, so it sets
> {{false}} and
> {{true}}. Now let's assume that this project
> also has a file named {{META-INF/beans.xml}} under {{src/main/resources}}.
> My assumption - especially when using {{false}}
> - is that everything should be fine: the beans.xml from the bundle should not
> be conflicting with the one from the main branch of the project that wants to
> use the bundled file.
> But this is what happens instead: The file from {{src/main/resources}} ends
> up in {{maven-shared-archive-resources}}, *not* the one from the bundle.
> The problem is caused by the way existing project resources are seemingly
> preferred over the bundled resources from the user defined artifact (and are
> even copied to the output directory). From a user perspective, this is not
> what I want. See also
> {{ProcessRemoteResourcesMojo.copyResourceIfExists(...)}}.
> A possible fix might be to introduce a new property like
> {{preferProjectResources}} which can be set to {{false}} (which should be the
> default value in my opinion, would break backwards compatibility though).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRRESOURCES-81) Unexpected behaviour when bundled resource has the same name as another file in src/main/resources
[
https://jira.codehaus.org/browse/MRRESOURCES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359704#comment-359704
]
Karl-Heinz Marbaise commented on MRRESOURCES-81:
After diving more into this issue I changed it to back to a bug cause it
shouldn't silently overwrite files which already exist...at least a warning
should in such cases being created. And yes you are right...i was on the wrong
path...
> Unexpected behaviour when bundled resource has the same name as another file
> in src/main/resources
> --
>
> Key: MRRESOURCES-81
> URL: https://jira.codehaus.org/browse/MRRESOURCES-81
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Priority: Minor
> Fix For: more-investigation
>
> Attachments: MRRESOURCES-81.zip
>
>
> Scenario:
> Some project bundles a file named {{META-INF/beans.xml}}.
> Another project wants to use that file for its tests, so it sets
> {{false}} and
> {{true}}. Now let's assume that this project
> also has a file named {{META-INF/beans.xml}} under {{src/main/resources}}.
> My assumption - especially when using {{false}}
> - is that everything should be fine: the beans.xml from the bundle should not
> be conflicting with the one from the main branch of the project that wants to
> use the bundled file.
> But this is what happens instead: The file from {{src/main/resources}} ends
> up in {{maven-shared-archive-resources}}, *not* the one from the bundle.
> The problem is caused by the way existing project resources are seemingly
> preferred over the bundled resources from the user defined artifact (and are
> even copied to the output directory). From a user perspective, this is not
> what I want. See also
> {{ProcessRemoteResourcesMojo.copyResourceIfExists(...)}}.
> A possible fix might be to introduce a new property like
> {{preferProjectResources}} which can be set to {{false}} (which should be the
> default value in my opinion, would break backwards compatibility though).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[
https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359705#comment-359705
]
Tibor Digana commented on MNGSITE-216:
--
Sure, provide me with svn repo url and i will update it.
Thx
> Obsolete instructions in
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> -
>
> Key: MNGSITE-216
> URL: https://jira.codehaus.org/browse/MNGSITE-216
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: GnuPG
>Reporter: Tibor Digana
>Priority: Critical
>
> Me as a new Committer had to register public GnuPG key. Few parts of this
> documentation were not maintained as it seems.
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> The DSA algorithm is nowadays considered not secure enough. Therefore RSA
> should be chosen:
> {noformat}(1) DSA and Elgamal (default)
> Your selection? 1
> DSA keypair will have 1024 bits.{noformat}
> DSA Key size is nowadays too short even for RSA and should be 4096:
> {noformat}What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits{noformat}
> Password was not entered. Here we have different opinions. From my PoV no
> password might be ok for signature verification. The Committers use to keep
> their keys in .gpg folder on their private laptops and they do not distribute
> them in CI systems.
> {noformat}You need a Passphrase to protect your secret key.
> You don't want a passphrase - this is probably a *bad* idea!
> I will do it anyway. You can change your passphrase at any time,
> using this program with the option "--edit-key".{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1129) JDK 5 should be the min requirements in surefire project
[ https://jira.codehaus.org/browse/SUREFIRE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1129: -- Assignee: Tibor Digana > JDK 5 should be the min requirements in surefire project > > > Key: SUREFIRE-1129 > URL: https://jira.codehaus.org/browse/SUREFIRE-1129 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > updating maven-plugin-plugin configuration with requirements.jdk=1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[
https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned MNGSITE-216:
Assignee: Tibor Digana
> Obsolete instructions in
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> -
>
> Key: MNGSITE-216
> URL: https://jira.codehaus.org/browse/MNGSITE-216
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: GnuPG
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Critical
>
> Me as a new Committer had to register public GnuPG key. Few parts of this
> documentation were not maintained as it seems.
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> The DSA algorithm is nowadays considered not secure enough. Therefore RSA
> should be chosen:
> {noformat}(1) DSA and Elgamal (default)
> Your selection? 1
> DSA keypair will have 1024 bits.{noformat}
> DSA Key size is nowadays too short even for RSA and should be 4096:
> {noformat}What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits{noformat}
> Password was not entered. Here we have different opinions. From my PoV no
> password might be ok for signature verification. The Committers use to keep
> their keys in .gpg folder on their private laptops and they do not distribute
> them in CI systems.
> {noformat}You need a Passphrase to protect your secret key.
> You don't want a passphrase - this is probably a *bad* idea!
> I will do it anyway. You can change your passphrase at any time,
> using this program with the option "--edit-key".{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1130) Remove TODO in surefire 3.0
[ https://jira.codehaus.org/browse/SUREFIRE-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1130: --- Summary: Remove TODO in surefire 3.0 (was: Remove TOTO in surefire 3.0) > Remove TODO in surefire 3.0 > --- > > Key: SUREFIRE-1130 > URL: https://jira.codehaus.org/browse/SUREFIRE-1130 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 3.0 > > > Resolve: > //todo add @Override in surefire 3.0 running on the top of JDK 6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1130) Remove TOTO in surefire 3.0
[ https://jira.codehaus.org/browse/SUREFIRE-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1130: -- Assignee: Tibor Digana > Remove TOTO in surefire 3.0 > --- > > Key: SUREFIRE-1130 > URL: https://jira.codehaus.org/browse/SUREFIRE-1130 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 3.0 > > > Resolve: > //todo add @Override in surefire 3.0 running on the top of JDK 6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1130) Remove TOTO in surefire 3.0
[ https://jira.codehaus.org/browse/SUREFIRE-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1130: --- Fix Version/s: 3.0 > Remove TOTO in surefire 3.0 > --- > > Key: SUREFIRE-1130 > URL: https://jira.codehaus.org/browse/SUREFIRE-1130 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Reporter: Tibor Digana > Fix For: 3.0 > > > Resolve: > //todo add @Override in surefire 3.0 running on the top of JDK 6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1130) Remove TOTO in surefire 3.0
Tibor Digana created SUREFIRE-1130: -- Summary: Remove TOTO in surefire 3.0 Key: SUREFIRE-1130 URL: https://jira.codehaus.org/browse/SUREFIRE-1130 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven Surefire Report Plugin Reporter: Tibor Digana Resolve: //todo add @Override in surefire 3.0 running on the top of JDK 6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1131) Remove obsolete maven profiles
Tibor Digana created SUREFIRE-1131: -- Summary: Remove obsolete maven profiles Key: SUREFIRE-1131 URL: https://jira.codehaus.org/browse/SUREFIRE-1131 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven Surefire Report Plugin Affects Versions: 2.18 Reporter: Tibor Digana remove jdk1.3, 1.4, maven-2.2.1 profiles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1131) Remove obsolete maven profiles
[ https://jira.codehaus.org/browse/SUREFIRE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1131: --- Fix Version/s: 2.19 > Remove obsolete maven profiles > -- > > Key: SUREFIRE-1131 > URL: https://jira.codehaus.org/browse/SUREFIRE-1131 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana > Fix For: 2.19 > > > remove jdk1.3, 1.4, maven-2.2.1 profiles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1131) Remove obsolete maven profiles
[ https://jira.codehaus.org/browse/SUREFIRE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1131: -- Assignee: Tibor Digana > Remove obsolete maven profiles > -- > > Key: SUREFIRE-1131 > URL: https://jira.codehaus.org/browse/SUREFIRE-1131 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > remove jdk1.3, 1.4, maven-2.2.1 profiles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRRESOURCES-81) Unexpected behaviour when bundled resource has the same name as another file in src/main/resources
[
https://jira.codehaus.org/browse/MRRESOURCES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MRRESOURCES-81:
---
Comment: was deleted
(was: After diving more into this issue I changed it to back to a bug cause it
shouldn't silently overwrite files which already exist...at least a warning
should in such cases being created. And yes you are right...i was on the wrong
path...)
> Unexpected behaviour when bundled resource has the same name as another file
> in src/main/resources
> --
>
> Key: MRRESOURCES-81
> URL: https://jira.codehaus.org/browse/MRRESOURCES-81
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Priority: Minor
> Fix For: more-investigation
>
> Attachments: MRRESOURCES-81.zip
>
>
> Scenario:
> Some project bundles a file named {{META-INF/beans.xml}}.
> Another project wants to use that file for its tests, so it sets
> {{false}} and
> {{true}}. Now let's assume that this project
> also has a file named {{META-INF/beans.xml}} under {{src/main/resources}}.
> My assumption - especially when using {{false}}
> - is that everything should be fine: the beans.xml from the bundle should not
> be conflicting with the one from the main branch of the project that wants to
> use the bundled file.
> But this is what happens instead: The file from {{src/main/resources}} ends
> up in {{maven-shared-archive-resources}}, *not* the one from the bundle.
> The problem is caused by the way existing project resources are seemingly
> preferred over the bundled resources from the user defined artifact (and are
> even copied to the output directory). From a user perspective, this is not
> what I want. See also
> {{ProcessRemoteResourcesMojo.copyResourceIfExists(...)}}.
> A possible fix might be to introduce a new property like
> {{preferProjectResources}} which can be set to {{false}} (which should be the
> default value in my opinion, would break backwards compatibility though).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-216) Obsolete instructions in http://maven.apache.org/developers/release/pmc-gpg-keys.html
[
https://jira.codehaus.org/browse/MNGSITE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359706#comment-359706
]
Robert Scholte commented on MNGSITE-216:
http://cms.apache.org see also
http://maven.apache.org/developers/website/index.html
> Obsolete instructions in
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> -
>
> Key: MNGSITE-216
> URL: https://jira.codehaus.org/browse/MNGSITE-216
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: GnuPG
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Critical
>
> Me as a new Committer had to register public GnuPG key. Few parts of this
> documentation were not maintained as it seems.
> http://maven.apache.org/developers/release/pmc-gpg-keys.html
> The DSA algorithm is nowadays considered not secure enough. Therefore RSA
> should be chosen:
> {noformat}(1) DSA and Elgamal (default)
> Your selection? 1
> DSA keypair will have 1024 bits.{noformat}
> DSA Key size is nowadays too short even for RSA and should be 4096:
> {noformat}What keysize do you want? (2048) 2048
> Requested keysize is 2048 bits{noformat}
> Password was not entered. Here we have different opinions. From my PoV no
> password might be ok for signature verification. The Committers use to keep
> their keys in .gpg folder on their private laptops and they do not distribute
> them in CI systems.
> {noformat}You need a Passphrase to protect your secret key.
> You don't want a passphrase - this is probably a *bad* idea!
> I will do it anyway. You can change your passphrase at any time,
> using this program with the option "--edit-key".{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1128) Fix mvn 2.2.1 build process https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1
[ https://jira.codehaus.org/browse/SUREFIRE-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1128: --- Description: Fix + OOM: MaxPermSize (?) + "Reports directory is missing" looks like h/w issue, but the root cause is unknown (?) + IT(jetty-war-test-failing) Unsupported major.minor version 51.0 (fixed in PR#76) + comment out @Override on interfaces in MarkAsFailureListener.java, see TODO comment and SUREFIRE-1030 (fixed in PR#76) + remove unnecessary javac 1.6 in IT test surefire-1055-parallelTestCount/pom.xml (fixed in PR#76) was: Fix OOM: MaxPermSize, IT(jetty-war-test-failing) Unsupported major.minor version 51.0 > Fix mvn 2.2.1 build process > https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 > --- > > Key: SUREFIRE-1128 > URL: https://jira.codehaus.org/browse/SUREFIRE-1128 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 > Environment: > https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 >Reporter: Tibor Digana > Fix For: 2.19 > > > Fix > + OOM: MaxPermSize (?) > + "Reports directory is missing" looks like h/w issue, but the root cause is > unknown (?) > + IT(jetty-war-test-failing) Unsupported major.minor version 51.0 (fixed in > PR#76) > + comment out @Override on interfaces in MarkAsFailureListener.java, see TODO > comment and SUREFIRE-1030 (fixed in PR#76) > + remove unnecessary javac 1.6 in IT test > surefire-1055-parallelTestCount/pom.xml (fixed in PR#76) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1128) Fix mvn 2.2.1 build process https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1
[ https://jira.codehaus.org/browse/SUREFIRE-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1128: --- Description: Fix + OOM: MaxPermSize (?) + "Reports directory is missing" looks like h/w issue, but the root cause is unknown (?) + IT(jetty-war-test-failing) Unsupported major.minor version 51.0 (fixed in PR#76) + comment out @Override on interfaces in MarkAsFailureListener.java, see TODO comment and SUREFIRE-1130 (fixed in PR#76) + remove unnecessary javac 1.6 in IT test surefire-1055-parallelTestCount/pom.xml (fixed in PR#76) was: Fix + OOM: MaxPermSize (?) + "Reports directory is missing" looks like h/w issue, but the root cause is unknown (?) + IT(jetty-war-test-failing) Unsupported major.minor version 51.0 (fixed in PR#76) + comment out @Override on interfaces in MarkAsFailureListener.java, see TODO comment and SUREFIRE-1030 (fixed in PR#76) + remove unnecessary javac 1.6 in IT test surefire-1055-parallelTestCount/pom.xml (fixed in PR#76) > Fix mvn 2.2.1 build process > https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 > --- > > Key: SUREFIRE-1128 > URL: https://jira.codehaus.org/browse/SUREFIRE-1128 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 > Environment: > https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 >Reporter: Tibor Digana > Fix For: 2.19 > > > Fix > + OOM: MaxPermSize (?) > + "Reports directory is missing" looks like h/w issue, but the root cause is > unknown (?) > + IT(jetty-war-test-failing) Unsupported major.minor version 51.0 (fixed in > PR#76) > + comment out @Override on interfaces in MarkAsFailureListener.java, see TODO > comment and SUREFIRE-1130 (fixed in PR#76) > + remove unnecessary javac 1.6 in IT test > surefire-1055-parallelTestCount/pom.xml (fixed in PR#76) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-247:
Labels: (was: close-pending)
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
> at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:376)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:182)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:146)
> at j
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPIR-247:
---
Assignee: Michael Osipov
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
> at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:376)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:182)
> at java.util.ComparableTimSort.sort(Co
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359707#comment-359707
]
Michael Osipov commented on MPIR-247:
-
OK, I will prepare a branch and will let you know to check it.
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
> at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:376)
> at java.util.ComparableTimSor
[jira] (MPMD-170) Have targetJdk default to maven.compiler.target
[
https://jira.codehaus.org/browse/MPMD-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359708#comment-359708
]
Michael Osipov commented on MPMD-170:
-
[~hboutemy], what do you think about this patch. Adapt the logic from MPIR-263?
Think a step further, is this parameter necessary at all?
> Have targetJdk default to maven.compiler.target
> ---
>
> Key: MPMD-170
> URL: https://jira.codehaus.org/browse/MPMD-170
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 3.0.1
>Reporter: Stevo Slavic
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.4
>
> Attachments: MPMD-170.patch
>
>
> Currently {{targetJdk}} has to be defined separately from
> {{maven.compiler.target}} property that most plugins already default to, so
> target JDK information is unnecessarily repeated, making POMs with
> maven-pmd-plugin less DRY, harder to maintain, prone to mistakes and unwanted
> behavior.
> So, please make {{targetJdk}} default to {{maven.compiler.target}} property.
> Attached is [^MPMD-170.patch] which adds this behavior.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-326) Make file encoding default to platform encoding
[ https://jira.codehaus.org/browse/MSITE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359710#comment-359710 ] Michael Osipov commented on MSITE-326: -- I prefer consistency because we always prefer convention over configuration. If someone still has failed to properly configure his project it should fail to make him aware of. > Make file encoding default to platform encoding > --- > > Key: MSITE-326 > URL: https://jira.codehaus.org/browse/MSITE-326 > Project: Maven Site Plugin > Issue Type: Wish > Components: encoding >Affects Versions: 2.0-beta-5, 2.0-beta-6 >Reporter: Herve Boutemy > > According to the [user poll about the default file > encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], > the inputEncoding should default to the platform default encoding instead of > Latin-1. Since that would be a breaking change it is left to users to vote > for this issue if they feelt it's worth to have it like that. > If the change is made, we should have the plugin output a warning when using > the platform encoding. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5744) UNable to login unix after configuring the env variable permanently
[ https://jira.codehaus.org/browse/MNG-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5744. --- Resolution: Not A Bug Seek help on the users mailing list. > UNable to login unix after configuring the env variable permanently > --- > > Key: MNG-5744 > URL: https://jira.codehaus.org/browse/MNG-5744 > Project: Maven > Issue Type: Bug > Components: General >Affects Versions: 3.2.5 > Environment: Win 8.1, I use to connect Ubento using VMware > RAM : 8 GB > HDD : 1 TB > apache-maven-3.2.5-bin.tar.gz (Trying to create the project) >Reporter: Karthikeyan balusamy >Priority: Blocker > > I have set the M2_HOME, M2 and JAVA_HOME value in /etc/profile in Ubento and > after re-starting, I could not able to login to Ubento. I am getting the > error message. Please assist me as soon as possble. This is completely > blocking login to linux. > "Not enough physical memory is available to power on this virtual machine > with its configured settings. > It is possible that native applications and/or services have locked down > memory which could be preventing the virtual machine from launching. Shutting > down unnecessary applications or services may free enough memory to launch > this virtual machine. > If you were able to power on this virtual machine on this host computer in > the past, try rebooting the host computer. Rebooting may allow you to use > slightly more host memory to run virtual machines." -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5743) Add support for splitted POMs
[
https://jira.codehaus.org/browse/MNG-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359712#comment-359712
]
Michael Osipov commented on MNG-5743:
-
This wouldn't be better than using Ant. I am against this, you might want to
seach for mixins.
> Add support for splitted POMs
> -
>
> Key: MNG-5743
> URL: https://jira.codehaus.org/browse/MNG-5743
> Project: Maven
> Issue Type: Improvement
> Components: Design, Patterns & Best Practices
>Affects Versions: Issues to be reviewed for 4.x
>Reporter: Oliver B. Fischer
>
> Please add the possibility to split a POM into multiple files. A huge POM is
> difficult to maintain and it is also difficult to navigate through a huge
> POM.
> So it would be nice to have the possibility to split a POM into multiple
> files.
> This could be achived by adding an {{include}} directive or by supporting
> configuration directory as suggested in [Optional support for splitting up
> pom.xml in multiple files|http://docs.codehaus.org/x/BgSV].
> Adding this feature would be help to promoted Maven in new projects.
> Futhermore it would be helpful for all maintaining large Maven based projects.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1131) Remove obsolete maven profiles
[ https://jira.codehaus.org/browse/SUREFIRE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359713#comment-359713 ] Michael Osipov commented on SUREFIRE-1131: -- Shouldn't be Maven 2.2.1 support removed with the next major only? > Remove obsolete maven profiles > -- > > Key: SUREFIRE-1131 > URL: https://jira.codehaus.org/browse/SUREFIRE-1131 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > remove jdk1.3, 1.4, maven-2.2.1 profiles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIASITETOOLS-88) normalize newlines of text resources copied from skin
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359714#comment-359714 ] Michael Osipov commented on DOXIASITETOOLS-88: -- MSITE-453 has not moved for years. If so, I would move this ticket as a subticket of MSITE-453. Without having knowledge about the skin, I wouldn't transform anything. > normalize newlines of text resources copied from skin > - > > Key: DOXIASITETOOLS-88 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-88 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Herve Boutemy >Priority: Minor > > text resources from skin (*.css, *.js, ...) are copied in binary form > but since the skin jar is done on one machine and reused on multiple other > ones, not necessarily same platform, these files can have newlines > inconsistent with actual platform > Notice: I don't know if this is a severe problem, as severe as > DOXIASITETOOLS-87, where inconsistency happened inside text files -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIASITETOOLS-88) normalize newlines of text resources copied from skin
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359714#comment-359714 ] Michael Osipov edited comment on DOXIASITETOOLS-88 at 12/26/14 1:48 PM: MSITE-453 has not moved for years. Regardless of that I would move this ticket as a subticket of MSITE-453. Without having knowledge about the skin, I wouldn't transform anything. was (Author: michael-o): MSITE-453 has not moved for years. If so, I would move this ticket as a subticket of MSITE-453. Without having knowledge about the skin, I wouldn't transform anything. > normalize newlines of text resources copied from skin > - > > Key: DOXIASITETOOLS-88 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-88 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Herve Boutemy >Priority: Minor > > text resources from skin (*.css, *.js, ...) are copied in binary form > but since the skin jar is done on one machine and reused on multiple other > ones, not necessarily same platform, these files can have newlines > inconsistent with actual platform > Notice: I don't know if this is a severe problem, as severe as > DOXIASITETOOLS-87, where inconsistency happened inside text files -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1683) type zip for packaging ?
[ https://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359715#comment-359715 ] Michael Osipov commented on MNG-1683: - Do you still need this? We have Maven Assembly plugin. > type zip for packaging ? > > > Key: MNG-1683 > URL: https://jira.codehaus.org/browse/MNG-1683 > Project: Maven > Issue Type: Improvement > Environment: not significant >Reporter: Olivier Lamy > Fix For: Issues to be reviewed for 3.x > > Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, > maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip > > > Hi, > I don't know if the artifact type zip exists (I think not after few test). > But I want to separate the html content and the webapp content (classes, > configuration files and so on). > The use case is to separate this different works (html designer and java > developpement) and production installation (one is to an http server and the > other is on an app server) in two artifacts with separate versionning. > But the zip is not recognized. > Then I would like to use it as an artifact with maven's features (snapshot, > pom, version, goals : install, deploy release and all others). > Add it to the webapp dependencies (needed only for developpment or unit > tests). > With this type of dependency the zip content could be unpacked to a directory > in the exploded webapp. (certainly need hack on the maven-war-plugin). > I have certainly the workaround to declare this as jar and using the assembly > plugin to generate a zip. > But I can't use install release deploy or something else to manage the > generated zip which is not an artifact. > Thanks for help or workaround. > - Olivier -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSKINS-92) Facebook Like iframe too narrow when in topbar
[
https://jira.codehaus.org/browse/MSKINS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSKINS-92:
Assignee: Michael Osipov
> Facebook Like iframe too narrow when in topbar
> --
>
> Key: MSKINS-92
> URL: https://jira.codehaus.org/browse/MSKINS-92
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Francesco Chicchiriccò
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: MSKINS-92.patch
>
>
> See Apache Syncope website at http://syncope.apache.org
> On the top right you can see the Facebook Like button rendered by
> {code}
> src="http://www.facebook.com/plugins/like.php?href=http://syncope.apache.org/&send=false&layout=button_count&show-faces=false&action=like&colorscheme=dark";
> scrolling="no" frameborder="0"
> style="border:none; width:80px; height:20px; margin-top: 10px;"
> class="pull-right" >
> {code}
> when changing style to
> {code}
> "border:none; width:100px; height:20px; margin-top: 10px;"
> {code}
> the right-side box is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-92) Facebook Like iframe too narrow when in topbar
[
https://jira.codehaus.org/browse/MSKINS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-92:
-
Labels: (was: close-pending)
> Facebook Like iframe too narrow when in topbar
> --
>
> Key: MSKINS-92
> URL: https://jira.codehaus.org/browse/MSKINS-92
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Francesco Chicchiriccò
>Priority: Minor
> Attachments: MSKINS-92.patch
>
>
> See Apache Syncope website at http://syncope.apache.org
> On the top right you can see the Facebook Like button rendered by
> {code}
> src="http://www.facebook.com/plugins/like.php?href=http://syncope.apache.org/&send=false&layout=button_count&show-faces=false&action=like&colorscheme=dark";
> scrolling="no" frameborder="0"
> style="border:none; width:80px; height:20px; margin-top: 10px;"
> class="pull-right" >
> {code}
> when changing style to
> {code}
> "border:none; width:100px; height:20px; margin-top: 10px;"
> {code}
> the right-side box is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1683) type zip for packaging ?
[ https://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359715#comment-359715 ] Michael Osipov edited comment on MNG-1683 at 12/26/14 2:17 PM: --- Do we still need this? We have Maven Assembly plugin. was (Author: michael-o): Do you still need this? We have Maven Assembly plugin. > type zip for packaging ? > > > Key: MNG-1683 > URL: https://jira.codehaus.org/browse/MNG-1683 > Project: Maven > Issue Type: Improvement > Environment: not significant >Reporter: Olivier Lamy > Fix For: Issues to be reviewed for 3.x > > Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, > maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip > > > Hi, > I don't know if the artifact type zip exists (I think not after few test). > But I want to separate the html content and the webapp content (classes, > configuration files and so on). > The use case is to separate this different works (html designer and java > developpement) and production installation (one is to an http server and the > other is on an app server) in two artifacts with separate versionning. > But the zip is not recognized. > Then I would like to use it as an artifact with maven's features (snapshot, > pom, version, goals : install, deploy release and all others). > Add it to the webapp dependencies (needed only for developpment or unit > tests). > With this type of dependency the zip content could be unpacked to a directory > in the exploded webapp. (certainly need hack on the maven-war-plugin). > I have certainly the workaround to declare this as jar and using the assembly > plugin to generate a zip. > But I can't use install release deploy or something else to manage the > generated zip which is not an artifact. > Thanks for help or workaround. > - Olivier -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1131) Remove obsolete maven profiles
[
https://jira.codehaus.org/browse/SUREFIRE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359717#comment-359717
]
Tibor Digana commented on SUREFIRE-1131:
We are already not able to build with maven-2.2.1:
[INFO] Scanning for projects...
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] The projects in the reactor contain a cyclic reference: Edge between
'Vertex{label='org.apache.maven.surefire:surefire-api'}' and
'Vertex{label='org.apache.maven.surefire:surefire-shadefire'}' introduces to
cycle in the graph org.apache.maven.surefire:surefire-shadefire -->
org.apache.maven.surefire:surefire-api -->
org.apache.maven.surefire:surefire-shadefire
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: < 1 second
[INFO] Finished at: Fri Dec 26 21:26:19 CET 2014
[INFO] Final Memory: 7M/31M
[INFO]
> Remove obsolete maven profiles
> --
>
> Key: SUREFIRE-1131
> URL: https://jira.codehaus.org/browse/SUREFIRE-1131
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven
> Surefire Report Plugin
>Affects Versions: 2.18
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.19
>
>
> remove jdk1.3, 1.4, maven-2.2.1 profiles
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5743) Add support for splitted POMs
[
https://jira.codehaus.org/browse/MNG-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359721#comment-359721
]
Oliver B. Fischer commented on MNG-5743:
I am not agains mixins but for 95% of the problems huge POMs causes it would be
enough to store dependency problems in one file, profiles in different files
and so one. This is a simple, easy to understand and to implement way to help
us. I agree with you if you refuse to add the ability to spread the same
section across multiple files.
> Add support for splitted POMs
> -
>
> Key: MNG-5743
> URL: https://jira.codehaus.org/browse/MNG-5743
> Project: Maven
> Issue Type: Improvement
> Components: Design, Patterns & Best Practices
>Affects Versions: Issues to be reviewed for 4.x
>Reporter: Oliver B. Fischer
>
> Please add the possibility to split a POM into multiple files. A huge POM is
> difficult to maintain and it is also difficult to navigate through a huge
> POM.
> So it would be nice to have the possibility to split a POM into multiple
> files.
> This could be achived by adding an {{include}} directive or by supporting
> configuration directory as suggested in [Optional support for splitting up
> pom.xml in multiple files|http://docs.codehaus.org/x/BgSV].
> Adding this feature would be help to promoted Maven in new projects.
> Futhermore it would be helpful for all maintaining large Maven based projects.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-217) Deploy SSH external: copypasta fail in POM snippet comment
Rob Moore created MNGSITE-217: - Summary: Deploy SSH external: copypasta fail in POM snippet comment Key: MNGSITE-217 URL: https://jira.codehaus.org/browse/MNGSITE-217 Project: Maven Project Web Site Issue Type: Bug Reporter: Rob Moore Priority: Trivial At http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html, the comment should say SSH. Looks like it was copied and pasted from the FTP instructions. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1131) Remove obsolete maven profiles
[ https://jira.codehaus.org/browse/SUREFIRE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359723#comment-359723 ] Michael Osipov commented on SUREFIRE-1131: -- I had fun like this with Maven 2.2.x too. Removing Maven 2 support in this release does not mean that you going to bump all deps to Maven 3.0.x? > Remove obsolete maven profiles > -- > > Key: SUREFIRE-1131 > URL: https://jira.codehaus.org/browse/SUREFIRE-1131 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > remove jdk1.3, 1.4, maven-2.2.1 profiles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5742) inconsistent classloading for extensions=true plugins
[ https://jira.codehaus.org/browse/MNG-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5742. --- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6ab41ee8d3f82af456031b13d3a3e1d5834043dc > inconsistent classloading for extensions=true plugins > - > > Key: MNG-5742 > URL: https://jira.codehaus.org/browse/MNG-5742 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.2.1, 3.2.5 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.2.6 > > > Maven creates two class realms for build extensions plugins. One realm is > used to contribute core extensions and the other to execute plugins goals. > The two realms have slightly different classpath, with extensions realm not > "seeing" classes from other extensions and not resolving reactor > dependencies. The two realms are mostly independent and have duplicate copies > of components, including duplicate copies of singletons. This results in > multiple invocation of singleton components in some cases. This also results > inconsistent/unexpected component wiring. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSKINS-92) Facebook Like iframe too narrow when in topbar
[
https://jira.codehaus.org/browse/MSKINS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359725#comment-359725
]
Michael Osipov commented on MSKINS-92:
--
Thank you for the patch. The entire thing has two problems:
1. The iframe has already 100 pixels on your demo page but not in {{site.vm}}
2. The iframe has to grow as soon as the number of likers grows + the width of
the 'Like' content is locale-specific. For instance on my browser, even those
100 pixels are too narrow for the German text.
As you can see on the uploaded screenshot, the entire badge row is crappy. The
patch won't solve the problem.
> Facebook Like iframe too narrow when in topbar
> --
>
> Key: MSKINS-92
> URL: https://jira.codehaus.org/browse/MSKINS-92
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Francesco Chicchiriccò
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: MSKINS-92.patch
>
>
> See Apache Syncope website at http://syncope.apache.org
> On the top right you can see the Facebook Like button rendered by
> {code}
> src="http://www.facebook.com/plugins/like.php?href=http://syncope.apache.org/&send=false&layout=button_count&show-faces=false&action=like&colorscheme=dark";
> scrolling="no" frameborder="0"
> style="border:none; width:80px; height:20px; margin-top: 10px;"
> class="pull-right" >
> {code}
> when changing style to
> {code}
> "border:none; width:100px; height:20px; margin-top: 10px;"
> {code}
> the right-side box is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-92) Facebook Like iframe too narrow when in topbar
[
https://jira.codehaus.org/browse/MSKINS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359725#comment-359725
]
Michael Osipov edited comment on MSKINS-92 at 12/26/14 4:19 PM:
Thank you for the patch. The entire thing has two problems:
1. The iframe has already 100 pixels on your demo page but not in {{site.vm}}
2. The iframe has to grow as soon as the number of likers grows + the width of
the 'Like' content is locale-specific. For instance on my browser, even those
100 pixels are too narrow for the German text.
As you can see on the uploaded screenshot, the entire badge row is crappy. The
patch won't solve the problem. Do you have a better idea? Unfortunately, I am
not really CSS-skilled to provide a better patch.
was (Author: michael-o):
Thank you for the patch. The entire thing has two problems:
1. The iframe has already 100 pixels on your demo page but not in {{site.vm}}
2. The iframe has to grow as soon as the number of likers grows + the width of
the 'Like' content is locale-specific. For instance on my browser, even those
100 pixels are too narrow for the German text.
As you can see on the uploaded screenshot, the entire badge row is crappy. The
patch won't solve the problem.
> Facebook Like iframe too narrow when in topbar
> --
>
> Key: MSKINS-92
> URL: https://jira.codehaus.org/browse/MSKINS-92
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Francesco Chicchiriccò
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: MSKINS-92.patch
>
>
> See Apache Syncope website at http://syncope.apache.org
> On the top right you can see the Facebook Like button rendered by
> {code}
> src="http://www.facebook.com/plugins/like.php?href=http://syncope.apache.org/&send=false&layout=button_count&show-faces=false&action=like&colorscheme=dark";
> scrolling="no" frameborder="0"
> style="border:none; width:80px; height:20px; margin-top: 10px;"
> class="pull-right" >
> {code}
> when changing style to
> {code}
> "border:none; width:100px; height:20px; margin-top: 10px;"
> {code}
> the right-side box is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-92) Facebook Like iframe too narrow when in topbar
[
https://jira.codehaus.org/browse/MSKINS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-92:
-
Attachment: badges.png
> Facebook Like iframe too narrow when in topbar
> --
>
> Key: MSKINS-92
> URL: https://jira.codehaus.org/browse/MSKINS-92
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Francesco Chicchiriccò
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: badges.png, MSKINS-92.patch
>
>
> See Apache Syncope website at http://syncope.apache.org
> On the top right you can see the Facebook Like button rendered by
> {code}
> src="http://www.facebook.com/plugins/like.php?href=http://syncope.apache.org/&send=false&layout=button_count&show-faces=false&action=like&colorscheme=dark";
> scrolling="no" frameborder="0"
> style="border:none; width:80px; height:20px; margin-top: 10px;"
> class="pull-right" >
> {code}
> when changing style to
> {code}
> "border:none; width:100px; height:20px; margin-top: 10px;"
> {code}
> the right-side box is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5743) Add support for splitted POMs
[
https://jira.codehaus.org/browse/MNG-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359726#comment-359726
]
Michael Osipov commented on MNG-5743:
-
Maven even omits properties files for a reason. I think is is a duplicate of
MNG-5102. If you agree I would resolve as duplicate.
> Add support for splitted POMs
> -
>
> Key: MNG-5743
> URL: https://jira.codehaus.org/browse/MNG-5743
> Project: Maven
> Issue Type: Improvement
> Components: Design, Patterns & Best Practices
>Affects Versions: Issues to be reviewed for 4.x
>Reporter: Oliver B. Fischer
>
> Please add the possibility to split a POM into multiple files. A huge POM is
> difficult to maintain and it is also difficult to navigate through a huge
> POM.
> So it would be nice to have the possibility to split a POM into multiple
> files.
> This could be achived by adding an {{include}} directive or by supporting
> configuration directory as suggested in [Optional support for splitting up
> pom.xml in multiple files|http://docs.codehaus.org/x/BgSV].
> Adding this feature would be help to promoted Maven in new projects.
> Futhermore it would be helpful for all maintaining large Maven based projects.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIASITETOOLS-88) normalize newlines of text resources copied from skin
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359727#comment-359727 ] Herve Boutemy commented on DOXIASITETOOLS-88: - ok, good idea > normalize newlines of text resources copied from skin > - > > Key: DOXIASITETOOLS-88 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-88 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Herve Boutemy >Priority: Minor > > text resources from skin (*.css, *.js, ...) are copied in binary form > but since the skin jar is done on one machine and reused on multiple other > ones, not necessarily same platform, these files can have newlines > inconsistent with actual platform > Notice: I don't know if this is a severe problem, as severe as > DOXIASITETOOLS-87, where inconsistency happened inside text files -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1132) Surefire: regular isolated classloader failures in parallelbuild
Alexander Ashitkin created SUREFIRE-1132:
Summary: Surefire: regular isolated classloader failures in
parallelbuild
Key: SUREFIRE-1132
URL: https://jira.codehaus.org/browse/SUREFIRE-1132
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.17
Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
windows server 2008 x64
Maven 3.2.2, 3.2.3, 3.2.5
Java 7.0.25
Reporter: Alexander Ashitkin
Attachments: consoleText-1.txt, consoleText-2.txt, consoleText-3.txt
We have a large project of 300+ modules which regularly fails with different
kind of classloading issues in different places in surefire plugin. The issue
is reproduced only with parallel build and results in build failure. This is a
main contributor in build instability for us. All the dependnecies are actually
present and single treaded build works fine.I attached 3 different samples of
how build fails.
Surefire config:
{code}
0
false
false
{code}
Please advise how to sort thisout - ready to run any provided diagnostic and
evaluate any options.
Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIASITETOOLS-88) normalize newlines of text resources copied from skin
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359728#comment-359728 ] Michael Osipov commented on DOXIASITETOOLS-88: -- Subtasks are only possible within one project. I have linked to MSITE-453. > normalize newlines of text resources copied from skin > - > > Key: DOXIASITETOOLS-88 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-88 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Herve Boutemy >Priority: Minor > > text resources from skin (*.css, *.js, ...) are copied in binary form > but since the skin jar is done on one machine and reused on multiple other > ones, not necessarily same platform, these files can have newlines > inconsistent with actual platform > Notice: I don't know if this is a severe problem, as severe as > DOXIASITETOOLS-87, where inconsistency happened inside text files -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1131) Remove obsolete maven profiles
[ https://jira.codehaus.org/browse/SUREFIRE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1131: --- Description: remove jdk1.3, 1.4 profiles (was: remove jdk1.3, 1.4, maven-2.2.1 profiles) > Remove obsolete maven profiles > -- > > Key: SUREFIRE-1131 > URL: https://jira.codehaus.org/browse/SUREFIRE-1131 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > remove jdk1.3, 1.4 profiles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1131) Remove obsolete maven profiles
[ https://jira.codehaus.org/browse/SUREFIRE-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359729#comment-359729 ] Tibor Digana commented on SUREFIRE-1131: @Michael No, we have to be compliant with Maven 2 till surefire 3, but we have to keep the maven-221 only in the internal IT tests however the complete build is triggered by 3.0.5. Sorry for the mistake. > Remove obsolete maven profiles > -- > > Key: SUREFIRE-1131 > URL: https://jira.codehaus.org/browse/SUREFIRE-1131 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > remove jdk1.3, 1.4 profiles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1132) Surefire: regular isolated classloader failures in parallelbuild
[
https://jira.codehaus.org/browse/SUREFIRE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Ashitkin updated SUREFIRE-1132:
-
Description:
We have a large project of 300+ modules which regularly fails with different
kind of classloading issues in different places in surefire plugin. The issue
is reproduced only with parallel build and is not reproduced in single
threaded. This is a main contributor in build instability for us. All the not
loaded dependnecies are actually present in dependency tree. I attached 3
different samples of how build fails.
Surefire config:
{code}
0
false
false
{code}
maven cmd is like install -T 10
Please advise how to sort this out - ready to run any provided diagnostic and
evaluate any options.
Thanks in advance, Alexander
was:
We have a large project of 300+ modules which regularly fails with different
kind of classloading issues in different places in surefire plugin. The issue
is reproduced only with parallel build and results in build failure. This is a
main contributor in build instability for us. All the dependnecies are actually
present and single treaded build works fine.I attached 3 different samples of
how build fails.
Surefire config:
{code}
0
false
false
{code}
Please advise how to sort thisout - ready to run any provided diagnostic and
evaluate any options.
Thanks in advance, Alexander
> Surefire: regular isolated classloader failures in parallelbuild
>
>
> Key: SUREFIRE-1132
> URL: https://jira.codehaus.org/browse/SUREFIRE-1132
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.17
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
> windows server 2008 x64
> Maven 3.2.2, 3.2.3, 3.2.5
> Java 7.0.25
>Reporter: Alexander Ashitkin
> Attachments: consoleText-1.txt, consoleText-2.txt, consoleText-3.txt
>
>
> We have a large project of 300+ modules which regularly fails with different
> kind of classloading issues in different places in surefire plugin. The issue
> is reproduced only with parallel build and is not reproduced in single
> threaded. This is a main contributor in build instability for us. All the not
> loaded dependnecies are actually present in dependency tree. I attached 3
> different samples of how build fails.
> Surefire config:
> {code}
>
> 0
>
> false
> false
>
> {code}
> maven cmd is like install -T 10
> Please advise how to sort this out - ready to run any provided diagnostic
> and evaluate any options.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1132) Surefire: regular isolated classloader failures in parallelbuild
[
https://jira.codehaus.org/browse/SUREFIRE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Ashitkin updated SUREFIRE-1132:
-
Component/s: classloading
> Surefire: regular isolated classloader failures in parallelbuild
>
>
> Key: SUREFIRE-1132
> URL: https://jira.codehaus.org/browse/SUREFIRE-1132
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.17
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
> windows server 2008 x64
> Maven 3.2.2, 3.2.3, 3.2.5
> Java 7.0.25
>Reporter: Alexander Ashitkin
> Attachments: consoleText-1.txt, consoleText-2.txt, consoleText-3.txt
>
>
> We have a large project of 300+ modules which regularly fails with different
> kind of classloading issues in different places in surefire plugin. The issue
> is reproduced only with parallel build and is not reproduced in single
> threaded. This is a main contributor in build instability for us. All the not
> loaded dependnecies are actually present in dependency tree. I attached 3
> different samples of how build fails.
> Surefire config:
> {code}
>
> 0
>
> false
> false
>
> {code}
> maven cmd is like install -T 10
> Please advise how to sort this out - ready to run any provided diagnostic
> and evaluate any options.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1132) Surefire: regular isolated classloader failures in parallelbuild
[
https://jira.codehaus.org/browse/SUREFIRE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359730#comment-359730
]
Tibor Digana commented on SUREFIRE-1132:
Do you use IBM JVM?
Can you switch off the GC logs and retry again?
> Surefire: regular isolated classloader failures in parallelbuild
>
>
> Key: SUREFIRE-1132
> URL: https://jira.codehaus.org/browse/SUREFIRE-1132
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.17
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
> windows server 2008 x64
> Maven 3.2.2, 3.2.3, 3.2.5
> Java 7.0.25
>Reporter: Alexander Ashitkin
> Attachments: consoleText-1.txt, consoleText-2.txt, consoleText-3.txt
>
>
> We have a large project of 300+ modules which regularly fails with different
> kind of classloading issues in different places in surefire plugin. The issue
> is reproduced only with parallel build and is not reproduced in single
> threaded. This is a main contributor in build instability for us. All the not
> loaded dependnecies are actually present in dependency tree. I attached 3
> different samples of how build fails.
> Surefire config:
> {code}
>
> 0
>
> false
> false
>
> {code}
> maven cmd is like install -T 10
> Please advise how to sort this out - ready to run any provided diagnostic
> and evaluate any options.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1128) Fix mvn 2.2.1 build process https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1
[ https://jira.codehaus.org/browse/SUREFIRE-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1128: -- Assignee: Tibor Digana > Fix mvn 2.2.1 build process > https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 > --- > > Key: SUREFIRE-1128 > URL: https://jira.codehaus.org/browse/SUREFIRE-1128 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 > Environment: > https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > Fix > + OOM: MaxPermSize (?) > + "Reports directory is missing" looks like h/w issue, but the root cause is > unknown (?) > + IT(jetty-war-test-failing) Unsupported major.minor version 51.0 (fixed in > PR#76) > + comment out @Override on interfaces in MarkAsFailureListener.java, see TODO > comment and SUREFIRE-1130 (fixed in PR#76) > + remove unnecessary javac 1.6 in IT test > surefire-1055-parallelTestCount/pom.xml (fixed in PR#76) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1128) Fix mvn 2.2.1 build process https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1
[ https://jira.codehaus.org/browse/SUREFIRE-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359731#comment-359731 ] Tibor Digana commented on SUREFIRE-1128: [INFO] BUILD SUCCESS mvn install -P run-its,maven-2.2.1 JAVA_HOME= MAVEN_OPTS=-server -Xmx752m -XX:MaxPermSize=512m -Djava.awt.headless=true M2_HOME=D:\apache-maven-3.0.5 If the build fails again in Apache CI, then it can be only a serious problem on Jenkins build settings https://builds.apache.org/job/maven-surefire-mvn-2.2.1/ > Fix mvn 2.2.1 build process > https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 > --- > > Key: SUREFIRE-1128 > URL: https://jira.codehaus.org/browse/SUREFIRE-1128 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Affects Versions: 2.18 > Environment: > https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1 >Reporter: Tibor Digana > Fix For: 2.19 > > > Fix > + OOM: MaxPermSize (?) > + "Reports directory is missing" looks like h/w issue, but the root cause is > unknown (?) > + IT(jetty-war-test-failing) Unsupported major.minor version 51.0 (fixed in > PR#76) > + comment out @Override on interfaces in MarkAsFailureListener.java, see TODO > comment and SUREFIRE-1130 (fixed in PR#76) > + remove unnecessary javac 1.6 in IT test > surefire-1055-parallelTestCount/pom.xml (fixed in PR#76) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1132) Surefire: regular isolated classloader failures in parallelbuild
[
https://jira.codehaus.org/browse/SUREFIRE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359730#comment-359730
]
Tibor Digana edited comment on SUREFIRE-1132 at 12/26/14 6:37 PM:
--
Do you use IBM JVM?
Can you switch off the GC logs and retry again?
Can you remove forkCount line in your configuration and retry again?
was (Author: tibor17):
Do you use IBM JVM?
Can you switch off the GC logs and retry again?
> Surefire: regular isolated classloader failures in parallelbuild
>
>
> Key: SUREFIRE-1132
> URL: https://jira.codehaus.org/browse/SUREFIRE-1132
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.17
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
> windows server 2008 x64
> Maven 3.2.2, 3.2.3, 3.2.5
> Java 7.0.25
>Reporter: Alexander Ashitkin
> Attachments: consoleText-1.txt, consoleText-2.txt, consoleText-3.txt
>
>
> We have a large project of 300+ modules which regularly fails with different
> kind of classloading issues in different places in surefire plugin. The issue
> is reproduced only with parallel build and is not reproduced in single
> threaded. This is a main contributor in build instability for us. All the not
> loaded dependnecies are actually present in dependency tree. I attached 3
> different samples of how build fails.
> Surefire config:
> {code}
>
> 0
>
> false
> false
>
> {code}
> maven cmd is like install -T 10
> Please advise how to sort this out - ready to run any provided diagnostic
> and evaluate any options.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-92) Facebook Like iframe too narrow when in topbar
[
https://jira.codehaus.org/browse/MSKINS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359737#comment-359737
]
Francesco Chicchiriccò commented on MSKINS-92:
--
Hi Michael,
# if by "demo page" you mean the Apache Syncope website, I've manually set
there the width to 100px after site generation
# I realize that a fixed width does not solve the general case - but I am not
a CSS guru as well
What about passing the iframe width as a parameter ({{socialBadgeWidth}})?
{code}
120px
syncopeidm
true
false
{code}
> Facebook Like iframe too narrow when in topbar
> --
>
> Key: MSKINS-92
> URL: https://jira.codehaus.org/browse/MSKINS-92
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Francesco Chicchiriccò
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: badges.png, MSKINS-92.patch
>
>
> See Apache Syncope website at http://syncope.apache.org
> On the top right you can see the Facebook Like button rendered by
> {code}
> src="http://www.facebook.com/plugins/like.php?href=http://syncope.apache.org/&send=false&layout=button_count&show-faces=false&action=like&colorscheme=dark";
> scrolling="no" frameborder="0"
> style="border:none; width:80px; height:20px; margin-top: 10px;"
> class="pull-right" >
> {code}
> when changing style to
> {code}
> "border:none; width:100px; height:20px; margin-top: 10px;"
> {code}
> the right-side box is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-92) Facebook Like iframe too narrow when in topbar
[
https://jira.codehaus.org/browse/MSKINS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359737#comment-359737
]
Francesco Chicchiriccò edited comment on MSKINS-92 at 12/26/14 11:52 PM:
-
Hi Michael,
# if by "demo page" you mean the Apache Syncope website, I've manually set
there the width to 100px after site generation
# I realize that a fixed width does not solve the general case - but I am not
a CSS guru as well
What about passing the various width values as parameters?
{code}
172px
syncopeidm
true
false
120px
20px
{code}
was (Author: ilgrosso):
Hi Michael,
# if by "demo page" you mean the Apache Syncope website, I've manually set
there the width to 100px after site generation
# I realize that a fixed width does not solve the general case - but I am not
a CSS guru as well
What about passing the iframe width as a parameter ({{socialBadgeWidth}})?
{code}
120px
syncopeidm
true
false
{code}
> Facebook Like iframe too narrow when in topbar
> --
>
> Key: MSKINS-92
> URL: https://jira.codehaus.org/browse/MSKINS-92
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Francesco Chicchiriccò
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: badges.png, MSKINS-92.patch
>
>
> See Apache Syncope website at http://syncope.apache.org
> On the top right you can see the Facebook Like button rendered by
> {code}
> src="http://www.facebook.com/plugins/like.php?href=http://syncope.apache.org/&send=false&layout=button_count&show-faces=false&action=like&colorscheme=dark";
> scrolling="no" frameborder="0"
> style="border:none; width:80px; height:20px; margin-top: 10px;"
> class="pull-right" >
> {code}
> when changing style to
> {code}
> "border:none; width:100px; height:20px; margin-top: 10px;"
> {code}
> the right-side box is rendered correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
