[jira] (MENFORCER-193) Add new rule
Simon Wang created MENFORCER-193: Summary: Add new rule Key: MENFORCER-193 URL: https://jira.codehaus.org/browse/MENFORCER-193 Project: Maven Enforcer Plugin Issue Type: New Feature Reporter: Simon Wang -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-193) Add new rule: BannedRepositories to ban specified repositories for whole maven session
[ https://jira.codehaus.org/browse/MENFORCER-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Wang updated MENFORCER-193: - Component/s: Standard Rules Description: *Description* There are use cases that need to ban specified repositories. Ex. one enterprise migrate their repositories from old one to new one. But some users still use old settings.xml or some projects' pom.xml still have old repositories. What this rule did: 1. bannedRepositories: user could add banned repositories and support wildcard "*" to simplify user's usage. 2. allowedRepositories: that's simpler and useful for enterprise users. Affects Version/s: 2.0 Fix Version/s: 2.0 Summary: Add new rule: BannedRepositories to ban specified repositories for whole maven session (was: Add new rule) > Add new rule: BannedRepositories to ban specified repositories for whole > maven session > -- > > Key: MENFORCER-193 > URL: https://jira.codehaus.org/browse/MENFORCER-193 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 2.0 >Reporter: Simon Wang > Fix For: 2.0 > > > *Description* > There are use cases that need to ban specified repositories. > Ex. one enterprise migrate their repositories from old one to new one. > But some users still use old settings.xml or some projects' pom.xml still > have old repositories. > What this rule did: > 1. bannedRepositories: user could add banned repositories and support > wildcard "*" to simplify user's usage. > 2. allowedRepositories: that's simpler and useful for enterprise users. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-193) Add new rule: BannedRepositories to ban specified repositories for whole maven session
[ https://jira.codehaus.org/browse/MENFORCER-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347238#comment-347238 ] Simon Wang commented on MENFORCER-193: -- pull request is here: https://github.com/apache/maven-enforcer/pull/13 > Add new rule: BannedRepositories to ban specified repositories for whole > maven session > -- > > Key: MENFORCER-193 > URL: https://jira.codehaus.org/browse/MENFORCER-193 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 2.0 >Reporter: Simon Wang > Fix For: 2.0 > > > *Description* > There are use cases that need to ban specified repositories. > Ex. one enterprise migrate their repositories from old one to new one. > But some users still use old settings.xml or some projects' pom.xml still > have old repositories. > What this rule did: > 1. bannedRepositories: user could add banned repositories and support > wildcard "*" to simplify user's usage. > 2. allowedRepositories: that's simpler and useful for enterprise users. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-186) Source and Resource Directories are Ignored
[ https://jira.codehaus.org/browse/MEAR-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347240#comment-347240 ] Thomas Beauvais commented on MEAR-186: -- Thanks for the detailed response Stéphane. That all sounds about right. Is there a better way to get around this? Currently, I am copying everything into the working directory in the /target before running the ear:ear. > Source and Resource Directories are Ignored > --- > > Key: MEAR-186 > URL: https://jira.codehaus.org/browse/MEAR-186 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.9 > Environment: Ubuntu 13.10 >Reporter: Thomas Beauvais > Attachments: pom.xml > > > Due to an odd necessity for different source and resource directories because > of using another IDE that can't be configued (JDeveloper). > When running the EAR plugin, I expect the to be included in the > base of the EAR file. > > src > > > .adf > > > ... > > Here is the project tree: > ./src > ./src/META-INF > ./src/META-INF/jps-config.xml > ./src/META-INF/weblogic-application.xml > ./.adf > ./.adf/META-INF > ./.adf/META-INF/adf-config.xml > ./.adf/META-INF/connections.xml > ./pom.xml > Here is the contents of the EAR: > META-INF/ > META-INF/MANIFEST.MF > META-INF/application.xml > web-0.0.1-SNAPSHOT.war > META-INF/maven/ > META-INF/maven/org.my.company/ > META-INF/maven/org.my.company/ssxa/ > META-INF/maven/org.my.company/ssxa/pom.xml > META-INF/maven/org.my.company/ssxa/pom.properties > Notice, it doesn't include either the source or the resources. I know that I > can include a but this only allows for a single > directory and I have two (.adf and src). > Attached is the pom.xml used. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5638) Whitespaces matter in configuration can cause the incorrect repo to be selected
[
https://jira.codehaus.org/browse/MNG-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5638:
---
Summary: Whitespaces matter in configuration can cause the
incorrect repo to be selected (was: Whitespaces matter in
configuration)
> Whitespaces matter in configuration can cause the incorrect repo
> to be selected
> --
>
> Key: MNG-5638
> URL: https://jira.codehaus.org/browse/MNG-5638
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Tobias Oberlies
>
> Steps to reproduce the problem:
> # Use the following settings.xml (replacing the URLs with valid URLs in your
> environment):
> {noformat}
> http://maven.apache.org/SETTINGS/1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";>
>
>
> mirror1
> http://nexus:8081/nexus/content/repositories/releases/
>
> external:*, !snapshots.repo
>
>
>
>
>
> use-snapshots-repo
>
>
>snapshots.repo
>
> http://nexus:8081/nexus/content/repositories/snapshots/
>
>
>
>
>snapshots.repo
>
> http://nexus:8081/nexus/content/repositories/snapshots/
>
>
>
>
>
> use-snapshots-repo
>
>
> {noformat}
> # Set up a project which uses an artifact from {{snapshots.repo}} which is
> not available in the local Maven repository
> # Build the project: The build fails because Maven only tries to download
> from the releases repository.
> Expected behaviour: Maven should have used the snapshots repo.
> The root cause of the problem is that whitespaces around the separators in
> the {{mirrorOf}} configuration are not trimmed. When changing the
> configuration to
> {noformat}
>
> external:*,!snapshots.repo
>
> {noformat}
> the snapshots repository is used and the build passes.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5638) Whitespaces matter in configuration can cause the incorrect repo to be selected
[
https://jira.codehaus.org/browse/MNG-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347249#comment-347249
]
Paul Benedict commented on MNG-5638:
It would be nice to know whether this element is the exception or do all
elements suffer from accidental whitespace?
> Whitespaces matter in configuration can cause the incorrect repo
> to be selected
> --
>
> Key: MNG-5638
> URL: https://jira.codehaus.org/browse/MNG-5638
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Tobias Oberlies
>
> Steps to reproduce the problem:
> # Use the following settings.xml (replacing the URLs with valid URLs in your
> environment):
> {noformat}
> http://maven.apache.org/SETTINGS/1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";>
>
>
> mirror1
> http://nexus:8081/nexus/content/repositories/releases/
>
> external:*, !snapshots.repo
>
>
>
>
>
> use-snapshots-repo
>
>
>snapshots.repo
>
> http://nexus:8081/nexus/content/repositories/snapshots/
>
>
>
>
>snapshots.repo
>
> http://nexus:8081/nexus/content/repositories/snapshots/
>
>
>
>
>
> use-snapshots-repo
>
>
> {noformat}
> # Set up a project which uses an artifact from {{snapshots.repo}} which is
> not available in the local Maven repository
> # Build the project: The build fails because Maven only tries to download
> from the releases repository.
> Expected behaviour: Maven should have used the snapshots repo.
> The root cause of the problem is that whitespaces around the separators in
> the {{mirrorOf}} configuration are not trimmed. When changing the
> configuration to
> {noformat}
>
> external:*,!snapshots.repo
>
> {noformat}
> the snapshots repository is used and the build passes.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://jira.codehaus.org/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347262#comment-347262
]
Mark Ingram commented on MNG-5639:
--
See pull request for an integration test.
https://github.com/apache/maven-integration-testing/pull/4
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://jira.codehaus.org/browse/MNG-5639
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Priority: Minor
> Attachments: pom.xml
>
>
> Running mvn help-effective-pom on the attached POM:
> [ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]
> mvn help-effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> ${nexus.baseurl}/content/groups/${stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the ${nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
