[jira] Issue Comment Edited: (MWAR-249) War plugin doesn't let modify the contents of the exploded directory
[ http://jira.codehaus.org/browse/MWAR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256095#action_256095 ] cem koc edited comment on MWAR-249 at 2/15/11 2:00 AM: --- But there is a two different behaviour between different versions of the war plugin. For example, this behaviour was different in 2.1-beta-1. If you modify war plugin version of the pom.xml, you can easily see that war plugin does not touch modified files. Please let me know after trying since this issue is a serious block for us for updating our war plugin. In many of our projects we are using such kind of pre-processing before package phase. Thanks was (Author: cem koc): But there is a two different behaviour between different versions of the war plugin. For example, this behaviour was different in 2.1-beta-1. If you modify war plugin version of the pom.xml, you can easily see that war plugin does not touch modified files. War plugin doesn't let modify the contents of the exploded directory -- Key: MWAR-249 URL: http://jira.codehaus.org/browse/MWAR-249 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1, 2.2 Environment: maven 3 Reporter: cem koc Attachments: Test.zip Shortly I am trying to modify the contents of the exploded directory before package phase. I was successfully modifying contents of the exploded directories before updating my war plugin. My goal was 1) Creating an exploded directory of the sources. 2) Modifying contents with Replace plugin 3) Creating a war file including modified files To recreate issue, *) mvn clean prepare-package -- This will create as expected file. *) mvn clean package -- This will replace again modified file with old one. Thanks -- 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: (MRELEASE-653) Filter reactor projects that are concerned by a submodule branch operation
Filter reactor projects that are concerned by a submodule branch operation
--
Key: MRELEASE-653
URL: http://jira.codehaus.org/browse/MRELEASE-653
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.1
Reporter: Lucien Weller
Attachments: filter-modules.patch
We have the requirement to create a separate branch of one submodule when
releasing the entire project. We solved this with the follwoing config in
pom.xml of concerned submodule:
profile
idbranchSubModule/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
inheritedfalse/inherited
executions
execution
idexplorer-branch/id
inheritedfalse/inherited
phasepackage/phase
goals
goalbranch/goal
/goals
configuration
branchNamere${project.version}-submodule/branchName
developmentVersion${project.version}/developmentVersion
updateBranchVersionstrue/updateBranchVersions
releaseVersion${project.version}-00-SNAPSHOT/releaseVersion
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
We launch the release build of parent project with:
mvn release:prepare release:perform -DreleaseProfiles=branchSubModule
Beside issue adressed by MRELEASE-619, we also face the problem that all
submodules are affected when our special submodule gets branched.
We solved this issue by filtering reactor projects with the current working
path.
--
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: (MSHARED-187) Added option to execute a maven build with alsoMake and alsoMakeDependents
Added option to execute a maven build with alsoMake and alsoMakeDependents -- Key: MSHARED-187 URL: http://jira.codehaus.org/browse/MSHARED-187 Project: Maven Shared Components Issue Type: Improvement Components: maven-invoker Affects Versions: maven-invoker 2.0.11 Reporter: Lucien Weller Attachments: also-make.patch Added possibility to create a build request with alsoMake and alsoMakeDependents options. -- 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: (DOXIASITETOOLS-53) SiteRender generates double anchors for section headers
SiteRender generates double anchors for section headers --- Key: DOXIASITETOOLS-53 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-53 Project: Maven Doxia Sitetools Issue Type: Bug Components: Site renderer Affects Versions: 1.1.4 Reporter: SebbASF The SiteRenderer adds anchors to section headers, even if they have already been added. See http://jira.codehaus.org/browse/DOXIA-420 which has examples of double-anchors on the Maven site. -- 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-420) 1.1 is not supposed to generate anchors for section titles, but it does
[
http://jira.codehaus.org/browse/DOXIA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256118#action_256118
]
SebbASF commented on DOXIA-420:
---
In that case. there is a bug in the SiteRenderer - it should not add the extra
anchors. Issue created.
1.1 is not supposed to generate anchors for section titles, but it does
---
Key: DOXIA-420
URL: http://jira.codehaus.org/browse/DOXIA-420
Project: Maven Doxia
Issue Type: Bug
Components: Module - Apt
Affects Versions: 1.1.4
Reporter: SebbASF
According to
http://maven.apache.org/doxia/references/doxia-apt.html#Anchors_for_section_titles
Contrary to the original APT format, section titles are not implicitly
defined anchors. If you want an anchor for a section title you need to define
it explicitly as such:
However, Doxia *does* generate anchors for section headers.
This is clear from the URL above; the underlying HTML is:
h4a name=Anchors_for_section_titlesAnchors for section titles/aa
name=Anchors_for_section_titles/a/h4
Compare with the code for
http://maven.apache.org/doxia/references/doxia-apt.html#Enhancements_to_the_APT_format
at the top of the page, and then compare with the APT source:
http://svn.apache.org/viewvc/maven/doxia/site/src/site/apt/references/doxia-apt.apt?revision=985438view=markup
which does not have {} round the initial section header, yet the anchor is
still generated.
Headers with {} around them have 2 anchors.
--
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: (DOXIASITETOOLS-53) SiteRender generates double anchors for section headers
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256119#action_256119 ] SebbASF commented on DOXIASITETOOLS-53: --- It ought to be possible to suppress unwanted anchors. Doxia itself does not auto-generate them, so the SiteRenderer should be configurable too. Since some people may be relying on the auto-generation, I think the behaviour should be changed as follows: 1) Don't generate a second anchor, ever. 2) Optionally, suppress generation of anchors for section headers. SiteRender generates double anchors for section headers --- Key: DOXIASITETOOLS-53 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-53 Project: Maven Doxia Sitetools Issue Type: Bug Components: Site renderer Affects Versions: 1.1.4 Reporter: SebbASF The SiteRenderer adds anchors to section headers, even if they have already been added. See http://jira.codehaus.org/browse/DOXIA-420 which has examples of double-anchors on the Maven site. -- 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-555) site:clean option to clear out target/site directories
[ http://jira.codehaus.org/browse/MSITE-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256120#action_256120 ] SebbASF commented on MSITE-555: --- In that case, it would be all the more useful to have a clean option to take care of all these additional directories. site:clean option to clear out target/site directories -- Key: MSITE-555 URL: http://jira.codehaus.org/browse/MSITE-555 Project: Maven 2.x and 3.x Site Plugin Issue Type: New Feature Reporter: SebbASF It would be useful to have a simple method of cleaning out target/site directories. This would help when testing skins to ensure that the correct images etc are installed, but would also help when rebuilding, as site:site skips some rebuilds if the files already exist. By default it should clear all the contents of each target/site, but it might be useful to be able to exclude certain subdirectories (e.g. apidocs). -- 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: (MWAR-249) War plugin doesn't let modify the contents of the exploded directory
[
http://jira.codehaus.org/browse/MWAR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256124#action_256124
]
cem koc edited comment on MWAR-249 at 2/15/11 6:16 AM:
---
Hi,
It seems that default configuration of the war plugin changed. To make expected
behaviour as in this example cache parameter should be activated.
{code:xml}
plugin
artifactIdmaven-war-plugin/artifactId
version2.1.1/version
executions
execution
phasegenerate-resources/phase
goals
goalexploded/goal
/goals
/execution
/executions
configuration
useCachetrue/useCache
/configuration
/plugin
{code}
By the way at maven mail list Marc helped me to solve this problem.
http://maven.40175.n5.nabble.com/War-plugin-2-1-beta-1-problem-td3384365.html#a3385808
was (Author: cem koc):
Hi,
It seems that default configuration of the war plugin changed. To make expected
behaviour as in this example cache parameter should be activated.
{code:xml}
plugin
artifactIdmaven-war-plugin/artifactId
version2.1.1/version
executions
execution
phasegenerate-resources/phase
goals
goalexploded/goal
/goals
/execution
/executions
configuration
useCachetrue/useCache
/configuration
/plugin
{code}
By the way at maven mail list Marc helped me to solve this problem.
http://maven.40175.n5.nabble.com/War-plugin-2-1-beta-1-problem-td3384365.html#a3385808
War plugin doesn't let modify the contents of the exploded directory
--
Key: MWAR-249
URL: http://jira.codehaus.org/browse/MWAR-249
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: maven 3
Reporter: cem koc
Attachments: Test.zip
Shortly I am trying to modify the contents of the exploded directory before
package phase. I was successfully modifying contents of the exploded
directories before updating my war plugin.
My goal was
1) Creating an exploded directory of the sources.
2) Modifying contents with Replace plugin
3) Creating a war file including modified files
To recreate issue,
*) mvn clean prepare-package -- This will create as expected file.
*) mvn clean package -- This will replace again modified file with old one.
Thanks
--
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-249) War plugin doesn't let modify the contents of the exploded directory
[
http://jira.codehaus.org/browse/MWAR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256124#action_256124
]
cem koc commented on MWAR-249:
--
Hi,
It seems that default configuration of the war plugin changed. To make expected
behaviour as in this example cache parameter should be activated.
{code:xml}
plugin
artifactIdmaven-war-plugin/artifactId
version2.1.1/version
executions
execution
phasegenerate-resources/phase
goals
goalexploded/goal
/goals
/execution
/executions
configuration
useCachetrue/useCache
/configuration
/plugin
{code}
By the way at maven mail list Marc helped me to solve this problem.
http://maven.40175.n5.nabble.com/War-plugin-2-1-beta-1-problem-td3384365.html#a3385808
War plugin doesn't let modify the contents of the exploded directory
--
Key: MWAR-249
URL: http://jira.codehaus.org/browse/MWAR-249
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: maven 3
Reporter: cem koc
Attachments: Test.zip
Shortly I am trying to modify the contents of the exploded directory before
package phase. I was successfully modifying contents of the exploded
directories before updating my war plugin.
My goal was
1) Creating an exploded directory of the sources.
2) Modifying contents with Replace plugin
3) Creating a war file including modified files
To recreate issue,
*) mvn clean prepare-package -- This will create as expected file.
*) mvn clean package -- This will replace again modified file with old one.
Thanks
--
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-249) War plugin doesn't let modify the contents of the exploded directory
[ http://jira.codehaus.org/browse/MWAR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256125#action_256125 ] Stephane Nicoll commented on MWAR-249: -- I don't see what the useCache parameter has anything to do with this. War plugin doesn't let modify the contents of the exploded directory -- Key: MWAR-249 URL: http://jira.codehaus.org/browse/MWAR-249 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1, 2.2 Environment: maven 3 Reporter: cem koc Attachments: Test.zip Shortly I am trying to modify the contents of the exploded directory before package phase. I was successfully modifying contents of the exploded directories before updating my war plugin. My goal was 1) Creating an exploded directory of the sources. 2) Modifying contents with Replace plugin 3) Creating a war file including modified files To recreate issue, *) mvn clean prepare-package -- This will create as expected file. *) mvn clean package -- This will replace again modified file with old one. Thanks -- 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-249) War plugin doesn't let modify the contents of the exploded directory
[ http://jira.codehaus.org/browse/MWAR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256135#action_256135 ] cem koc commented on MWAR-249: -- Without use cache directive, war plugin is replacing modified files which are modified at another phase. Use cache is protecting files which are modified at another phases. Without use cache 1) Copy files with war:exploded 2) Modify them with replace plugin 3) Replace all files at target folder with war:war at package phase. this is completely deleting modified files with are enhanced with another plugin With use cache 1) Copy files with war:exploded 2) Modify them with replace plugin 3) War:war without deleting modified files And as a result of this, It lets us for pre-processing before package phase at exploded folder. War plugin doesn't let modify the contents of the exploded directory -- Key: MWAR-249 URL: http://jira.codehaus.org/browse/MWAR-249 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1, 2.2 Environment: maven 3 Reporter: cem koc Attachments: Test.zip Shortly I am trying to modify the contents of the exploded directory before package phase. I was successfully modifying contents of the exploded directories before updating my war plugin. My goal was 1) Creating an exploded directory of the sources. 2) Modifying contents with Replace plugin 3) Creating a war file including modified files To recreate issue, *) mvn clean prepare-package -- This will create as expected file. *) mvn clean package -- This will replace again modified file with old one. Thanks -- 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-373) Macro snippet with file option in a multi-pom project
[
http://jira.codehaus.org/browse/DOXIA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256138#action_256138
]
tischda commented on DOXIA-373:
---
I'm getting the file to parse from the target directory, in my index.apt.vm:
%{snippet|id=maven-local-repo|file=${project.build.outputDirectory}/settings.xml}
Now if I add a trailing space after the closing brace of the snippet macro, it
fails the first time. The second time, the build succeeds but the index.html is
empty. Remove the space, clean build and it works again.
Macro snippet with file option in a multi-pom project
-
Key: DOXIA-373
URL: http://jira.codehaus.org/browse/DOXIA-373
Project: Maven Doxia
Issue Type: Bug
Environment: Window XP
Reporter: poulfich
Fix For: 1.2
The project is a multi pom project. In the main pom project, I declare the
other pom like this :
modules
module../moduleA/module
module../moduleB/module
...
/modules
To avoid duplicate code,I use the macro snippet in my documentation in
modules A, B and Main. For convenient, the following syntax :
%{snippet|id=myid|file=src/main/java/mypackage/File.java}.
When I build the site from each module A or B, all work fine. But when the
site was generated from the main module, the snippet seem not work : All the
pages who include a snippet's macros in A or B are not generated. I obtain
the same problem if i do a simple site or a site:stage
The maven site work fine work include pictures and schemas of local
documentation (in A et B). I try to use
the velocity macro and transform MyFile.apt to MyFile.apt.vm like these :
MyFile.apt.vm
%{snippet|id=myid|file=${basedir}/src/main/java/mypackage/File.java}.
It's fail too.
I use maven 2.1.0
Sorry for my poor english
--
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: (MCOMPILER-149) Java compiler warning is masking a javac exception, which the compiler plugin doesn't know how to parse
Java compiler warning is masking a javac exception, which the compiler plugin doesn't know how to parse --- Key: MCOMPILER-149 URL: http://jira.codehaus.org/browse/MCOMPILER-149 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Windows XP SP3, Java 1.6.0_17, Maven 2.0.8 Reporter: David Erie The following javac error is hidden when the project that produced it also contains a java compiler warning. If the code that produces the warning is removed, and the project is rebuilt, then the javac error is output; otherwise, only the warning is output. This is the error that is hidden by the warning below: [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Failure executing javac, but could not parse the error: An exception has occurred in the compiler (1.6.0_17). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. com.sun.tools.javac.code.Symbol$CompletionFailure: class file for javax.persistence.AccessType not found This is the warning that hides the above error when produced: [WARNING] somefile.java:[79,24] com.sun.jmx.trace.Trace is Sun proprietary API and may be removed in a future release -- 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: (ARCHETYPE-365) archetype generate does not translate correctly accentuated characters
[ http://jira.codehaus.org/browse/ARCHETYPE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256155#action_256155 ] amber commented on ARCHETYPE-365: - well, just try to put some characters like 'é' or 'à'or 'ç' in a java file (like comments or a string declaration), the phase archetype:create don't change them, but the archetype:generate translate them into klingon ! archetype generate does not translate correctly accentuated characters --- Key: ARCHETYPE-365 URL: http://jira.codehaus.org/browse/ARCHETYPE-365 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.0 Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100) Java version: 1.6.0_23, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_23\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows 2003, version: 5.2, arch: x86, family: windows Reporter: amber Priority: Minor Generating archetype do not preserve accentuated characters. � for é The archetype:create work fine and does not alter accentuated characters -- 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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[ http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256160#action_256160 ] Robert Glover Jr commented on MNG-4211: --- I want to be clearer about the addition to settings.xml shown in the comment above not working in maven version 2.1.0. I originally tested to my satisfaction that it does not work (in maven 2.1.0) by testing with the version of maven that comes prepackaged in the zip file for the newest version of the Atlassian Plugin SDK ( http://confluence.atlassian.com/display/DEVNET/Atlassian+Plugin+SDK+Documentation ) . To rule out that the version of maven (2.1.0) Atlassian's included in their package maven-2.1.0-uber.jar is not the latest version of maven 2.1.0, I just now went into the maven archives and downloaded/installed the latest version of maven 2.1.0 and verified that when I test against Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) I get this same Unable to apply wagon configuration. error (which I do not get in Maven 2.2.1) : The reason this is a problem is that I cannot simply start using maven 2.2.1 for my specific need: the Atlassian Plugin SDK will only work with maven 2.1.0. I confirmed that with the Atlassian Plugin developers at Atlassian. So, since this JIRA is closed because MNG-4211 this is not a bug, I wonder if a new JIRA should be opened for this specific inability to change the User-Agent in version 2.1.0 of maven without getting a Wagon error? [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+ - Key: MNG-4211 URL: http://jira.codehaus.org/browse/MNG-4211 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.1.0, 2.2.0 Environment: WinXP SP2 Reporter: Robert Glover Jr Assignee: Benjamin Bentmann Priority: Blocker Attachments: jira_files_4_total.zip At a large company, maven become impossible to use via proxy when maven upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9 and continues to work fine. however maven via proxy always fails in version 2.1.0 and higher. Attached is a zip file containing 1) log of GMAIL chat between the creater of this JIRA and a maven developer. 2) two console outputs of running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml (with comments stripped out) -- 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-700) Surefire is not isolated from itself
Surefire is not isolated from itself Key: SUREFIRE-700 URL: http://jira.codehaus.org/browse/SUREFIRE-700 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.7.2, 2.7.1, 2.7, 2.6, 2.5, 2.4.3, 2.4.2, 2.4.1 Reporter: Kristian Rosenvold The current classloader structure in surefire does not isolate surefire from changes to surefire in itself. This means an interface change in *most* private interfaces and classes can break the build of surefire itself. This is due to the classloader structure systemclassloader-testclassloader-providerclassloader, where a modified surefire immediately becomes effective by being loaded in testclassloader. This issue will be fixed by making the following structure: systemclassloader-testframeworkclassloader-testclassloader ^--surefireclassloader -- 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-700) Surefire is not isolated from itself
[ http://jira.codehaus.org/browse/SUREFIRE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-700: Description: The current classloader structure in surefire does not isolate surefire from changes to surefire in itself. This means an interface change in *most* private interfaces and classes can break the build of surefire itself. This is due to the classloader structure systemclassloader-testclassloader-providerclassloader, where a modified surefire immediately becomes effective by being loaded in testclassloader. This issue will be fixed by making the following structure: systemclassloader-testframeworkclassloader-testclassloader systemclassloader-testframeworkclassloader-surefireclassloader Pardon the ascii graphics but it seems like jira does not allow me to draw systemclassloader-testframeworkclassloader as one common root ;) was: The current classloader structure in surefire does not isolate surefire from changes to surefire in itself. This means an interface change in *most* private interfaces and classes can break the build of surefire itself. This is due to the classloader structure systemclassloader-testclassloader-providerclassloader, where a modified surefire immediately becomes effective by being loaded in testclassloader. This issue will be fixed by making the following structure: systemclassloader-testframeworkclassloader-testclassloader ^--surefireclassloader Surefire is not isolated from itself Key: SUREFIRE-700 URL: http://jira.codehaus.org/browse/SUREFIRE-700 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.4.1, 2.4.2, 2.4.3, 2.5, 2.6, 2.7, 2.7.1, 2.7.2 Reporter: Kristian Rosenvold The current classloader structure in surefire does not isolate surefire from changes to surefire in itself. This means an interface change in *most* private interfaces and classes can break the build of surefire itself. This is due to the classloader structure systemclassloader-testclassloader-providerclassloader, where a modified surefire immediately becomes effective by being loaded in testclassloader. This issue will be fixed by making the following structure: systemclassloader-testframeworkclassloader-testclassloader systemclassloader-testframeworkclassloader-surefireclassloader Pardon the ascii graphics but it seems like jira does not allow me to draw systemclassloader-testframeworkclassloader as one common root ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (SUREFIRE-700) Surefire is not isolated from itself
[ http://jira.codehaus.org/browse/SUREFIRE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SUREFIRE-700 started by Kristian Rosenvold. Surefire is not isolated from itself Key: SUREFIRE-700 URL: http://jira.codehaus.org/browse/SUREFIRE-700 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.4.1, 2.4.2, 2.4.3, 2.5, 2.6, 2.7, 2.7.1, 2.7.2 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold The current classloader structure in surefire does not isolate surefire from changes to surefire in itself. This means an interface change in *most* private interfaces and classes can break the build of surefire itself. This is due to the classloader structure systemclassloader-testclassloader-providerclassloader, where a modified surefire immediately becomes effective by being loaded in testclassloader. This issue will be fixed by making the following structure: systemclassloader-testframeworkclassloader-testclassloader systemclassloader-testframeworkclassloader-surefireclassloader Pardon the ascii graphics but it seems like jira does not allow me to draw systemclassloader-testframeworkclassloader as one common root ;) -- 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: (MDEP-272) purge-local-repository does nothing if certain dependencies are included
[
http://jira.codehaus.org/browse/MDEP-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256172#action_256172
]
Paul Mackinlay commented on MDEP-272:
-
This does not look like it is specific to jasperreports.jar, I have other
dependencies and am experiencing the same issue.
purge-local-repository does nothing if certain dependencies are included
Key: MDEP-272
URL: http://jira.codehaus.org/browse/MDEP-272
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: purge-local-repository
Affects Versions: 2.0
Reporter: Michele Lorenzini
Assignee: Brian Fox
Attachments: pom.xml
I've noticed that the {{purge-local-repository}} goal does nothing if certain
dependencies are present in the dependency tree of the project.
After some attempts I've found some of the dependencies that can show problem.
See attached {{pom.xml}}: if I run {{mvn validate}} as is, maven purges the
local repository and the log4j jar is downloaded from the remote repository.
Removing the comment around the jasperreports dependency and re-running {{mvn
validate}} gives the following result:
{code}
[INFO] [dependency:purge-local-repository {execution: default}]
[INFO] Nothing to do for project: test-issue:test-issue:pom:1.0.0.0-SNAPSHOT
{code}
So it seems that something goes wrong while resolving the dependencies for
the project if the jasperreports jar is included, resulting in the
{{purge-local-repository}} to skip the clean of the local repository.
I dont know if this happens only with jasperreports dependency or if it is
something more general.
--
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-4001) Unable to resolve Dashboard mojo from Central
[
http://jira.codehaus.org/browse/MNG-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256193#action_256193
]
André Ribeiro commented on MNG-4001:
This should be fixed ASAP, some organizations cannot afford to switch to
version 3 just like that.
Unable to resolve Dashboard mojo from Central
-
Key: MNG-4001
URL: http://jira.codehaus.org/browse/MNG-4001
Project: Maven 2 3
Issue Type: Bug
Components: Sites Reporting
Affects Versions: 2.0.9
Environment: Windows, JDK 1.6
Reporter: Anthony Whitford
Fix For: Issues to be reviewed for 3.x
Attachments: dashbug.zip
I have a simple test project that declares the dashboard-maven-plugin (see
http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).
Note that the usage does explicitly state that the Codehaus repository must
be specified as a plugin repository...
However, according to:
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
I'm pretty sure that Maven should be able to resolve the
dashboard-maven-plugin from the central repo.
I validated that the [dashboard-maven-plugin residing in
central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
is indeed the same artifact as that which lives at the [codehaus
repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].
But as you can see from my attached test case, the codehaus mojo is NOT being
resolved without the special plugin repository defined. When running
{noformat}mvn dashboard:dashboard{noformat}, I get the following error
message:
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dashboard'.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not
exist or no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
[INFO] Final Memory: 1M/254M
[INFO]
{noformat}
If you edit the pom.xml to uncomment out the plugin repository declaration
for codehaus, it works as one would expect.
My understanding is that the only reason why the Dashboard Usage mentions
their plugin repository is because the artifact was not available on the
central repository -- but it certainly is today.
I also thought that perhaps the maven-metadata.xml might be incorrect
(perhaps the dashboard plugin prefix is missing or different). I checked:
* http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
* http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml
and they both look OK to me... I clearly see:{code:xml}
plugin
nameMaven Dashboard Report Plugin/name
prefixdashboard/prefix
artifactIddashboard-maven-plugin/artifactId
/plugin
{code}
And I don't see any plugin with a dashboard prefix specified as an Apache
Maven Plugin here:
* http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
If I explicitly specify the dashboard plugin like: {noformat}mvn
org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
that works...
Overall, I am recording a bug because the
[documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
states:{quote}
Maven will always search the following groupId's after searching any plugin
groups specified in the user's settings:
* org.apache.maven.plugins
* org.codehaus.mojo
{quote}
I don't see this being done.
Finally, I even tried adding a {{pluginGroups}} to my
{{settings.xml}}:{code:xml}
pluginGroups
pluginGrouporg.codehaus.mojo/pluginGroup
/pluginGroups
{code}
But that did not work either...
--
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: (MNG-4001) Unable to resolve Dashboard mojo from Central
[
http://jira.codehaus.org/browse/MNG-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256193#action_256193
]
André Ribeiro edited comment on MNG-4001 at 2/15/11 11:37 AM:
--
This should be fixed in 2.2.x, some organizations cannot afford to switch to
version 3 just like that.
was (Author: aferrazlr):
This should be fixed in 2.2x, some organizations cannot afford to switch to
version 3 just like that.
Unable to resolve Dashboard mojo from Central
-
Key: MNG-4001
URL: http://jira.codehaus.org/browse/MNG-4001
Project: Maven 2 3
Issue Type: Bug
Components: Sites Reporting
Affects Versions: 2.0.9
Environment: Windows, JDK 1.6
Reporter: Anthony Whitford
Fix For: Issues to be reviewed for 3.x
Attachments: dashbug.zip
I have a simple test project that declares the dashboard-maven-plugin (see
http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).
Note that the usage does explicitly state that the Codehaus repository must
be specified as a plugin repository...
However, according to:
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
I'm pretty sure that Maven should be able to resolve the
dashboard-maven-plugin from the central repo.
I validated that the [dashboard-maven-plugin residing in
central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
is indeed the same artifact as that which lives at the [codehaus
repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].
But as you can see from my attached test case, the codehaus mojo is NOT being
resolved without the special plugin repository defined. When running
{noformat}mvn dashboard:dashboard{noformat}, I get the following error
message:
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dashboard'.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not
exist or no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
[INFO] Final Memory: 1M/254M
[INFO]
{noformat}
If you edit the pom.xml to uncomment out the plugin repository declaration
for codehaus, it works as one would expect.
My understanding is that the only reason why the Dashboard Usage mentions
their plugin repository is because the artifact was not available on the
central repository -- but it certainly is today.
I also thought that perhaps the maven-metadata.xml might be incorrect
(perhaps the dashboard plugin prefix is missing or different). I checked:
* http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
* http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml
and they both look OK to me... I clearly see:{code:xml}
plugin
nameMaven Dashboard Report Plugin/name
prefixdashboard/prefix
artifactIddashboard-maven-plugin/artifactId
/plugin
{code}
And I don't see any plugin with a dashboard prefix specified as an Apache
Maven Plugin here:
* http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
If I explicitly specify the dashboard plugin like: {noformat}mvn
org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
that works...
Overall, I am recording a bug because the
[documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
states:{quote}
Maven will always search the following groupId's after searching any plugin
groups specified in the user's settings:
* org.apache.maven.plugins
* org.codehaus.mojo
{quote}
I don't see this being done.
Finally, I even tried adding a {{pluginGroups}} to my
{{settings.xml}}:{code:xml}
pluginGroups
pluginGrouporg.codehaus.mojo/pluginGroup
/pluginGroups
{code}
But that did not work either...
--
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: (MNG-4001) Unable to resolve Dashboard mojo from Central
[
http://jira.codehaus.org/browse/MNG-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=256193#action_256193
]
André Ribeiro edited comment on MNG-4001 at 2/15/11 11:36 AM:
--
This should be fixed in 2.2x, some organizations cannot afford to switch to
version 3 just like that.
was (Author: aferrazlr):
This should be fixed ASAP, some organizations cannot afford to switch to
version 3 just like that.
Unable to resolve Dashboard mojo from Central
-
Key: MNG-4001
URL: http://jira.codehaus.org/browse/MNG-4001
Project: Maven 2 3
Issue Type: Bug
Components: Sites Reporting
Affects Versions: 2.0.9
Environment: Windows, JDK 1.6
Reporter: Anthony Whitford
Fix For: Issues to be reviewed for 3.x
Attachments: dashbug.zip
I have a simple test project that declares the dashboard-maven-plugin (see
http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).
Note that the usage does explicitly state that the Codehaus repository must
be specified as a plugin repository...
However, according to:
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
I'm pretty sure that Maven should be able to resolve the
dashboard-maven-plugin from the central repo.
I validated that the [dashboard-maven-plugin residing in
central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
is indeed the same artifact as that which lives at the [codehaus
repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].
But as you can see from my attached test case, the codehaus mojo is NOT being
resolved without the special plugin repository defined. When running
{noformat}mvn dashboard:dashboard{noformat}, I get the following error
message:
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dashboard'.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not
exist or no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
[INFO] Final Memory: 1M/254M
[INFO]
{noformat}
If you edit the pom.xml to uncomment out the plugin repository declaration
for codehaus, it works as one would expect.
My understanding is that the only reason why the Dashboard Usage mentions
their plugin repository is because the artifact was not available on the
central repository -- but it certainly is today.
I also thought that perhaps the maven-metadata.xml might be incorrect
(perhaps the dashboard plugin prefix is missing or different). I checked:
* http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
* http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml
and they both look OK to me... I clearly see:{code:xml}
plugin
nameMaven Dashboard Report Plugin/name
prefixdashboard/prefix
artifactIddashboard-maven-plugin/artifactId
/plugin
{code}
And I don't see any plugin with a dashboard prefix specified as an Apache
Maven Plugin here:
* http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
If I explicitly specify the dashboard plugin like: {noformat}mvn
org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
that works...
Overall, I am recording a bug because the
[documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
states:{quote}
Maven will always search the following groupId's after searching any plugin
groups specified in the user's settings:
* org.apache.maven.plugins
* org.codehaus.mojo
{quote}
I don't see this being done.
Finally, I even tried adding a {{pluginGroups}} to my
{{settings.xml}}:{code:xml}
pluginGroups
pluginGrouporg.codehaus.mojo/pluginGroup
/pluginGroups
{code}
But that did not work either...
--
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: (MDEP-166) runtime-scoped dependencies should be specially handled
[ http://jira.codehaus.org/browse/MDEP-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-166: --- Fix Version/s: (was: 2.2) 2.3 runtime-scoped dependencies should be specially handled --- Key: MDEP-166 URL: http://jira.codehaus.org/browse/MDEP-166 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0 Reporter: Max Bowsher Assignee: Brian Fox Fix For: 2.3 Currently the plugin warns that runtime-scope dependencies are unused. It should understand that the correct status for a runtime-scoped dependency is to *not* be discoverable in the bytecode. -- 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: (MDEP-231) Create a single dependency resolution plugin
[ http://jira.codehaus.org/browse/MDEP-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-231: --- Fix Version/s: (was: 2.2) 2.3 Create a single dependency resolution plugin Key: MDEP-231 URL: http://jira.codehaus.org/browse/MDEP-231 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: resolve Affects Versions: 2.1, 2.2 Reporter: Marvin Froeder Assignee: John Casey Fix For: 2.3 Attachments: maven-dependency-plugin.patch, maven-dependency-plugin.patch, maven-dependency-plugin.patch The attached patch has a new goal that allows a single dependency to be resolved, like this: mvn org.apache.maven.plugins:maven-dependency-plugin:2.2-SNAPSHOT:resolve-single -DgroupId=com.acme -DartifactId=dummy -Dversion=1.0 -- 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: (MDEP-265) Add classifier option for dependency:get
[ http://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-265: --- Fix Version/s: (was: 2.2) 2.3 Add classifier option for dependency:get Key: MDEP-265 URL: http://jira.codehaus.org/browse/MDEP-265 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Andreas Kohn Assignee: Brian Fox Fix For: 2.3 Attachments: MDEP-265-include-artifact-string.diff, MDEP-265.diff The dependency:get mojo is really helpful, but it currently seems to be unable to get an artifact that uses a non-default classifier. Please add a classifier configuration option for the get mojo. -- 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: (MDEP-145) Outputting dependency resolution/tree in a well known _machine readable_ output format
[
http://jira.codehaus.org/browse/MDEP-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-145:
---
Fix Version/s: (was: 2.2)
2.3
Outputting dependency resolution/tree in a well known _machine readable_
output format
--
Key: MDEP-145
URL: http://jira.codehaus.org/browse/MDEP-145
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: resolve, tree
Affects Versions: 2.0
Reporter: Samuel Le Berrigaud
Assignee: Brian Fox
Fix For: 2.3
Attachments: MDEP-145-velocity.patch, MDEP-145.zip, treegraph.patch
Currently (at least on trunk) one can output the dependencies in a file.
However the file output doesn't follow any specific format, except from being
the exact same output than on the console.
I would be nice to have an easily parse-able, format so that tools could
leverage the dependency resolution/tree. I am thinking for example of
continuous integration tools that could report on added/removed/updated
dependencies on modules.
The format could be xml, json or something else. I've been playing with the
current output to make it so that:
* the first line describes the current module for which dependency resolution
is done, formatted as such: {{groupId:artifactId:packaging:version}}
* every following line is a dependency (indented by 2 or more spaces),
formatted as such: {{groupId:artifactId:packaging:version:scope}}
This already is easy to parse.
What do you think?
--
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: (MDEP-124) Dependency incorrectly reported as Unused declared
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-124:
---
Fix Version/s: (was: 2.2)
2.3
Dependency incorrectly reported as Unused declared
Key: MDEP-124
URL: http://jira.codehaus.org/browse/MDEP-124
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Reporter: Olivier Dehon
Assignee: Brian Fox
Fix For: 2.3
When a dependency is only required for a constant in a JAR,
dependency:analyze incorrectly reports the dependency as Unused declared.
Example:
Constants.jar has 1 class called Constants.java:
{code}
package com.myco.util;
public class Constants
{
private Constants() {};
public static final double PI = 3.14159;
}
{code}
Then App jar has App.java as:
{code}
package com.myco.app;
public class App
{
public static void main( String[] args )
{
System.out.println( com.myco.util.Constants.PI );
}
}
{code}
Since the constant gets optimized away in the generated {{App.class}}, the
dependency is not detected, even though the project won't compile without it.
--
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
