[jira] Commented: (DOXIA-74) Added muse format to doxia-core
[ http://jira.codehaus.org/browse/DOXIA-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120745 ] Arnaud Bailly commented on DOXIA-74: Hello, Following Jason's advice, I created a module for muse format, but it doesn't seem to work properly. I followed http://jira.codehaus.org/browse/DOXIA-68 's conclusions, added a test case for dependencies included in the site-plugin mojo, but it doesn't work. It works for twiki however, as said in the issue comments. What am I doing wrong ? Here is a link to the sources of the project: http://www.oqube.com/projects/muse-java/muse-doxia/muse-doxia-module/xref/ Any help appreciated. > Added muse format to doxia-core > --- > > Key: DOXIA-74 > URL: http://jira.codehaus.org/browse/DOXIA-74 > Project: Maven Doxia > Issue Type: New Feature > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Arnaud Bailly >Priority: Minor > Attachments: patch-doxia-1.0-alpha-8, patch-doxia-1.0-alpha-8-1.0-rc3 > > > As a workaround to DOXIA-68 bug, I have m\ade a patch to > doxia-core-1.0-alpha-8 that include necessary code for generating maven sites > from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. > This patch may be useful for people who wish to write their documentation > using Emacs muse mode. -- 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: (DOXIA-74) Added muse format to doxia-core
[ http://jira.codehaus.org/browse/DOXIA-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120744 ] Arnaud Bailly commented on DOXIA-74: Hello, Following Jason's advice, I created a module for muse format, but it doesn't seem to work properly. I followed http://jira.codehaus.org/browse/DOXIA-68 's conclusions, added a test case for dependencies included in the site-plugin mojo, but it doesn't work. It works for twiki however, as said in the issue comments. What am I doing wrong ? Here is a link to the sources of the project: http://www.oqube.com/projects/muse-java/muse-doxia/muse-doxia-module/xref/ Any help appreciated. > Added muse format to doxia-core > --- > > Key: DOXIA-74 > URL: http://jira.codehaus.org/browse/DOXIA-74 > Project: Maven Doxia > Issue Type: New Feature > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Arnaud Bailly >Priority: Minor > Attachments: patch-doxia-1.0-alpha-8, patch-doxia-1.0-alpha-8-1.0-rc3 > > > As a workaround to DOXIA-68 bug, I have m\ade a patch to > doxia-core-1.0-alpha-8 that include necessary code for generating maven sites > from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. > This patch may be useful for people who wish to write their documentation > using Emacs muse mode. -- 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: (SUREFIRE-121) System properties set on the command line get clobbered
[
http://jira.codehaus.org/browse/SUREFIRE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120747
]
Milos Kleint commented on SUREFIRE-121:
---
Unfortunately most components/classes in Maven have no javadoc, MavenSession is
no exception. Since the instance can be retrieved via the ${session} expression
in mojos, it makes it part of the official APIs to me though. Other can have
more insight on the status of the class..
Currently the command line maven put all System.getProperties() there plus any
props that were added on the command line.
Embedders can choose to provide same set or limit it. (eg. in my case I now
filter out any netbeans-related properties in System.getproperties() list to
prevent XML parser failures)
> System properties set on the command line get clobbered
> ---
>
> Key: SUREFIRE-121
> URL: http://jira.codehaus.org/browse/SUREFIRE-121
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Linux, Maven 2.0.4, Sun JDK 1.5U5, bash 3.0
>Reporter: Brenton Leanhardt
>Priority: Critical
> Fix For: 2.x
>
>
> Some system properties get clobbered if you set them on the command line. For
> example,
> mvn clean test -Dtest=LoginTest -Dselenium.user=test32
> The 'test' system property will work, but the 'selenium.user' property will
> be null at runtime. I have tried:
> * hard coding the system property in the unit test, this worked fine.
> * setting the system properties in the pom file, this worked fine also.
> * tried an older version of the surefire plugin, this worked fine.
--
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: (SUREFIRE-434) Cannot run TestNG suites that contains other suites
Cannot run TestNG suites that contains other suites --- Key: SUREFIRE-434 URL: http://jira.codehaus.org/browse/SUREFIRE-434 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4 Environment: Linux (k)ubuntu, Eclipse 3.3 /w TestNG plugin, TestNG 5.1, Maven 2, Java 5 Reporter: Daniel Brolund Priority: Critical Attachments: testng-bug.tar When running suites containing suites for TestNG I get an error in maven: org.apache.maven.surefire.booter.SurefireExecutionException: Error reading test suite; nested exception is org.xml.sax.SAXParseException: Element type "suite-files" must be declared.; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: Error reading test suite; nested exception is org.xml.sax.SAXParseException: Element type "suite-files" must be declared. org.apache.maven.surefire.testset.TestSetFailedException: Error reading test suite; nested exception is org.xml.sax.SAXParseException: Element type "suite-files" must be declared. org.xml.sax.SAXParseException: Element type "suite-files" must be declared. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131) See attached project for full stacktrace and working example. Configuring the respective leaf suites and running them works fine in maven. The same suite works fine with the TestNG plugin in Eclipse. -- 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: (MEV-571) velocity and org.apache.velocity refer to the same product
velocity and org.apache.velocity refer to the same product -- Key: MEV-571 URL: http://jira.codehaus.org/browse/MEV-571 Project: Maven Evangelism Issue Type: Bug Reporter: Al Sutton Both groupIds org.apache.velocity and velocity refer to the same product (the velocity template engine), having two different groupIDs for the same product creates the possibility for multiple jars of the same product to be included in a compile and run classpath. This has been seen in Struts2 where we had 1.4 from groupID velocity from a dependancy, and 1.5 from org.apache.velocity in our pom. One needs to go and a redirect put in place inorder to ensure correct dependancy resolution. -- 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: (MEV-570) groupId org.freemarker and freemarker refer to the same product
groupId org.freemarker and freemarker refer to the same product --- Key: MEV-570 URL: http://jira.codehaus.org/browse/MEV-570 Project: Maven Evangelism Issue Type: Bug Components: Relocation Reporter: Al Sutton Both org.freemarker and freemarker refer to the same product (the freemarker template library), having two different groupIDs for the same product creates the possibility for multiple jars of the same product to be included in a compile and run classpath. This has been seen in Struts2 where we had 2.3.4 from groupID freemarker from a dependancy, and 2.3.11 from org.freemarker in our pom. One needs to go and a redirect put in place inorder to ensure consistency. -- 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: (MRM-660) unable to uncheck "releases included" on a managed repository when editing the repository
unable to uncheck "releases included" on a managed repository when editing the repository - Key: MRM-660 URL: http://jira.codehaus.org/browse/MRM-660 Project: Archiva Issue Type: Bug Components: web application Affects Versions: 1.0 Reporter: Brett Porter -- 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: (MRM-661) remote repository removals are not saved after restart
remote repository removals are not saved after restart -- Key: MRM-661 URL: http://jira.codehaus.org/browse/MRM-661 Project: Archiva Issue Type: Bug Components: web application Affects Versions: 1.0 Reporter: Brett Porter -- 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: (MRESOURCES-53) maven replaces @@ with [EMAIL PROTECTED] in resources
[ http://jira.codehaus.org/browse/MRESOURCES-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Torben Heuer updated MRESOURCES-53: --- Attachment: mavenbug.tar.gz Added a sample project. Have a look at the pom, src/webresources/filterme.xml and the generated output under: target/test-2.0-SNAPSHOT/filterme.xml Note: project won't install, because a web.xml is missing. Jan > maven replaces @@ with [EMAIL PROTECTED] in resources > -- > > Key: MRESOURCES-53 > URL: http://jira.codehaus.org/browse/MRESOURCES-53 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Environment: Linux 2.6 >Reporter: Jan Torben Heuer >Priority: Critical > Attachments: mavenbug.tar.gz > > > maven replaces the String @@ in resources with [EMAIL PROTECTED] > I enabled filtering for the resources and my variables are correctly replaced. > Jan -- 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: (MSITE-290) Move logic from AbstractSiteMojo and AbstractSiteRenderingMojo for Doxia related stuff
Move logic from AbstractSiteMojo and AbstractSiteRenderingMojo for Doxia related stuff -- Key: MSITE-290 URL: http://jira.codehaus.org/browse/MSITE-290 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-7 Reporter: Vincent Siveton -- 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: (DOXIA-185) Add encoding support
[ http://jira.codehaus.org/browse/DOXIA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120767 ] Vincent Siveton commented on DOXIA-185: --- I mean in the Skin API > Add encoding support > > > Key: DOXIA-185 > URL: http://jira.codehaus.org/browse/DOXIA-185 > Project: Maven Doxia > Issue Type: Improvement > Components: Sink API >Affects Versions: 1.0-alpha-10 >Reporter: Vincent Siveton > -- 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: (MSITE-290) Move logic from AbstractSiteMojo and AbstractSiteRenderingMojo for Doxia related stuff
[
http://jira.codehaus.org/browse/MSITE-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120768
]
Vincent Siveton commented on MSITE-290:
---
Working on the linkcheck-plugin, I realize that the logic for Doxia's stuff
(mainly around on the Decorationmodel) is too stuck to site-plugin. It could be
related to MNG-3346.
I proposed to create a maven-doxia-tools project in shared to include this
logic. So, we could reuse it.
Actually, I saw this API mainly from AbstractSiteMojo and
AbstractSiteRenderingMojo.
{code:title=SiteTool.java|borderStyle=solid}
public interface SiteTool
{
Artifact getSkinArtifactFromRepository( ArtifactRepository localRepository,
List remoteArtifactRepositories, DecorationModel decoration )
throws ArtifactResolutionException, SiteToolException;
Artifact getDefaultSkinArtifact( ArtifactRepository localRepository, List
remoteArtifactRepositories )
throws ArtifactResolutionException, SiteToolException;
String getRelativePath( String to, String from );
DecorationModel getDecorationModel( MavenProject project, List
reactorProjects, ArtifactRepository localRepository )
throws SiteToolException;
File getSiteDescriptorFromRepository( MavenProject project,
ArtifactRepository localRepository, Locale locale )
throws ArtifactResolutionException, IOException;
File getSiteDescriptorFromProject( MavenProject project, Locale locale );
}
{code}
> Move logic from AbstractSiteMojo and AbstractSiteRenderingMojo for Doxia
> related stuff
> --
>
> Key: MSITE-290
> URL: http://jira.codehaus.org/browse/MSITE-290
> Project: Maven 2.x Site Plugin
> Issue Type: Improvement
>Affects Versions: 2.0-beta-7
>Reporter: Vincent Siveton
>
--
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] Issue Comment Edited: (DOXIA-185) Add encoding support
[ http://jira.codehaus.org/browse/DOXIA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120767 ] siveton edited comment on DOXIA-185 at 1/21/08 7:24 AM: I mean in the Sink API was (Author: siveton): I mean in the Skin API > Add encoding support > > > Key: DOXIA-185 > URL: http://jira.codehaus.org/browse/DOXIA-185 > Project: Maven Doxia > Issue Type: Improvement > Components: Sink API >Affects Versions: 1.0-alpha-10 >Reporter: Vincent Siveton > -- 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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120773 ] David Hoffer commented on MNG-3092: --- Can we decide what we are going to do regarding this bug? This issue has been going on for a long time and some resolution is needed now. In the past, we have made manual patches of maven to fix this bug. However now I have found that I need to upgrade to 2.0.8 and I cannot because of this issue (there may also be other places in maven where this needs to be applied as well). I.e. since the release plug-in did not use maven's core to handle version ranges we had to patch it as well, once this is fixed I would assume it should use the core instead of duplicating logic. I have found that release-plugin 2.0-beta-6 & 2.0-beta-7 are broken with respect to 2.0.8 if using version ranges, refer to MNG-3351. The current situation at our company is dire; we have spent the last 2 years implementing an enterprise CI build system using maven. Now we find ourselves in a situation were builds do not work anymore and I can find NO workaround. That is, I have deploys that now fail because I (assume) am tripping over transitive dependency bugs that have been fixed but I cannot use because I cannot get to 2.0.8. I cannot go to 2.0.8 because with it most releases fail (again see MNG-3351). As far as I can tell, all of the failures are caused by usage of version ranges; hence the need for this bug to be fixed. It seems the main proponent of retaining the current behavior of version ranges, gets around this issue because he does not use snapshots (does not deploy snapshots). He simply replaces snapshot builds with releases and then manually tags the releases with metadata to indicate the good vs. bad releases. I am not convinced that this is the best way to go for an enterprise CI build system. I feel the normal maven usage of snapshots and releases is too great to give up. I am at a point now that I need to know if this will be fixed or not, if yes you will make us very happy, as we can continue with Maven. However if it cannot be fixed I am forced into either not using version ranges or not using Maven. We are an international company with well over 100 engineers, it would be great to be able to use maven globally but because of this issue we are forced to rethink our maven usage. First, let me be clear why we are using version ranges. For internally developed components & applications we make a contract with component developers/consumers that we will not (knowingly) break an existing API unless the major version changes, because of this contract we want developers/consumers to always use the latest version of a released component. Not only does always using the latest released version force usage of that component so we can find problems, apply fixes, etc it also is our dependency version management system. We don't need to ever say what version we want to release with because we always want that which version range is supposed to give us, i.e. the latest released version. (Note we always state the range of versions we will accept, i.e. [1.23, 2.0). Is there a way I can get this behavior without version ranges? I would be happy to use a different syntax if available. Now my first option (if this cannot be fixed asap) is to not use version ranges. How can I get this behavior without them? I am not familiar with the other mechanisms maven may have for dependency management. Is there some other technique I can use? If I were to fix all versions could I write some plug-in that would/could dynamically look for latest released versions and then rewrite the pom to use what it finds? Lastly, I hate to say it but we could move to something other than maven. I understand there are maven like systems, i.e. buildr, that attempt at least to not have these problems. How many other large companies find they can use maven across the entire enterprise? I note there are 14 votes to fix this issue, how are the other 13 working around this bug? I suspect that most using maven are not using it internally to create libraries of reusable components that are consumed by others within the same organization. If there are, I would love to hear how they resolve this issue. Regards, Dave Hoffer X-Rite, Inc. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: http://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 2.0.x > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not re
[jira] Created: (MCHECKSTYLE-83) Checkstyle report showing a check as Error when it is Warning
Checkstyle report showing a check as Error when it is Warning - Key: MCHECKSTYLE-83 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-83 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Ben Lidgey Priority: Minor Attachments: inuk-checks.xml Checkstyle report showing a check as Error when it is Warning. The report is attached as a screenshot, together with the custom checks XML. The maven output shows the custom file being used: [DEBUG] (f) headerFile = /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/LICENSE.txt [DEBUG] (f) headerLocation = LICENSE.txt [DEBUG] (f) includes = **/*.java [DEBUG] (f) linkXRef = true [DEBUG] (f) outputDirectory = /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/target/site [DEBUG] (f) outputFile = /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/target/checkstyle-result.xml [DEBUG] (f) outputFileFormat = xml [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) sourceDirectory = /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/src/main/java [DEBUG] (f) xrefLocation = /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/target/site/xref [DEBUG] -- end configuration -- [INFO] [checkstyle:checkstyle] [DEBUG] resolveLocation(/home/devadmin/Tools/EclipseConfig/inuk-checks.xml, checkstyle-checker.xml) [DEBUG] Location is not a URL. [DEBUG] Potential File: /home/devadmin/Tools/EclipseConfig/inuk-checks.xml [DEBUG] resolveLocation(null, checkstyle-checker.properties) [DEBUG] resolveLocation(LICENSE.txt, checkstyle-header.txt) [DEBUG] Location is not a URL. [DEBUG] Location is not a File. [DEBUG] Potential Resource: jar:file:/home/devadmin/maven-2.0.7/lib/maven-core-2.0.7-uber.jar!/LICENSE.txt [DEBUG] resolveLocation(null, checkstyle-packages.xml) [DEBUG] resolveLocation(null, checkstyle-suppressions.xml) -- 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: (MCHECKSTYLE-83) Checkstyle report showing a check as Error when it is Warning
[ http://jira.codehaus.org/browse/MCHECKSTYLE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Lidgey updated MCHECKSTYLE-83: -- Attachment: report.jpg Screenshot snippet of Checkstyle report showing severity as Error, when it is defined as Warning in the file. > Checkstyle report showing a check as Error when it is Warning > - > > Key: MCHECKSTYLE-83 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-83 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ben Lidgey >Priority: Minor > Attachments: inuk-checks.xml, report.jpg > > > Checkstyle report showing a check as Error when it is Warning. > The report is attached as a screenshot, together with the custom checks XML. > The maven output shows the custom file being used: > [DEBUG] (f) headerFile = > /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/LICENSE.txt > [DEBUG] (f) headerLocation = LICENSE.txt > [DEBUG] (f) includes = **/*.java > [DEBUG] (f) linkXRef = true > [DEBUG] (f) outputDirectory = > /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/target/site > [DEBUG] (f) outputFile = > /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/target/checkstyle-result.xml > [DEBUG] (f) outputFileFormat = xml > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) sourceDirectory = > /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/src/main/java > [DEBUG] (f) xrefLocation = > /home/devadmin/data/cruisecontrol/cruisecontrol-bin-2.7.1/projects/InukCommonWSFramework/target/site/xref > [DEBUG] -- end configuration -- > [INFO] [checkstyle:checkstyle] > [DEBUG] resolveLocation(/home/devadmin/Tools/EclipseConfig/inuk-checks.xml, > checkstyle-checker.xml) > [DEBUG] Location is not a URL. > [DEBUG] Potential File: /home/devadmin/Tools/EclipseConfig/inuk-checks.xml > [DEBUG] resolveLocation(null, checkstyle-checker.properties) > [DEBUG] resolveLocation(LICENSE.txt, checkstyle-header.txt) > [DEBUG] Location is not a URL. > [DEBUG] Location is not a File. > [DEBUG] Potential Resource: > jar:file:/home/devadmin/maven-2.0.7/lib/maven-core-2.0.7-uber.jar!/LICENSE.txt > [DEBUG] resolveLocation(null, checkstyle-packages.xml) > [DEBUG] resolveLocation(null, checkstyle-suppressions.xml) -- 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: (MWAR-109) Problem using webResources in configuration
[ http://jira.codehaus.org/browse/MWAR-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120786 ] Den Orlov commented on MWAR-109: Got the same issue. Changed configuration to filter only mxml files (plain text files) and all start fitering correctly. Might be filtering failed due to my resources contained binary files (jpg or gif) > Problem using webResources in configuration > --- > > Key: MWAR-109 > URL: http://jira.codehaus.org/browse/MWAR-109 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.2, 2.1-alpha-1 >Reporter: David Castro > > I have been trying to get web resources into a resources directory where I > can have them copied over during packaging and filtered as necessary. With > 2.0 the targetPath doesn't work. And with 2.0.2 and 2.0.3-SNAPSHOT I can't > seem to configure without it blowing up at all. They both die at the > IOUtil.copy call in AbstractWarMojo > org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) > --- > > org.apache.maven.plugins > maven-war-plugin > 2.0.2 > > > > WEB-INF/spring > true > src/main/resources/WEB-INF/spring > > *.xml > *.properties > > > > > > --- > [INFO] Copy webapp webResources to > /home/arimus/workspace-ym/ym/ym-proj/ym-web/target/myapp > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.maven.project.MavenProject cannot be cast to > java.lang.String > [INFO] > > [INFO] Trace > java.lang.ClassCastException: org.apache.maven.project.MavenProject cannot be > cast to java.lang.String > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269) > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:201) > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162) > at java.io.Reader.read(Reader.java:123) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:415) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:518) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:347) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:164) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was se
[jira] Issue Comment Edited: (MNG-3086) NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
[
http://jira.codehaus.org/browse/MNG-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120793
]
germuska edited comment on MNG-3086 at 1/21/08 11:06 AM:
-
Some more information, although I am still learning my way through M2 code.
Egor, thanks for the idea of adding debug to a local build. For general
information, the above workaround doesn't work with 2.0.9-SNAPSHOT code; the
error doesn't get to that location (although I'm pretty sure it's ultimately
the same error.) I was able to sneak in some debug in
DefaultArtifact.setBaseVersionInternal to catch a null before it throws an NPE:
if ( checkScopeUpdate( farthest, nearest, listeners ) )
{
// if we need to update scope of nearest to use
farthest scope, use the nearest version, but farthest scope
nearest.disable();
if (nearest.getArtifact().getVersion() == null) {
throw new NullPointerException("nearest
artifact has null version so setVersion will error: nearest: " + nearest + ";
farthest: " + farthest);
}
farthest.getArtifact().setVersion(
nearest.getArtifact().getVersion() );
Because now in artifact.setVersion there's a regex Matcher that throws an NPE
if the nearest artifact's version is null.
This happens when the "nearest" artifact is a ranged-version dependency. In
this case, the immediate work-around was to create an explicit dependency on
the "farthest version" AT THE TOP of the list, so that it
overrides the ranged dependency before a transitive dependency resolution runs
into this problem.
This should probably be either filed as a separate bug more directly
implicating ranged transitive dependencies, or the name of this bug should be
changed. If Maven developers need any more info I can try to provide some, but
as much time as I've sunk into tracking this down, I'm short on time to file a
test case at the moment.
was (Author: germuska):
Some more information, although I am still learning my way through M2 code.
Egor, thanks for the idea of adding debug to a local build. For general
information, the above workaround doesn't work with 2.0.9-SNAPSHOT code; the
error doesn't get to that location (although I'm pretty sure it's ultimately
the same error.) I was able to sneak in some debug in
DefaultArtifact.setBaseVersionInternal to catch a null before it throws an NPE:
if ( checkScopeUpdate( farthest, nearest, listeners ) )
{
// if we need to update scope of nearest to use
farthest scope, use the nearest version, but farthest scope
nearest.disable();
if (nearest.getArtifact().getVersion() == null) {
throw new NullPointerException("nearest
artifact has null version so setVersion will error: nearest: " + nearest + ";
farthest: " + farthest);
}
farthest.getArtifact().setVersion(
nearest.getArtifact().getVersion() );
Because now in artifact.setVersion there's a regex Matcher that throws an NPE
if the nearest artifact's version is null.
This happens when the "nearest" artifact is a ranged-version dependency. In
this case, the immediate work-around was to create an explicit dependency on
the same version as "farthest" AT THE TOP of the list, so that
it overrides the ranged dependency before a transitive dependency resolution
runs into this problem.
This should probably be either filed as a separate bug more directly
implicating ranged transitive dependencies, or the name of this bug should be
changed. If Maven developers need any more info I can try to provide some, but
as much time as I've sunk into tracking this down, I'm short on time to file a
test case at the moment.
> NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
>
>
> Key: MNG-3086
> URL: http://jira.codehaus.org/browse/MNG-3086
> Project: Maven 2
> Issue Type: Bug
> Components: Errors
>Affects Versions: 2.0.7
>Reporter: Thomas Leonard
> Fix For: 2.0.x
>
>
> After upgrading from 2.0.6 to 2.0.7, our build fails with:
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache
[jira] Updated: (MPLUGIN-53) Plugin descriptor extractor crashes on certain types of Java source files
[
http://jira.codehaus.org/browse/MPLUGIN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MPLUGIN-53:
-
Attachment: maven-plugin-tools-java-MPLUGIN-53-r613932.patch
It looks like the issue when away with one of the recent changes. I'm
attaching a test case that tests for the issue in case it recurs in the future.
> Plugin descriptor extractor crashes on certain types of Java source files
> -
>
> Key: MPLUGIN-53
> URL: http://jira.codehaus.org/browse/MPLUGIN-53
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Environment: Tested with Maven version 2.0.4, and 2.0.x SNAPSHOT.
>Reporter: Paul Gier
> Attachments: JavaMojoDescriptorExtractor.java,
> JavaMojoDescriptorExtractor.java,
> maven-plugin-tools-java-MPLUGIN-53-r613932.patch
>
>
> Part of my plugin includes a .java file that contains an annotation type
> declaration. It looks like this:
> {quote}
> package org.jboss.lang.annotation;
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.ANNOTATION_TYPE)
> public @interface Inherited {
> }
> {quote}
> When the JavaMojoDescriptorExtractor encounters this file it crashes because
> of an ArrayIndexOutOfBoundsException. Because the code is trying to access
> the 1st element of a zero length array. The attached file has a simple fix
> where the descriptor extractor just ignores any java source file that does
> not contain a valid class.
--
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-3086) NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
[
http://jira.codehaus.org/browse/MNG-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120793
]
Joe Germuska commented on MNG-3086:
---
Some more information, although I am still learning my way through M2 code.
Egor, thanks for the idea of adding debug to a local build. For general
information, the above workaround doesn't work with 2.0.9-SNAPSHOT code; the
error doesn't get to that location (although I'm pretty sure it's ultimately
the same error.) I was able to sneak in some debug in
DefaultArtifact.setBaseVersionInternal to catch a null before it throws an NPE:
if ( checkScopeUpdate( farthest, nearest, listeners ) )
{
// if we need to update scope of nearest to use
farthest scope, use the nearest version, but farthest scope
nearest.disable();
if (nearest.getArtifact().getVersion() == null) {
throw new NullPointerException("nearest
artifact has null version so setVersion will error: nearest: " + nearest + ";
farthest: " + farthest);
}
farthest.getArtifact().setVersion(
nearest.getArtifact().getVersion() );
Because now in artifact.setVersion there's a regex Matcher that throws an NPE
if the nearest artifact's version is null.
This happens when the "nearest" artifact is a ranged-version dependency. In
this case, the immediate work-around was to create an explicit dependency on
the same version as "farthest" AT THE TOP of the list, so that
it overrides the ranged dependency before a transitive dependency resolution
runs into this problem.
This should probably be either filed as a separate bug more directly
implicating ranged transitive dependencies, or the name of this bug should be
changed. If Maven developers need any more info I can try to provide some, but
as much time as I've sunk into tracking this down, I'm short on time to file a
test case at the moment.
> NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
>
>
> Key: MNG-3086
> URL: http://jira.codehaus.org/browse/MNG-3086
> Project: Maven 2
> Issue Type: Bug
> Components: Errors
>Affects Versions: 2.0.7
>Reporter: Thomas Leonard
> Fix For: 2.0.x
>
>
> After upgrading from 2.0.6 to 2.0.7, our build fails with:
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:136)
> at
> org.apache.maven.artifact.resolver.ResolutionNode.filterTrail(ResolutionNode.java:211)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:89)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
> at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(De
[jira] Closed: (MCHANGES-66) The changes plugin scatters white space over its Changes report
[ http://jira.codehaus.org/browse/MCHANGES-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-66. --- Resolution: Fixed Fix Version/s: 2.0-beta-4 I have applied the patch, but I opted not to remove line breaks. Thanks! A new SNAPSHOT has been deployed. Please give a try. > The changes plugin scatters white space over its Changes report > --- > > Key: MCHANGES-66 > URL: http://jira.codehaus.org/browse/MCHANGES-66 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Reporter: Henning Schmiedehausen >Assignee: Dennis Lundberg > Fix For: 2.0-beta-4 > > Attachments: changes-report.html, changes.xml, changes4.patch, > changes7.patch, MCHANGES-66.zip, sax-parsing.patch > > > The changelog plugin reads the contents of the changes.xml file and scatters > \n characters into it. The attached patch fixes this and also improves > performance by using a string buffer. -- 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] Issue Comment Edited: (MPLUGIN-53) Plugin descriptor extractor crashes on certain types of Java source files
[
http://jira.codehaus.org/browse/MPLUGIN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120794
]
pgier edited comment on MPLUGIN-53 at 1/21/08 2:00 PM:
---
It looks like the issue went away with one of the recent changes. I'm
attaching a test case that tests for the issue in case it recurs in the future.
was (Author: pgier):
It looks like the issue when away with one of the recent changes. I'm
attaching a test case that tests for the issue in case it recurs in the future.
> Plugin descriptor extractor crashes on certain types of Java source files
> -
>
> Key: MPLUGIN-53
> URL: http://jira.codehaus.org/browse/MPLUGIN-53
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Environment: Tested with Maven version 2.0.4, and 2.0.x SNAPSHOT.
>Reporter: Paul Gier
> Attachments: JavaMojoDescriptorExtractor.java,
> JavaMojoDescriptorExtractor.java,
> maven-plugin-tools-java-MPLUGIN-53-r613932.patch
>
>
> Part of my plugin includes a .java file that contains an annotation type
> declaration. It looks like this:
> {quote}
> package org.jboss.lang.annotation;
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.ANNOTATION_TYPE)
> public @interface Inherited {
> }
> {quote}
> When the JavaMojoDescriptorExtractor encounters this file it crashes because
> of an ArrayIndexOutOfBoundsException. Because the code is trying to access
> the 1st element of a zero length array. The attached file has a simple fix
> where the descriptor extractor just ignores any java source file that does
> not contain a valid class.
--
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-2431) Make it possible to specify that version should be the LATEST STABLE available
[ http://jira.codehaus.org/browse/MNG-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120828 ] Michael McCallum commented on MNG-2431: --- In order to have a stable system you MUST understand what the latest release means... if you introduce this into your build you have no control over what actually ends up in it. As an end user this is not a huge deal direct except when people start using release in libraries in the main repositories you end up using the latest released code of every project and the shit hits the fan i vote a big -1 for this > Make it possible to specify that version should be the LATEST STABLE available > -- > > Key: MNG-2431 > URL: http://jira.codehaus.org/browse/MNG-2431 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Jimisola Laursen > Fix For: Reviewed Pending Version Assignment > > > Hi! > I've been looking for a way to specify that the latest STABLE version of a > library (dependency) should be used automatically. However, I can't seem to > find any information on this. Is this not possible? The "Dependency Version > Ranges" doesn't solve the problem for me since it sets with the lowest > version satisfying the range. > This guy had the same question about a year ago, but it doesn't look > promising: > http://www.nabble.com/newbie-ques%3A-downloading-latest-stable-jars-t74577.html#a202750 > I asked the same question is this thread: > http://www.nabble.com/How-to-get-the-latest-STABLE-version-of-a-library-dependency-automatical-tf1851718.html -- 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-2431) Make it possible to specify that version should be the LATEST STABLE available
[ http://jira.codehaus.org/browse/MNG-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120830 ] Wayne Fay commented on MNG-2431: We've talked about this on the User list multiple times. Its just a bad idea. The "latest stable" version of something is not a reproducible element. > Make it possible to specify that version should be the LATEST STABLE available > -- > > Key: MNG-2431 > URL: http://jira.codehaus.org/browse/MNG-2431 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Jimisola Laursen > Fix For: Reviewed Pending Version Assignment > > > Hi! > I've been looking for a way to specify that the latest STABLE version of a > library (dependency) should be used automatically. However, I can't seem to > find any information on this. Is this not possible? The "Dependency Version > Ranges" doesn't solve the problem for me since it sets with the lowest > version satisfying the range. > This guy had the same question about a year ago, but it doesn't look > promising: > http://www.nabble.com/newbie-ques%3A-downloading-latest-stable-jars-t74577.html#a202750 > I asked the same question is this thread: > http://www.nabble.com/How-to-get-the-latest-STABLE-version-of-a-library-dependency-automatical-tf1851718.html -- 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-2431) Make it possible to specify that version should be the LATEST STABLE available
[ http://jira.codehaus.org/browse/MNG-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120832 ] David J. M. Karlsen commented on MNG-2431: -- Dependency ranges shold be sufficient for this. > Make it possible to specify that version should be the LATEST STABLE available > -- > > Key: MNG-2431 > URL: http://jira.codehaus.org/browse/MNG-2431 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Jimisola Laursen > Fix For: Reviewed Pending Version Assignment > > > Hi! > I've been looking for a way to specify that the latest STABLE version of a > library (dependency) should be used automatically. However, I can't seem to > find any information on this. Is this not possible? The "Dependency Version > Ranges" doesn't solve the problem for me since it sets with the lowest > version satisfying the range. > This guy had the same question about a year ago, but it doesn't look > promising: > http://www.nabble.com/newbie-ques%3A-downloading-latest-stable-jars-t74577.html#a202750 > I asked the same question is this thread: > http://www.nabble.com/How-to-get-the-latest-STABLE-version-of-a-library-dependency-automatical-tf1851718.html -- 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-2431) Make it possible to specify that version should be the LATEST STABLE available
[ http://jira.codehaus.org/browse/MNG-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120833 ] David Hoffer commented on MNG-2431: --- What do you mean by 'latest STABLE version of a library"? If you mean latest released version this is what version ranges is supposed to be for. It does bring the latest version into your build, the trouble with it is that it will also consider snapshots to be valid which is a documented bug, see MNG-3092. > Make it possible to specify that version should be the LATEST STABLE available > -- > > Key: MNG-2431 > URL: http://jira.codehaus.org/browse/MNG-2431 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Jimisola Laursen > Fix For: Reviewed Pending Version Assignment > > > Hi! > I've been looking for a way to specify that the latest STABLE version of a > library (dependency) should be used automatically. However, I can't seem to > find any information on this. Is this not possible? The "Dependency Version > Ranges" doesn't solve the problem for me since it sets with the lowest > version satisfying the range. > This guy had the same question about a year ago, but it doesn't look > promising: > http://www.nabble.com/newbie-ques%3A-downloading-latest-stable-jars-t74577.html#a202750 > I asked the same question is this thread: > http://www.nabble.com/How-to-get-the-latest-STABLE-version-of-a-library-dependency-automatical-tf1851718.html -- 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: (MPLUGIN-67) Document somewhere the minimum version of maven required by the plugin
Document somewhere the minimum version of maven required by the plugin -- Key: MPLUGIN-67 URL: http://jira.codehaus.org/browse/MPLUGIN-67 Project: Maven 2.x Plugin Tools Issue Type: Improvement Affects Versions: 2.3 Reporter: Arnaud Heritier When a plugin is designed for a minimal version of maven this information isn't documented on the web site. It is important to have this information to know if we can upgrade it or not on a given version of maven. A cool thing could be to have an history of this compatibility to know which is the last version available for a given version of maven's core. -- 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: (MCHANGES-66) The changes plugin scatters white space over its Changes report
[ http://jira.codehaus.org/browse/MCHANGES-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120838 ] Henning Schmiedehausen commented on MCHANGES-66: 51 weeks and one day after the initial bug report, a new snapshot has been deployed. I'm really impressed. > The changes plugin scatters white space over its Changes report > --- > > Key: MCHANGES-66 > URL: http://jira.codehaus.org/browse/MCHANGES-66 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Reporter: Henning Schmiedehausen >Assignee: Dennis Lundberg > Fix For: 2.0-beta-4 > > Attachments: changes-report.html, changes.xml, changes4.patch, > changes7.patch, MCHANGES-66.zip, sax-parsing.patch > > > The changelog plugin reads the contents of the changes.xml file and scatters > \n characters into it. The attached patch fixes this and also improves > performance by using a string buffer. -- 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: (MCHANGES-66) The changes plugin scatters white space over its Changes report
[ http://jira.codehaus.org/browse/MCHANGES-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120839 ] Dennis Lundberg commented on MCHANGES-66: - That's an utterly disrespectful thing to say. > The changes plugin scatters white space over its Changes report > --- > > Key: MCHANGES-66 > URL: http://jira.codehaus.org/browse/MCHANGES-66 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Reporter: Henning Schmiedehausen >Assignee: Dennis Lundberg > Fix For: 2.0-beta-4 > > Attachments: changes-report.html, changes.xml, changes4.patch, > changes7.patch, MCHANGES-66.zip, sax-parsing.patch > > > The changelog plugin reads the contents of the changes.xml file and scatters > \n characters into it. The attached patch fixes this and also improves > performance by using a string buffer. -- 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: (MCHANGES-66) The changes plugin scatters white space over its Changes report
[ http://jira.codehaus.org/browse/MCHANGES-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120844 ] Benjamin Bentmann commented on MCHANGES-66: --- bq. 51 weeks and one day after the initial bug report, a new snapshot has been deployed. Henning, how many weeks have passed since Dennis asked you to provide a changes.xml to nail the issue down? I guess you had something better to do, just like the committers. This issue has just one vote and there are lots of other, higher voted issues waiting to be investigated and solved. > The changes plugin scatters white space over its Changes report > --- > > Key: MCHANGES-66 > URL: http://jira.codehaus.org/browse/MCHANGES-66 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Reporter: Henning Schmiedehausen >Assignee: Dennis Lundberg > Fix For: 2.0-beta-4 > > Attachments: changes-report.html, changes.xml, changes4.patch, > changes7.patch, MCHANGES-66.zip, sax-parsing.patch > > > The changelog plugin reads the contents of the changes.xml file and scatters > \n characters into it. The attached patch fixes this and also improves > performance by using a string buffer. -- 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: (MCHANGES-94) Add option to configure the sort order of the JIRA report
[
http://jira.codehaus.org/browse/MCHANGES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHANGES-94:
Description:
Would be nice to be able to specify what order the columns are sorted in.
Attaching a patch to do this which adds new configuration parameter -
sortColumnNames. This is a comma separated list and appending "DESC" specifies
"descending" order - so for example to sort by "Fix Version" in descending
sequence and then "Issue Key" in ascending sequence you would configure the
following:
{code:xml}
Fix Version DESC, Type, Key
{code}
was:
Would be nice to be able to specify what order the columns are sorted in.
Attaching a patch to do this which adds new configuration parameter -
sortColumnNames. This is a comma separated list and appending "DESC" specifies
"descending" order - so for example to sort by "Fix Version" in descending
sequence and then "Issue Key" in ascending sequence you would configure the
following:
Fix Version DESC, Type, Key
Summary: Add option to configure the sort order of the JIRA report
(was: Add option to configure the sort order of te JIRA report)
> Add option to configure the sort order of the JIRA report
> -
>
> Key: MCHANGES-94
> URL: http://jira.codehaus.org/browse/MCHANGES-94
> Project: Maven 2.x Changes Plugin
> Issue Type: Improvement
> Components: jira-report
>Affects Versions: 2.0-beta-3
>Reporter: Niall Pemberton
>Priority: Minor
> Attachments: maven-changes-jira-report-sort-config.patch
>
>
> Would be nice to be able to specify what order the columns are sorted in.
> Attaching a patch to do this which adds new configuration parameter -
> sortColumnNames. This is a comma separated list and appending "DESC"
> specifies "descending" order - so for example to sort by "Fix Version" in
> descending sequence and then "Issue Key" in ascending sequence you would
> configure the following:
> {code:xml}
>
> Fix Version DESC, Type, Key
>
> {code}
--
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: (MCHANGES-94) Add option to configure the sort order of the JIRA report
[
http://jira.codehaus.org/browse/MCHANGES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGES-94.
---
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.0-beta-4
Patch applied with modifications. Thanks!
A new SNAPSHOT has been deployed.
> Add option to configure the sort order of the JIRA report
> -
>
> Key: MCHANGES-94
> URL: http://jira.codehaus.org/browse/MCHANGES-94
> Project: Maven 2.x Changes Plugin
> Issue Type: Improvement
> Components: jira-report
>Affects Versions: 2.0-beta-3
>Reporter: Niall Pemberton
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.0-beta-4
>
> Attachments: maven-changes-jira-report-sort-config.patch
>
>
> Would be nice to be able to specify what order the columns are sorted in.
> Attaching a patch to do this which adds new configuration parameter -
> sortColumnNames. This is a comma separated list and appending "DESC"
> specifies "descending" order - so for example to sort by "Fix Version" in
> descending sequence and then "Issue Key" in ascending sequence you would
> configure the following:
> {code:xml}
>
> Fix Version DESC, Type, Key
>
> {code}
--
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: (SUREFIRE-432) Surefire swallows redirected test output if uncaught exceptions occur in forked SurefireBooter
[
http://jira.codehaus.org/browse/SUREFIRE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated SUREFIRE-432:
---
Attachment: testng-execute-error.patch
Fixed IT patch, contained duplicate contents.
> Surefire swallows redirected test output if uncaught exceptions occur in
> forked SurefireBooter
> --
>
> Key: SUREFIRE-432
> URL: http://jira.codehaus.org/browse/SUREFIRE-432
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.4
> Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
>Reporter: Benjamin Bentmann
> Attachments: file-output-consumer-proxy-close.patch,
> testng-execute-error.patch, testng-execute-error.patch,
> testng-execute-error.patch
>
>
> If Surefire
> - forks a test and
> - is configured to redirect test output to a file and
> - encounters an uncaught exception in its internals
> the tests fail (as expected) but the user does not get any information about
> the error, i.e. the txt files under target/surefire-reports are of zero
> length. This can be quite fustrating.
> Attached is an integration test which produces the following exception:
> {noformat}
> java.lang.reflect.InvocationTargetException
> 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:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:334)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:980)
> Caused by: org.testng.TestNGException:
> Cyclic graph of methods
> at org.testng.internal.Graph.topologicalSort(Graph.java:117)
> at
> org.testng.internal.MethodHelper.topologicalSort(MethodHelper.java:494)
> at org.testng.internal.MethodHelper.sortMethods(MethodHelper.java:544)
> at
> org.testng.internal.MethodHelper.internalCollectAndOrderMethods(MethodHelper.java:77)
> at
> org.testng.internal.MethodHelper.collectAndOrderMethods(MethodHelper.java:49)
> at org.testng.TestRunner.initMethods(TestRunner.java:337)
> at org.testng.TestRunner.init(TestRunner.java:216)
> at org.testng.TestRunner.init(TestRunner.java:178)
> at org.testng.TestRunner.(TestRunner.java:127)
> at
> org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:454)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:235)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:64)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:136)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> ... 6 more
> {noformat}
> This uncaught exception causes abnormal completion of Surefire.run() such
> that reporterManager.runCompleted() never gets called. Without the call the
> runCompleted(), Reporter.writeFooter() gets never called, too. This means
> ForkingStreamConsumer.consumeLine() will never call
> OutputConsumer.testSetCompleted(). However, the later call would be required
> to properly flush the FileWriter employed by FileOutputConsumerProxy.
> I think what is needed is a means in SurefireBooter.fork() to flush/close the
> StreamConsumers after the call to CommandLineUtils.executeCommandLine()
> returned.
--
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: (SUREFIRE-428) Add integration test to check class path order
[ http://jira.codehaus.org/browse/SUREFIRE-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated SUREFIRE-428: --- Attachment: classpath-order-it.patch Fixed IT patch, contained duplicate contents. > Add integration test to check class path order > -- > > Key: SUREFIRE-428 > URL: http://jira.codehaus.org/browse/SUREFIRE-428 > Project: Maven Surefire > Issue Type: Task >Reporter: Benjamin Bentmann > Attachments: classpath-order-it.patch, classpath-order-it.patch > > > The attached integration test checks some ordering constraints on the class > path for testing: > - test-classes should come before main-classes > - main-classes should come before dependencies > It might not catch all bad cases but currently there seems to be nothing that > prevents regression of MNG-3118 or SUREFIRE-61 and this test at least tells > you that Surefire-2.3 is broken. > In concern of quality assurance, I would also like to mention that MNG-2365 > has an unapplied patch that provides a unit test for MNG-3118. -- 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: (MCHANGES-95) Add german translation
[ http://jira.codehaus.org/browse/MCHANGES-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120851 ] Dennis Lundberg commented on MCHANGES-95: - I've fixed the two issues that you pointed out Benjamin. Would you mind creating a new patch that includes the new keys that were added to the JIRA report in MCHANGES-92. My technical German is not good enough :-) > Add german translation > -- > > Key: MCHANGES-95 > URL: http://jira.codehaus.org/browse/MCHANGES-95 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: changes-report, jira-report >Affects Versions: 2.0-beta-3 >Reporter: Benjamin Bentmann >Priority: Trivial > Attachments: i18n-de.patch > > > Teaching the report another language. > BTW, the key "report.changes.error" seems to be unused and could be deleted. > The key "report.changes.warn.url" seems to be used only for a log > statement... Unless you intend to consistently use i18n for log message, this > key should be deleted as well. -- 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: (MEV-570) groupId org.freemarker and freemarker refer to the same product
[ http://jira.codehaus.org/browse/MEV-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-570. -- Assignee: Carlos Sanchez Resolution: Won't Fix you need to use exclusions in your pom if you see that behavior the repository is provided by the project and if they decide to move to a new groupId is something between you and them and thier upgrade instructions for new versions > groupId org.freemarker and freemarker refer to the same product > --- > > Key: MEV-570 > URL: http://jira.codehaus.org/browse/MEV-570 > Project: Maven Evangelism > Issue Type: Bug > Components: Relocation >Reporter: Al Sutton >Assignee: Carlos Sanchez > > Both org.freemarker and freemarker refer to the same product (the freemarker > template library), having two different groupIDs for the same product creates > the possibility for multiple jars of the same product to be included in a > compile and run classpath. > This has been seen in Struts2 where we had 2.3.4 from groupID freemarker from > a dependancy, and 2.3.11 from org.freemarker in our pom. > One needs to go and a redirect put in place inorder to ensure consistency. -- 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: (MEV-571) velocity and org.apache.velocity refer to the same product
[ http://jira.codehaus.org/browse/MEV-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-571. -- Assignee: Carlos Sanchez Resolution: Won't Fix you need to use exclusions in your pom if you see that behavior the repository is provided by the project and if they decide to move to a new groupId is something between you and them and thier upgrade instructions for new versions > velocity and org.apache.velocity refer to the same product > -- > > Key: MEV-571 > URL: http://jira.codehaus.org/browse/MEV-571 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Al Sutton >Assignee: Carlos Sanchez > > Both groupIds org.apache.velocity and velocity refer to the same product (the > velocity template engine), having two different groupIDs for the same product > creates the possibility for multiple jars of the same product to be included > in a compile and run classpath. > This has been seen in Struts2 where we had 1.4 from groupID velocity from a > dependancy, and 1.5 from org.apache.velocity in our pom. > One needs to go and a redirect put in place inorder to ensure correct > dependancy resolution. -- 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: (WAGON-86) add timeout to HttpUtils/wagon
[ http://jira.codehaus.org/browse/WAGON-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James William Dumay updated WAGON-86: - Attachment: WAGON-86.patch > add timeout to HttpUtils/wagon > -- > > Key: WAGON-86 > URL: http://jira.codehaus.org/browse/WAGON-86 > Project: wagon > Issue Type: Improvement >Reporter: Brett Porter >Priority: Minor > Attachments: WAGON-86.patch > > > in httputils (and heavyweight http wagon), add a configurable timeout for > requests. -- 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: (WAGON-86) add timeout to HttpUtils/wagon
[ http://jira.codehaus.org/browse/WAGON-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120857 ] James William Dumay commented on WAGON-86: -- Implementation of timeouts on wagon. Could not be implemented for lightweight http provider since setConnectionTimeout is a >= JDK 1.5 method on UrlConnection. > add timeout to HttpUtils/wagon > -- > > Key: WAGON-86 > URL: http://jira.codehaus.org/browse/WAGON-86 > Project: wagon > Issue Type: Improvement >Reporter: Brett Porter >Priority: Minor > Attachments: WAGON-86.patch > > > in httputils (and heavyweight http wagon), add a configurable timeout for > requests. -- 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: (MEV-570) groupId org.freemarker and freemarker refer to the same product
[ http://jira.codehaus.org/browse/MEV-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120858 ] Wendy Smoak commented on MEV-570: - The artifacts in the 'freemarker' group need to be relocated in the repository. Will you accept relocation poms from someone who is not a developer of the project, or would we need to get their cooperation/approval? > groupId org.freemarker and freemarker refer to the same product > --- > > Key: MEV-570 > URL: http://jira.codehaus.org/browse/MEV-570 > Project: Maven Evangelism > Issue Type: Bug > Components: Relocation >Reporter: Al Sutton >Assignee: Carlos Sanchez > > Both org.freemarker and freemarker refer to the same product (the freemarker > template library), having two different groupIDs for the same product creates > the possibility for multiple jars of the same product to be included in a > compile and run classpath. > This has been seen in Struts2 where we had 2.3.4 from groupID freemarker from > a dependancy, and 2.3.11 from org.freemarker in our pom. > One needs to go and a redirect put in place inorder to ensure consistency. -- 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: (MEV-570) groupId org.freemarker and freemarker refer to the same product
[ http://jira.codehaus.org/browse/MEV-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120859 ] Carlos Sanchez commented on MEV-570: it's not that trivial, if you put relocation poms for old releases you can break builds, that's why old things don't get changed (we had this discussion before for commons and they decided not to do it). If struts adds the appropriate exclusion then it's going to be transparent for all struts users. For reference see MAVENUPLOAD-1419 > groupId org.freemarker and freemarker refer to the same product > --- > > Key: MEV-570 > URL: http://jira.codehaus.org/browse/MEV-570 > Project: Maven Evangelism > Issue Type: Bug > Components: Relocation >Reporter: Al Sutton >Assignee: Carlos Sanchez > > Both org.freemarker and freemarker refer to the same product (the freemarker > template library), having two different groupIDs for the same product creates > the possibility for multiple jars of the same product to be included in a > compile and run classpath. > This has been seen in Struts2 where we had 2.3.4 from groupID freemarker from > a dependancy, and 2.3.11 from org.freemarker in our pom. > One needs to go and a redirect put in place inorder to ensure consistency. -- 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: (MEV-570) groupId org.freemarker and freemarker refer to the same product
[ http://jira.codehaus.org/browse/MEV-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120862 ] Al Sutton commented on MEV-570: --- I'm not familiar with the Maven codebase, but haven't you got (or couldn't you add) add a redirect from one groupId to another? For example, is it not possible to create a file (e.g. .maven_groupId_alias) in /freemarker in the repository which contains; groupId: org.freemarker which would tell any clients trying to connect to the /freemarker groupId that it should use the org.freemarker groupId? > groupId org.freemarker and freemarker refer to the same product > --- > > Key: MEV-570 > URL: http://jira.codehaus.org/browse/MEV-570 > Project: Maven Evangelism > Issue Type: Bug > Components: Relocation >Reporter: Al Sutton >Assignee: Carlos Sanchez > > Both org.freemarker and freemarker refer to the same product (the freemarker > template library), having two different groupIDs for the same product creates > the possibility for multiple jars of the same product to be included in a > compile and run classpath. > This has been seen in Struts2 where we had 2.3.4 from groupID freemarker from > a dependancy, and 2.3.11 from org.freemarker in our pom. > One needs to go and a redirect put in place inorder to ensure consistency. -- 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
