[jira] (DOXIA-496) AptParser cannot render velocimacros file with literal anchors in links
[
https://jira.codehaus.org/browse/DOXIA-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=331950#comment-331950
]
Jared Roberts commented on DOXIA-496:
-
I found a workaround to this issue that isn't pretty, but functions.
{noformat}
#set( $method1 = '##broken(java.lang.String)' )
{{{./apidocs/org/brandon/example/MyClass.html$method1}broken}}
{noformat}
AptParser cannot render velocimacros file with literal anchors in links
---
Key: DOXIA-496
URL: https://jira.codehaus.org/browse/DOXIA-496
Project: Maven Doxia
Issue Type: Bug
Components: Module - Apt
Affects Versions: 1.4
Environment: Maven 3.1.0, maven-site-plugin-3.3, doxia 1.4
Reporter: Brandon Heck
When generating a site, I get the following error and a subsequent build
failure:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
myProject: Error during page generation: Error parsing 'theFile.apt.vm':
line [15] missing '}' - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
project myProject: Error during page generation
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:143)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
parsing 'myFile.apt.vm': line [15] missing '}'
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:414)
at
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
... 21 more
Caused by: org.apache.maven.doxia.module.apt.AptParseException: missing '}'
at org.apache.maven.doxia.module.apt.AptParser.parse(AptParser.java:235)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:406)
... 26 more
Caused by: org.apache.maven.doxia.module.apt.AptParseException: missing '}'
at
org.apache.maven.doxia.module.apt.AptParser.skipTraversedLinkAnchor(AptParser.java:1485)
at
org.apache.maven.doxia.module.apt.AptParser.doTraverseText(AptParser.java:453)
at
[jira] (DOXIA-496) AptParser cannot render velocimacros file with literal anchors in links
[
https://jira.codehaus.org/browse/DOXIA-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=331964#comment-331964
]
Jared Roberts commented on DOXIA-496:
-
Yes, I tried all combinations of escaping both hashtags and one or the other.
It either caused the error above or the problem that was worked around by
DOXIA-397 -- which is the reason for needing the double hash.
AptParser cannot render velocimacros file with literal anchors in links
---
Key: DOXIA-496
URL: https://jira.codehaus.org/browse/DOXIA-496
Project: Maven Doxia
Issue Type: Bug
Components: Module - Apt
Affects Versions: 1.4
Environment: Maven 3.1.0, maven-site-plugin-3.3, doxia 1.4
Reporter: Brandon Heck
When generating a site, I get the following error and a subsequent build
failure:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
myProject: Error during page generation: Error parsing 'theFile.apt.vm':
line [15] missing '}' - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on
project myProject: Error during page generation
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:143)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
parsing 'myFile.apt.vm': line [15] missing '}'
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:414)
at
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
... 21 more
Caused by: org.apache.maven.doxia.module.apt.AptParseException: missing '}'
at org.apache.maven.doxia.module.apt.AptParser.parse(AptParser.java:235)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:406)
... 26 more
Caused by: org.apache.maven.doxia.module.apt.AptParseException: missing '}'
at
org.apache.maven.doxia.module.apt.AptParser.skipTraversedLinkAnchor(AptParser.java:1485)
at
org.apache.maven.doxia.module.apt.AptParser.doTraverseText(AptParser.java:453)
at
[jira] (ARCHETYPE-409) IntegrationTestMojo deletes project folder before test.
Jared Roberts created ARCHETYPE-409: --- Summary: IntegrationTestMojo deletes project folder before test. Key: ARCHETYPE-409 URL: https://jira.codehaus.org/browse/ARCHETYPE-409 Project: Maven Archetype Issue Type: Bug Components: Plugin Affects Versions: 2.2 Reporter: Jared Roberts Attachments: partial-archetype-example.zip I am attempting to integration test a partial archetype by including a valid POM inside the test project. The test fails to generate the expected output because prior to running the test, a call to FileUtils.deleteDirectory() is made to delete all files in the test basedir. I believe the intent of performing the deletion is to clean up prior test runs, but this makes testing partial archetypes impossible with the maven-archetype-plugin. A couple possible solutions exist. The first would be to stop deleting the basedir before testing. This might be surprising if someone forgets to clean between tests, but is that really a valid use-case? The second option that I can think of would be to add a new conventional directory (expected?) where the test project files can be placed and the Archetype plugin will check if that directory exists and copy the contents to the project folder after cleaning up. This option seems like a good compromise because it allows tests to succeed without an explicit clean between and also allows testing of partial archetypes. I've attached an example archetype that demonstrates the behavior I'm describing. Notice that the output from both the empty and existing projects are the same. -- 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: (MNG-5103) NPE thrown when DefaultArtifact.getSelectedVersion is called
NPE thrown when DefaultArtifact.getSelectedVersion is called Key: MNG-5103 URL: http://jira.codehaus.org/browse/MNG-5103 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0 Environment: not env dependent Reporter: Jared Roberts Assignee: Benjamin Bentmann getSelectedVersion() uses the versionRange variable directly instead of using getVersionRange() which creates the version range from version if its null. This bug when using the appfuse warpath plugin when doing a double war overlay -- 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: (MNG-5103) NPE thrown when DefaultArtifact.getSelectedVersion is called
[
http://jira.codehaus.org/browse/MNG-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268362#action_268362
]
Jared Roberts commented on MNG-5103:
I'm resurrecting this from MNG-4887 because I also ran into the same issue. For
certain artifacts, it seems that the versionRange does not get initialized and
will throw an NPE when
[{{DefaultArtifact.getSelectedVersion()}}|http://maven.apache.org/ref/2.2.1/maven-artifact/xref/org/apache/maven/artifact/DefaultArtifact.html#618]
is called. I encountered it while using Maven 2.1.0 and 2.2.1. Switching to
3.0.1 resolved my specific issue, so I assume something changed in the way the
Artifact gets created. The original poster referenced using
{{DefaultArtifact.getVersionRange()}} where there is a relevant
[comment|http://maven.apache.org/ref/2.2.1/maven-artifact/xref/org/apache/maven/artifact/DefaultArtifact.html#513]
hinting that further investigation was probably needed.
I worked around the issue by using the following code block
{code:title=Before.java}
Artifact dep = ...;
ArtifactVersion selectedVersion = dep.getSelectedVersion();
{code}
{code:title=After.java}
Artifact dep = ...;
ArtifactVersion selectedVersion = dep.getVersionRange().getSelectedVersion(dep);
{code}
NPE thrown when DefaultArtifact.getSelectedVersion is called
Key: MNG-5103
URL: http://jira.codehaus.org/browse/MNG-5103
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0
Environment: not env dependent
Reporter: Jared Roberts
getSelectedVersion() uses the versionRange variable directly instead of using
getVersionRange() which creates the version range from version if its null.
This bug when using the appfuse warpath plugin when doing a double war overlay
--
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: (MINVOKER-70) invoker:install does not properly handle versioned dependencies
[ http://jira.codehaus.org/browse/MINVOKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Roberts updated MINVOKER-70: -- Attachment: MINVOKER-70-Example.zip The problem is that no maven-metadata-local.xml exists when a dependency of the main project is downloaded from the remote repository. This file is inserted into the local repo when the project is deployed. I'm attaching a couple of test projects to illustrate what I'm seeing. These are the steps to recreate the problem: 1) Deploy project bar 2) Clear your local repository 3) Verify project foo invoker:install does not properly handle versioned dependencies --- Key: MINVOKER-70 URL: http://jira.codehaus.org/browse/MINVOKER-70 Project: Maven 2.x Invoker Plugin Issue Type: Bug Affects Versions: 1.3 Reporter: Jared Roberts Priority: Critical Attachments: MINVOKER-70-Example.zip The fix for MINVOKER-64 introduced a regression. Previously, only the artifact under test was installed to the IT local repository. The other dependencies were then resolved from remote repositories. In 1.3, the other dependencies are pulled from the actual local repository. It appears that the resolution of uniquely versioned dependencies is different in the two flows because the 1.2.1 flow downloaded both the uniquely versioned jar and the non-unique jar but the 1.3 flow only installs the uniquely versioned jar. My build now fails because it cannot find the non-uniquely versioned jar to run my integration tests. -- 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: (MINVOKER-70) invoker:install does not properly handle versioned dependencies
[ http://jira.codehaus.org/browse/MINVOKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=150235#action_150235 ] Jared Roberts commented on MINVOKER-70: --- A work around that I've found is to use the instructions [1] for improving build speed by including a custom settings.xml file. The local repository is then set up as a remote repository for the forked build and the required artifacts are resolved. [1] http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html invoker:install does not properly handle versioned dependencies --- Key: MINVOKER-70 URL: http://jira.codehaus.org/browse/MINVOKER-70 Project: Maven 2.x Invoker Plugin Issue Type: Bug Affects Versions: 1.3 Reporter: Jared Roberts Priority: Critical Attachments: MINVOKER-70-Example.zip The fix for MINVOKER-64 introduced a regression. Previously, only the artifact under test was installed to the IT local repository. The other dependencies were then resolved from remote repositories. In 1.3, the other dependencies are pulled from the actual local repository. It appears that the resolution of uniquely versioned dependencies is different in the two flows because the 1.2.1 flow downloaded both the uniquely versioned jar and the non-unique jar but the 1.3 flow only installs the uniquely versioned jar. My build now fails because it cannot find the non-uniquely versioned jar to run my integration tests. -- 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: (MINVOKER-70) invoker:install does not properly handle versioned dependencies
invoker:install does not properly handle versioned dependencies --- Key: MINVOKER-70 URL: http://jira.codehaus.org/browse/MINVOKER-70 Project: Maven 2.x Invoker Plugin Issue Type: Bug Affects Versions: 1.3 Reporter: Jared Roberts Priority: Critical The fix for MINVOKER-64 introduced a regression. Previously, only the artifact under test was installed to the IT local repository. The other dependencies were then resolved from remote repositories. In 1.3, the other dependencies are pulled from the actual local repository. It appears that the resolution of uniquely versioned dependencies is different in the two flows because the 1.2.1 flow downloaded both the uniquely versioned jar and the non-unique jar but the 1.3 flow only installs the uniquely versioned jar. My build now fails because it cannot find the non-uniquely versioned jar to run my integration tests. -- 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: (MNG-2817) Add identity specification in maven-model and maven-settings
[ http://jira.codehaus.org/browse/MNG-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=134703#action_134703 ] Jared Roberts commented on MNG-2817: Is there any way this could get patched back to the 2.0.x branch? These are defect fixes rather than new functionality and the project I'm working on would rather not wait until the 2.1 release. Add identity specification in maven-model and maven-settings Key: MNG-2817 URL: http://jira.codehaus.org/browse/MNG-2817 Project: Maven 2 Issue Type: Bug Components: POM, Settings Reporter: Vincent Siveton Fix For: 2.1 Some generated objects are used in lists. Thus, it will be very useful to have identity specification for them: equals(..) and hashcode() (see MODELLO-43) For instance, see org.apache.maven.model.Resource used in model/build/resources -- 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: (MNG-3266) maven-model RepositoryBase overrides equals() but not hashCode()
[ http://jira.codehaus.org/browse/MNG-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Roberts updated MNG-3266: --- Attachment: MNG-3266-maven-model-v2.patch The first version of this patch had a NPE in hashCode() since 217 + null != null. I opted to just use the identifier tag instead of implementing these methods. maven-model RepositoryBase overrides equals() but not hashCode() Key: MNG-3266 URL: http://jira.codehaus.org/browse/MNG-3266 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Jared Roberts Priority: Minor Attachments: MNG-3266-maven-model-v2.patch, MNG-3266-maven-model.patch Overriding equals and not hashCode is considered bad practice. Also, while looking around, I noticed the two subclasses (Repository and PluginRepository) both override equals and just call super.equals(). There is a cryptic comment nearby that leads me to believe this is a temporary fix for an old problem. -- 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: (MNG-3265) maven-model Repository.equals causes NPE when any field is uninitialized
maven-model Repository.equals causes NPE when any field is uninitialized Key: MNG-3265 URL: http://jira.codehaus.org/browse/MNG-3265 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Jared Roberts The equals(Object) method of Extension does not check for null values before calling String.equals(). -- 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: (MNG-3265) maven-model Repository.equals causes NPE when any field is uninitialized
[ http://jira.codehaus.org/browse/MNG-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Roberts updated MNG-3265: --- Attachment: MNG-3265-maven-model.patch This patch should take care of it. maven-model Repository.equals causes NPE when any field is uninitialized Key: MNG-3265 URL: http://jira.codehaus.org/browse/MNG-3265 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Jared Roberts Attachments: MNG-3265-maven-model.patch The equals(Object) method of Extension does not check for null values before calling String.equals(). -- 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: (MNG-3265) maven-model Repository.equals causes NPE when any field is uninitialized
[ http://jira.codehaus.org/browse/MNG-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112149 ] Jared Roberts commented on MNG-3265: That's what I get for copying and pasting... The title should be Extension.equals causes NPE not Repository. maven-model Repository.equals causes NPE when any field is uninitialized Key: MNG-3265 URL: http://jira.codehaus.org/browse/MNG-3265 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Jared Roberts Attachments: MNG-3265-maven-model.patch The equals(Object) method of Extension does not check for null values before calling String.equals(). -- 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: (MNG-3266) maven-model RepositoryBase overrides equals() but not hashCode()
maven-model RepositoryBase overrides equals() but not hashCode() Key: MNG-3266 URL: http://jira.codehaus.org/browse/MNG-3266 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Jared Roberts Priority: Minor Overriding equals and not hashCode is considered bad practice. Also, while looking around, I noticed the two subclasses (Repository and PluginRepository) both override equals and just call super.equals(). There is a cryptic comment nearby that leads me to believe this is a temporary fix for an old problem. -- 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: (MNG-3266) maven-model RepositoryBase overrides equals() but not hashCode()
[ http://jira.codehaus.org/browse/MNG-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Roberts updated MNG-3266: --- Attachment: MNG-3266-maven-model.patch This patch implements hashCode() and also removes the subclasses' overrides of equals. maven-model RepositoryBase overrides equals() but not hashCode() Key: MNG-3266 URL: http://jira.codehaus.org/browse/MNG-3266 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Jared Roberts Priority: Minor Attachments: MNG-3266-maven-model.patch Overriding equals and not hashCode is considered bad practice. Also, while looking around, I noticed the two subclasses (Repository and PluginRepository) both override equals and just call super.equals(). There is a cryptic comment nearby that leads me to believe this is a temporary fix for an old problem. -- 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: (MNG-3240) maven-model RepositoryBase.equals() causes ClassCastException
maven-model RepositoryBase.equals() causes ClassCastException - Key: MNG-3240 URL: http://jira.codehaus.org/browse/MNG-3240 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0 Reporter: Jared Roberts The equals(Object) method of RepositoryBase does not check the type of the input before casting it to RepositoryBase. This behavior violates the contract of Object.equals(Object) and causes ClassCastExceptions when any other type of object is passed in. -- 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: (MNG-3240) maven-model RepositoryBase.equals() causes ClassCastException
[ http://jira.codehaus.org/browse/MNG-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Roberts updated MNG-3240: --- Attachment: MNG-3240-maven-model.patch This patch should fix the issue. maven-model RepositoryBase.equals() causes ClassCastException - Key: MNG-3240 URL: http://jira.codehaus.org/browse/MNG-3240 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0 Reporter: Jared Roberts Attachments: MNG-3240-maven-model.patch The equals(Object) method of RepositoryBase does not check the type of the input before casting it to RepositoryBase. This behavior violates the contract of Object.equals(Object) and causes ClassCastExceptions when any other type of object is passed in. -- 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
