[jira] Created: (JXR-52) Dont generate xref report if project has pom packaging
Dont generate xref report if project has pom packaging
--
Key: JXR-52
URL: http://jira.codehaus.org/browse/JXR-52
Project: Maven JXR
Issue Type: Bug
Components: maven2 jxr plugin
Affects Versions: 2.2
Reporter: Vincent Siveton
For instance:
{noformat}
project\
|-- pom.xml => POM packaging
|-- module1\
| `-- pom.xml => JAR packaging
|-- module2\
| `-- pom.xml => JAR packaging
`-- src\
|-- main\
|-- java\
`-- ...
|-- test\
|-- java\
`-- ...
{noformat}
Should ignore src/main because it is a POM
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-2871: - Attachment: MNG-2871-core-integration-tests.diff New integrating tests for the issue (ejb-client) and (test-jar) > Subartifact (ejb-client for example) are not reselved as active project > artifacts > - > > Key: MNG-2871 > URL: http://jira.codehaus.org/browse/MNG-2871 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4, 2.0.5 > Environment: Not platform dependent >Reporter: Piotr Tabor >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: MavenProject.java, MNG-2871-core-integration-tests.diff, > root.tar > > > I have prepared simple project to show the bug. > It contains three artifacts: > |-root > \--- ejb3 > \--- client > Client depends on ejb3 with ejb-client. > The local and remote repository must not contain those artifacts. > When I do "mvn -X compile" (or even integration-tests) on root project I will > get those errors: > ... > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' --> > [DEBUG] (f) filters = [] > [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) resources = [EMAIL PROTECTED] > [DEBUG] -- end configuration -- > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] junit:junit:jar:3.8.1:test (selected for test) > [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected > for compile) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Skipping disabled repository central > [DEBUG] ejb3: using locally installed snapshot > [DEBUG] Trying repository Newitech-snapshots-repository > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Trying repository Newitech-publiczne > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven > Snapshots (http://people.apache.org/maven-snapshot-repository) > [DEBUG] Trying repository codehausSnapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) > [DEBUG] Skipping disabled repository central > [DEBUG] Unable to download the artifact from any repository > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ > -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file > Path to dependency: > 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT > 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT > pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT > from the specified remote repositories: > Maven Snapshots (http://people.apache.org/maven-snapshot-repository), > central (http://repo1.maven.org/maven2), > codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), > Newitech-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT > Try downloading t
[jira] Issue Comment Edited: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98088 ] Piotr Tabor edited comment on MNG-2871 at 6/2/07 7:48 AM: -- New integrating tests for the issue (ejb-client) and (test-jar) attached. ejb-client test passes. test-jar test fails. The dependency types (classifiers) are the most popular... but the problem probably touch all classified (sub-)dependences. was: New integrating tests for the issue (ejb-client) and (test-jar) > Subartifact (ejb-client for example) are not reselved as active project > artifacts > - > > Key: MNG-2871 > URL: http://jira.codehaus.org/browse/MNG-2871 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4, 2.0.5 > Environment: Not platform dependent >Reporter: Piotr Tabor >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: MavenProject.java, MNG-2871-core-integration-tests.diff, > root.tar > > > I have prepared simple project to show the bug. > It contains three artifacts: > |-root > \--- ejb3 > \--- client > Client depends on ejb3 with ejb-client. > The local and remote repository must not contain those artifacts. > When I do "mvn -X compile" (or even integration-tests) on root project I will > get those errors: > ... > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' --> > [DEBUG] (f) filters = [] > [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) resources = [EMAIL PROTECTED] > [DEBUG] -- end configuration -- > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] junit:junit:jar:3.8.1:test (selected for test) > [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected > for compile) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Skipping disabled repository central > [DEBUG] ejb3: using locally installed snapshot > [DEBUG] Trying repository Newitech-snapshots-repository > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) > [DEBUG] Skipping disabled repository Newitech-repository > [DEBUG] Trying repository Newitech-publiczne > Downloading: > scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven > Snapshots (http://people.apache.org/maven-snapshot-repository) > [DEBUG] Trying repository codehausSnapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar > [WARNING] Unable to get resource > 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository > codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) > [DEBUG] Skipping disabled repository central > [DEBUG] Unable to download the artifact from any repository > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ > -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file > Path to dependency: > 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT > 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT > pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT > from the specified remote repositories: > Maven Snapshots (http://people.apache.org/maven-snapshot-repository), > central (http://repo1.maven.org/maven2), > codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), > Newitech-snapshots-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), > Newitech-publiczne > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), > Newitech-repository > (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) > [INFO] > ---
[jira] Commented: (DOXIA-63) Add CSS style class to XHTML tags
[ http://jira.codehaus.org/browse/DOXIA-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98089 ] Vincent Siveton commented on DOXIA-63: -- Patch need to be more generic. Maybe a text configuration of how each element was written out. > Add CSS style class to XHTML tags > - > > Key: DOXIA-63 > URL: http://jira.codehaus.org/browse/DOXIA-63 > Project: doxia > Issue Type: Improvement > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Vance Karimi >Priority: Minor > Fix For: 1.0 > > Attachments: doxia-1.0-alpha-8-core-patch.txt, > doxia-1.0-alpha-8-sink-api-patch.txt > > > Add support for CSS style formatting with a class property on tags. > Previously filed http://jira.codehaus.org/browse/MNG-545. > Patches for core and sink-api for doxia-1.0-alpha-8 attached. > It provides the following fixes: > 1. class property on list and numbered list tag > 2. class property on paragraph tag > 3. class property on link tag > 4. target property on link tag > 5. class property on table cells > 6. class property on table header cells > 7. class property on anchors > Is this an acceptable request or have people achieved CSS style differently > when generating XHTML using Doxia? > 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] Updated: (DOXIA-63) Add CSS style class to XHTML tags
[ http://jira.codehaus.org/browse/DOXIA-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated DOXIA-63: - Fix Version/s: 1.0 > Add CSS style class to XHTML tags > - > > Key: DOXIA-63 > URL: http://jira.codehaus.org/browse/DOXIA-63 > Project: doxia > Issue Type: Improvement > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Vance Karimi >Priority: Minor > Fix For: 1.0 > > Attachments: doxia-1.0-alpha-8-core-patch.txt, > doxia-1.0-alpha-8-sink-api-patch.txt > > > Add support for CSS style formatting with a class property on tags. > Previously filed http://jira.codehaus.org/browse/MNG-545. > Patches for core and sink-api for doxia-1.0-alpha-8 attached. > It provides the following fixes: > 1. class property on list and numbered list tag > 2. class property on paragraph tag > 3. class property on link tag > 4. target property on link tag > 5. class property on table cells > 6. class property on table header cells > 7. class property on anchors > Is this an acceptable request or have people achieved CSS style differently > when generating XHTML using Doxia? > 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: (MNG-3029) Filtering of resources using a templating engine (e.g. Freemarker)
Filtering of resources using a templating engine (e.g. Freemarker) -- Key: MNG-3029 URL: http://jira.codehaus.org/browse/MNG-3029 Project: Maven 2 Issue Type: New Feature Components: Plugin Requests Reporter: Sami Dalouche Resource Filtering is often used to generate different configuration files for different environments... It often makes sense to use different values (debug set to true for the development profile, to false for the production environment). However, it is sometimes impossible to just switch values, and additional sections need to be added or removed depending on the environment. Additionally, the configuration could sometimes be cleaner by adopting conventions based on the environment name. (if the application needs to connect to 5 databases whose url depends on the environment name, only part of the settings can be required in the .properties files). That's why I believe it would be nice to have a plugin that would filter a set of resources using some templating engine (freemarker, velocity, ...). Each resource would then be a freemarker/velocity-compliant file, and the possibilities then become endless :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3030) PluginParameterExpressionEvaluatorTest failure in the components maven-core module
PluginParameterExpressionEvaluatorTest failure in the components maven-core module --- Key: MNG-3030 URL: http://jira.codehaus.org/browse/MNG-3030 Project: Maven 2 Issue Type: Test Components: Bootstrap & Build Affects Versions: 2.1 Reporter: Young Lee ant bootstrap build on the maven 2.1 components trunk test failure. The components maven-core test PluginParameterExpressionEvaluatorTest fails with the message: --- Test set: org.apache.maven.plugin.PluginParameterExpressionEvaluatorTest --- Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.922 sec <<< F AILURE! testTwoExpressions(org.apache.maven.plugin.PluginParameterExpressionEvaluatorTest) Time elapsed: 0.094 sec <<< FAILURE! junit.framework.AssertionFailedError: expected: but was: at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:71) at org.apache.maven.plugin.PluginParameterExpressionEvaluatorTest.testTwoExpressions(PluginParameterExpressionEvaluatorTest.java:259) -- 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-2689) ejb-client dependency not working properly as reactor build
[
http://jira.codehaus.org/browse/MNG-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98090
]
Stephane Nicoll commented on MNG-2689:
--
I think this could be generalized to any classified dependency. We have
obfuscated builds with the "obfuscated" classifier. If we run a reactor build,
it fails, if we disable ofuscation (i.e. we take the main artifacts) it works.
> ejb-client dependency not working properly as reactor build
>
>
> Key: MNG-2689
> URL: http://jira.codehaus.org/browse/MNG-2689
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle, POM, Reactor and
> workspace
>Affects Versions: 2.0.4
>Reporter: Brian Topping
> Attachments: it200x.tgz
>
>
> I've attached an tarball in standard IT test format. :-)
> If an artifact of ejb-client is built, it cannot be properly
> used as a dependency by other builds in a reactor build without also having
> improper access to the rest of the EJB libs.
> The reason is somewhat disturbing, when the client project is built under
> reactor, the compile plugin classpath includes the target/classes directory
> of the EJB project. Take a look at it with -X:
> {quote}
> [INFO]
>
> [INFO] Building client
> [INFO]task-segment: [install]
> [INFO]
>
> [DEBUG] maven-jar-plugin: resolved to version 2.1 from repository central
> [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::3 for
> project: null:maven-jar-plugin:maven-plugin:2.1 from the repository.
> [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::4 for project:
> org.apache.maven.plugins:maven-plugins:pom:3 from the repository.
> [DEBUG] Retrieving parent-POM: org.apache:apache::3 for project:
> org.apache.maven:maven-parent:pom:4 from the repository.
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -->
> [DEBUG] (f) filters = []
> [DEBUG] (f) outputDirectory =
> /Users/briantopping/dev/it200x/client/target/classes
> [DEBUG] (f) project = [EMAIL PROTECTED]
> [DEBUG] (f) resources = [EMAIL PROTECTED]
> [DEBUG] -- end configuration --
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [DEBUG] org.apache.maven.it:client:jar:1-SNAPSHOT (selected for null)
> [DEBUG] org.apache.maven.it:ejb:ejb-client:client:1-SNAPSHOT:compile
> (selected for compile)
> [DEBUG] junit:junit:jar:3.8.1:test (selected for test)
> [DEBUG] Skipping disabled repository central
> [DEBUG] ejb: using locally installed snapshot
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.0.1:compile' -->
> [DEBUG] (f) basedir = /Users/briantopping/dev/it200x/client
> [DEBUG] (f) buildDirectory = /Users/briantopping/dev/it200x/client/target
> [DEBUG] (f) classpathElements =
> [/Users/briantopping/dev/it200x/client/target/classes,
> /Users/briantopping/dev/it200x/ejb/target/classes]
> [DEBUG] (f) compileSourceRoots =
> [/Users/briantopping/dev/it200x/client/src/main/java]
> [DEBUG] (f) compilerId = javac
> [DEBUG] (f) debug = true
> [DEBUG] (f) fork = false
> [DEBUG] (f) optimize = false
> [DEBUG] (f) outputDirectory =
> /Users/briantopping/dev/it200x/client/target/classes
> [DEBUG] (f) outputFileName = client-1-SNAPSHOT
> [DEBUG] (f) projectArtifact = org.apache.maven.it:client:jar:1-SNAPSHOT
> [DEBUG] (f) showDeprecation = false
> [DEBUG] (f) showWarnings = false
> [DEBUG] (f) staleMillis = 0
> [DEBUG] (f) verbose = false
> [DEBUG] -- end configuration --
> [INFO] [compiler:compile]
> [DEBUG] Using compiler 'javac'.
> [DEBUG] Source directories:
> [/Users/briantopping/dev/it200x/client/src/main/java]
> [DEBUG] Classpath: [/Users/briantopping/dev/it200x/client/target/classes
> /Users/briantopping/dev/it200x/ejb/target/classes]
> [DEBUG] Output directory: /Users/briantopping/dev/it200x/client/target/classes
> [DEBUG] Classpath:
> [DEBUG] /Users/briantopping/dev/it200x/client/target/classes
> *[DEBUG] /Users/briantopping/dev/it200x/ejb/target/classes*
> [DEBUG] Source roots:
> [DEBUG] /Users/briantopping/dev/it200x/client/src/main/java
> Compiling 2 source files to
> /Users/briantopping/dev/it200x/client/target/classes
> {quote}
> Note the boldfaced text.
> Now let's try again, but inside the client directory of the attached IT test:
> {quote}
> [INFO]
>
> [INFO] Building client
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [DEBUG] maven-clean-plugin: resolved to ve
[jira] Updated: (MNG-3030) PluginParameterExpressionEvaluatorTest failure in the components maven-core module
[ http://jira.codehaus.org/browse/MNG-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Young Lee updated MNG-3030: --- Attachment: MNG-3030-maven-core.patch fix for the test is attached > PluginParameterExpressionEvaluatorTest failure in the components maven-core > module > --- > > Key: MNG-3030 > URL: http://jira.codehaus.org/browse/MNG-3030 > Project: Maven 2 > Issue Type: Test > Components: Bootstrap & Build >Affects Versions: 2.1 >Reporter: Young Lee > Attachments: MNG-3030-maven-core.patch > > > ant bootstrap build on the maven 2.1 components trunk test failure. The > components maven-core test PluginParameterExpressionEvaluatorTest fails with > the message: > --- > Test set: org.apache.maven.plugin.PluginParameterExpressionEvaluatorTest > --- > Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.922 sec > <<< F > AILURE! > testTwoExpressions(org.apache.maven.plugin.PluginParameterExpressionEvaluatorTest) > Time elapsed: 0.094 sec <<< FAILURE! > junit.framework.AssertionFailedError: > expected: > but > was: > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > org.apache.maven.plugin.PluginParameterExpressionEvaluatorTest.testTwoExpressions(PluginParameterExpressionEvaluatorTest.java:259) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2923: --- Priority: (was: Blocker) I'm testing out this patch now on the trunk and branch. It looks like some MNG-1577 work at play. > Having any active profiles causes the build to fail > --- > > Key: MNG-2923 > URL: http://jira.codehaus.org/browse/MNG-2923 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Matthew Beermann > Fix For: 2.0.7 > > Attachments: MNG-2923-maven-artifact.patch, pom.xml > > > (This seems to be a regression in 2.0.6, and does not occur in 2.0.5.) If I > have any active profiles when building certain projects in Maven 2.0.6, the > build will fail. For example, adding something as simple as: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > 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: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:585) > 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 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-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98094 ] Jason van Zyl commented on MNG-2923: Patch applied. > Having any active profiles causes the build to fail > --- > > Key: MNG-2923 > URL: http://jira.codehaus.org/browse/MNG-2923 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Matthew Beermann > Fix For: 2.0.7 > > Attachments: MNG-2923-maven-artifact.patch, pom.xml > > > (This seems to be a regression in 2.0.6, and does not occur in 2.0.5.) If I > have any active profiles when building certain projects in Maven 2.0.6, the > build will fail. For example, adding something as simple as: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > 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: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:585) > 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 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: (MNG-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2923. -- > Having any active profiles causes the build to fail > --- > > Key: MNG-2923 > URL: http://jira.codehaus.org/browse/MNG-2923 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Matthew Beermann > Fix For: 2.0.7 > > Attachments: MNG-2923-maven-artifact.patch, pom.xml > > > (This seems to be a regression in 2.0.6, and does not occur in 2.0.5.) If I > have any active profiles when building certain projects in Maven 2.0.6, the > build will fail. For example, adding something as simple as: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > 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: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:585) > 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 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: (MNG-728) Consider using java.net.useSystemProxies
[ http://jira.codehaus.org/browse/MNG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-728. - Don't re-open this until you have patches, test projects, and you have run the integration tests. I'm processing all patches to start a new way of accepting patches and test projects. I will be finished processing all the patches today and I'll make instructions on how to submit requests for updating Maven. > Consider using java.net.useSystemProxies > > > Key: MNG-728 > URL: http://jira.codehaus.org/browse/MNG-728 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0-alpha-3 >Reporter: Kohsuke Kawaguchi >Priority: Minor > Fix For: 2.1.x > > Attachments: maven-proxy-1.patch, maven-proxy-2.patch, > maven-proxy-3.patch > > > Consider using the java.net.useSystemProxies property so that Maven can work > with a proxy without requring any user intervention. > See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html > for more information. -- 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-728) Consider using java.net.useSystemProxies
[ http://jira.codehaus.org/browse/MNG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98096 ] Jochen Wiedmann commented on MNG-728: - Jason, I *have* provided patches to this issue. If you don't like them, that's fine. Simply closing this issue with the lack of patches as a reason doesn't seem sensible to me. > Consider using java.net.useSystemProxies > > > Key: MNG-728 > URL: http://jira.codehaus.org/browse/MNG-728 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0-alpha-3 >Reporter: Kohsuke Kawaguchi >Priority: Minor > Fix For: 2.1.x > > Attachments: maven-proxy-1.patch, maven-proxy-2.patch, > maven-proxy-3.patch > > > Consider using the java.net.useSystemProxies property so that Maven can work > with a proxy without requring any user intervention. > See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html > for more information. -- 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: (MNG-2884) MultipleArtifactsNotFoundException provides access to missing artifacts
[ http://jira.codehaus.org/browse/MNG-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2884. -- Resolution: Fixed > MultipleArtifactsNotFoundException provides access to missing artifacts > --- > > Key: MNG-2884 > URL: http://jira.codehaus.org/browse/MNG-2884 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Chris Eldredge > Attachments: MultipleArtifactsNotFoundException.patch > > > MultipleArtifactsNotFoundException is not reusable outside of a console based > application because the missing artifacts cannot be programmatically obtained > either to be processed or displayed to the user in some other UI. > The attached patch provides access to the list of artifacts. -- 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: (MECLIPSE-276) AndroMDA crashes with commons.collections arraystack error
AndroMDA crashes with commons.collections arraystack error -- Key: MECLIPSE-276 URL: http://jira.codehaus.org/browse/MECLIPSE-276 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.0 Environment: Eclipse 3.2 Reporter: Ron Wheeler If you follow the AndroMDA tutorial and you connect the project to Eclipse as an external project (or create the project in your Eclipse workspace), you get to the point of the maven.install. If you do it at the Windows XP command line, it works. If you run the install task from Eclipse, it fails with the following error. [INFO] Error running AndroMDA Embedded error: org.apache.commons.collections.ArrayStack: method (I)V not found [INFO] [DEBUG] Trace Error running AndroMDA [INFO] [ERROR] reactor-execute : C:\aerationmanager FATAL ERROR: Error executing Maven for a project I am not sure if it happens to everyone but others have reported it. I have rebuilt the project several times but always end up here. I can send the project if it will help . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1581) Upload rat-lib-0.5
Upload rat-lib-0.5 -- Key: MAVENUPLOAD-1581 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1581 Project: maven-upload-requests Issue Type: Improvement Reporter: Jochen Wiedmann Release Audit Tool (RAT) is a tool to improve accuracy and efficiency when checking releases. It is heuristic in nature: making guesses about possible problems. It will produce false positives and cannot find every possible issue with a release. It's reports require interpretation. In response to demands from project quality tool developers, RAT is available as a library suitable for inclusion in tools. This POM describes that library. Note that binary compatibility is not gauranteed between 0.x releases. -- 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: (MNG-2855) [PATCH] quote handling in linkPatternedText seems broken
[ http://jira.codehaus.org/browse/MNG-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2855. -- Resolution: Fixed Patch applied. Thanks. > [PATCH] quote handling in linkPatternedText seems broken > > > Key: MNG-2855 > URL: http://jira.codehaus.org/browse/MNG-2855 > Project: Maven 2 > Issue Type: Bug > Components: Multiple Language Support, Sites & Reporting >Affects Versions: 2.0.5 >Reporter: Herve Boutemy > Attachments: AbstractMavenReportRendererTest.java, > maven-reporting-impl-quote.patch, maven-reporting-impl-quote2.patch > > > MPIR-59 shows a problem on a quote for french translation : an easy > workaround is to double the quote '', but these 2 quotes are rendered in the > final report, which is not what is expected. > Then I checked the correponding code, and found inconsistencies in the way > quotes are handled (apparently to protect braces from being interpreted). > I wrote a JUnit test to show these inconsistencies (which in addition showed > some bugs on special situations). > To get consistent results, I think that single quotes should be removed when > found: that's what is done in the patch. > But doing so, there will be problems with existing texts that contain only > one single quote: what used to work won't work any more, because the quote > should be doubled (and not let without a closing quote). > Should this patch be applied or not ? I really don't know: without it, you > can have weird results (showed in the JUnit test). But when applying it, > prepare yourself to some problems with existing texts: I can't say how much > content it will break... > At least, adding the JUnit test to the codebase will help to deal with the > current situation. -- 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: (MNG-2188) Report mojos should check canGenerateReport() when called directly
[
http://jira.codehaus.org/browse/MNG-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2188.
--
Resolution: Won't Fix
Already dealt with as report mojos can only be called by a report document
renderer.
> Report mojos should check canGenerateReport() when called directly
> --
>
> Key: MNG-2188
> URL: http://jira.codehaus.org/browse/MNG-2188
> Project: Maven 2
> Issue Type: Improvement
> Components: Sites & Reporting
>Affects Versions: 2.0.3
>Reporter: Vincent Massol
> Fix For: 2.0.x
>
> Attachments: AbstractMavenReport-canGenerateReport-check.patch
>
>
> There's a canGenerateReport() method in a ReportMojo. This method is called
> by the site phase to decide if the mojo should be called or not. This is
> cool. However the user can call directly the report mojo and in that case the
> canGenerateReport() method is not called automatically. Thus the solution for
> a plugin developer is to write:
> {code}
> public void executeReport()
> {
> if (canGenerateReport() )
> {
> [...]
> }
> }
> {code}
> Which means that the canGenerateReport method is going to be called twice
> when mvn site is executed.
--
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: (MNG-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-671. - Yah, I don't think this is a burning issue anymore. At least not with respect to click through license handling of things like hibernate which maven is just going to take from the repository (I don't know what the status is now honestly) and there are impls of things like JavaMail/Activation now. So we'll let this one rest for now. > implement a license clickthrough > > > Key: MNG-671 > URL: http://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.1.x > > Attachments: maven-artifact-manager-patch-2.txt, > maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, > maven-license-patches-3.zip, maven-settings-patch-2.txt, > maven-settings-patch.txt > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- 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-2188) Report mojos should check canGenerateReport() when called directly
[
http://jira.codehaus.org/browse/MNG-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98109
]
Vincent Massol commented on MNG-2188:
-
hmm... so does it mean users cannot call, say, mvn clover:clover anymore?
> Report mojos should check canGenerateReport() when called directly
> --
>
> Key: MNG-2188
> URL: http://jira.codehaus.org/browse/MNG-2188
> Project: Maven 2
> Issue Type: Improvement
> Components: Sites & Reporting
>Affects Versions: 2.0.3
>Reporter: Vincent Massol
> Fix For: 2.0.x
>
> Attachments: AbstractMavenReport-canGenerateReport-check.patch
>
>
> There's a canGenerateReport() method in a ReportMojo. This method is called
> by the site phase to decide if the mojo should be called or not. This is
> cool. However the user can call directly the report mojo and in that case the
> canGenerateReport() method is not called automatically. Thus the solution for
> a plugin developer is to write:
> {code}
> public void executeReport()
> {
> if (canGenerateReport() )
> {
> [...]
> }
> }
> {code}
> Which means that the canGenerateReport method is going to be called twice
> when mvn site is executed.
--
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: (MNG-1830) add a 'compiled on ' label when maven 2 is invoked with --version option
[ http://jira.codehaus.org/browse/MNG-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1830. -- Resolution: Won't Fix Bootstrap is entirely different now. Ant-based and it's not really a problem making sure you have the right Maven ... knowing from experience building it 20 times a day when applying patches for example. > add a 'compiled on ' label when maven 2 is invoked with --version > option > > > Key: MNG-1830 > URL: http://jira.codehaus.org/browse/MNG-1830 > Project: Maven 2 > Issue Type: Improvement >Reporter: Rahul Thakur >Priority: Minor > Fix For: 2.0.x > > Attachments: bootstrap_builtOn.patch, maven-archiver_builtOn.patch > > > It might be a good idea to append > 'compiled on ' > when maven2 is invoked with '--version' swtich/option, just like Ant does. > Can be helpful when compiling m2 locally 'n' times and need to ensure the m2 > installation was infact updated or when was it last updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2398) attached artifacts (such as assemblies) are not resolved in the workspace when running 'package' phase
[ http://jira.codehaus.org/browse/MNG-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2398: --- Priority: (was: Major) This really needs to account for many attached artifacts and this patch is now stale. Our fault but it needs work again. > attached artifacts (such as assemblies) are not resolved in the workspace > when running 'package' phase > -- > > Key: MNG-2398 > URL: http://jira.codehaus.org/browse/MNG-2398 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.4 > Environment: Running of Mac OSX 10.4 >Reporter: Matt Brozowski > Fix For: 2.1.x > > Attachments: attached-artifact-bug.tar.gz, > maven-project-2.0.4-patch.txt > > > I have attached a sample project. > submoduleA creates an attached artifact (a tar.gz assembly) which submoduleB > depends on. > When running: > mvn package > The attached artifact cannot be resolved from the workspace but tries the > repos instead, yet when running: > > This problems makes using attached artifacts very 'risky' because it could be > running 'old' 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: (MNG-2398) attached artifacts (such as assemblies) are not resolved in the workspace when running 'package' phase
[ http://jira.codehaus.org/browse/MNG-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2398. -- Resolution: Won't Fix If you do a little more work and make it work with multiple attached artifacts and not just one and update the code then I'd be happy to commit it. I think it would definitely be better if thing inside the reactor worked as expected. > attached artifacts (such as assemblies) are not resolved in the workspace > when running 'package' phase > -- > > Key: MNG-2398 > URL: http://jira.codehaus.org/browse/MNG-2398 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.4 > Environment: Running of Mac OSX 10.4 >Reporter: Matt Brozowski > Fix For: 2.1.x > > Attachments: attached-artifact-bug.tar.gz, > maven-project-2.0.4-patch.txt > > > I have attached a sample project. > submoduleA creates an attached artifact (a tar.gz assembly) which submoduleB > depends on. > When running: > mvn package > The attached artifact cannot be resolved from the workspace but tries the > repos instead, yet when running: > > This problems makes using attached artifacts very 'risky' because it could be > running 'old' 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: (MNG-2992) Batch file uses %HOME% - can set this to a value if blank
[ http://jira.codehaus.org/browse/MNG-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2992. -- Resolution: Fixed Patch applied. > Batch file uses %HOME% - can set this to a value if blank > - > > Key: MNG-2992 > URL: http://jira.codehaus.org/browse/MNG-2992 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.6 > Environment: Windows_NT (WinXP) >Reporter: Tim Reilly >Priority: Minor > Attachments: MNG-2992-maven-core.patch, > MNG-2992-maven-embedder.patch, mvn.bat.patch > > > Batch file uses %HOME% let's set this to a nice value if blank. The patch > adds this line to set HOME to the value of > HOMEDRIVE + HOMEPATH -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2522) Regression for the Eclipse codestyle
[
http://jira.codehaus.org/browse/MNG-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2522:
---
Priority: (was: Major)
One of the developers can do this, and probably has been update. I don't use
eclipse and this is almost a year old.
> Regression for the Eclipse codestyle
>
>
> Key: MNG-2522
> URL: http://jira.codehaus.org/browse/MNG-2522
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: Guides, IDEs
>Affects Versions: 2.0-alpha-1
> Environment: trunk
>Reporter: Vincent Siveton
> Attachments: MNG-2522.patch, test-codestyle.zip
>
>
> For instance, with the old codestyle (rev 397213), the Eclipse formatter
> formats like this:
> {noformat}
> public class SiteRunMojo
> extends AbstractSiteRenderingMojo
> {noformat}
> With the new one (rev 431101), we have
> {noformat}
> public class SiteRunMojo extends AbstractSiteRenderingMojo
> {noformat}
> Other problems exist.
--
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: (MNG-2522) Regression for the Eclipse codestyle
[
http://jira.codehaus.org/browse/MNG-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2522.
--
Resolution: Fixed
> Regression for the Eclipse codestyle
>
>
> Key: MNG-2522
> URL: http://jira.codehaus.org/browse/MNG-2522
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: Guides, IDEs
>Affects Versions: 2.0-alpha-1
> Environment: trunk
>Reporter: Vincent Siveton
> Attachments: MNG-2522.patch, test-codestyle.zip
>
>
> For instance, with the old codestyle (rev 397213), the Eclipse formatter
> formats like this:
> {noformat}
> public class SiteRunMojo
> extends AbstractSiteRenderingMojo
> {noformat}
> With the new one (rev 431101), we have
> {noformat}
> public class SiteRunMojo extends AbstractSiteRenderingMojo
> {noformat}
> Other problems exist.
--
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: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2471. -- Resolution: Fixed Someone can reopen this is they care. It's all Maven committers anyway now working on this. > Add search box to the index page > > > Key: MNG-2471 > URL: http://jira.codehaus.org/browse/MNG-2471 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Reporter: Marvin King > Attachments: index-wfocus-woutlogo-wmojocodehausoption.html, > index-with-focus.html, index-without-logo-with-mojocodehausoption.html, > index.html, index[wlogo_wfocus_XHTML].html, > index[wlogo_wfocus_XHTML_CSS2].html, index[wlogo_wfocus_XHTML_CSS].html, > MNG-2471-site.patch, > MNG-2471-site[with_focus_smallsearchbox_withmojocodehausoption].patch, > MNG-2471-site[wlogo_wfocus_XHTML].patch, > site-without-logo-with-mojocodehausoption.css, site[wlogo_wfocus_XHTML].css > > > - google for now -- 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: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak closed ARCHETYPE-39.
Resolution: Fixed
To get ${artifactId} in the output, use $\{artifactId} in the template.
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
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] Reopened: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak reopened ARCHETYPE-39:
--
wrong resolution...
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
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: (MNG-2066) Specify multiple proxies
[ http://jira.codehaus.org/browse/MNG-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2066. -- Resolution: Won't Fix > Specify multiple proxies > > > Key: MNG-2066 > URL: http://jira.codehaus.org/browse/MNG-2066 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Thomas Recloux > Fix For: 2.1.x > > Attachments: MNG-2066-maven-site.patch, MNG-2066-maven.patch, > multiple-proxies-paches.zip > > > After this discussion : > http://www.mail-archive.com/[EMAIL PROTECTED]/msg53099.html > In the attached zip file, you'll find four patch files : > - on the maven-artifact-manager projet : changes in the DefaultWagonManager > class, using the http proxy when no https proxy is specified. > - on the maven-core project : changes in the DefaultMaven, adding all teh > active proxies from the settings to the wagon manager > - on the maven-settings project : changes in the settings.mdo file > Theses patches are built on the maven-2.0.x branch. -- 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: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak closed ARCHETYPE-39.
Resolution: Won't Fix
corrected resolution.
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2066) Specify multiple proxies
[ http://jira.codehaus.org/browse/MNG-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2066: --- Priority: (was: Major) This is too complicated for Maven. If you have more then one repository that you need to use then you can use one of the many proxying tools. Trying to cycle through proxies doesn't seem all that great. And really you want to be able to bind a proxy to a particular repository as you know what you are trying to get and where. This is not the right solution. Nothing more then simple proxy support belongs in Maven as the proxying solutions are available now and work. See Proximity. > Specify multiple proxies > > > Key: MNG-2066 > URL: http://jira.codehaus.org/browse/MNG-2066 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Thomas Recloux > Fix For: 2.1.x > > Attachments: MNG-2066-maven-site.patch, MNG-2066-maven.patch, > multiple-proxies-paches.zip > > > After this discussion : > http://www.mail-archive.com/[EMAIL PROTECTED]/msg53099.html > In the attached zip file, you'll find four patch files : > - on the maven-artifact-manager projet : changes in the DefaultWagonManager > class, using the http proxy when no https proxy is specified. > - on the maven-core project : changes in the DefaultMaven, adding all teh > active proxies from the settings to the wagon manager > - on the maven-settings project : changes in the settings.mdo file > Theses patches are built on the maven-2.0.x branch. -- 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: (MNG-2860) Empty entry causes OutOfMemoryError
[ http://jira.codehaus.org/browse/MNG-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2860. -- Resolution: Fixed Added a simple check for the empty string. > Empty entry causes OutOfMemoryError > - > > Key: MNG-2860 > URL: http://jira.codehaus.org/browse/MNG-2860 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.5 > Environment: Windows XP SP2 with all available patches > Sun JDK 1.6.0 >Reporter: Thorsten Heit >Assignee: Jason van Zyl >Priority: Minor > Fix For: 2.0.7, 2.1-alpha-1 > > > Accidentially I forgot to remove an empty entry in my > pom.xml. When I tried to fully clean my project and all its subprojects Maven > crashes with an OutOfMemoryError after a couple of minutes: > [EMAIL PROTECTED] /cygdrive/d/workspaces/sukv-maven > $ mvn -e -X clean > + Error stacktraces are turned on. > Maven version: 2.0.5 > [DEBUG] Building Maven user-level plugin registry from: 'D:\Dokumente und > Einstellungen\H2841\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\maven-2.0.5\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Java heap space > [INFO] > > [DEBUG] Trace > java.lang.OutOfMemoryError: Java heap space > at > org.codehaus.plexus.util.xml.pull.MXParser.ensurePC(MXParser.java:3047) > at > org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1374) > at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1090) > at > org.codehaus.plexus.util.xml.pull.MXParser.nextText(MXParser.java:1055) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseScm(MavenXpp3Reader.java:4045) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2206) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4422) > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1345) > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1309) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:429) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:195) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:523) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:455) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499) > [INFO] > > [INFO] Total time: 5 minutes 26 seconds > [INFO] Finished at: Wed Mar 07 12:40:03 CET 2007 > [INFO] Final Memory: 31M/234M > [INFO] > > [EMAIL PROTECTED] /cygdrive/d/workspaces/s
[jira] Closed: (MSITE-217) Internal Error with latest doxia-core update
[ http://jira.codehaus.org/browse/MSITE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MSITE-217. - Assignee: Wendy Smoak Resolution: Cannot Reproduce Fix Version/s: (was: 2.0-beta-6) Seems to have been resolved already, 'mvn site:stage' works fine for me with the latest Doxia and Site Plugin snapshots. > Internal Error with latest doxia-core update > > > Key: MSITE-217 > URL: http://jira.codehaus.org/browse/MSITE-217 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: doxia integration >Affects Versions: 2.0-beta-6 > Environment: Windows XP >Reporter: Indrajit Khare >Assignee: Wendy Smoak >Priority: Critical > > With the latest doxia-core alpha 9 update site:stage has an internal error: > [ERROR] BUILD ERROR > [INFO] > > [INFO] Internal error in the plugin manager executing goal > 'org.apache.maven.plugins:maven-site-plugin:2.0-SNAPSHOT:stage': Unable to > find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-SNAPSHOT:stage' > in the plugin 'org.apache.maven.plugins:maven-site-plugin' > org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext > I was able to get it working by reversing the doxia-core alpha 9 snapshot to > an older version -- 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-201) ${modules} renders as [] causing parse error
[
http://jira.codehaus.org/browse/MSITE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98128
]
Wendy Smoak commented on MSITE-201:
---
This is still a problem:
$ cd maven-site-plugin/src/test/projects/site-plugin-test12
$ mvn clean site
[INFO] Scanning for projects...
...
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing site descriptor
Embedded error: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...<
menu ref="reports"/>\r\n\r\n[]\r\n ${modules} renders as [] causing parse error
>
>
> Key: MSITE-201
> URL: http://jira.codehaus.org/browse/MSITE-201
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: Kenney Westerhof
> Fix For: 2.0-beta-6
>
>
--
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: (MSITE-223) Enable optional velocity processing of input documents
[ http://jira.codehaus.org/browse/MSITE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MSITE-223: -- Issue Type: New Feature (was: Task) Summary: Enable optional velocity processing of input documents (was: make velocity processing of input documents optional) This has been resolved by only filtering files that have a ".vm" extension. Adjusted summary and issue type for the release notes, and documented the new feature in r543823. > Enable optional velocity processing of input documents > -- > > Key: MSITE-223 > URL: http://jira.codehaus.org/browse/MSITE-223 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-6 >Reporter: Brett Porter > Fix For: 2.0-beta-6 > > > per discussion on dev list - we need to do this before the next site plugin > release. > There are probably a couple of implementation options: > - only processing files that have .vm appended to the filename > - adding configuration to the site plugin that is passed through to doxia as > includes/excludes > - ...? -- 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: (MSITE-223) Enable optional velocity processing of input documents
[ http://jira.codehaus.org/browse/MSITE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MSITE-223. - Assignee: Jason van Zyl Resolution: Fixed > Enable optional velocity processing of input documents > -- > > Key: MSITE-223 > URL: http://jira.codehaus.org/browse/MSITE-223 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-6 >Reporter: Brett Porter >Assignee: Jason van Zyl > Fix For: 2.0-beta-6 > > > per discussion on dev list - we need to do this before the next site plugin > release. > There are probably a couple of implementation options: > - only processing files that have .vm appended to the filename > - adding configuration to the site plugin that is passed through to doxia as > includes/excludes > - ...? -- 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-206) Move the webapp features to a separate plugin
[ http://jira.codehaus.org/browse/MSITE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98130 ] Wendy Smoak commented on MSITE-206: --- Relevant dev list thread: http://www.nabble.com/Moving-site-plugin-webapp-to-another-plugin-t2956928s177.html > Move the webapp features to a separate plugin > - > > Key: MSITE-206 > URL: http://jira.codehaus.org/browse/MSITE-206 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-5 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.0-beta-6 > > > Prevent the complete download of Jetty for rendering the site and move to a > separate plugin. -- 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: (MNG-2904) Misleading error message if profiles that are active by default do not have an ID
[ http://jira.codehaus.org/browse/MNG-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2904. -- Resolution: Fixed Fixed in trunk and the branch. > Misleading error message if profiles that are active by default do not have > an ID > - > > Key: MNG-2904 > URL: http://jira.codehaus.org/browse/MNG-2904 > Project: Maven 2 > Issue Type: Improvement > Components: Errors >Affects Versions: 2.0.5 > Environment: Maven 2.0.x on Mac OSX Java 1.5.0_07 - happens on Java > 1.4.2 also >Reporter: Andrew Williams >Assignee: Jason van Zyl > Fix For: 2.0.7 > > > to reproduce edit your ~/.m2/settings.xml and add a new profile. > Mark it as active by default and make sure it has no ID. > The resulting stack is thus: > java.lang.ClassCastException: Settings.addActiveProfiles(string) parameter > must be instanceof java.lang.String > at > org.apache.maven.settings.Settings.addActiveProfile(Settings.java:91) > at > org.apache.maven.settings.DefaultMavenSettingsBuilder.activateDefaultProfiles(DefaultMavenSettingsBuilder.java:197) > at > org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:177) > at > org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:153) > at > org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:141) > at org.apache.maven.cli.MavenCli.buildSettings(MavenCli.java:315) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:176) > 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.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 sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2879) Thousands of [WARNING] Component returned which is not the same manager.
[ http://jira.codehaus.org/browse/MNG-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2879: --- Affects Version/s: (was: 2.0.4) (was: 2.0.5) (was: 2.0.2) (was: 2.0.3) (was: 2.0.1) (was: 2.0) 2.0.8 Sorry, this one seems to be of limited concern, and again requires more container work then I'd like for this version. > Thousands of [WARNING] Component returned which is not the same manager. > > > Key: MNG-2879 > URL: http://jira.codehaus.org/browse/MNG-2879 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.8 >Reporter: Brian Fox >Assignee: Jason van Zyl > Fix For: 2.0.7 > > > It happens when processing resources, mostly for war projects although I'm > not 100% positive it's only wars. We see one of these warnings apparently for > every file processed because sometimes there are just a few and sometimes > there are 1000s correlating to the number of files in the project. So far it > only happens on dual-core machines although not every time. It smells of a > multithreading issue. > This issue has already been fixed in PLX-287. This MNG issue is to try and > get that fix into 2.0.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-97) War plugin and Overlays handling
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-97: Description: Piotr and I are currently working on the war plugin and especially this overlay mechanism that needs to be upgraded. Currently a couple of issues [1] in the war plugin are linked to this functionality and we should really address them. The idea here is to provide a better way to handle overlays through an explicit configuration. An overlay has the following parameters: * groupId * artifactId * classifier (optionnal) * includes (default includes everything) * excludes (default META-INF) The order in which overlays are specified defined the order in which they are applied. An overlay without a groupId/artifactId is considered as the current build. If no such overlay is defined, it is applied first. The behavior should be deterministic so the copy will happen not matter how if a file is newer than the one being applied. Overlays use a first win strategy. If no overlays section is defined, the wars are processed as before; dependentWarIncludes and dependentWarExcludes are honored. If an overlays section is defined and those configuration items are defined, they are ignored and a warning is logged. If a dependent war is missing in the overlays section, it's applied after custom overlays with the default includes/excludes. Does that sounds ok to you? If so I'll add the proposition to the war site and start the implementation with Piotr. We're also thinking about integrating the merge functionality of the cargo plugin but we still need to discuss with the cargo guys if it will be feasible. Please comment. Stéphane was: Piotr and I are currently working on the war plugin and especially this overlay mechanism that needs to be upgraded. Currently a couple of issues [1] in the war plugin are linked to this functionality and we should really address them. The idea here is to provide a better way to handle overlays through an explicit configuration. An overlay has the following parameters: * groupId * artifactId * classifier (optionnal) * includes (default includes everything) * excludes (default META-INF) The order in which overlays are specified defined the order in which they are applied. An overlay without a groupId/artifactId is considered as the current build. If no such overlay is defined, it is applied *last*. The behavior should be deterministic so the copy will happen not matter how if a file is newer than the one being applied. Overlays order always wins. If no overlays section is defined, the wars are processed as before; dependentWarIncludes and dependentWarExcludes are honored. If an overlays section is defined and those configuration items are defined, they are ignored and a warning is logged. If a dependent war is missing in the overlays section, it's applied after custom overlays *and* before the current build (if the current build is not specified of course) with the default includes/excludes. Does that sounds ok to you? If so I'll add the proposition to the war site and start the implementation with Piotr. We're also thinking about integrating the merge functionality of the cargo plugin but we still need to discuss with the cargo guys if it will be feasible. Please comment. Stéphane > War plugin and Overlays handling > > > Key: MWAR-97 > URL: http://jira.codehaus.org/browse/MWAR-97 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 >Reporter: Piotr Tabor >Assignee: Stephane Nicoll > Attachments: MWAR-97.diff > > > Piotr and I are currently working on the war plugin and especially > this overlay mechanism that needs to be upgraded. Currently a couple > of issues [1] in the war plugin are linked to this functionality and > we should really address them. > The idea here is to provide a better way to handle overlays through an > explicit configuration. An overlay has the following parameters: > * groupId > * artifactId > * classifier (optionnal) > * includes (default includes everything) > * excludes (default META-INF) > The order in which overlays are specified defined the order in which > they are applied. An overlay without a groupId/artifactId is > considered as the current build. If no such overlay is defined, it is > applied first. > The behavior should be deterministic so the copy will happen not > matter how if a file is newer than the one being applied. Overlays > use a first win strategy. > If no overlays section is defined, the wars are processed as before; > dependentWarIncludes and dependentWarExcludes are honored. If an > overlays section is defined and those configuration items are defined, > they are ignored and a warning is logged. > If a dependent war
[jira] Commented: (SUREFIRE-288) Surefire tries to instantiate nested TestCase classes
[
http://jira.codehaus.org/browse/SUREFIRE-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98135
]
Karl Wettin commented on SUREFIRE-288:
--
I just hit this.
Could not find anything about it, so I just excluded all inner classes:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
**/*$*
{code}
I know this is not the forum, but as you notice I'm already at it: it would be
nice if I could configure Surefire to what combinations of test scemes (ng,
junit, pojo) to run. I need to exclude a lot of pojos now..
> Surefire tries to instantiate nested TestCase classes
> -
>
> Key: SUREFIRE-288
> URL: http://jira.codehaus.org/browse/SUREFIRE-288
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 3.x support, Junit 4.x support
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Windows XP, Java 1.4.2
>Reporter: Stephen Coy
> Fix For: 2.4
>
>
> If a JUnit TestCase contains any kind of nested class (static or not),
> Surefire feels obliged to try and instantiate it. This will fail with access
> violations if the class is not public.
> Work around seems to be to make the nested class public, but surely Surefire
> has no business doing this anyway?
> Here is a sample stack trace:
> org.apache.maven.surefire.booter.SurefireExecutionException: Unable to
> instantiate POJO 'class
> au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent';
> nested exception is java.lang.InstantiationException:
> au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent;
> nested exception is
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to
> instantiate POJO 'class
> au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent';
> nested exception is java.lang.InstantiationException:
> au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to
> instantiate POJO 'class
> au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent';
> nested exception is java.lang.InstantiationException:
> au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent
> java.lang.InstantiationException:
> au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent
> at java.lang.Class.newInstance0(Class.java:293)
> at java.lang.Class.newInstance(Class.java:261)
> at
> org.apache.maven.surefire.testset.PojoTestSet.(PojoTestSet.java:52)
> at
> org.apache.maven.surefire.junit.JUnitDirectoryTestSuite.createTestSet(JUnitDirectoryTestSuite.java:61)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:93)
> at
> org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:108)
> 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:324)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
--
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: (NMAVEN-71) Replace various hard-coded paths with environment-aware versions
Replace various hard-coded paths with environment-aware versions Key: NMAVEN-71 URL: http://jira.codehaus.org/browse/NMAVEN-71 Project: NMaven Issue Type: Improvement Environment: Windows? Reporter: Campbell Boucher-Burnet Priority: Blocker Attachments: patches.zip I'm in an environment where my system drive is not "C:\" and I cannot guarantee that all .NET related libraries/SDKs are on "C:\" in their default locations. As such, it was impossible to build NMavewn (and presumably, the binaries, as built by default, would not work in my environment, regardless). So, I am submitting minimal patches that replace hardcoded strings containing "C:\WINDOWS" and" C:\", respectively, with the SystemRoot and SystemDrive paths from the enviroment. -- 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: (NMAVEN-71) Replace various hard-coded paths with environment-aware versions
[ http://jira.codehaus.org/browse/NMAVEN-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98139 ] Shane Isbell commented on NMAVEN-71: Thanks, Campbell. I'll get these patches tested and applied next week. > Replace various hard-coded paths with environment-aware versions > > > Key: NMAVEN-71 > URL: http://jira.codehaus.org/browse/NMAVEN-71 > Project: NMaven > Issue Type: Improvement > Environment: Windows? >Reporter: Campbell Boucher-Burnet >Priority: Blocker > Attachments: patches.zip > > > I'm in an environment where my system drive is not "C:\" and I cannot > guarantee that all .NET related libraries/SDKs are on "C:\" in their default > locations. > As such, it was impossible to build NMavewn (and presumably, the binaries, as > built by default, would not work in my environment, regardless). > So, I am submitting minimal patches that replace hardcoded strings containing > "C:\WINDOWS" and" C:\", respectively, with the SystemRoot and SystemDrive > paths from the enviroment. -- 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
