[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15641092#comment-15641092
]
ASF GitHub Bot commented on MNG-5889:
-
Github user rpatrick00 commented on the issue:
https://github.com/apache/maven/pull/94
OK, addressed both comments from michael-o
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.4.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPH-120) Migrate plugin to Maven 3.0
[ https://issues.apache.org/jira/browse/MPH-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640650#comment-15640650 ] Robert Scholte commented on MPH-120: Only in very rare cases we do a final 2.x release, I don't see any reason why we should do that here. Let's push this plugin forward. > Migrate plugin to Maven 3.0 > --- > > Key: MPH-120 > URL: https://issues.apache.org/jira/browse/MPH-120 > Project: Maven Help Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Robert Scholte > > Migrate plugin as described at > https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1299) Distributed testing using junit inside pom.xml(just like testnames property in testng maven)
[ https://issues.apache.org/jira/browse/SUREFIRE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hemanth updated SUREFIRE-1299: -- Description: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> [...] org.apache.maven.plugins maven-surefire-plugin 2.19.1 [...] src/test/resources/testng.xml testnames Regression Testing,Test2 [...] [...] Can I do something similar inside the pom.xml for Junit? Unfortunately there is no documentation on this. I am assuming that there isn't. Thank you in advance. was: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> [...] org.apache.maven.plugins maven-surefire-plugin 2.19.1 [...] src/test/resources/testng.xml testnames Regression Testing,Test2 [...] [...] Can I do something similar inside the pom.xml for Junit? Unfortunately there is no documentation on this. I am assuming that there isn't. > Distributed testing using junit inside pom.xml(just like testnames property > in testng maven) > > > Key: SUREFIRE-1299 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1299 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, TestNG support >Reporter: Hemanth >Priority: Minor > > Is there a way to configure the distribution of tests in pom.xml to run on > different machines like how we do in testng.xml(Eg: below) > http://testng.org/testng-1.0.dtd";> > thread-count="4"> > > > >value="http://hemanthip:/wd/hub";> > > > > > > > >value="http://hemanthip:4567/wd/hub";> > > > > > > > > [...] > > org.apache.maven.plugins > maven-surefire-plugin > 2.19.1 > > [...] > > src/test/resources/testng.xml > > > > testnames > Regression Testing,Test2 > > > [...] > > > [...] > > Can I do something similar inside the pom.xml for Junit? > Unfortunately there is no documentation on this. I am assuming that there > isn't. > Thank you in advance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1299) Distributed testing using junit inside pom.xml(just like testnames property in testng maven)
[ https://issues.apache.org/jira/browse/SUREFIRE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hemanth updated SUREFIRE-1299: -- Description: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> org.apache.maven.plugins maven-surefire-plugin 2.19.1 src/test/resources/testng.xml testnames Regression Testing,Test2 Can I do something similar inside the pom.xml for Junit? Unfortunately there is no documentation on this. I am assuming that there isn't. Thank you in advance. was: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> [...] org.apache.maven.plugins maven-surefire-plugin 2.19.1 [...] src/test/resources/testng.xml testnames Regression Testing,Test2 [...] [...] Can I do something similar inside the pom.xml for Junit? Unfortunately there is no documentation on this. I am assuming that there isn't. Thank you in advance. > Distributed testing using junit inside pom.xml(just like testnames property > in testng maven) > > > Key: SUREFIRE-1299 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1299 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, TestNG support >Reporter: Hemanth >Priority: Minor > > Is there a way to configure the distribution of tests in pom.xml to run on > different machines like how we do in testng.xml(Eg: below) > http://testng.org/testng-1.0.dtd";> > thread-count="4"> > > > >value="http://hemanthip:/wd/hub";> > > > > > > > >value="http://hemanthip:4567/wd/hub";> > > > > > > > > > org.apache.maven.plugins > maven-surefire-plugin > 2.19.1 > > > src/test/resources/testng.xml > > > > testnames > Regression Testing,Test2 > > > > > > Can I do something similar inside the pom.xml for Junit? > Unfortunately there is no documentation on this. I am assuming that there > isn't. > Thank you in advance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1299) Distributed testing using junit inside pom.xml(just like testnames property in testng maven)
[ https://issues.apache.org/jira/browse/SUREFIRE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hemanth updated SUREFIRE-1299: -- Description: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> [...] org.apache.maven.plugins maven-surefire-plugin 2.19.1 [...] src/test/resources/testng.xml testnames Regression Testing,Test2 [...] [...] Can I do something similar inside the pom.xml for Junit? Unfortunately there is no documentation on this. I am assuming that there isn't. was: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> [...] org.apache.maven.plugins maven-surefire-plugin 2.19.1 [...] src/test/resources/testng.xml testnames Regression Testing,Test2 [...] [...] Can I do the same inside the pom.xml for Junit? Unfortunately there is no documentation on this. I am assuming that there isn't. > Distributed testing using junit inside pom.xml(just like testnames property > in testng maven) > > > Key: SUREFIRE-1299 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1299 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, TestNG support >Reporter: Hemanth >Priority: Minor > > Is there a way to configure the distribution of tests in pom.xml to run on > different machines like how we do in testng.xml(Eg: below) > http://testng.org/testng-1.0.dtd";> > thread-count="4"> > > > >value="http://hemanthip:/wd/hub";> > > > > > > > >value="http://hemanthip:4567/wd/hub";> > > > > > > > > [...] > > org.apache.maven.plugins > maven-surefire-plugin > 2.19.1 > > [...] > > src/test/resources/testng.xml > > > > testnames > Regression Testing,Test2 > > > [...] > > > [...] > > Can I do something similar inside the pom.xml for Junit? > Unfortunately there is no documentation on this. I am assuming that there > isn't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1299) Distributed testing using junit inside pom.xml(just like testnames property in testng maven)
[ https://issues.apache.org/jira/browse/SUREFIRE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hemanth updated SUREFIRE-1299: -- Description: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> [...] org.apache.maven.plugins maven-surefire-plugin 2.19.1 [...] src/test/resources/testng.xml testnames Regression Testing,Test2 [...] [...] Can I do the same inside the pom.xml for Junit? Unfortunately there is no documentation on this. I am assuming that there isn't. was: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> [...] org.apache.maven.plugins maven-surefire-plugin 2.19.1 [...] src/test/resources/testng.xml testnames Regression Testing,Test2 [...] [...] Can I do the same inside the pom.xml? Unfortunately there is no documentation on this. I am assuming that there isn't. > Distributed testing using junit inside pom.xml(just like testnames property > in testng maven) > > > Key: SUREFIRE-1299 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1299 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, TestNG support >Reporter: Hemanth >Priority: Minor > > Is there a way to configure the distribution of tests in pom.xml to run on > different machines like how we do in testng.xml(Eg: below) > http://testng.org/testng-1.0.dtd";> > thread-count="4"> > > > >value="http://hemanthip:/wd/hub";> > > > > > > > >value="http://hemanthip:4567/wd/hub";> > > > > > > > > [...] > > org.apache.maven.plugins > maven-surefire-plugin > 2.19.1 > > [...] > > src/test/resources/testng.xml > > > > testnames > Regression Testing,Test2 > > > [...] > > > [...] > > Can I do the same inside the pom.xml for Junit? > Unfortunately there is no documentation on this. I am assuming that there > isn't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1299) Distributed testing using junit inside pom.xml(just like testnames property in testng maven)
[ https://issues.apache.org/jira/browse/SUREFIRE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hemanth updated SUREFIRE-1299: -- Description: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> http://hemanthip:4567/wd/hub";> [...] org.apache.maven.plugins maven-surefire-plugin 2.19.1 [...] src/test/resources/testng.xml testnames Regression Testing,Test2 [...] [...] Can I do the same inside the pom.xml? Unfortunately there is no documentation on this. I am assuming that there isn't. was: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> Can I do the same inside the pom.xml? Unfortunately there is no documentation on this. I am assuming that there isn't. > Distributed testing using junit inside pom.xml(just like testnames property > in testng maven) > > > Key: SUREFIRE-1299 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1299 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, TestNG support >Reporter: Hemanth >Priority: Minor > > Is there a way to configure the distribution of tests in pom.xml to run on > different machines like how we do in testng.xml(Eg: below) > http://testng.org/testng-1.0.dtd";> > thread-count="4"> > > > >value="http://hemanthip:/wd/hub";> > > > > > > > >value="http://hemanthip:4567/wd/hub";> > > > > > > > > [...] > > org.apache.maven.plugins > maven-surefire-plugin > 2.19.1 > > [...] > > src/test/resources/testng.xml > > > > testnames > Regression Testing,Test2 > > > [...] > > > [...] > > Can I do the same inside the pom.xml? > Unfortunately there is no documentation on this. I am assuming that there > isn't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1299) Distributed testing using junit inside pom.xml(just like testnames property in testng maven)
[ https://issues.apache.org/jira/browse/SUREFIRE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hemanth updated SUREFIRE-1299: -- Summary: Distributed testing using junit inside pom.xml(just like testnames property in testng maven) (was: Distributed testing using junit/testng inside pom.xml) > Distributed testing using junit inside pom.xml(just like testnames property > in testng maven) > > > Key: SUREFIRE-1299 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1299 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, TestNG support >Reporter: Hemanth >Priority: Minor > > Is there a way to configure the distribution of tests in pom.xml to run on > different machines like how we do in testng.xml(Eg: below) > http://testng.org/testng-1.0.dtd";> > thread-count="4"> > > > >value="http://hemanthip:/wd/hub";> > > > > > > > > Can I do the same inside the pom.xml? > Unfortunately there is no documentation on this. I am assuming that there > isn't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1299) Distributed testing using junit/testng inside pom.xml
[ https://issues.apache.org/jira/browse/SUREFIRE-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hemanth updated SUREFIRE-1299: -- Description: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> Can I do the same inside the pom.xml? Unfortunately there is no documentation on this. I am assuming that there isn't. was: Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> Can I do the same inside the pom.xml? Unfortunately there is no documentation on this. I am assuming that there isn't. > Distributed testing using junit/testng inside pom.xml > - > > Key: SUREFIRE-1299 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1299 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, TestNG support >Reporter: Hemanth >Priority: Minor > > Is there a way to configure the distribution of tests in pom.xml to run on > different machines like how we do in testng.xml(Eg: below) > http://testng.org/testng-1.0.dtd";> > thread-count="4"> > > > >value="http://hemanthip:/wd/hub";> > > > > > > > > Can I do the same inside the pom.xml? > Unfortunately there is no documentation on this. I am assuming that there > isn't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SUREFIRE-1299) Distributed testing using junit/testng inside pom.xml
Hemanth created SUREFIRE-1299: - Summary: Distributed testing using junit/testng inside pom.xml Key: SUREFIRE-1299 URL: https://issues.apache.org/jira/browse/SUREFIRE-1299 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support, TestNG support Reporter: Hemanth Priority: Minor Is there a way to configure the distribution of tests in pom.xml to run on different machines like how we do in testng.xml(Eg: below) http://testng.org/testng-1.0.dtd";> http://hemanthip:/wd/hub";> Can I do the same inside the pom.xml? Unfortunately there is no documentation on this. I am assuming that there isn't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPH-120) Migrate plugin to Maven 3.0
[ https://issues.apache.org/jira/browse/MPH-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640536#comment-15640536 ] Guillaume Boué commented on MPH-120: The next version is currently 2.2.1. Do we move directly to a 3.0.0 along with this change without having a 2.2.1? > Migrate plugin to Maven 3.0 > --- > > Key: MPH-120 > URL: https://issues.apache.org/jira/browse/MPH-120 > Project: Maven Help Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Robert Scholte > > Migrate plugin as described at > https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MDEPLOY-211) uniqueVersion broken (if not supported, should be removed from doc, and warning printed)
[
https://issues.apache.org/jira/browse/MDEPLOY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640523#comment-15640523
]
Guillaume Boué commented on MDEPLOY-211:
Should the {{uniqueVersion}} parameter of the {{deploy-file}} plugin be
completely removed, or first deprecated (adding code to break the build if
used) and then removed in a later release? Since the next release is currently
the major upgrade to 3.0.0, we could maybe remove it directly, and add a note
in the index of the site.
> uniqueVersion broken (if not supported, should be removed from doc, and
> warning printed)
>
>
> Key: MDEPLOY-211
> URL: https://issues.apache.org/jira/browse/MDEPLOY-211
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Reporter: Michael Vorburger
>
> Doc on 1. http://maven.apache.org/plugins/maven-deploy-plugin/usage.html as
> well as 2.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html as
> well as 3.
> http://maven.apache.org/plugins/maven-deploy-plugin/file-deployment.html
> (link "Disable timestamps suffix in an artifact", currently broken!)
> currently mentions a uniqueVersion.
> This appears to be broken at least with Maven v3.3.9. For example, if I do:
> {noformat}$ mvn deploy:deploy-file -Durl=file:///tmp/system
> -DrepositoryId=some.id -Dfile=target/hello-impl-0.1.0-SNAPSHOT.jar
> -DpomFile=pom.xml -DuniqueVersion=false
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building hello-impl 0.1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-deploy-plugin:2.8.2:deploy-file (default-cli) @ hello-impl
> ---
> Downloading:
> file:///tmp/system/org/opendaylight/vorburger/hello/hello-impl/0.1.0-SNAPSHOT/maven-metadata.xml
> Uploading:
> file:///tmp/system/org/opendaylight/vorburger/hello/hello-impl/0.1.0-SNAPSHOT/hello-impl-0.1.0-20160618.170929-1.jar
> {noformat}
> Note hello-impl-0.1.0-20160618.170929-1.jar despite -DuniqueVersion=false.
> If this possibility has been removed, as I have the feeling it has been from
> posts incl. MDEPLOY-44 (that was about adding uniqueVersion to deploy just
> like, supposedly, it is on deploy-file; this is about it not even working on
> deploy-file, anymore), then before you close this as WONTFIX, I would argue
> this current half removal is confusing to say the least ..
> If this is not coming back, then the uniqueVersion configuration should be
> fully removed from maven-deploy-plugin, and the documentation in at least 3
> places referred to above should be cleaned up accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MDEPLOY-211) uniqueVersion broken (if not supported, should be removed from doc, and warning printed)
[
https://issues.apache.org/jira/browse/MDEPLOY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640523#comment-15640523
]
Guillaume Boué edited comment on MDEPLOY-211 at 11/5/16 8:24 PM:
-
Should the {{uniqueVersion}} parameter of the {{deploy-file}} goal be
completely removed, or first deprecated (adding code to break the build if
used) and then removed in a later release? Since the next release is currently
the major upgrade to 3.0.0, we could maybe remove it directly, and add a note
in the index of the site.
was (Author: gboue):
Should the {{uniqueVersion}} parameter of the {{deploy-file}} plugin be
completely removed, or first deprecated (adding code to break the build if
used) and then removed in a later release? Since the next release is currently
the major upgrade to 3.0.0, we could maybe remove it directly, and add a note
in the index of the site.
> uniqueVersion broken (if not supported, should be removed from doc, and
> warning printed)
>
>
> Key: MDEPLOY-211
> URL: https://issues.apache.org/jira/browse/MDEPLOY-211
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Reporter: Michael Vorburger
>
> Doc on 1. http://maven.apache.org/plugins/maven-deploy-plugin/usage.html as
> well as 2.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html as
> well as 3.
> http://maven.apache.org/plugins/maven-deploy-plugin/file-deployment.html
> (link "Disable timestamps suffix in an artifact", currently broken!)
> currently mentions a uniqueVersion.
> This appears to be broken at least with Maven v3.3.9. For example, if I do:
> {noformat}$ mvn deploy:deploy-file -Durl=file:///tmp/system
> -DrepositoryId=some.id -Dfile=target/hello-impl-0.1.0-SNAPSHOT.jar
> -DpomFile=pom.xml -DuniqueVersion=false
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building hello-impl 0.1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-deploy-plugin:2.8.2:deploy-file (default-cli) @ hello-impl
> ---
> Downloading:
> file:///tmp/system/org/opendaylight/vorburger/hello/hello-impl/0.1.0-SNAPSHOT/maven-metadata.xml
> Uploading:
> file:///tmp/system/org/opendaylight/vorburger/hello/hello-impl/0.1.0-SNAPSHOT/hello-impl-0.1.0-20160618.170929-1.jar
> {noformat}
> Note hello-impl-0.1.0-20160618.170929-1.jar despite -DuniqueVersion=false.
> If this possibility has been removed, as I have the feeling it has been from
> posts incl. MDEPLOY-44 (that was about adding uniqueVersion to deploy just
> like, supposedly, it is on deploy-file; this is about it not even working on
> deploy-file, anymore), then before you close this as WONTFIX, I would argue
> this current half removal is confusing to say the least ..
> If this is not coming back, then the uniqueVersion configuration should be
> fully removed from maven-deploy-plugin, and the documentation in at least 3
> places referred to above should be cleaned up accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MWAR-352) web.xml not being replaced by plugin configuration
[
https://issues.apache.org/jira/browse/MWAR-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MWAR-352:
Description:
My pom.xml file has the following in it:
{code:xml}
org.apache.maven.plugins
maven-war-plugin
2.6
src/main/webconfig/release/web.xml
{code}
As you can see, the web.xml to be used by war plugin when running Maven install
is located outside of the webapp folder. This work perfectly if there ins't a
web.xml in webapp/WEB-INF folder, but the pluging refuses to use the web.xml
from webconfig/release if there is already a file with the same name in
webapp/WEB-INF.
The issue is that I have to keep one web.xml in webapp/WEB-INF in order to be
able publish the application to my local application server for debug. This
file has particular settings for a local environment.
However, when I want to produce a war to publish in the production server, it
has to be another web.xml, the one located in webconfig/release folder. Problem
is that the war plugin does not replaces one file by the other when generating
the war file.
was:
My pom.xml file has the following in it:
org.apache.maven.plugins
maven-war-plugin
2.6
src/main/webconfig/release/web.xml
As you can see, the web.xml to be used by war plugin when running Maven install
is located outside of the webapp folder. This work perfectly if there ins't a
web.xml in webapp/WEB-INF folder, but the pluging refuses to use the web.xml
from webconfig/release if there is already a file with the same name in
webapp/WEB-INF.
The issue is that I have to keep one web.xml in webapp/WEB-INF in order to be
able publish the application to my local application server for debug. This
file has particular settings for a local environment.
However, when I want to produce a war to publish in the production server, it
has to be another web.xml, the one located in webconfig/release folder. Problem
is that the war plugin does not replaces one file by the other when generating
the war file.
> web.xml not being replaced by plugin configuration
> --
>
> Key: MWAR-352
> URL: https://issues.apache.org/jira/browse/MWAR-352
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: Windows 7 x64, Eclipse Luna, JSF 2 project
>Reporter: Alex Sebastiao Constancio
> Labels: build
> Fix For: 2.6
>
>
> My pom.xml file has the following in it:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.6
>
>
> src/main/webconfig/release/web.xml
>
>
>
>
> {code}
> As you can see, the web.xml to be used by war plugin when running Maven
> install is located outside of the webapp folder. This work perfectly if there
> ins't a web.xml in webapp/WEB-INF folder, but the pluging refuses to use the
> web.xml from webconfig/release if there is already a file with the same name
> in webapp/WEB-INF.
> The issue is that I have to keep one web.xml in webapp/WEB-INF in order to be
> able publish the application to my local application server for debug. This
> file has particular settings for a local environment.
> However, when I want to produce a war to publish in the production server, it
> has to be another web.xml, the one located in webconfig/release folder.
> Problem is that the war plugin does not replaces one file by the other when
> generating the war file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MWAR-397) Replace XStream with Modello to merge overlays
Robert Scholte created MWAR-397:
---
Summary: Replace XStream with Modello to merge overlays
Key: MWAR-397
URL: https://issues.apache.org/jira/browse/MWAR-397
Project: Maven WAR Plugin
Issue Type: Improvement
Reporter: Robert Scholte
When packaging a war with most recent jigsaw-jdk9-ea releases you will get the
following exception:
{noformat}
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final java.util.Comparator java.util.TreeMap.comparator accessible:
module java.base does not "exports private java.util" to unnamed module
@17088b23
at jdk.internal.reflect.Reflection.throwInaccessibleObjectException
(Reflection.java:414)
at java.lang.reflect.AccessibleObject.checkCanSetAccessible
(AccessibleObject.java:198)
at java.lang.reflect.Field.checkCanSetAccessible (Field.java:171)
at java.lang.reflect.Field.setAccessible (Field.java:165)
at com.thoughtworks.xstream.core.util.Fields.locate (Fields.java:40)
at
com.thoughtworks.xstream.converters.collections.TreeMapConverter.
(TreeMapConverter.java:50)
at com.thoughtworks.xstream.XStream.setupConverters (XStream.java:832)
at com.thoughtworks.xstream.XStream. (XStream.java:574)
at com.thoughtworks.xstream.XStream. (XStream.java:496)
at com.thoughtworks.xstream.XStream. (XStream.java:465)
at com.thoughtworks.xstream.XStream. (XStream.java:411)
at com.thoughtworks.xstream.XStream. (XStream.java:378)
at org.apache.maven.plugins.war.util.WebappStructureSerializer.
(WebappStructureSerializer.java:47)
{noformat}
Root cause is the change is the
[jigsaw-jdk-9-ea+135|http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009404.html]
{quote}
The changes to setAccessible in #AwkwardStrongEncapsulation is going to
be disruptive and will no doubt expose hacks in many areas. We've run
into several of these already. The command line option to allow existing
code to break into non-public types/members is --add-exports-private.
The format of the value passed to this option is the same--add-exports.
With #AddExportsInManifest then there are equivalents in the application
JAR main manifest to try out too.
{quote}
The stacktrace exposes that the issue is caused by XStream. It seems that
XStream is used to be able to merge overlays. Maven and most other plugins use
Modello for these kind of things.
There's still a lot of discussion about #ReflectiveAccessToNonExportedTypes and
#AwkwardStrongEncapsulation and but I think we can avoid this issue by simply
switching to the well known Modello solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPH-120) Migrate plugin to Maven 3.0
Robert Scholte created MPH-120: -- Summary: Migrate plugin to Maven 3.0 Key: MPH-120 URL: https://issues.apache.org/jira/browse/MPH-120 Project: Maven Help Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Robert Scholte Migrate plugin as described at https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MPH-107) Mojos use inconsistent line endings throughout
[
https://issues.apache.org/jira/browse/MPH-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué closed MPH-107.
--
Resolution: Fixed
Assignee: Guillaume Boué
> Mojos use inconsistent line endings throughout
> --
>
> Key: MPH-107
> URL: https://issues.apache.org/jira/browse/MPH-107
> Project: Maven Help Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Michael Osipov
>Assignee: Guillaume Boué
> Fix For: 2.2.1
>
>
> Most mojos use {{\n}} instead of using system line ending. This looks weird
> on Windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPH-107) Mojos use inconsistent line endings throughout
[
https://issues.apache.org/jira/browse/MPH-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640327#comment-15640327
]
Hudson commented on MPH-107:
SUCCESS: Integrated in Jenkins build maven-plugins #7459 (See
[https://builds.apache.org/job/maven-plugins/7459/])
[MPH-107] Mojos use inconsistent line endings throughout
Using the system line separator instead of hard-coding "\n" in the different
mojos. (gboue: [http://svn.apache.org/viewvc/?view=rev&rev=1768264])
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/ActiveProfilesMojo.java
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/AllProfilesMojo.java
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EffectivePomMojo.java
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EffectiveSettingsMojo.java
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EvaluateMojo.java
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/ExpressionsMojo.java
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/HelpUtil.java
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/SystemMojo.java
* (edit)
maven-help-plugin/src/test/java/org/apache/maven/plugins/help/DescribeMojoTest.java
* (edit)
maven-help-plugin/src/test/java/org/apache/maven/plugins/help/EvaluateMojoTest.java
> Mojos use inconsistent line endings throughout
> --
>
> Key: MPH-107
> URL: https://issues.apache.org/jira/browse/MPH-107
> Project: Maven Help Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Michael Osipov
> Fix For: 2.2.1
>
>
> Most mojos use {{\n}} instead of using system line ending. This looks weird
> on Windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPH-107) Mojos use inconsistent line endings throughout
[
https://issues.apache.org/jira/browse/MPH-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640251#comment-15640251
]
Guillaume Boué commented on MPH-107:
Fixed in [r1768264|http://svn.apache.org/viewvc?rev=1768264&view=rev].
> Mojos use inconsistent line endings throughout
> --
>
> Key: MPH-107
> URL: https://issues.apache.org/jira/browse/MPH-107
> Project: Maven Help Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Michael Osipov
> Fix For: 2.2.1
>
>
> Most mojos use {{\n}} instead of using system line ending. This looks weird
> on Windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MPH-106) add gav parameter to calculate effective pom for any gav, not only reactor
[ https://issues.apache.org/jira/browse/MPH-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué closed MPH-106. -- Resolution: Fixed Fix Version/s: 2.2.1 > add gav parameter to calculate effective pom for any gav, not only reactor > -- > > Key: MPH-106 > URL: https://issues.apache.org/jira/browse/MPH-106 > Project: Maven Help Plugin > Issue Type: Improvement > Components: effective-pom >Affects Versions: 2.2 >Reporter: Hervé Boutemy > Fix For: 2.2.1 > > > would be useful for example when trying to show a difference between > effective model calculated from reactor and effective model calculated from > repo (see MNG-5890) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MPH-106) add gav parameter to calculate effective pom for any gav, not only reactor
[ https://issues.apache.org/jira/browse/MPH-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué reassigned MPH-106: -- Assignee: Guillaume Boué > add gav parameter to calculate effective pom for any gav, not only reactor > -- > > Key: MPH-106 > URL: https://issues.apache.org/jira/browse/MPH-106 > Project: Maven Help Plugin > Issue Type: Improvement > Components: effective-pom >Affects Versions: 2.2 >Reporter: Hervé Boutemy >Assignee: Guillaume Boué > Fix For: 2.2.1 > > > would be useful for example when trying to show a difference between > effective model calculated from reactor and effective model calculated from > repo (see MNG-5890) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPH-106) add gav parameter to calculate effective pom for any gav, not only reactor
[ https://issues.apache.org/jira/browse/MPH-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640194#comment-15640194 ] Hudson commented on MPH-106: SUCCESS: Integrated in Jenkins build maven-plugins #7457 (See [https://builds.apache.org/job/maven-plugins/7457/]) [MPH-106] add gav parameter to calculate effective pom for any gav, not only reactor Adding an "artifact" parameter to the effective-pom goal. The name is to be consistent with the evaluate goal. -> Refactoring the common code into AbstractHelpMojo (gboue: [http://svn.apache.org/viewvc/?view=rev&rev=1768250]) * (add) maven-help-plugin/src/it/effective-pom-artifact * (add) maven-help-plugin/src/it/effective-pom-artifact/invoker.properties * (add) maven-help-plugin/src/it/effective-pom-artifact/pom.xml * (add) maven-help-plugin/src/it/effective-pom-artifact/test.properties * (add) maven-help-plugin/src/it/effective-pom-artifact/verify.groovy * (edit) maven-help-plugin/src/main/java/org/apache/maven/plugins/help/AbstractHelpMojo.java * (edit) maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EffectivePomMojo.java * (edit) maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EvaluateMojo.java > add gav parameter to calculate effective pom for any gav, not only reactor > -- > > Key: MPH-106 > URL: https://issues.apache.org/jira/browse/MPH-106 > Project: Maven Help Plugin > Issue Type: Improvement > Components: effective-pom >Affects Versions: 2.2 >Reporter: Hervé Boutemy > > would be useful for example when trying to show a difference between > effective model calculated from reactor and effective model calculated from > repo (see MNG-5890) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640150#comment-15640150
]
Rik Smith commented on SUREFIRE-1264:
-
[~tibor17] I am facing the same issue in a project. We also use Parameterized
tests and run them in parallel (suitesAndClasses) with a fork. I also created a
simple project to replicate this issue:
https://github.com/riksmith/SUREFIRE-1264-demo
The actual project has a much more complex setup (including a custom junit
runner code), but I hope a fix for this sample project will also fix our actual
project.
Perhaps good to know:
If you run the sample project with parallel: classes the issue does not occur.
If you run the sample project with forkCount=0 the issue does not occur.
I think it is some kind of threading issue. I tried looking into the code but I
find it quite difficult to understand and I can't get it to debug properly.
It is quite an important issue for us because this means that builds are
sometimes succeeding while actually there are tests failing!
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARCHETYPE-512) archetype:generate while merging the pom with existing pom does not copy the attributes on the elements
[ https://issues.apache.org/jira/browse/ARCHETYPE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetana resolved ARCHETYPE-512. --- Resolution: Fixed Fix Version/s: 2.5 The patch has been attached to the issue. > archetype:generate while merging the pom with existing pom does not copy the > attributes on the elements > > > Key: ARCHETYPE-512 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-512 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Affects Versions: 2.4 > Environment: Windows >Reporter: Chetana > Fix For: 2.5 > > Attachments: MNG-ARCHETYPE-512-archetype-common.patch > > Original Estimate: 5h > Remaining Estimate: 5h > > I am using partial=true and running the archetype on an existing project. The > template pom has plugins with attributes. On archetype:generate, the template > pom is getting merged with the existing pom however the attributes are missed > out -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARCHETYPE-512) archetype:generate while merging the pom with existing pom does not copy the attributes on the elements
[ https://issues.apache.org/jira/browse/ARCHETYPE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetana updated ARCHETYPE-512: -- Attachment: MNG-ARCHETYPE-512-archetype-common.patch The patch now adds the attributes of the configuration elements under the build > archetype:generate while merging the pom with existing pom does not copy the > attributes on the elements > > > Key: ARCHETYPE-512 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-512 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Affects Versions: 2.4 > Environment: Windows >Reporter: Chetana > Fix For: 2.5 > > Attachments: MNG-ARCHETYPE-512-archetype-common.patch > > Original Estimate: 5h > Remaining Estimate: 5h > > I am using partial=true and running the archetype on an existing project. The > template pom has plugins with attributes. On archetype:generate, the template > pom is getting merged with the existing pom however the attributes are missed > out -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-5896) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MNG-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639991#comment-15639991 ] Michael Osipov edited comment on MNG-5896 at 11/5/16 5:12 PM: -- Yes, please. Create a Maven issue: "Upgrade Aether to Maven Resolver 1.2" and create the PR. I intend to roll Maven 3.4 with our new Resolver. was (Author: michael-o): Yes, please. Create a Maven issue: "Upgrade Aether to Maven Resolver 1.2" and create the PR. I have intended to roll Maven 3.4 with our new Resolver. > Download dependency POMs in parallel > > > Key: MNG-5896 > URL: https://issues.apache.org/jira/browse/MNG-5896 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.3.3 >Reporter: Harald Wellmann >Assignee: Michael Osipov > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.3 first downloads the dependency POMs > _sequentially_ and then proceeds downloading the dependency JARs with up to 5 > threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPH-106) add gav parameter to calculate effective pom for any gav, not only reactor
[ https://issues.apache.org/jira/browse/MPH-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15640087#comment-15640087 ] Guillaume Boué commented on MPH-106: Fixed in [r1768250|http://svn.apache.org/viewvc?rev=1768250&view=rev]. > add gav parameter to calculate effective pom for any gav, not only reactor > -- > > Key: MPH-106 > URL: https://issues.apache.org/jira/browse/MPH-106 > Project: Maven Help Plugin > Issue Type: Improvement > Components: effective-pom >Affects Versions: 2.2 >Reporter: Hervé Boutemy > > would be useful for example when trying to show a difference between > effective model calculated from reactor and effective model calculated from > repo (see MNG-5890) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5896) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MNG-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639991#comment-15639991 ] Michael Osipov commented on MNG-5896: - Yes, please. Create a Maven issue: "Upgrade Aether to Maven Resolver 1.2" and create the PR. I have intended to roll Maven 3.4 with our new Resolver. > Download dependency POMs in parallel > > > Key: MNG-5896 > URL: https://issues.apache.org/jira/browse/MNG-5896 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.3.3 >Reporter: Harald Wellmann >Assignee: Michael Osipov > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.3 first downloads the dependency POMs > _sequentially_ and then proceeds downloading the dependency JARs with up to 5 > threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MPH-119) The "artifact" parameter is not taken into account with Maven 3
[
https://issues.apache.org/jira/browse/MPH-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué closed MPH-119.
--
Resolution: Fixed
Fix Version/s: 2.2.1
> The "artifact" parameter is not taken into account with Maven 3
> ---
>
> Key: MPH-119
> URL: https://issues.apache.org/jira/browse/MPH-119
> Project: Maven Help Plugin
> Issue Type: Bug
> Components: evaluate
>Affects Versions: 2.2
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
> Fix For: 2.2.1
>
>
> With Maven 3, the {{artifact}} parameter is not taken into account when
> evaluating expressions. Example:
> {noformat}
> $ mvn help:evaluate -Dartifact=log4j:log4j -Dexpression=project.name
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:evaluate (default-cli) @ standalone-pom ---
> [INFO]
> Maven Stub Project (No POM)
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Expected output would be "Apache Log4j", instead of the stub Maven project.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MPH-114) Goal fails with “Unable to get the POM for the artifact”
[ https://issues.apache.org/jira/browse/MPH-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué closed MPH-114. -- Resolution: Fixed Fix Version/s: 2.2.1 > Goal fails with “Unable to get the POM for the artifact” > > > Key: MPH-114 > URL: https://issues.apache.org/jira/browse/MPH-114 > Project: Maven Help Plugin > Issue Type: Bug > Components: evaluate >Affects Versions: 2.2 >Reporter: Jakub Bochenski >Assignee: Guillaume Boué > Fix For: 2.2.1 > > > See linked SO question -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPH-114) Goal fails with “Unable to get the POM for the artifact”
[ https://issues.apache.org/jira/browse/MPH-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639912#comment-15639912 ] Hudson commented on MPH-114: SUCCESS: Integrated in Jenkins build maven-plugins #7454 (See [https://builds.apache.org/job/maven-plugins/7454/]) [MPH-114] Goal fails with “Unable to get the POM for the artifact” Clarifying docs: the latest version of the artifact is used when no version is specified for the artifact. (gboue: [http://svn.apache.org/viewvc/?view=rev&rev=1768232]) * (edit) maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EvaluateMojo.java > Goal fails with “Unable to get the POM for the artifact” > > > Key: MPH-114 > URL: https://issues.apache.org/jira/browse/MPH-114 > Project: Maven Help Plugin > Issue Type: Bug > Components: evaluate >Affects Versions: 2.2 >Reporter: Jakub Bochenski >Assignee: Guillaume Boué > > See linked SO question -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPH-119) The "artifact" parameter is not taken into account with Maven 3
[
https://issues.apache.org/jira/browse/MPH-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639913#comment-15639913
]
Hudson commented on MPH-119:
SUCCESS: Integrated in Jenkins build maven-plugins #7454 (See
[https://builds.apache.org/job/maven-plugins/7454/])
[MPH-119] The "artifact" parameter is not taken into account with Maven 3
Starting with Maven 3, PluginParameterExpressionEvaluator ignores the project
given as parameter in its 6-args constructor, and fetches instead the current
project from the Maven session. As such, the plugin needs to set the fake
project created through the "artifact" parameter as the session current
project, and put back the real one after construction of the evaluator. (gboue:
[http://svn.apache.org/viewvc/?view=rev&rev=1768231])
* (add) maven-help-plugin/src/it/evaluate-artifact-with-expression-with-output
* (add)
maven-help-plugin/src/it/evaluate-artifact-with-expression-with-output/pom.xml
* (add)
maven-help-plugin/src/it/evaluate-artifact-with-expression-with-output/test.properties
* (add)
maven-help-plugin/src/it/evaluate-artifact-with-expression-with-output/verify.groovy
* (edit)
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EvaluateMojo.java
> The "artifact" parameter is not taken into account with Maven 3
> ---
>
> Key: MPH-119
> URL: https://issues.apache.org/jira/browse/MPH-119
> Project: Maven Help Plugin
> Issue Type: Bug
> Components: evaluate
>Affects Versions: 2.2
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>
> With Maven 3, the {{artifact}} parameter is not taken into account when
> evaluating expressions. Example:
> {noformat}
> $ mvn help:evaluate -Dartifact=log4j:log4j -Dexpression=project.name
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:evaluate (default-cli) @ standalone-pom ---
> [INFO]
> Maven Stub Project (No POM)
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Expected output would be "Apache Log4j", instead of the stub Maven project.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MPH-114) Goal fails with “Unable to get the POM for the artifact”
[ https://issues.apache.org/jira/browse/MPH-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué reassigned MPH-114: -- Assignee: Guillaume Boué > Goal fails with “Unable to get the POM for the artifact” > > > Key: MPH-114 > URL: https://issues.apache.org/jira/browse/MPH-114 > Project: Maven Help Plugin > Issue Type: Bug > Components: evaluate >Affects Versions: 2.2 >Reporter: Jakub Bochenski >Assignee: Guillaume Boué > > See linked SO question -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSKINS-127) For all http://maven.apache.org/ pages it take 2 minutes to see content in China
[ https://issues.apache.org/jira/browse/MSKINS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639883#comment-15639883 ] Hervé Boutemy commented on MSKINS-127: -- thanks for your confirmation: that's better to close the issue once we get a confirmation we didn't miss something we're not proficient in html+css+js in general: help wanted on a lot of topics on this :) > For all http://maven.apache.org/ pages it take 2 minutes to see content in > China > > > Key: MSKINS-127 > URL: https://issues.apache.org/jira/browse/MSKINS-127 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.5 > Environment: a device behind Great Firewall or google.com not > available >Reporter: Paul Verest > Fix For: fluido-1.6 > > > For all http://maven.apache.org/ pages it take 2 minutes to see content, > because page rendeing depends on getting to files > - https://www.google.com/coop/cse/brand > - https://apis.google.com/js/plusone.js > see > http://stackoverflow.com/questions/36959899/maven-site-google-issue-in-china > As far as I know, it is generally good practice to put all script in the end > of body, so that page is visible even if any 3rd party server fail the moment > the page is requests. > This is major bug as it affects many users, the reason it was not filed > before is English skill, motivation and where to raise. > Please review all page for 3rd party loads to insure that generated site will > work even on PC without Internet access. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MSKINS-127) For all http://maven.apache.org/ pages it take 2 minutes to see content in China
[ https://issues.apache.org/jira/browse/MSKINS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy reassigned MSKINS-127: Assignee: Hervé Boutemy > For all http://maven.apache.org/ pages it take 2 minutes to see content in > China > > > Key: MSKINS-127 > URL: https://issues.apache.org/jira/browse/MSKINS-127 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.5 > Environment: a device behind Great Firewall or google.com not > available >Reporter: Paul Verest >Assignee: Hervé Boutemy > Fix For: fluido-1.6 > > > For all http://maven.apache.org/ pages it take 2 minutes to see content, > because page rendeing depends on getting to files > - https://www.google.com/coop/cse/brand > - https://apis.google.com/js/plusone.js > see > http://stackoverflow.com/questions/36959899/maven-site-google-issue-in-china > As far as I know, it is generally good practice to put all script in the end > of body, so that page is visible even if any 3rd party server fail the moment > the page is requests. > This is major bug as it affects many users, the reason it was not filed > before is English skill, motivation and where to raise. > Please review all page for 3rd party loads to insure that generated site will > work even on PC without Internet access. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSKINS-127) For all http://maven.apache.org/ pages it take 2 minutes to see content in China
[ https://issues.apache.org/jira/browse/MSKINS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSKINS-127: - Fix Version/s: fluido-1.6 > For all http://maven.apache.org/ pages it take 2 minutes to see content in > China > > > Key: MSKINS-127 > URL: https://issues.apache.org/jira/browse/MSKINS-127 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.5 > Environment: a device behind Great Firewall or google.com not > available >Reporter: Paul Verest >Assignee: Hervé Boutemy > Fix For: fluido-1.6 > > > For all http://maven.apache.org/ pages it take 2 minutes to see content, > because page rendeing depends on getting to files > - https://www.google.com/coop/cse/brand > - https://apis.google.com/js/plusone.js > see > http://stackoverflow.com/questions/36959899/maven-site-google-issue-in-china > As far as I know, it is generally good practice to put all script in the end > of body, so that page is visible even if any 3rd party server fail the moment > the page is requests. > This is major bug as it affects many users, the reason it was not filed > before is English skill, motivation and where to raise. > Please review all page for 3rd party loads to insure that generated site will > work even on PC without Internet access. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPH-114) Goal fails with “Unable to get the POM for the artifact”
[ https://issues.apache.org/jira/browse/MPH-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639877#comment-15639877 ] Guillaume Boué commented on MPH-114: Fixed in [r1768232|http://svn.apache.org/viewvc?rev=1768232&view=rev]. > Goal fails with “Unable to get the POM for the artifact” > > > Key: MPH-114 > URL: https://issues.apache.org/jira/browse/MPH-114 > Project: Maven Help Plugin > Issue Type: Bug > Components: evaluate >Affects Versions: 2.2 >Reporter: Jakub Bochenski > > See linked SO question -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPH-119) The "artifact" parameter is not taken into account with Maven 3
[
https://issues.apache.org/jira/browse/MPH-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639878#comment-15639878
]
Guillaume Boué commented on MPH-119:
Fixed in [r1768231|http://svn.apache.org/viewvc?rev=1768231&view=rev].
> The "artifact" parameter is not taken into account with Maven 3
> ---
>
> Key: MPH-119
> URL: https://issues.apache.org/jira/browse/MPH-119
> Project: Maven Help Plugin
> Issue Type: Bug
> Components: evaluate
>Affects Versions: 2.2
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>
> With Maven 3, the {{artifact}} parameter is not taken into account when
> evaluating expressions. Example:
> {noformat}
> $ mvn help:evaluate -Dartifact=log4j:log4j -Dexpression=project.name
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:evaluate (default-cli) @ standalone-pom ---
> [INFO]
> Maven Stub Project (No POM)
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Expected output would be "Apache Log4j", instead of the stub Maven project.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPH-114) Goal fails with “Unable to get the POM for the artifact”
[
https://issues.apache.org/jira/browse/MPH-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639875#comment-15639875
]
Guillaume Boué commented on MPH-114:
When invoking {{mvn help:evaluate -Dartifact=com.acme:aggregator}}, without
specifying the version of the wanted artifact, the plugin tries to locate the
latest version of it. But when no metadata for this artifact are present in the
local repository, and the artifact cannot be found in any remote repositories,
it cannot determine the latest version and fails.
The solution is therefore to pass a version with {{mvn help:evaluate
-Dartifact=com.acme:aggregator:0.0.1-SNAPSHOT}}, and it will find it from the
reactor, if present.
The documentation didn't cover the case when no version is specified, so the
real fix here is to clarify the doc.
> Goal fails with “Unable to get the POM for the artifact”
>
>
> Key: MPH-114
> URL: https://issues.apache.org/jira/browse/MPH-114
> Project: Maven Help Plugin
> Issue Type: Bug
> Components: evaluate
>Affects Versions: 2.2
>Reporter: Jakub Bochenski
>
> See linked SO question
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MSKINS-127) For all http://maven.apache.org/ pages it take 2 minutes to see content in China
[ https://issues.apache.org/jira/browse/MSKINS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Verest closed MSKINS-127. -- Resolution: Fixed Yes, main site works OK now. I have seen the issues on some plugin sites, so general message would be asking upgrade to the latest maven-site-plugin/skin and generate/update site. And yes, never use blocking loading. > For all http://maven.apache.org/ pages it take 2 minutes to see content in > China > > > Key: MSKINS-127 > URL: https://issues.apache.org/jira/browse/MSKINS-127 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.5 > Environment: a device behind Great Firewall or google.com not > available >Reporter: Paul Verest > > For all http://maven.apache.org/ pages it take 2 minutes to see content, > because page rendeing depends on getting to files > - https://www.google.com/coop/cse/brand > - https://apis.google.com/js/plusone.js > see > http://stackoverflow.com/questions/36959899/maven-site-google-issue-in-china > As far as I know, it is generally good practice to put all script in the end > of body, so that page is visible even if any 3rd party server fail the moment > the page is requests. > This is major bug as it affects many users, the reason it was not filed > before is English skill, motivation and where to raise. > Please review all page for 3rd party loads to insure that generated site will > work even on PC without Internet access. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MPH-119) The "artifact" parameter is not taken into account with Maven 3
Guillaume Boué created MPH-119:
--
Summary: The "artifact" parameter is not taken into account with
Maven 3
Key: MPH-119
URL: https://issues.apache.org/jira/browse/MPH-119
Project: Maven Help Plugin
Issue Type: Bug
Components: evaluate
Affects Versions: 2.2
Reporter: Guillaume Boué
Assignee: Guillaume Boué
With Maven 3, the {{artifact}} parameter is not taken into account when
evaluating expressions. Example:
{noformat}
$ mvn help:evaluate -Dartifact=log4j:log4j -Dexpression=project.name
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Maven Stub Project (No POM) 1
[INFO]
[INFO]
[INFO] --- maven-help-plugin:2.2:evaluate (default-cli) @ standalone-pom ---
[INFO]
Maven Stub Project (No POM)
[INFO]
[INFO] BUILD SUCCESS
[INFO]
{noformat}
Expected output would be "Apache Log4j", instead of the stub Maven project.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639828#comment-15639828
]
ASF GitHub Bot commented on MNG-5889:
-
Github user rpatrick00 commented on a diff in the pull request:
https://github.com/apache/maven/pull/94#discussion_r86667117
--- Diff: apache-maven/src/bin/mvn.cmd ---
@@ -86,19 +86,65 @@ set MAVEN_CMD_LINE_ARGS=%*
set MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%
if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
-set "EXEC_DIR=%CD%"
-set "WDIR=%EXEC_DIR%"
+set EXEC_DIR=%CD%
+set WDIR=%EXEC_DIR%
+
+@REM Look for the --file switch and start the search for the .mvn
directory from the specified
+@REM POM location, if supplied.
+
+set FILE_ARG=
+:arg_loop
+if "%1" == "-f" (
+ set "FILE_ARG=%2"
+ shift
+ goto process_file_arg
+)
+if "%1" == "--file" (
+ set "FILE_ARG=%2"
+ shift
+ goto process_file_arg
+)
+@REM If none of the above, skip the argument
+shift
+if not "%~1" == "" (
+ goto arg_loop
+) else (
+ goto findBaseDir
+)
+
+:process_file_arg
+if "%FILE_ARG%" == "" (
+ goto findBaseDir
+)
+call :get_directory_from_file %FILE_ARG%
+if not exist "%POM_DIR%" (
+ echo Directory %POM_DIR% extracted from the -f/--file command-line
argument does not exist
--- End diff --
OK
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.4.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639827#comment-15639827
]
ASF GitHub Bot commented on MNG-5889:
-
Github user rpatrick00 commented on a diff in the pull request:
https://github.com/apache/maven/pull/94#discussion_r86667111
--- Diff: apache-maven/src/bin/mvn.cmd ---
@@ -86,19 +86,65 @@ set MAVEN_CMD_LINE_ARGS=%*
set MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%
if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
-set "EXEC_DIR=%CD%"
-set "WDIR=%EXEC_DIR%"
+set EXEC_DIR=%CD%
+set WDIR=%EXEC_DIR%
+
+@REM Look for the --file switch and start the search for the .mvn
directory from the specified
+@REM POM location, if supplied.
+
+set FILE_ARG=
+:arg_loop
+if "%1" == "-f" (
+ set "FILE_ARG=%2"
+ shift
+ goto process_file_arg
+)
+if "%1" == "--file" (
+ set "FILE_ARG=%2"
+ shift
+ goto process_file_arg
+)
+@REM If none of the above, skip the argument
+shift
+if not "%~1" == "" (
+ goto arg_loop
+) else (
+ goto findBaseDir
+)
+
+:process_file_arg
+if "%FILE_ARG%" == "" (
+ goto findBaseDir
+)
+call :get_directory_from_file %FILE_ARG%
+if not exist "%POM_DIR%" (
--- End diff --
Like it or not, sh and cmd are different and have different capabilities.
In the sh script, we know that the directory exists because of the check for
existence of the POM file. I easily can add the POM file existence test to the
cmd script and print the same errors if the pom file does not exist.
In the cmd script, I need to check for the existence of the extracted
directory because if, for some reason, the directory extracted doesn't exist
(e.g., a bug in the extraction code), the user gets a cryptic error. The same
is not true for the sh script.
I will add the redundant check to the sh script too just for symmetry
purposes...
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.4.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSKINS-129) upgrade old ga.js to analytics.js
[ https://issues.apache.org/jira/browse/MSKINS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639790#comment-15639790 ] Hervé Boutemy commented on MSKINS-129: -- I think we have sufficient changes in this release, let's wait before adding this one > upgrade old ga.js to analytics.js > - > > Key: MSKINS-129 > URL: https://issues.apache.org/jira/browse/MSKINS-129 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.5 >Reporter: Hervé Boutemy > > see https://developers.google.com/analytics/devguides/collection/gajs/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSKINS-127) For all http://maven.apache.org/ pages it take 2 minutes to see content in China
[ https://issues.apache.org/jira/browse/MSKINS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639786#comment-15639786 ] Hervé Boutemy commented on MSKINS-127: -- as asked to [~paulvi], I think I did the job: without confirmation from reporter, I think we can decide it is fixed... > For all http://maven.apache.org/ pages it take 2 minutes to see content in > China > > > Key: MSKINS-127 > URL: https://issues.apache.org/jira/browse/MSKINS-127 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.5 > Environment: a device behind Great Firewall or google.com not > available >Reporter: Paul Verest > > For all http://maven.apache.org/ pages it take 2 minutes to see content, > because page rendeing depends on getting to files > - https://www.google.com/coop/cse/brand > - https://apis.google.com/js/plusone.js > see > http://stackoverflow.com/questions/36959899/maven-site-google-issue-in-china > As far as I know, it is generally good practice to put all script in the end > of body, so that page is visible even if any 3rd party server fail the moment > the page is requests. > This is major bug as it affects many users, the reason it was not filed > before is English skill, motivation and where to raise. > Please review all page for 3rd party loads to insure that generated site will > work even on PC without Internet access. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5896) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MNG-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639781#comment-15639781 ] Harald Wellmann commented on MNG-5896: -- I've reworked my patch, created a new issue MRESOLVER-7 and submitted a pull request. I also did a local build of 3.4.0-SNAPSHOT, replacing the Aether dependencies by Maven Resolver. Is there already a branch for that dependency upgrade, or should I submit another pull request for that? > Download dependency POMs in parallel > > > Key: MNG-5896 > URL: https://issues.apache.org/jira/browse/MNG-5896 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.3.3 >Reporter: Harald Wellmann >Assignee: Michael Osipov > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.3 first downloads the dependency POMs > _sequentially_ and then proceeds downloading the dependency JARs with up to 5 > threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639766#comment-15639766 ] Harald Wellmann commented on MRESOLVER-7: - Pull request: https://github.com/apache/maven-resolver/pull/2 > Download dependency POMs in parallel > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MRESOLVER-7) Download dependency POMs in parallel
Harald Wellmann created MRESOLVER-7: --- Summary: Download dependency POMs in parallel Key: MRESOLVER-7 URL: https://issues.apache.org/jira/browse/MRESOLVER-7 Project: Maven Resolver Issue Type: Improvement Affects Versions: Aether 1.0.2 Reporter: Harald Wellmann h3. Background When building a project with dependencies not yet available in the local repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the dependency POMs _sequentially_ and then proceeds downloading the dependency JARs with up to 5 threads _in parallel_. Due to this, when first building a project with a large number of dependencies, downloading a large number of small POMs may take a lot longer than downloading the much larger JARs, or even longer than building the project itself, especially when a repository manager is used which increases the download latency. h3. Enhancement Download POMs of (transitive) dependencies in parallel to significantly speed up initial builds of large projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSKINS-132) Add option to skip adding the Date-Revision meta header
[ https://issues.apache.org/jira/browse/MSKINS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639551#comment-15639551 ] Hudson commented on MSKINS-132: --- FAILURE: Integrated in Jenkins build maven-skins #265 (See [https://builds.apache.org/job/maven-skins/265/]) [MSKINS-132] Add option to skip adding the Date-Revision meta header (michaelo: [http://svn.apache.org/viewvc/?view=rev&rev=1768207]) * (edit) maven-fluido-skin/src/main/resources/META-INF/maven/site.vm > Add option to skip adding the Date-Revision meta header > --- > > Key: MSKINS-132 > URL: https://issues.apache.org/jira/browse/MSKINS-132 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Markus Kilås >Assignee: Michael Osipov > Fix For: fluido-1.6 > > Attachments: MSKINS-132-skipmetadaterevision-1.patch > > > The current fluido-skin adds a meta header to the generated page > "Date-Revision-mmdd" with the modification date of the source file (?). > This time-stamp in the generated document makes it harder to achieve > deterministic/reproducible builds. > The skin already has the option "skipGenerationDate" to not include a similar > timestamp as a comment in the beginning of the page. > Suggestion: > - Add a similar option to skip this "Date-Revision-mmdd" header -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSKINS-131) Enable the responsive features of Bootstrap 2.3.2
[
https://issues.apache.org/jira/browse/MSKINS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639552#comment-15639552
]
Hudson commented on MSKINS-131:
---
FAILURE: Integrated in Jenkins build maven-skins #265 (See
[https://builds.apache.org/job/maven-skins/265/])
[MSKINS-131] Enable the responsive features of Bootstrap 2.3.2
Submitted by: Jon Harper (michaelo:
[http://svn.apache.org/viewvc/?view=rev&rev=1768202])
* (edit) maven-fluido-skin/pom.xml
* (add) maven-fluido-skin/src/main/resources/css/bootstrap-2.3.2-responsive.css
> Enable the responsive features of Bootstrap 2.3.2
> -
>
> Key: MSKINS-131
> URL: https://issues.apache.org/jira/browse/MSKINS-131
> Project: Maven Skins
> Issue Type: Improvement
> Components: Fluido Skin
>Affects Versions: fluido-1.5
> Environment: All
>Reporter: Jon Harper
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: fluido-1.6
>
> Attachments: fluido-reponsive.patch
>
>
> Bootstrap 2.3.2 has opt-in support for responsive layouts. In 2016, mobile
> has grown a lot. I think it should be enabled.
> To enable it, we just have to download bootstrap-responsive.css from
> http://getbootstrap.com/2.3.2/ and add it to the page. See
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive
> The following mail was sent to the mailing list:
> {quote}
> I tried enabling Bootstrap's 2 responsive mode on
> https://maven.apache.org and I thought that it was better than the
> current version. Please see a demo here: http://jonenst.github.io/maven-site/
> .
> I also added preview images of the main the page using firefox
> "Responsive Design View".
> The only difference between the two types of images is the inclusion
> of the responsive css as per
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive .
> Note that the responsive mode does significant changes only on
> displays of width 767 pixels or less. Above 767px, the changes are very
> minor (tiny adjustments to fonts, columns and gutters sizes).
> Did you try enabling the responsive mode? Was there something
> preventing you from using it ? The only drawback I see is that devices
> with 767 pixels have a bigger menu than needed, but:
> - the current mode already has some problems (text and images going
> outside of the menu, less size of the content).
> - there are almost no devices in the 610-767 range. (see
> http://mydevice.io/devices/ ). For 600px width, the menu still looks
> big but not as oversized as for 767 pixels and using it this way is an
> improvement.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSKINS-127) For all http://maven.apache.org/ pages it take 2 minutes to see content in China
[ https://issues.apache.org/jira/browse/MSKINS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639540#comment-15639540 ] Michael Osipov commented on MSKINS-127: --- [~hboutemy], is this fixed? > For all http://maven.apache.org/ pages it take 2 minutes to see content in > China > > > Key: MSKINS-127 > URL: https://issues.apache.org/jira/browse/MSKINS-127 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.5 > Environment: a device behind Great Firewall or google.com not > available >Reporter: Paul Verest > > For all http://maven.apache.org/ pages it take 2 minutes to see content, > because page rendeing depends on getting to files > - https://www.google.com/coop/cse/brand > - https://apis.google.com/js/plusone.js > see > http://stackoverflow.com/questions/36959899/maven-site-google-issue-in-china > As far as I know, it is generally good practice to put all script in the end > of body, so that page is visible even if any 3rd party server fail the moment > the page is requests. > This is major bug as it affects many users, the reason it was not filed > before is English skill, motivation and where to raise. > Please review all page for 3rd party loads to insure that generated site will > work even on PC without Internet access. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSKINS-132) Add option to skip adding the Date-Revision meta header
[ https://issues.apache.org/jira/browse/MSKINS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSKINS-132. - Resolution: Fixed Fixed with [r1768207|http://svn.apache.org/r1768207]. I took as slightly different approach. See commit. > Add option to skip adding the Date-Revision meta header > --- > > Key: MSKINS-132 > URL: https://issues.apache.org/jira/browse/MSKINS-132 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Markus Kilås >Assignee: Michael Osipov > Fix For: fluido-1.6 > > Attachments: MSKINS-132-skipmetadaterevision-1.patch > > > The current fluido-skin adds a meta header to the generated page > "Date-Revision-mmdd" with the modification date of the source file (?). > This time-stamp in the generated document makes it harder to achieve > deterministic/reproducible builds. > The skin already has the option "skipGenerationDate" to not include a similar > timestamp as a comment in the beginning of the page. > Suggestion: > - Add a similar option to skip this "Date-Revision-mmdd" header -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MSKINS-132) Add option to skip adding the Date-Revision meta header
[ https://issues.apache.org/jira/browse/MSKINS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MSKINS-132: - Assignee: Michael Osipov > Add option to skip adding the Date-Revision meta header > --- > > Key: MSKINS-132 > URL: https://issues.apache.org/jira/browse/MSKINS-132 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Markus Kilås >Assignee: Michael Osipov > Fix For: fluido-1.6 > > Attachments: MSKINS-132-skipmetadaterevision-1.patch > > > The current fluido-skin adds a meta header to the generated page > "Date-Revision-mmdd" with the modification date of the source file (?). > This time-stamp in the generated document makes it harder to achieve > deterministic/reproducible builds. > The skin already has the option "skipGenerationDate" to not include a similar > timestamp as a comment in the beginning of the page. > Suggestion: > - Add a similar option to skip this "Date-Revision-mmdd" header -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1298) surefire-junit4 contains commons-io 2.2 pom.xml
[
https://issues.apache.org/jira/browse/SUREFIRE-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639480#comment-15639480
]
Thomas Mortagne edited comment on SUREFIRE-1298 at 11/5/16 12:10 PM:
-
bq. Is it a problem that we incluse commons pom.xml?
This is my direct issue. The fact that the jar contains a descriptor saying in
contains commons-io which is not true (since it's not the same packages).
bq. Is it a problem that we include but repackage all dependencies except for
commons-io? Please extract the *.jar file and see the packages.
I don't mind that you shade whatever you want (as long as the jar then does not
contain a pom saying it contains something for which you actually modified all
packages). I just find pretty weird to shade common-io instead of just
depending on it.
bq. Can you show me the real warning from classpath as you mentioned?
It won't really help you, it's nothing standard. I as said I have a tool (an
extension manger) looking at the classpath to knows what is already there (and
also checking if the classpath contains the same artifact in different versions
to warn about possible issues). And for that it look at Maven pom located in
jars since they are supposed to describe what the jar contains (plus some hacks
for jars not containing any pom.xml).
was (Author: tmortagne):
> Is it a problem that we incluse commons pom.xml?
This is my direct issue. The fact that the jar contains a descriptor saying in
contains commons-io which is not true (since it's not the same packages).
> Is it a problem that we include but repackage all dependencies except for
> commons-io? Please extract the *.jar file and see the packages.
I don't mind that you shade whatever you want (as long as the jar then does not
contain a pom saying it contains something for which you actually modified all
packages). I just find pretty weird to shade common-io instead of just
depending on it.
> Can you show me the real warning from classpath as you mentioned?
It won't really help you, it's nothing standard. I as said I have a tool (an
extension manger) looking at the classpath to knows what is already there (and
also checking if the classpath contains the same artifact in different versions
to warn about possible issues). And for that it look at Maven pom located in
jars since they are supposed to describe what the jar contains (plus some hacks
for jars not containing any pom.xml).
> surefire-junit4 contains commons-io 2.2 pom.xml
> ---
>
> Key: SUREFIRE-1298
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1298
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Thomas Mortagne
>Assignee: Tibor Digana
>
> For some reason surefire-junit4 jar ends up with
> {{/META-INF/maven/commons-io/commons-io/pom.xml}} (and {{pom.properties}}).
> The issue is that I have some code scanning classloader jars to find out
> what's there and I end up with a conflict in all my unit tests between
> commons-io 2.9 in commons-io jar I'm depending on and commons-io 2.2 which is
> supposed to be in surefire-junit4 jar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1298) surefire-junit4 contains commons-io 2.2 pom.xml
[
https://issues.apache.org/jira/browse/SUREFIRE-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639480#comment-15639480
]
Thomas Mortagne commented on SUREFIRE-1298:
---
> Is it a problem that we incluse commons pom.xml?
This is my direct issue. The fact that the jar contains a descriptor saying in
contains commons-io which is not true (since it's not the same packages).
> Is it a problem that we include but repackage all dependencies except for
> commons-io? Please extract the *.jar file and see the packages.
I don't mind that you shade whatever you want (as long as the jar then does not
contain a pom saying it contains something for which you actually modified all
packages). I just find pretty weird to shade common-io instead of just
depending on it.
> Can you show me the real warning from classpath as you mentioned?
It won't really help you, it's nothing standard. I as said I have a tool (an
extension manger) looking at the classpath to knows what is already there (and
also checking if the classpath contains the same artifact in different versions
to warn about possible issues). And for that it look at Maven pom located in
jars since they are supposed to describe what the jar contains (plus some hacks
for jars not containing any pom.xml).
> surefire-junit4 contains commons-io 2.2 pom.xml
> ---
>
> Key: SUREFIRE-1298
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1298
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.19.1
>Reporter: Thomas Mortagne
>Assignee: Tibor Digana
>
> For some reason surefire-junit4 jar ends up with
> {{/META-INF/maven/commons-io/commons-io/pom.xml}} (and {{pom.properties}}).
> The issue is that I have some code scanning classloader jars to find out
> what's there and I end up with a conflict in all my unit tests between
> commons-io 2.9 in commons-io jar I'm depending on and commons-io 2.2 which is
> supposed to be in surefire-junit4 jar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSKINS-129) upgrade old ga.js to analytics.js
[ https://issues.apache.org/jira/browse/MSKINS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639476#comment-15639476 ] Michael Osipov commented on MSKINS-129: --- Hervé, do you want to fix this? I want to push 1.6 somewhere this month. > upgrade old ga.js to analytics.js > - > > Key: MSKINS-129 > URL: https://issues.apache.org/jira/browse/MSKINS-129 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.5 >Reporter: Hervé Boutemy > > see https://developers.google.com/analytics/devguides/collection/gajs/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSKINS-132) Add option to skip adding the Date-Revision meta header
[ https://issues.apache.org/jira/browse/MSKINS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-132: -- Component/s: (was: Default Skin) > Add option to skip adding the Date-Revision meta header > --- > > Key: MSKINS-132 > URL: https://issues.apache.org/jira/browse/MSKINS-132 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Markus Kilås > Fix For: fluido-1.6 > > Attachments: MSKINS-132-skipmetadaterevision-1.patch > > > The current fluido-skin adds a meta header to the generated page > "Date-Revision-mmdd" with the modification date of the source file (?). > This time-stamp in the generated document makes it harder to achieve > deterministic/reproducible builds. > The skin already has the option "skipGenerationDate" to not include a similar > timestamp as a comment in the beginning of the page. > Suggestion: > - Add a similar option to skip this "Date-Revision-mmdd" header -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSKINS-132) Add option to skip adding the Date-Revision meta header
[ https://issues.apache.org/jira/browse/MSKINS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-132: -- Component/s: Default Skin > Add option to skip adding the Date-Revision meta header > --- > > Key: MSKINS-132 > URL: https://issues.apache.org/jira/browse/MSKINS-132 > Project: Maven Skins > Issue Type: New Feature > Components: Default Skin, Fluido Skin >Reporter: Markus Kilås > Fix For: fluido-1.6 > > Attachments: MSKINS-132-skipmetadaterevision-1.patch > > > The current fluido-skin adds a meta header to the generated page > "Date-Revision-mmdd" with the modification date of the source file (?). > This time-stamp in the generated document makes it harder to achieve > deterministic/reproducible builds. > The skin already has the option "skipGenerationDate" to not include a similar > timestamp as a comment in the beginning of the page. > Suggestion: > - Add a similar option to skip this "Date-Revision-mmdd" header -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSKINS-119) Text overlapping on mobile devices
[ https://issues.apache.org/jira/browse/MSKINS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSKINS-119. - Resolution: Fixed Fixed implicitly with [r1768202|http://svn.apache.org/r1768202]. > Text overlapping on mobile devices > -- > > Key: MSKINS-119 > URL: https://issues.apache.org/jira/browse/MSKINS-119 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.4 >Reporter: Nils Breunese >Assignee: Michael Osipov > Fix For: fluido-1.6 > > Attachments: screenshot.jpg > > > When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an > iPhone 4 you see the main body text and navigation text is overlapping, > making the page hard to read. Please see the attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSKINS-131) Enable the responsive features of Bootstrap 2.3.2
[
https://issues.apache.org/jira/browse/MSKINS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSKINS-131.
-
Resolution: Fixed
Fixed with [r1768202|http://svn.apache.org/r1768202].
> Enable the responsive features of Bootstrap 2.3.2
> -
>
> Key: MSKINS-131
> URL: https://issues.apache.org/jira/browse/MSKINS-131
> Project: Maven Skins
> Issue Type: Improvement
> Components: Fluido Skin
>Affects Versions: fluido-1.5
> Environment: All
>Reporter: Jon Harper
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: fluido-1.6
>
> Attachments: fluido-reponsive.patch
>
>
> Bootstrap 2.3.2 has opt-in support for responsive layouts. In 2016, mobile
> has grown a lot. I think it should be enabled.
> To enable it, we just have to download bootstrap-responsive.css from
> http://getbootstrap.com/2.3.2/ and add it to the page. See
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive
> The following mail was sent to the mailing list:
> {quote}
> I tried enabling Bootstrap's 2 responsive mode on
> https://maven.apache.org and I thought that it was better than the
> current version. Please see a demo here: http://jonenst.github.io/maven-site/
> .
> I also added preview images of the main the page using firefox
> "Responsive Design View".
> The only difference between the two types of images is the inclusion
> of the responsive css as per
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive .
> Note that the responsive mode does significant changes only on
> displays of width 767 pixels or less. Above 767px, the changes are very
> minor (tiny adjustments to fonts, columns and gutters sizes).
> Did you try enabling the responsive mode? Was there something
> preventing you from using it ? The only drawback I see is that devices
> with 767 pixels have a bigger menu than needed, but:
> - the current mode already has some problems (text and images going
> outside of the menu, less size of the content).
> - there are almost no devices in the 610-767 range. (see
> http://mydevice.io/devices/ ). For 600px width, the menu still looks
> big but not as oversized as for 767 pixels and using it this way is an
> improvement.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MSKINS-119) Text overlapping on mobile devices
[ https://issues.apache.org/jira/browse/MSKINS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MSKINS-119: - Assignee: Michael Osipov > Text overlapping on mobile devices > -- > > Key: MSKINS-119 > URL: https://issues.apache.org/jira/browse/MSKINS-119 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.4 >Reporter: Nils Breunese >Assignee: Michael Osipov > Fix For: fluido-1.6 > > Attachments: screenshot.jpg > > > When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an > iPhone 4 you see the main body text and navigation text is overlapping, > making the page hard to read. Please see the attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSKINS-119) Text overlapping on mobile devices
[ https://issues.apache.org/jira/browse/MSKINS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-119: -- Component/s: Fluido Skin > Text overlapping on mobile devices > -- > > Key: MSKINS-119 > URL: https://issues.apache.org/jira/browse/MSKINS-119 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.4 >Reporter: Nils Breunese > Fix For: fluido-1.6 > > Attachments: screenshot.jpg > > > When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an > iPhone 4 you see the main body text and navigation text is overlapping, > making the page hard to read. Please see the attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSKINS-131) Enable the responsive features of Bootstrap 2.3.2
[
https://issues.apache.org/jira/browse/MSKINS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-131:
--
Summary: Enable the responsive features of Bootstrap 2.3.2 (was: Enable
the responsive features of bootstrap 2.3.2)
> Enable the responsive features of Bootstrap 2.3.2
> -
>
> Key: MSKINS-131
> URL: https://issues.apache.org/jira/browse/MSKINS-131
> Project: Maven Skins
> Issue Type: Improvement
> Components: Fluido Skin
>Affects Versions: fluido-1.5
> Environment: All
>Reporter: Jon Harper
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: fluido-1.6
>
> Attachments: fluido-reponsive.patch
>
>
> Bootstrap 2.3.2 has opt-in support for responsive layouts. In 2016, mobile
> has grown a lot. I think it should be enabled.
> To enable it, we just have to download bootstrap-responsive.css from
> http://getbootstrap.com/2.3.2/ and add it to the page. See
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive
> The following mail was sent to the mailing list:
> {quote}
> I tried enabling Bootstrap's 2 responsive mode on
> https://maven.apache.org and I thought that it was better than the
> current version. Please see a demo here: http://jonenst.github.io/maven-site/
> .
> I also added preview images of the main the page using firefox
> "Responsive Design View".
> The only difference between the two types of images is the inclusion
> of the responsive css as per
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive .
> Note that the responsive mode does significant changes only on
> displays of width 767 pixels or less. Above 767px, the changes are very
> minor (tiny adjustments to fonts, columns and gutters sizes).
> Did you try enabling the responsive mode? Was there something
> preventing you from using it ? The only drawback I see is that devices
> with 767 pixels have a bigger menu than needed, but:
> - the current mode already has some problems (text and images going
> outside of the menu, less size of the content).
> - there are almost no devices in the 610-767 range. (see
> http://mydevice.io/devices/ ). For 600px width, the menu still looks
> big but not as oversized as for 767 pixels and using it this way is an
> improvement.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSKINS-119) Text overlapping on mobile devices
[ https://issues.apache.org/jira/browse/MSKINS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-119: -- Fix Version/s: fluido-1.6 > Text overlapping on mobile devices > -- > > Key: MSKINS-119 > URL: https://issues.apache.org/jira/browse/MSKINS-119 > Project: Maven Skins > Issue Type: Bug >Affects Versions: fluido-1.4 >Reporter: Nils Breunese > Fix For: fluido-1.6 > > Attachments: screenshot.jpg > > > When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an > iPhone 4 you see the main body text and navigation text is overlapping, > making the page hard to read. Please see the attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MSKINS-131) Enable the responsive features of bootstrap 2.3.2
[
https://issues.apache.org/jira/browse/MSKINS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSKINS-131:
-
Assignee: Michael Osipov
> Enable the responsive features of bootstrap 2.3.2
> -
>
> Key: MSKINS-131
> URL: https://issues.apache.org/jira/browse/MSKINS-131
> Project: Maven Skins
> Issue Type: Improvement
> Components: Fluido Skin
>Affects Versions: fluido-1.5
> Environment: All
>Reporter: Jon Harper
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: fluido-1.6
>
> Attachments: fluido-reponsive.patch
>
>
> Bootstrap 2.3.2 has opt-in support for responsive layouts. In 2016, mobile
> has grown a lot. I think it should be enabled.
> To enable it, we just have to download bootstrap-responsive.css from
> http://getbootstrap.com/2.3.2/ and add it to the page. See
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive
> The following mail was sent to the mailing list:
> {quote}
> I tried enabling Bootstrap's 2 responsive mode on
> https://maven.apache.org and I thought that it was better than the
> current version. Please see a demo here: http://jonenst.github.io/maven-site/
> .
> I also added preview images of the main the page using firefox
> "Responsive Design View".
> The only difference between the two types of images is the inclusion
> of the responsive css as per
> http://getbootstrap.com/2.3.2/scaffolding.html#responsive .
> Note that the responsive mode does significant changes only on
> displays of width 767 pixels or less. Above 767px, the changes are very
> minor (tiny adjustments to fonts, columns and gutters sizes).
> Did you try enabling the responsive mode? Was there something
> preventing you from using it ? The only drawback I see is that devices
> with 767 pixels have a bigger menu than needed, but:
> - the current mode already has some problems (text and images going
> outside of the menu, less size of the content).
> - there are almost no devices in the 610-767 range. (see
> http://mydevice.io/devices/ ). For 600px width, the menu still looks
> big but not as oversized as for 767 pixels and using it this way is an
> improvement.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSKINS-119) Text overlapping on mobile devices
[ https://issues.apache.org/jira/browse/MSKINS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-119: -- Affects Version/s: fluido-1.4 > Text overlapping on mobile devices > -- > > Key: MSKINS-119 > URL: https://issues.apache.org/jira/browse/MSKINS-119 > Project: Maven Skins > Issue Type: Bug >Affects Versions: fluido-1.4 >Reporter: Nils Breunese > Fix For: fluido-1.6 > > Attachments: screenshot.jpg > > > When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an > iPhone 4 you see the main body text and navigation text is overlapping, > making the page hard to read. Please see the attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSKINS-116) use font icons bundled with bootstrap
[ https://issues.apache.org/jira/browse/MSKINS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSKINS-116. - Resolution: Incomplete No reaction to my question. > use font icons bundled with bootstrap > - > > Key: MSKINS-116 > URL: https://issues.apache.org/jira/browse/MSKINS-116 > Project: Maven Skins > Issue Type: Wish > Components: Fluido Skin >Affects Versions: fluido-1.4 >Reporter: jieryn >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639366#comment-15639366
]
ASF GitHub Bot commented on MNG-5889:
-
Github user michael-o commented on a diff in the pull request:
https://github.com/apache/maven/pull/94#discussion_r86662937
--- Diff: apache-maven/src/bin/mvn.cmd ---
@@ -86,19 +86,65 @@ set MAVEN_CMD_LINE_ARGS=%*
set MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%
if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
-set "EXEC_DIR=%CD%"
-set "WDIR=%EXEC_DIR%"
+set EXEC_DIR=%CD%
+set WDIR=%EXEC_DIR%
+
+@REM Look for the --file switch and start the search for the .mvn
directory from the specified
+@REM POM location, if supplied.
+
+set FILE_ARG=
+:arg_loop
+if "%1" == "-f" (
+ set "FILE_ARG=%2"
+ shift
+ goto process_file_arg
+)
+if "%1" == "--file" (
+ set "FILE_ARG=%2"
+ shift
+ goto process_file_arg
+)
+@REM If none of the above, skip the argument
+shift
+if not "%~1" == "" (
+ goto arg_loop
+) else (
+ goto findBaseDir
+)
+
+:process_file_arg
+if "%FILE_ARG%" == "" (
+ goto findBaseDir
+)
+call :get_directory_from_file %FILE_ARG%
+if not exist "%POM_DIR%" (
--- End diff --
Why is this check not present in the shell script?
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.4.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1230) Issue with config parameter 'redirectTestOutputToFile' when running cucumber parallel tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639146#comment-15639146
]
Tibor Digana commented on SUREFIRE-1230:
[~giacomotaylor]
[~mpalki]
I have lately found this issue:
https://github.com/cucumber/cucumber-jvm/issues/966
As I understood the problem in Cucumber the RunListener and run of test method
is not totally synchronized.
Is it so that the Cucumber annotation on the test method does not match "step
definitions" and should be a subject to ignored test?
If it is this issue, then Cucumber can fix it by overriding
{{ParentRunner#runChild(final FrameworkMethod method, RunNotifier notifier)}}
to something like this:
{code}
if (child.getAnnotation(SomeCucumberAnnotation.class) != matched step
definition) notifier.fireTestIgnored(description);
super.runChild(method, notifier);
{code}
I can provide a workaround but it will be only workaround which is in your case
still worse than regular consistent report.
> Issue with config parameter 'redirectTestOutputToFile' when running cucumber
> parallel tests
> ---
>
> Key: SUREFIRE-1230
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1230
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1
>Reporter: Manoj Palki
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: cucumber_java_skeleton.tar.gz
>
>
> The config parameter redirectTestOutputToFile behaves differently based on
> how parallelism is configured in the surefire plugin.
> If the config is
> 2
> false
> true
> then the output from the tests is directed correctly to 'xxxtest-output.txt'
> file.
> However, if the config is
> 2
> classes
> true
> then the output from the tests is partially directed to the
> 'xxxtest-output.txt file and partially to stdout.
> Also the output files have different names in two cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPOM-136) Upgrade maven-resources-plugin to 3.0.1
[ https://issues.apache.org/jira/browse/MPOM-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15639065#comment-15639065 ] Hudson commented on MPOM-136: - SUCCESS: Integrated in Jenkins build maven-parent #2058 (See [https://builds.apache.org/job/maven-parent/2058/]) [MPOM-136] upgraded enforcer extra rules to 1.0-beta-6 (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1768158]) * (edit) pom.xml > Upgrade maven-resources-plugin to 3.0.1 > --- > > Key: MPOM-136 > URL: https://issues.apache.org/jira/browse/MPOM-136 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-19 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: ASF-19 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
