[jira] Updated: (MEAR-103) Filtered MANIFEST not added to generated EAR
[
http://jira.codehaus.org/browse/MEAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MEAR-103:
-
Fix Version/s: 2.3.3
Filtered MANIFEST not added to generated EAR
Key: MEAR-103
URL: http://jira.codehaus.org/browse/MEAR-103
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Luca Masini
Assignee: Stephane Nicoll
Fix For: 2.3.3
Attachments: test-case.zip
When resource filtering is enabled filtered resources are written into the
${project.build.directory}/${project.build.finalName} directory.
In our test case we have to filter the MANIFEST.MF file, from the
src/main/application/META-INF directory.
But the EAR generator (JarArchiver) reads the MANIFEST in its default
original location ${basedir}/src/main/application/META-INF/MANIFEST.MF, and
there is not filtered.
The workaround is to change the manifestFile attribute so that it reads
directly the generated file, but I think this is a plugin misbehaviour, it
should automatically manage such a situation where the MANIFEST.MF is
filtered.
--
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] Work started: (MEAR-103) Filtered MANIFEST not added to generated EAR
[
http://jira.codehaus.org/browse/MEAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MEAR-103 started by Stephane Nicoll.
Filtered MANIFEST not added to generated EAR
Key: MEAR-103
URL: http://jira.codehaus.org/browse/MEAR-103
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Luca Masini
Assignee: Stephane Nicoll
Fix For: 2.3.3
Attachments: test-case.zip
When resource filtering is enabled filtered resources are written into the
${project.build.directory}/${project.build.finalName} directory.
In our test case we have to filter the MANIFEST.MF file, from the
src/main/application/META-INF directory.
But the EAR generator (JarArchiver) reads the MANIFEST in its default
original location ${basedir}/src/main/application/META-INF/MANIFEST.MF, and
there is not filtered.
The workaround is to change the manifestFile attribute so that it reads
directly the generated file, but I think this is a plugin misbehaviour, it
should automatically manage such a situation where the MANIFEST.MF is
filtered.
--
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] Closed: (MEAR-103) Filtered MANIFEST not added to generated EAR
[
http://jira.codehaus.org/browse/MEAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MEAR-103.
Resolution: Fixed
Fixed. Thanks for the test case!
Filtered MANIFEST not added to generated EAR
Key: MEAR-103
URL: http://jira.codehaus.org/browse/MEAR-103
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Luca Masini
Assignee: Stephane Nicoll
Fix For: 2.3.3
Attachments: test-case.zip
When resource filtering is enabled filtered resources are written into the
${project.build.directory}/${project.build.finalName} directory.
In our test case we have to filter the MANIFEST.MF file, from the
src/main/application/META-INF directory.
But the EAR generator (JarArchiver) reads the MANIFEST in its default
original location ${basedir}/src/main/application/META-INF/MANIFEST.MF, and
there is not filtered.
The workaround is to change the manifestFile attribute so that it reads
directly the generated file, but I think this is a plugin misbehaviour, it
should automatically manage such a situation where the MANIFEST.MF is
filtered.
--
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: (MEAR-75) Incorrect file name in class path (in manifest) if specifying different bundleFileName for module
[
http://jira.codehaus.org/browse/MEAR-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MEAR-75:
Assignee: Stephane Nicoll
Fix Version/s: (was: 2.4)
2.3.3
Last reported bug over here. Let's kill it! :)
Incorrect file name in class path (in manifest) if specifying different
bundleFileName for module
-
Key: MEAR-75
URL: http://jira.codehaus.org/browse/MEAR-75
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: Windows XP SP2, Maven 2.0.7, JDK 1.5.0_12
Reporter: Anders Hammar
Assignee: Stephane Nicoll
Fix For: 2.3.3
Attachments: jbossaop-poc.zip
The file name included in the class path in the generated Manifest.mf file is
incorrect if a different bundle file name is defined in the configuration for
the ear plugin. The file name used in the class path is the original file
name, not the defined bundle file name (which is the actual file name in the
created ear).
In my POM I have:
{code:title=pom.xml|borderStyle=solid}
...
dependencies
dependency
groupIdjbossaop-poc/groupId
artifactIdaop/artifactId
typejar/type
/dependency
...
/dependencies
build
plugins
plugin
artifactIdmaven-ear-plugin/artifactId
configuration
archive
manifest
addClasspathtrue/addClasspath
/manifest
/archive
modules
jarModule
groupIdjbossaop-poc/groupId
artifactIdaop/artifactId
bundleFileNameaop-${pom.version}.aop/bundleFileName
includeInApplicationXmltrue/includeInApplicationXml
/jarModule
/modules
/configuration
/plugin
/plugins
/build
{code}
In the resulting ear file, the included artifact 'aop-1.0-SNAPSHOT.jar' has
been renamed to 'aop-1.0-SNAPSHOT.aop'. However, in the Manifest.mf (in the
ear) the class path incorrectly specifies:
Class-Path: aop-1.0-SNAPSHOT.jar
Attached is a multi-module project that should reproduce this.
--
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] Work started: (MEAR-75) Incorrect file name in class path (in manifest) if specifying different bundleFileName for module
[
http://jira.codehaus.org/browse/MEAR-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MEAR-75 started by Stephane Nicoll.
Incorrect file name in class path (in manifest) if specifying different
bundleFileName for module
-
Key: MEAR-75
URL: http://jira.codehaus.org/browse/MEAR-75
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: Windows XP SP2, Maven 2.0.7, JDK 1.5.0_12
Reporter: Anders Hammar
Assignee: Stephane Nicoll
Fix For: 2.3.3
Attachments: jbossaop-poc.zip
The file name included in the class path in the generated Manifest.mf file is
incorrect if a different bundle file name is defined in the configuration for
the ear plugin. The file name used in the class path is the original file
name, not the defined bundle file name (which is the actual file name in the
created ear).
In my POM I have:
{code:title=pom.xml|borderStyle=solid}
...
dependencies
dependency
groupIdjbossaop-poc/groupId
artifactIdaop/artifactId
typejar/type
/dependency
...
/dependencies
build
plugins
plugin
artifactIdmaven-ear-plugin/artifactId
configuration
archive
manifest
addClasspathtrue/addClasspath
/manifest
/archive
modules
jarModule
groupIdjbossaop-poc/groupId
artifactIdaop/artifactId
bundleFileNameaop-${pom.version}.aop/bundleFileName
includeInApplicationXmltrue/includeInApplicationXml
/jarModule
/modules
/configuration
/plugin
/plugins
/build
{code}
In the resulting ear file, the included artifact 'aop-1.0-SNAPSHOT.jar' has
been renamed to 'aop-1.0-SNAPSHOT.aop'. However, in the Manifest.mf (in the
ear) the class path incorrectly specifies:
Class-Path: aop-1.0-SNAPSHOT.jar
Attached is a multi-module project that should reproduce this.
--
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: (MWAR-158) Overlaying breaks configuration of webXml with a fatal error
[ http://jira.codehaus.org/browse/MWAR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-158: - Fix Version/s: 2.1 Overlaying breaks configuration of webXml with a fatal error Key: MWAR-158 URL: http://jira.codehaus.org/browse/MWAR-158 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-alpha-1 Environment: Maven 2.0.9 SuSE Linux 10.3 java version 1.5.0_09 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03) Java HotSpot(TM) Server VM (build 1.5.0_09-b03, mixed mode) Reporter: Michael Heß Priority: Critical Fix For: 2.1 Attachments: webXmlBug.tar.gz When using overlays, it is no longer possible to use the webXml configuration value. The following exception is thrown: [INFO] [war:war] [INFO] Packaging webapp [INFO] Assembling webapp[webXmlBug] in [/home/mhe/workspace_spielwiese/webXmlBug/target/webXmlBug] [INFO] Processing war project OverlayPackagingTask performPackaging overlay.getTargetPath() null[INFO] Processing overlay[ id de.ordix.webXmlBug:overlay] [INFO] Unpacking overlay[ id de.ordix.webXmlBug:overlay] [INFO] Expanding: /home/mhe/.m2/repository/de/ordix/webXmlBug/overlay/1.0-SNAPSHOT/overlay-1.0-SNAPSHOT.war into /home/mhe/workspace_spielwiese/webXmlBug/target/war/work/de.ordix.webXmlBug/overlay [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Should not happen, path[WEB-INF/web.xml] is flagged as being registered but was not found. [INFO] [INFO] Trace java.lang.IllegalStateException: Should not happen, path[WEB-INF/web.xml] is flagged as being registered but was not found. at org.apache.maven.plugin.war.util.WebappStructure.getOwner(WebappStructure.java:157) at org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:105) at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:140) [...] I have attached a testcase, which reproduces the problem. Just build overlay and webXmlBug with mvn clean install. (I know the testcase is synthetic. If you want a real world scenario, just replace the resources-copy step with e.g. jsp-precompiling.) -- 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] Closed: (MEAR-75) Incorrect file name in class path (in manifest) if specifying different bundleFileName for module
[
http://jira.codehaus.org/browse/MEAR-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MEAR-75.
---
Resolution: Fixed
The issue is now fixed and a SNAPSHOT of 2.3.3 is available on the apache
repository.
The way the Class-Path entry is generated now is through a call to the getUri()
method on each EarModules. This method returns the location of the file
according to the root of the EAR file.
Please test this solution to validate it fits your needs.
I will call a vote to release 2.3.3 in the coming days.
Incorrect file name in class path (in manifest) if specifying different
bundleFileName for module
-
Key: MEAR-75
URL: http://jira.codehaus.org/browse/MEAR-75
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: Windows XP SP2, Maven 2.0.7, JDK 1.5.0_12
Reporter: Anders Hammar
Assignee: Stephane Nicoll
Fix For: 2.3.3
Attachments: jbossaop-poc.zip
The file name included in the class path in the generated Manifest.mf file is
incorrect if a different bundle file name is defined in the configuration for
the ear plugin. The file name used in the class path is the original file
name, not the defined bundle file name (which is the actual file name in the
created ear).
In my POM I have:
{code:title=pom.xml|borderStyle=solid}
...
dependencies
dependency
groupIdjbossaop-poc/groupId
artifactIdaop/artifactId
typejar/type
/dependency
...
/dependencies
build
plugins
plugin
artifactIdmaven-ear-plugin/artifactId
configuration
archive
manifest
addClasspathtrue/addClasspath
/manifest
/archive
modules
jarModule
groupIdjbossaop-poc/groupId
artifactIdaop/artifactId
bundleFileNameaop-${pom.version}.aop/bundleFileName
includeInApplicationXmltrue/includeInApplicationXml
/jarModule
/modules
/configuration
/plugin
/plugins
/build
{code}
In the resulting ear file, the included artifact 'aop-1.0-SNAPSHOT.jar' has
been renamed to 'aop-1.0-SNAPSHOT.aop'. However, in the Manifest.mf (in the
ear) the class path incorrectly specifies:
Class-Path: aop-1.0-SNAPSHOT.jar
Attached is a multi-module project that should reproduce this.
--
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] Created: (MASSEMBLY-404) Different behavior on Linux and Windows
Different behavior on Linux and Windows --- Key: MASSEMBLY-404 URL: http://jira.codehaus.org/browse/MASSEMBLY-404 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Reporter: Julien HENRY Priority: Minor Attachments: test.zip Hi, The assembly created with the given test project produces different results depending on the OS. On Linux, the main JAR is present only once: htmlunit-XX.jar On Windows, this JAR is present 2 times in the ZIP: htmlunit-XX.jar htmlunit-XX.jar -- 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] Commented: (MECLIPSE-551) [regression] Resources are excluded if resource dir equals source dir
[
http://jira.codehaus.org/browse/MECLIPSE-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=174222#action_174222
]
Ralf Ebert commented on MECLIPSE-551:
-
As workaround for this issue one can downgrade the maven-eclipse-plugin:
{noformat}!--
downgraded to 2.5.1 because of
http://jira.codehaus.org/browse/MECLIPSE-443
http://jira.codehaus.org/browse/MECLIPSE-551
(resource settings for src/main/java are ignored in general)
--
plugin
artifactIdmaven-eclipse-plugin/artifactId
version2.5.1/version
/plugin
{noformat}
Mainly for historical reasons I have resource files in {{src/main/java}} and
include them in the maven build like this:
{noformat}resources
resource
directorysrc/main/java/directory
includes
include**/*/include
/includes
excludes
exclude**/*.java/exclude
exclude**/*.sample/exclude
/excludes
/resource
/resources
{noformat}
This works perfectly for the mvn build and maven-eclipse-plugin 2.5.1. Since
maven-eclipse-plugin 2.6 this is not reflected by the generated eclipse project
configuration any more.
Ralf Ebert
[http://www.ralfebert.de/]
[regression] Resources are excluded if resource dir equals source dir
-
Key: MECLIPSE-551
URL: http://jira.codehaus.org/browse/MECLIPSE-551
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.6
Reporter: Benjamin Bentmann
{code:xml}
build
resources
resource
directorysrc/main/java/directory
includes
include**/*.properties/include
/includes
/resource
/resources
/build
{code}
For a non-standard project layout like sketched above where some resource
files reside next to the source files (e.g. Messages.properties in Mercury),
the change for MECLIPSE-443 causes these resources files to be excluded from
the build path since they don't match the filter **/*.java. This can for
instance cause test failures in Eclipse due to resources missing on the class
path.
When source and resource directories equal, the includes/excludes need to be
merged.
--
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] Created: (MAVENUPLOAD-2437) Update Bouncy Castle BCPROV/BCMAIL/BCTSP to 1.43
Update Bouncy Castle BCPROV/BCMAIL/BCTSP to 1.43 Key: MAVENUPLOAD-2437 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2437 Project: Maven Upload Requests Issue Type: Task Reporter: Ricardo Borillo Hi, I'm not a developer of the Bouncy Castle project, but it will be nice if you could upload this bundles: http://xml-utils.com/maven/bcmail-jdk15-143-bundle.jar http://xml-utils.com/maven/bcmail-jdk16-143-bundle.jar http://xml-utils.com/maven/bcprov-jdk15-143-bundle.jar http://xml-utils.com/maven/bcprov-jdk16-143-bundle.jar http://xml-utils.com/maven/bctsp-jdk15-143-bundle.jar http://xml-utils.com/maven/bctsp-jdk16-143-bundle.jar Thanks in advance -- 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: (MERCURY-75) DependencyBuilder does not check if the query artifacts exist
[ http://jira.codehaus.org/browse/MERCURY-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-75: Fix Version/s: (was: 1.0-alpha-7) DependencyBuilder does not check if the query artifacts exist - Key: MERCURY-75 URL: http://jira.codehaus.org/browse/MERCURY-75 Project: Mercury Issue Type: Bug Affects Versions: 1.0.0-alpha-3 Reporter: Oleg Gusakov Assignee: Oleg Gusakov DependencyBuilder always presumes they exist and if DependencyProcessor does not throw an exception (not finding the POM), it will return this as an artifact without dependencies. Need to enforce that DependencyProcessor fails for non-existent artifacts. Because Dep.Processor is reading POM from all known repos - if it does not get pom bytes - it means that artifact is not found -- 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: (MERCURY-95) embedd password encryption into mercury-ant
[ http://jira.codehaus.org/browse/MERCURY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-95: Fix Version/s: (was: 1.0-alpha-7) embedd password encryption into mercury-ant --- Key: MERCURY-95 URL: http://jira.codehaus.org/browse/MERCURY-95 Project: Mercury Issue Type: New Feature Components: Ant tasks Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov port password decryption from maven 3.0 trunk -- 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: (MERCURY-114) ad support for managed versions
[ http://jira.codehaus.org/browse/MERCURY-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-114: - Fix Version/s: (was: 1.0-alpha-7) 1.0-alpha-8 ad support for managed versions --- Key: MERCURY-114 URL: http://jira.codehaus.org/browse/MERCURY-114 Project: Mercury Issue Type: New Feature Components: Dependency Builder Affects Versions: 1.0-alpha-7 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-8 client should be able to supply a map of versions to override any retrieved artifact's versions -- 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: (MERCURY-69) LocalRepositoryWriterFlat leaks file handles
[
http://jira.codehaus.org/browse/MERCURY-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Gusakov updated MERCURY-69:
Fix Version/s: (was: 1.0-alpha-7)
1.0-alpha-8
LocalRepositoryWriterFlat leaks file handles
Key: MERCURY-69
URL: http://jira.codehaus.org/browse/MERCURY-69
Project: Mercury
Issue Type: Bug
Components: Repository
Affects Versions: 1.0.0-alpha-2
Reporter: Benjamin Bentmann
Assignee: Oleg Gusakov
Fix For: 1.0-alpha-8
Although my working copy includes the patch for MERCURY-68, I still
occasionally observe files named test-flat*-repo in the temp dir. The
{{LocalRepositoryFlatTest}} already employs {{deleteOnExit()}} so it seems
there are some open handles preventing the deletion. And indeed, in
{{LocalRepositoryWriterFlat.writeArtifact()}} a {{FileInputStream}} is
created but there is apparently no corresponding call to {{close()}} on the
stream.
--
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] Created: (MERCURY-117) allow sufficient repositories
allow sufficient repositories --- Key: MERCURY-117 URL: http://jira.codehaus.org/browse/MERCURY-117 Project: Mercury Issue Type: New Feature Components: Repository Affects Versions: 1.0-alpha-8 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Some repositories need to declare that artifacts found in them are final, and the virtual repository reader should stop scanning repositories for more. Apparent application is Maven's Reactor repository: if a snapshot is found there, it is final and should be used over any other version. This can be achieved by: * adding this repository to the front of the repository chain * declaring this repository sufficient -- 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: (MERCURY-117) allow sufficient repositories
[ http://jira.codehaus.org/browse/MERCURY-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-117: - Description: Some repositories need to declare that artifacts found in them are final, and the virtual repository reader should stop scanning repositories for more. Apparent application is Maven's Reactor repository: if an artifact is found there, it is final and should be used over any other version. This can be achieved by: * adding this repository to the front of the repository chain * declaring this repository sufficient was: Some repositories need to declare that artifacts found in them are final, and the virtual repository reader should stop scanning repositories for more. Apparent application is Maven's Reactor repository: if a snapshot is found there, it is final and should be used over any other version. This can be achieved by: * adding this repository to the front of the repository chain * declaring this repository sufficient allow sufficient repositories --- Key: MERCURY-117 URL: http://jira.codehaus.org/browse/MERCURY-117 Project: Mercury Issue Type: New Feature Components: Repository Affects Versions: 1.0-alpha-8 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Some repositories need to declare that artifacts found in them are final, and the virtual repository reader should stop scanning repositories for more. Apparent application is Maven's Reactor repository: if an artifact is found there, it is final and should be used over any other version. This can be achieved by: * adding this repository to the front of the repository chain * declaring this repository sufficient -- 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: (MERCURY-117) allow sufficient repositories
[ http://jira.codehaus.org/browse/MERCURY-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-117: - Description: Some repositories need to declare that artifacts found in them are final, and the virtual repository reader should stop scanning repositories for more. Apparent application is Maven's Reactor repository: if an artifact is found there, it is final and should be used over any other. This can be achieved by: * adding this repository to the front of the repository chain * declaring this repository sufficient was: Some repositories need to declare that artifacts found in them are final, and the virtual repository reader should stop scanning repositories for more. Apparent application is Maven's Reactor repository: if an artifact is found there, it is final and should be used over any other version. This can be achieved by: * adding this repository to the front of the repository chain * declaring this repository sufficient allow sufficient repositories --- Key: MERCURY-117 URL: http://jira.codehaus.org/browse/MERCURY-117 Project: Mercury Issue Type: New Feature Components: Repository Affects Versions: 1.0-alpha-8 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Some repositories need to declare that artifacts found in them are final, and the virtual repository reader should stop scanning repositories for more. Apparent application is Maven's Reactor repository: if an artifact is found there, it is final and should be used over any other. This can be achieved by: * adding this repository to the front of the repository chain * declaring this repository sufficient -- 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
