[GitHub] maven-surefire issue #173: [SUREFIRE-1004] Support full gavtc format for dep...
Github user bindul commented on the issue: https://github.com/apache/maven-surefire/pull/173 @Tibor17 I have reviewed the Maven Coordinates documentation you mentioned, and I can switch the order of elements in the parameter easily. However, I think I would disagree with requiring the version to be last element in the coordinates in this use case. As the functionality stands, the `dependenciesToScan` configuration does not add additional dependencies to the test scope of the project, it filters dependencies already added to the test scope in the project to allow for scanning test classes to run. If someone wants to add say a classfier or a type/packaging, requiring them them to also mention the version of the dependency would just make maintainers life harder by having another location to keep the version of the dependency in sync. As such I propose, we keep the version as optional and support the following variations of dependencies to scan: - `groupId:artifactId` - `groupId:artifactId:packaging/type` - `groupId:artifactId:packaging/type::version` - `groupId:artifactId:packaging/type:classifier` - `groupId:artifactId::classifier` - `groupId:artifactId::classifier:version` - `groupId:artifactId:packaging/type:classifier:version` It still maintains the same order of elements as the Maven Coordinates documentation in the POM, just makes the version not required to be the last element, or rather makes version optional. Thoughts? ---
[GitHub] maven-surefire issue #173: [SUREFIRE-1004] Support full gavtc format for dep...
Github user bindul commented on the issue: https://github.com/apache/maven-surefire/pull/173 @Tibor17, Sorry I misunderstood your first comment. Thank you again for taking the time to review the changes and for your patience. I will rework the pull request using your [latest comment](https://github.com/apache/maven-surefire/pull/173#issuecomment-357434597) and the inline review comments. I will get back to you soon. Bindul ---
[GitHub] maven-surefire issue #173: [SUREFIRE-1004] Support full gavtc format for dep...
Github user bindul commented on the issue: https://github.com/apache/maven-surefire/pull/173 @Tibor17 Thank you for your review. I agree with you that `version` check is not really useful in this use case, I put it in there as the JIRA ticket called for GAVT support and also to keep the format consistent with the other places maven defines gavtc. I am happy to remove the version check. If I do so, do you want the input configuration format to still be `groupId:artifactId[:version[:type[:classifier]]]` or would you rather it be `groupId:artifactId[:type[:classifier]]`. I will amend the commit based on your response. ---
[GitHub] maven-surefire pull request #173: [SUREFIRE-1004] Support full gavtc format ...
GitHub user bindul opened a pull request: https://github.com/apache/maven-surefire/pull/173 [SUREFIRE-1004] Support full gavtc format for dependenciesToScan Added support for specifying dependencies to scan for tests using full `groupId:artifactId[:version[:type[:classifier]]]` format. Has unit and integration tests and updates to documentation. Related Issues: - [SUREFIRE-1004](https://issues.apache.org/jira/browse/SUREFIRE-1004) You can merge this pull request into a Git repository by running: $ git pull https://github.com/bindul/maven-surefire SUREFIRE-1004_dependenciesToScan Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/173.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #173 commit 447537ccbe54ae64868a507624f4af7a2edf0d3a Author: Bindul Bhowmik <bindulbhowmik@...> Date: 2018-01-11T17:56:38Z [SUREFIRE-1004] Support full gavtc format for dependenciesToScan Submitted by: Bindul Bhowmik Code, unit tests and integration test to support full groupId:artifactId[:version[:type[:classifier]]] format when specifying additional dependencies to scan for test classes. Updated plugin parameter and site documentation. Related Issues: - [SUREFIRE-1004] Enhance pattern/wildcard capabilities for dependenciesToScan to GAVT ---
[jira] [Commented] (MNGSITE-277) Plugin testing documentation links update
[
https://issues.apache.org/jira/browse/MNGSITE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15184610#comment-15184610
]
Bindul Bhowmik commented on MNGSITE-277:
I did visit the source repository page you mentioned. I guess I did not look
hard enough, apologize for that. Looking at that page again, I think I gave up
after _A variety of other subsystems (including obsolete trees replaced by
git)_.
My two cents: If you see on that page, most everything like components, plugins
is in tables. While the site repository almost kind of merges into the
boilerplate links (anonymous access, developer access, access behind firewalls,
etc.). Maybe one idea could be to move the site repository into a row in the
table with plugins and shared components.
Another page I may not have spent much time on is
http://maven.apache.org/developers/website/deploy-maven-website.html. I may
have gotten the impression that CMS was the way to edit the main site.
Again thanks for your help fixing the docs, and apologize if I caused any
inconvenience.
> Plugin testing documentation links update
> -
>
> Key: MNGSITE-277
> URL: https://issues.apache.org/jira/browse/MNGSITE-277
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Anders Hammar
>Priority: Minor
> Attachments: MNGSITE-277-plugin-int-test-site.patch
>
>
> Reported on the dev mailing list:
> {quote}
> I ran across a few links on the documentation which should probably be
> updated. The pages either use CMS or Confluence, so I am unable to
> send a patch (or know how to).
> On the 'Developers centre - Testing Plugins Strategies' page \[1] on
> the Maven website, under the 'maven-verifier' subsection, the page
> links to the MAVENOLD confluence space for the 'Creating a Maven
> Integration Test' link \[2]; but that should probably point to the same
> page in the MAVEN space \[3].
> On the MAVEN/Creating+a+Maven+Integration+Test \[3] page itself, there
> are several links which point to the SVN location for the Core ITs
> \[4], which should point to the new Git location \[5] if I am not
> mistaken. Also the archetype catalog used in that page \[6] is no
> longer available (links to a Codehaus page), and probably also needs
> to point somewhere else.
> Regards,
> Bindul
> \[1] https://maven.apache.org/plugin-developers/plugin-testing.html
> \[2]
> https://cwiki.apache.org/confluence/display/MAVENOLD/Creating+a+Maven+Integration+Test
> \[3]
> https://cwiki.apache.org/confluence/display/MAVEN/Creating+a+Maven+Integration+Test
> \[4] http://svn.apache.org/repos/asf/maven/core-integration-testing/
> \[5] https://git-wip-us.apache.org/repos/asf/maven-integration-testing.git
> \[6]
> http://docs.codehaus.org/download/attachments/1835439/archetype-catalog.xml
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNGSITE-277) Plugin testing documentation links update
[
https://issues.apache.org/jira/browse/MNGSITE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bindul Bhowmik updated MNGSITE-277:
---
Attachment: MNGSITE-277-plugin-int-test-site.patch
[~hboutemy], thank you for the hint. Attached a patch fixing the URL on the
https://maven.apache.org/plugin-developers/plugin-testing.html page.
> Plugin testing documentation links update
> -
>
> Key: MNGSITE-277
> URL: https://issues.apache.org/jira/browse/MNGSITE-277
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Anders Hammar
>Priority: Minor
> Attachments: MNGSITE-277-plugin-int-test-site.patch
>
>
> Reported on the dev mailing list:
> {quote}
> I ran across a few links on the documentation which should probably be
> updated. The pages either use CMS or Confluence, so I am unable to
> send a patch (or know how to).
> On the 'Developers centre - Testing Plugins Strategies' page \[1] on
> the Maven website, under the 'maven-verifier' subsection, the page
> links to the MAVENOLD confluence space for the 'Creating a Maven
> Integration Test' link \[2]; but that should probably point to the same
> page in the MAVEN space \[3].
> On the MAVEN/Creating+a+Maven+Integration+Test \[3] page itself, there
> are several links which point to the SVN location for the Core ITs
> \[4], which should point to the new Git location \[5] if I am not
> mistaken. Also the archetype catalog used in that page \[6] is no
> longer available (links to a Codehaus page), and probably also needs
> to point somewhere else.
> Regards,
> Bindul
> \[1] https://maven.apache.org/plugin-developers/plugin-testing.html
> \[2]
> https://cwiki.apache.org/confluence/display/MAVENOLD/Creating+a+Maven+Integration+Test
> \[3]
> https://cwiki.apache.org/confluence/display/MAVEN/Creating+a+Maven+Integration+Test
> \[4] http://svn.apache.org/repos/asf/maven/core-integration-testing/
> \[5] https://git-wip-us.apache.org/repos/asf/maven-integration-testing.git
> \[6]
> http://docs.codehaus.org/download/attachments/1835439/archetype-catalog.xml
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MRELEASE-749) release:prepare copies contents of source of Subversion branch into release tag
Bindul Bhowmik created MRELEASE-749: --- Summary: release:prepare copies contents of source of Subversion branch into release tag Key: MRELEASE-749 URL: https://jira.codehaus.org/browse/MRELEASE-749 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x Reporter: Bindul Bhowmik When releasing from a branch, release:prepare copies the content of the source of the branch into the release tag rather than the content of the branch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-749) release:prepare copies contents of source of Subversion branch into release tag
[ https://jira.codehaus.org/browse/MRELEASE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294089#comment-294089 ] Bindul Bhowmik commented on MRELEASE-749: - I realize the initial description was not very clear. Here is a simple use case: A project with a standard subversion structure (trunk, branches, tags) has a tag project-1.1 (tags/project-1.2). If there is a need to create a bug fix release (1.2.1), a maintenance branch is created (branches/project-1.2.x) and changes made in the branch. Now, you try and run the release plugin (release:prepare) from the code checked out from the branch to create release 1.2.1. The release:prepare stage creates the proper tag in SVN (tags/project-1.2.1), but the content in the tag is identical to tags/project-1.2 rather than branches/project-1.2.x (with of course the version changes from 1.2.1-SNAPSHOT to 1.2.1). release:prepare run on code checked out from trunk works just fine. Not sure if it is relevant, but here is some additional information: - It is a multi-module maven project with a child module - Subversion client: Subversion command-line client, version 1.6.17-SlikSvn-tag-1.6.17@1130898-X64 - Subversion server: Subversion version 1.6.1 (r37116) release:prepare copies contents of source of Subversion branch into release tag --- Key: MRELEASE-749 URL: https://jira.codehaus.org/browse/MRELEASE-749 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x Reporter: Bindul Bhowmik When releasing from a branch, release:prepare copies the content of the source of the branch into the release tag rather than the content of the branch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-749) release:prepare copies contents of source of Subversion branch into release tag
[ https://jira.codehaus.org/browse/MRELEASE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294089#comment-294089 ] Bindul Bhowmik edited comment on MRELEASE-749 at 3/14/12 6:10 AM: -- I realize the initial description was not very clear. Here is a simple use case: A project with a standard subversion structure (trunk, branches, tags) has a tag project-1.1 (tags/project-1.2). If there is a need to create a bug fix release (1.2.1), a maintenance branch is created (branches/project-1.2.x) and changes made in the branch. Now, you try and run the release plugin (release:prepare) from the code checked out from the branch to create release 1.2.1. The release:prepare stage creates the proper tag in SVN (tags/project-1.2.1), but the content in the tag is identical to tags/project-1.2 rather than branches/project-1.2.x (with of course the version changes from 1.2.1-SNAPSHOT to 1.2.1). release:prepare run on code checked out from trunk works just fine. Not sure if it is relevant, but here is some additional information: - It is a multi-module maven project with a child module - Subversion client: Subversion command-line client, version 1.6.17-SlikSvn-tag-1.6.17@1130898-X64 - Subversion server: Subversion version 1.6.1 (r37116) - The branch above was created using Eclipse Subversive plugin ver. 0.7.9.I20110819-1700 (using SVNKit connector 1.3.5 r7406 (SVN 1.6.15 compatible)) was (Author: bindul): I realize the initial description was not very clear. Here is a simple use case: A project with a standard subversion structure (trunk, branches, tags) has a tag project-1.1 (tags/project-1.2). If there is a need to create a bug fix release (1.2.1), a maintenance branch is created (branches/project-1.2.x) and changes made in the branch. Now, you try and run the release plugin (release:prepare) from the code checked out from the branch to create release 1.2.1. The release:prepare stage creates the proper tag in SVN (tags/project-1.2.1), but the content in the tag is identical to tags/project-1.2 rather than branches/project-1.2.x (with of course the version changes from 1.2.1-SNAPSHOT to 1.2.1). release:prepare run on code checked out from trunk works just fine. Not sure if it is relevant, but here is some additional information: - It is a multi-module maven project with a child module - Subversion client: Subversion command-line client, version 1.6.17-SlikSvn-tag-1.6.17@1130898-X64 - Subversion server: Subversion version 1.6.1 (r37116) release:prepare copies contents of source of Subversion branch into release tag --- Key: MRELEASE-749 URL: https://jira.codehaus.org/browse/MRELEASE-749 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x Reporter: Bindul Bhowmik When releasing from a branch, release:prepare copies the content of the source of the branch into the release tag rather than the content of the branch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-176) helpmojo: Use Java 5 generics in generated help mojo
helpmojo: Use Java 5 generics in generated help mojo Key: MPLUGIN-176 URL: http://jira.codehaus.org/browse/MPLUGIN-176 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: Plugin Plugin Affects Versions: 2.6 Reporter: Bindul Bhowmik Priority: Minor The generated help mojo class generates List and ArrayList variables and parameters without generic collections. This causes compiler warnings for projects compiled with Java 5 or higher. It also causes warnings in IDEs. Possibly an optional parameter like useJava5 in Modello Maven Plugin ([http://modello.codehaus.org/modello-maven-plugin/java-mojo.html#useJava5]) could be used to control generating the help mojo with generic collections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPLUGIN-176) helpmojo: Use Java 5 generics in generated help mojo
[ http://jira.codehaus.org/browse/MPLUGIN-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bindul Bhowmik updated MPLUGIN-176: --- Attachment: MPLUGIN-176-patch.diff Attaching a patch that uses a 'useJava5' parameter to generate help mojo with Java5 generics support. helpmojo: Use Java 5 generics in generated help mojo Key: MPLUGIN-176 URL: http://jira.codehaus.org/browse/MPLUGIN-176 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: Plugin Plugin Affects Versions: 2.6 Reporter: Bindul Bhowmik Priority: Minor Attachments: MPLUGIN-176-patch.diff The generated help mojo class generates List and ArrayList variables and parameters without generic collections. This causes compiler warnings for projects compiled with Java 5 or higher. It also causes warnings in IDEs. Possibly an optional parameter like useJava5 in Modello Maven Plugin ([http://modello.codehaus.org/modello-maven-plugin/java-mojo.html#useJava5]) could be used to control generating the help mojo with generic collections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
