[jira] Commented: (DOXIA-119) How to deal with encoding and documentation
[ http://jira.codehaus.org/browse/DOXIA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134900#action_134900 ] Lukas Theussl commented on DOXIA-119: - Jason, can you clarify what you had in mind here, AFAIK there is no way to specify the encoding in an APT file? > How to deal with encoding and documentation > --- > > Key: DOXIA-119 > URL: http://jira.codehaus.org/browse/DOXIA-119 > Project: Maven Doxia > Issue Type: Task > Components: Core, Documentation >Reporter: Jason van Zyl > Fix For: 1.0-beta-1 > > > Show how people can use different encodings with APT. This can probably be > added to the guide-site.apt. -- 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: (DOXIA-241) Xdoc/XhtmlBaseParser doesn't close sections properly
Xdoc/XhtmlBaseParser doesn't close sections properly
Key: DOXIA-241
URL: http://jira.codehaus.org/browse/DOXIA-241
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Xdoc, Module - Xhtml
Reporter: Lukas Theussl
For the following valid xdoc snippet:
{code:xml}
subtitle
{code}
the current XdocParser emits this sequence of events:
{noformat}
section1
sectionTitle1
text
sectionTitle1_
section5
sectionTitle5
text
sectionTitle5_
section1_
{noformat}
ie there is a closing section5_ missing.
--
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: (MRESOURCES-64) CLONE -When filtering, properties defined in should be allowed as well.
[ http://jira.codehaus.org/browse/MRESOURCES-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magne Nordtveit closed MRESOURCES-64. - Resolution: Duplicate > CLONE -When filtering, properties defined in should be > allowed as well. > - > > Key: MRESOURCES-64 > URL: http://jira.codehaus.org/browse/MRESOURCES-64 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Reporter: Magne Nordtveit > > It would be nice to be able to reference custom properties defined in the > section of pom.xml in resources for filtering. -- 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: (MRESOURCES-64) CLONE -When filtering, properties defined in should be allowed as well.
[ http://jira.codehaus.org/browse/MRESOURCES-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134905#action_134905 ] Magne Nordtveit commented on MRESOURCES-64: --- Issue reported (cloned) on wrong plugin, closing... > CLONE -When filtering, properties defined in should be > allowed as well. > - > > Key: MRESOURCES-64 > URL: http://jira.codehaus.org/browse/MRESOURCES-64 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Reporter: Magne Nordtveit > > It would be nice to be able to reference custom properties defined in the > section of pom.xml in resources for filtering. -- 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: (MRESOURCES-64) CLONE -When filtering, properties defined in should be allowed as well.
CLONE -When filtering, properties defined in should be allowed as well. - Key: MRESOURCES-64 URL: http://jira.codehaus.org/browse/MRESOURCES-64 Project: Maven 2.x Resources Plugin Issue Type: Improvement Reporter: Magne Nordtveit It would be nice to be able to reference custom properties defined in the section of pom.xml in resources for filtering. -- 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-3576) Maven no longer uses properties from in pom.xml when assembeling
Maven no longer uses properties from in pom.xml when assembeling -- Key: MNG-3576 URL: http://jira.codehaus.org/browse/MNG-3576 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1 Environment: Product Version: NetBeans IDE 6.1 (Build 200804211638) Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22 System: Linux version 2.6.24-15-generic running on i386; UTF-8; en_GB (nb) Mevenide: 3.1.1; Maven 2.1-SNAPSHOT Reporter: Magne Nordtveit Attachments: assemblyreproduce.zip To reproduce this, the project needs to be run with two versions of Maven; 2.0.9 and 2.1-SNAPSHOT. 1. Run mvn clean install on the project with maven 2.1-SNAPSHOT; observer the target/assemblyreproduce-1.0-SNAPSHOT-null.dir/assemblyreproduce-1.0-SNAPSHOT/filtered.txt contains properties name, not value. 2. Run mvn clean install on the project with maven 2.0.9; observe that the filtered.txt now contains the properties values as they should. -- 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: (WAGON-109) Refactor Wagon HTTP and Wagon WebDav
[ http://jira.codehaus.org/browse/WAGON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on WAGON-109 started by Brett Porter. > Refactor Wagon HTTP and Wagon WebDav > > > Key: WAGON-109 > URL: http://jira.codehaus.org/browse/WAGON-109 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-webdav >Reporter: James William Dumay >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > Attachments: webdav-http-dav-refactor.patch, > webdav-http-dav-refactor.patch, webdav-http-dav-refactor.patch > > > This patch includes the following: > * Webdav wagon is now using Jackrabbits webdav client implementation over the > Apache Slide client library (now defunct) > * Inclusion of a commons HttpClient abstract wagon for code reuse between > Wagon Http and Wagon Dav. > * Improved consistency of http parameters across Wagon HTTP and Wagon Webdav > methods -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-109) Refactor Wagon HTTP and Wagon WebDav
[ http://jira.codehaus.org/browse/WAGON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134914#action_134914 ] Brett Porter commented on WAGON-109: I have this applied locally, but there is more work to be done: - review dependencies (see comment above) - get working inside Maven again (see comment above) - attach listeners properly (progress is not being displayed at end) - getting 409 again when directories don't exist (mustn't be creating directories properly?) > Refactor Wagon HTTP and Wagon WebDav > > > Key: WAGON-109 > URL: http://jira.codehaus.org/browse/WAGON-109 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-webdav >Reporter: James William Dumay > Fix For: 1.0-beta-3 > > Attachments: webdav-http-dav-refactor.patch, > webdav-http-dav-refactor.patch, webdav-http-dav-refactor.patch > > > This patch includes the following: > * Webdav wagon is now using Jackrabbits webdav client implementation over the > Apache Slide client library (now defunct) > * Inclusion of a commons HttpClient abstract wagon for code reuse between > Wagon Http and Wagon Dav. > * Improved consistency of http parameters across Wagon HTTP and Wagon Webdav > methods -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-109) Refactor Wagon HTTP and Wagon WebDav
[ http://jira.codehaus.org/browse/WAGON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134917#action_134917 ] Brett Porter commented on WAGON-109: dependencies culled a bit. it's unfortunate that jackrabbit is dependent on xerces itself... > Refactor Wagon HTTP and Wagon WebDav > > > Key: WAGON-109 > URL: http://jira.codehaus.org/browse/WAGON-109 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-webdav >Reporter: James William Dumay >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > Attachments: webdav-http-dav-refactor.patch, > webdav-http-dav-refactor.patch, webdav-http-dav-refactor.patch > > > This patch includes the following: > * Webdav wagon is now using Jackrabbits webdav client implementation over the > Apache Slide client library (now defunct) > * Inclusion of a commons HttpClient abstract wagon for code reuse between > Wagon Http and Wagon Dav. > * Improved consistency of http parameters across Wagon HTTP and Wagon Webdav > methods -- 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-2059) Upload FreeMarker 2.3.13
Upload FreeMarker 2.3.13 Key: MAVENUPLOAD-2059 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2059 Project: maven-upload-requests Issue Type: Task Reporter: Mirko Nasato -- 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-3577) bug in PluginParameterExpressionEvaluator when using '${plugin.something}
bug in PluginParameterExpressionEvaluator when using '${plugin.something}
-
Key: MNG-3577
URL: http://jira.codehaus.org/browse/MNG-3577
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.8
Reporter: Ittay Dror
when expression is 'plugin.something', this is the code that evaluates it:
value = ReflectionValueExtractor.evaluate(
expression.substring( 1 ), pluginDescriptor );
so the extractor sees 'lugin.something', which obviously won't work.
also, it returns 'null'. i think it would be better if evaluation of unfound
expressions will just leave them as they are (so evaluating ${foo} will leave
it as '${foo}').
--
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-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
[ http://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134931#action_134931 ] Anders Sveen commented on MNG-1991: --- We're packaging a standalone Jetty server in a zip with the assembly and appassembler plugin. This project has a dependency on two skinny war-projects, and thus need to resolve the transitive dependencies and include them in the zip. >From issues I have seen this is reported as problems with both the war and ear >plugin, but seems to be a broader issue on how to resolve dependencies when >the type is war. > Can't get transitive dependencies from a war pom when this war is added as a > depdency of a project > -- > > Key: MNG-1991 > URL: http://jira.codehaus.org/browse/MNG-1991 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2 >Reporter: Emmanuel Venisse > Fix For: 2.1 > > > I have a project (continuum-core-it) that need to use all transitive > dependencies of a war (continuum-webapp). If i add the war as a dependency of > the project with packaging war, war dependencies aren't shown by project, > maven doesn't try to resolve them and doesn't add them in classpath. > If if replace packaging from war to pom, all dependencies are resolved and > added to classpath. -- 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-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
[ http://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134933#action_134933 ] Anders Sveen commented on MNG-1991: --- Duplicating the dependency, just as a type=pom made the appassembler include the needed libraries. It's not the best way to do it, but might be an acceptable way for my use case. > Can't get transitive dependencies from a war pom when this war is added as a > depdency of a project > -- > > Key: MNG-1991 > URL: http://jira.codehaus.org/browse/MNG-1991 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2 >Reporter: Emmanuel Venisse > Fix For: 2.1 > > > I have a project (continuum-core-it) that need to use all transitive > dependencies of a war (continuum-webapp). If i add the war as a dependency of > the project with packaging war, war dependencies aren't shown by project, > maven doesn't try to resolve them and doesn't add them in classpath. > If if replace packaging from war to pom, all dependencies are resolved and > added to classpath. -- 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-3577) bug in PluginParameterExpressionEvaluator when using '${plugin.something}
[
http://jira.codehaus.org/browse/MNG-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ittay Dror closed MNG-3577.
---
Resolution: Not A Bug
my mistake, the code removes the first substring until the '.'. not sure why
'substring' is needed, but, well.
> bug in PluginParameterExpressionEvaluator when using '${plugin.something}
> -
>
> Key: MNG-3577
> URL: http://jira.codehaus.org/browse/MNG-3577
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.8
>Reporter: Ittay Dror
>
> when expression is 'plugin.something', this is the code that evaluates it:
> value = ReflectionValueExtractor.evaluate(
> expression.substring( 1 ), pluginDescriptor );
> so the extractor sees 'lugin.something', which obviously won't work.
> also, it returns 'null'. i think it would be better if evaluation of unfound
> expressions will just leave them as they are (so evaluating ${foo} will leave
> it as '${foo}').
--
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-3578) Enhancements to plugin parameters
Enhancements to plugin parameters
-
Key: MNG-3578
URL: http://jira.codehaus.org/browse/MNG-3578
Project: Maven 2
Issue Type: Improvement
Reporter: Ittay Dror
allow plugin parameters to reference other parameters. so, for example, i can
have 'dir' and 'file' parameters, where 'file' is '${dir}/something'. then, if
the user defines 'dir' in the plugin configuration in the pom, file uses the
configured value.
also, leave unknown expressions as they are. so if 'file' is ${dir}/${unknown}
it will be expanded to 'some/path/${unknown}'. this allows the mojo to further
expand the parameter with runtime value without resorting to the use of '$$"
--
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-3550) Support more prerequisites like compiler version
[
http://jira.codehaus.org/browse/MNG-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134941#action_134941
]
Brian Fox commented on MNG-3550:
The enforcer is definately the place to check for the other prerequisites
> Support more prerequisites like compiler version
>
>
> Key: MNG-3550
> URL: http://jira.codehaus.org/browse/MNG-3550
> Project: Maven 2
> Issue Type: Improvement
> Components: POM
>Reporter: Vincent Siveton
>Priority: Minor
> Fix For: 2.1-alpha-1
>
>
> It should be useful if the tag could support more
> informations than the maven version. I could imagine something like:
> {noformat}
>
> ...
>
> 2.0.6
> 1.5
> 512m
> 100m
>
> ...
>
> {noformat}
> See the concrete use case in the Maven Plugin Plugin report:
> http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-242) Echo macro outputs internal params
Echo macro outputs internal params -- Key: DOXIA-242 URL: http://jira.codehaus.org/browse/DOXIA-242 Project: Maven Doxia Issue Type: Bug Components: Core Affects Versions: 1.0-beta-1 Reporter: Lukas Theussl The Apt and XdocParsers are adding some "parser" and "sourceContent" params to the map of macro parameters (which I think are used only by the TOC macro), these are output as strings by the echo macro. We either need to define what macro parameters are reserved for internal use, or find a general way to distinguish such internal parameters from params passed in from the source document. -- 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-450) EAR projects are not correctly referenced in .component
EAR projects are not correctly referenced in .component
Key: MECLIPSE-450
URL: http://jira.codehaus.org/browse/MECLIPSE-450
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Environment: Eclipse 3.3, Wtp 2.0, Jboss 4.2, Linux
Reporter: Gabriele Contini
Priority: Critical
There is a problem generating wtp 2.0 configuration for multi-module j2ee
applications using ejb 3.0.
Here is my project structure.
{noformat}
myapp
|--ear
| |-- .settings
| ||--- org.eclipse.wst.common.component
| |
| |-- pom.xml
|--ejb
| |-- pom.xml
|
|
{noformat}
here is a snippet from: myapp/ejb/pom.xml
{code:xml}
myapp-ejb
ejb
...
{code}
here is a snippet from: myapp/ear/pom.xml
{code:xml}
${pom.groupId}
myapp-ejb
${pom.version}
ejb
{code}
and here is a snippet from the generated org.eclipse.wst.common.component file
in the ear project.
{code:xml}
EjbModule_9473961
uses
{code}
Thus inside the ear generated by eclipse i can find an artifact: myapp-ejb.ejb
Whereas the generated application.xml the module is referenced with .jar
extension:
{code:xml}
---
myapp-ejb.jar
{code}
I tried to override the application.xml with a custom one, but it seems that
jboss doesn't like at all the extension ".ejb" for ejb 3.0 jars.
To make it work i modified by hand the generated
org.eclipse.wst.common.component file in the ear project like this:
{code:xml}
EjbModule_12684337
uses
{code}
At the moment this file must be modified by hand every time i generate the
eclipse 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: (MINVOKER-38) Support easy install of IT parent POM
[
http://jira.codehaus.org/browse/MINVOKER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MINVOKER-38.
-
Resolution: Won't Fix
You're right, the ITs could simply use a parent POM via local lookups, I must
have been brain-dead...
bq. And no it's locked in maven himself (2.0.9).
What I meant with reproducible tests was to rely on the IT POMs *only*, not on
the executing Maven version. The plugin versions in the super POM are a hotfix
for newbies who don't know about the issue yet. A mature build setup should
never rely on these super versions but only on those versions that are
inherited from ordinary/explicit parent POMs.
> Support easy install of IT parent POM
> -
>
> Key: MINVOKER-38
> URL: http://jira.codehaus.org/browse/MINVOKER-38
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 1.1
>Reporter: Benjamin Bentmann
>Priority: Minor
>
> Recently it popped into my mind that all IT POMs need to lockdown plugin
> versions as well to make the tests reproducible. Doing this individually for
> each IT POM isn't that much fun so one quickly dreams of a common parent POM
> with a {{}}.
> One could already install such an IT parent by means of two Invoker
> executions or the help of the Install Plugin but that's far too much hassle
> to copy one little POM around.
--
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-325) PluginXdocGenerator NullPointerException
[
http://jira.codehaus.org/browse/MSITE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134949#action_134949
]
Benjamin Bentmann commented on MSITE-325:
-
Garvin, any more hints on how to reproduce this (debug log, your mojo sources,
repro project)? For example, the {{PluginXDocGenerator}} from which the
exception originates is not related to the Site Plugin, it's part of the Maven
Plugin Plugin, so the version of that plugin will be of interest, too.
> PluginXdocGenerator NullPointerException
>
>
> Key: MSITE-325
> URL: http://jira.codehaus.org/browse/MSITE-325
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: Garvin LeClaire
>
> When creating a site I get the following stack trace:
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95)
> at
> org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224)
> at
> org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> 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:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> 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)
> [INFO]
>
> [INFO] Total time: 33 seconds
> [INFO] Finished at: Wed May 14 23:36:51 EDT 2008
> [INFO] Final Memory: 41M/63M
> I have tried and get the same results with version of the site plg-in back to
> 2.0-beta-3
> Any suggestions??
--
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-3550) Support more prerequisites like compiler version
[
http://jira.codehaus.org/browse/MNG-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134954#action_134954
]
Paul Benedict commented on MNG-3550:
Mark as WONTFIX?
> Support more prerequisites like compiler version
>
>
> Key: MNG-3550
> URL: http://jira.codehaus.org/browse/MNG-3550
> Project: Maven 2
> Issue Type: Improvement
> Components: POM
>Reporter: Vincent Siveton
>Priority: Minor
> Fix For: 2.1-alpha-1
>
>
> It should be useful if the tag could support more
> informations than the maven version. I could imagine something like:
> {noformat}
>
> ...
>
> 2.0.6
> 1.5
> 512m
> 100m
>
> ...
>
> {noformat}
> See the concrete use case in the Maven Plugin Plugin report:
> http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3550) Support more prerequisites like compiler version
[
http://jira.codehaus.org/browse/MNG-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134960#action_134960
]
Vincent Siveton commented on MNG-3550:
--
IMHO it is more POM ontology issue...
Any product/projects have requirements to run and build. Enforcer is only used
for the build. So how to specify runtime prerequisites?
Note: I used the word compiler (and not JDK) to be more platform independent.
> Support more prerequisites like compiler version
>
>
> Key: MNG-3550
> URL: http://jira.codehaus.org/browse/MNG-3550
> Project: Maven 2
> Issue Type: Improvement
> Components: POM
>Reporter: Vincent Siveton
>Priority: Minor
> Fix For: 2.1-alpha-1
>
>
> It should be useful if the tag could support more
> informations than the maven version. I could imagine something like:
> {noformat}
>
> ...
>
> 2.0.6
> 1.5
> 512m
> 100m
>
> ...
>
> {noformat}
> See the concrete use case in the Maven Plugin Plugin report:
> http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-450) EAR projects are not correctly referenced in .component
[
http://jira.codehaus.org/browse/MECLIPSE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriele Contini closed MECLIPSE-450.
-
Resolution: Incomplete
Sorry i made a mistake in the headline. cloned as issue 451
> EAR projects are not correctly referenced in .component
>
>
> Key: MECLIPSE-450
> URL: http://jira.codehaus.org/browse/MECLIPSE-450
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Environment: Eclipse 3.3, Wtp 2.0, Jboss 4.2, Linux
>Reporter: Gabriele Contini
>Priority: Critical
>
> There is a problem generating wtp 2.0 configuration for multi-module j2ee
> applications using ejb 3.0.
> Here is my project structure.
> {noformat}
> myapp
>|--ear
>| |-- .settings
>| ||--- org.eclipse.wst.common.component
>| |
>| |-- pom.xml
>|--ejb
>| |-- pom.xml
>|
>|
> {noformat}
> here is a snippet from: myapp/ejb/pom.xml
> {code:xml}
>
> myapp-ejb
> ejb
> ...
> {code}
> here is a snippet from: myapp/ear/pom.xml
> {code:xml}
>
> ${pom.groupId}
> myapp-ejb
> ${pom.version}
> ejb
>
> {code}
> and here is a snippet from the generated org.eclipse.wst.common.component
> file in the ear project.
> {code:xml}
> handle="module:/resource/myapp-ejb/myapp-ejb">
> EjbModule_9473961
> uses
>
> {code}
> Thus inside the ear generated by eclipse i can find an artifact: myapp-ejb.ejb
> Whereas the generated application.xml the module is referenced with .jar
> extension:
> {code:xml}
>
> ---
>
> myapp-ejb.jar
>
> {code}
> I tried to override the application.xml with a custom one, but it seems that
> jboss doesn't like at all the extension ".ejb" for ejb 3.0 jars.
> To make it work i modified by hand the generated
> org.eclipse.wst.common.component file in the ear project like this:
> {code:xml}
> handle="module:/resource/unirepo-core/unirepo-core">
> EjbModule_12684337
> uses
>
> {code}
> At the moment this file must be modified by hand every time i generate the
> eclipse 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] Created: (MECLIPSE-451) EJB projects are not correctly referenced in .component
EJB projects are not correctly referenced in .component
Key: MECLIPSE-451
URL: http://jira.codehaus.org/browse/MECLIPSE-451
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Environment: Eclipse 3.3, Wtp 2.0, Jboss 4.2, Linux
Reporter: Gabriele Contini
Priority: Critical
There is a problem generating wtp 2.0 configuration for multi-module j2ee
applications using ejb 3.0.
Here is my project structure.
{noformat}
myapp
|--ear
| |-- .settings
| ||--- org.eclipse.wst.common.component
| |
| |-- pom.xml
|--ejb
| |-- pom.xml
|
|
{noformat}
here is a snippet from: myapp/ejb/pom.xml
{code:xml}
myapp-ejb
ejb
...
{code}
here is a snippet from: myapp/ear/pom.xml
{code:xml}
${pom.groupId}
myapp-ejb
${pom.version}
ejb
{code}
and here is a snippet from the generated org.eclipse.wst.common.component file
in the ear project.
{code:xml}
EjbModule_9473961
uses
{code}
Thus inside the ear generated by eclipse i can find an artifact: myapp-ejb.ejb
Whereas the generated application.xml the module is referenced with .jar
extension:
{code:xml}
---
myapp-ejb.jar
{code}
I tried to override the application.xml with a custom one, but it seems that
jboss doesn't like at all the extension ".ejb" for ejb 3.0 jars.
To make it work i modified by hand the generated
org.eclipse.wst.common.component file in the ear project like this:
{code:xml}
EjbModule_12684337
uses
{code}
At the moment this file must be modified by hand every time i generate the
eclipse 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] Commented: (MNG-3550) Support more prerequisites like compiler version
[
http://jira.codehaus.org/browse/MNG-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134965#action_134965
]
Paul Benedict commented on MNG-3550:
Vincent, I think the answer would be ToolChains.
> Support more prerequisites like compiler version
>
>
> Key: MNG-3550
> URL: http://jira.codehaus.org/browse/MNG-3550
> Project: Maven 2
> Issue Type: Improvement
> Components: POM
>Reporter: Vincent Siveton
>Priority: Minor
> Fix For: 2.1-alpha-1
>
>
> It should be useful if the tag could support more
> informations than the maven version. I could imagine something like:
> {noformat}
>
> ...
>
> 2.0.6
> 1.5
> 512m
> 100m
>
> ...
>
> {noformat}
> See the concrete use case in the Maven Plugin Plugin report:
> http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-452) mvn clean breaks eclipse configuration if wtpapplicationxml = true: files in target/eclipseEar are deleted
mvn clean breaks eclipse configuration if wtpapplicationxml = true: files in
target/eclipseEar are deleted
--
Key: MECLIPSE-452
URL: http://jira.codehaus.org/browse/MECLIPSE-452
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.5.2
Environment: Linux, wtp 2.0, Eclipse 3.3
Reporter: Gabriele Contini
When the parameter wtpapplicationxml is set to true in an ear project some file
is written to target/eclipseEar
and this location is added to the file org.eclipse.wst.common.component for
deployment
Subsequent executions of
{code}
mvn clean
{code}
delete the directory and break the eclipse 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] Commented: (MNG-2562) expose current time as a property for POM interpolation
[ http://jira.codehaus.org/browse/MNG-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134977#action_134977 ] Shane Isbell commented on MNG-2562: --- Bug fix here: https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536 This is part of a rewrite of the interpolation code. > expose current time as a property for POM interpolation > --- > > Key: MNG-2562 > URL: http://jira.codehaus.org/browse/MNG-2562 > Project: Maven 2 > Issue Type: New Feature > Components: Inheritance and Interpolation >Reporter: Brett Porter > Fix For: 2.0.10 > > > it is useful to have the current time, for example to write out a manifest > entry for the build time or to filter into another file. > I'm not sure of the best way to make the format of the time configurable - > perhaps another POM element/property. > See the related issue for a current example of how this can be done, but it > would be nice to have a built-in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3535) Valid properties which look self referential fail to resolve
[
http://jira.codehaus.org/browse/MNG-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134975#action_134975
]
Shane Isbell commented on MNG-3535:
---
Bug fix here: https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536
This is part of a rewrite of the interpolation code.
> Valid properties which look self referential fail to resolve
>
>
> Key: MNG-3535
> URL: http://jira.codehaus.org/browse/MNG-3535
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9
>Reporter: Chris Custine
> Fix For: 2.0.10
>
> Attachments: model-int.patch
>
>
> In 2.0.9 properties which look self referential but would otherwise resolve
> to a system property are failing due to fixes for MNG-2339. Current example
> is any version of jruby shared pom at
> http://repo1.maven.org/maven2/org/jruby/shared/1.0.1/shared-1.0.1.pom
> which contains:
> ${java.specification.version}
> The question is whether this should be valid or not, but it has worked in
> every version up to and including 2.0.8 because System properties were
> available in the first interpolate step. In 2.0.9 this first pass does not
> include the system props and an exception is thrown because of the self
> reference check.
--
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-3536) REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore
[
http://jira.codehaus.org/browse/MNG-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134976#action_134976
]
Shane Isbell commented on MNG-3536:
---
Bug fix here: https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536
This is part of a rewrite of the interpolation code.
> REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore
> -
>
> Key: MNG-3536
> URL: http://jira.codehaus.org/browse/MNG-3536
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: MacOSX, Java 6, Maven 2.0.9
>Reporter: Sébastien Arbogast
>Priority: Critical
> Fix For: 2.0.10
>
> Attachments: test.zip
>
>
> On one of my projects, I have the following property:
>
> file:${project.build.sourceDirectory}/myapp.xmi
>
> Knowing that in the same POM, sourceDirectory is configured that way:
>
> ${project.basedir}/src/main/uml
>
> With Maven 2.0.8, model.uri was correctly mapped to
> /Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi
> But with Maven 2.0.9, now it's mapped to
> /Users/sarbogast/dev/myapp/Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi,
> which is not good at all.
>
> I have attached a test project that builds with Maven 2.0.8 but not with
> Maven 2.0.9.
> It's not the simplest project ever but it's a real AndroMDA skeleton project.
> All the configuration is in mda/pom.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3475) Some directories are not basedir aligned
[
http://jira.codehaus.org/browse/MNG-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134978#action_134978
]
Shane Isbell commented on MNG-3475:
---
Bug fix here: https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536
This is part of a rewrite of the interpolation code.
> Some directories are not basedir aligned
>
>
> Key: MNG-3475
> URL: http://jira.codehaus.org/browse/MNG-3475
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
> Fix For: 2.0.10
>
> Attachments: base-directory-alignment.patch,
> base-directory-alignment.patch
>
>
> The output from
> {code:xml}
> ${project.build.sourceDirectory}
> ${project.build.testSourceDirectory}
> ${project.build.scriptSourceDirectory}
> ${project.build.directory}
> ${project.build.outputDirectory}
> ${project.build.testOutputDirectory}
> ${project.reporting.outputDirectory}
> {code}
> delivers something like
> {noformat}
> [echo] M:\maven\z\antrun\src\main\java
> [echo] M:\maven\z\antrun\src\test\java
> [echo] src/main/scripts
> [echo] M:\maven\z\antrun\target
> [echo] M:\maven\z\antrun\target\classes
> [echo] M:\maven\z\antrun\target\test-classes
> [echo] target/site
> {noformat}
> revealing that neither the script source directory nor the reporting output
> directory are basedir aligned.
--
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-3475) Some directories are not basedir aligned
[
http://jira.codehaus.org/browse/MNG-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134979#action_134979
]
Benjamin Bentmann commented on MNG-3475:
bq. Bug fix here:
https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536
No, it isn't. This issue is about missing alignment, not interpolation.
> Some directories are not basedir aligned
>
>
> Key: MNG-3475
> URL: http://jira.codehaus.org/browse/MNG-3475
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
> Fix For: 2.0.10
>
> Attachments: base-directory-alignment.patch,
> base-directory-alignment.patch
>
>
> The output from
> {code:xml}
> ${project.build.sourceDirectory}
> ${project.build.testSourceDirectory}
> ${project.build.scriptSourceDirectory}
> ${project.build.directory}
> ${project.build.outputDirectory}
> ${project.build.testOutputDirectory}
> ${project.reporting.outputDirectory}
> {code}
> delivers something like
> {noformat}
> [echo] M:\maven\z\antrun\src\main\java
> [echo] M:\maven\z\antrun\src\test\java
> [echo] src/main/scripts
> [echo] M:\maven\z\antrun\target
> [echo] M:\maven\z\antrun\target\classes
> [echo] M:\maven\z\antrun\target\test-classes
> [echo] target/site
> {noformat}
> revealing that neither the script source directory nor the reporting output
> directory are basedir aligned.
--
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-3475) Some directories are not basedir aligned
[
http://jira.codehaus.org/browse/MNG-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134979#action_134979
]
bentmann edited comment on MNG-3475 at 5/15/08 1:04 PM:
-
bq. Bug fix here:
https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536
No, it isn't. This issue is about missing path translation, not interpolation.
was (Author: bentmann):
bq. Bug fix here:
https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536
No, it isn't. This issue is about missing alignment, not interpolation.
> Some directories are not basedir aligned
>
>
> Key: MNG-3475
> URL: http://jira.codehaus.org/browse/MNG-3475
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
> Fix For: 2.0.10
>
> Attachments: base-directory-alignment.patch,
> base-directory-alignment.patch
>
>
> The output from
> {code:xml}
> ${project.build.sourceDirectory}
> ${project.build.testSourceDirectory}
> ${project.build.scriptSourceDirectory}
> ${project.build.directory}
> ${project.build.outputDirectory}
> ${project.build.testOutputDirectory}
> ${project.reporting.outputDirectory}
> {code}
> delivers something like
> {noformat}
> [echo] M:\maven\z\antrun\src\main\java
> [echo] M:\maven\z\antrun\src\test\java
> [echo] src/main/scripts
> [echo] M:\maven\z\antrun\target
> [echo] M:\maven\z\antrun\target\classes
> [echo] M:\maven\z\antrun\target\test-classes
> [echo] target/site
> {noformat}
> revealing that neither the script source directory nor the reporting output
> directory are basedir aligned.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-7) Add groovy support for pre/post build hook scripts
[
http://jira.codehaus.org/browse/MINVOKER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134980#action_134980
]
Benjamin Bentmann commented on MINVOKER-7:
--
How would you expect the plugin to choose between the BeanShell and the Groovy
interpreter (or some future thing) when processing scripts?
I could imagine a new mojo parameter "scriptLanguage" that could be set to
"beanshell" or "groovy". Would be an explicit hint for the plugin but would
limit all IT projects run during the same Invoker execution to use the same
script language.
Alternatively, some smarter heuristic that simply derives the interpreter from
the file extension of the configured pre-/post-build script. In addition, we
could consider to extend the mojo parameters "preBuildHookScript" and
"postBuildHookScript" to accept extension-less file names and have the plugin
search for supported scripts types. For example
{code:xml}
verify
{code}
could mean to search for "verify", next for "verify.groovy" and finally for a
"verify.bsh", where the first existing one will be picked up. This would allow
to easily mix the usage of BeanShell and Groovy among the various IT projects.
Thoughts?
> Add groovy support for pre/post build hook scripts
> --
>
> Key: MINVOKER-7
> URL: http://jira.codehaus.org/browse/MINVOKER-7
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
>Reporter: Arnaud Heritier
>Assignee: John Casey
>
> I would like to be able to write those scripts in groovy instead of
> beanshell. I suppose that it is possible. We could reuse the code of the
> maven plugin to execute groovy scripts (groovy-maven-plugin @ 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] Closed: (SCM-338) NullPointerException when using -DvssDirectory to set ss.exe path
[
http://jira.codehaus.org/browse/SCM-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed SCM-338.
Assignee: Emmanuel Venisse
Resolution: Fixed
Patch applied with some changes
> NullPointerException when using -DvssDirectory to set ss.exe path
> -
>
> Key: SCM-338
> URL: http://jira.codehaus.org/browse/SCM-338
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-vss
>Affects Versions: 1.0
> Environment: Windows XP, JRE 1.4.2
>Reporter: Allan Lang
>Assignee: Emmanuel Venisse
>Priority: Minor
> Fix For: 1.1
>
> Attachments: SCM-338-[02]-maven-scm-provider-vss.patch,
> SCM-338-maven-scm-provider-vss.patch, vssproviderbug.zip
>
>
> NullPointerException occurs with any SCM operation when there is no
> ~/.scm/vss-settings.xml file, and when the vssDirectory system property is
> set:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.scm.provider.vss.commands.VssCommandLineUtils.getSettings(VssCommandLineUtils.java:137)
> at
> org.apache.maven.scm.provider.vss.commands.VssCommandLineUtils.getSsDir(VssCommandLineUtils.java:145)
> at
> org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.buildCmdLine(VssHistoryCommand.java:91)
> at
> org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.executeChangeLogCommand(VssHistoryCommand.java:53)
> at
> org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:101)
> at
> org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:58)
> ... 21 more
> {code}
> This error is easily replicated using the attached project
> vssproviderbug.zip. Unzip the archive and run
> {code}
> mvn scm:changelog -DvssDirectory=something -e
> {code}
> Assuming the file ~/.scm/vss-settings.xml does not exist, you should see the
> above error in the stack traces. Note that you don't need VSS installed (or
> even to be on Windows) in order to replicate the error - Maven doesn't
> actually get as far as making a call to ss.exe.
--
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: (SCM-374) maven-scm-providers-git is missing some testdata
[ http://jira.codehaus.org/browse/SCM-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135005#action_135005 ] Emmanuel Venisse commented on SCM-374: -- ping > maven-scm-providers-git is missing some testdata > > > Key: SCM-374 > URL: http://jira.codehaus.org/browse/SCM-374 > Project: Maven SCM > Issue Type: Bug >Affects Versions: 1.1 > Environment: linux fedora-8, git-1.5.3.3., git-1.5.4 >Reporter: mark struberg >Assignee: Jason van Zyl > Fix For: 1.1 > > Attachments: maven-scm-providers-git-testdata.patch > > > It seems that something has gone missing by moving the > maven-scm-providers-git plugin from git to SVN. > I checked out the SVN version and compared it to my git repo. > It seems that the test/resource/git/ ... /*.log files have been ignored. > This files contain the testdata for testing the various commandline output > consumers for the git executable. > The appending patch does contain all missing files plus a small change in the > way the base command is constructed. > Tests and TCK successfully passed. -- 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-3106) Multiple profile activation conditions broken
[ http://jira.codehaus.org/browse/MNG-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MNG-3106. -- Resolution: Fixed This is now fixed in the 2.0.x branch and trunk. The new behaviour is that the profile will be activated if any of the activators returns true (i.e. an "or" operation). > Multiple profile activation conditions broken > - > > Key: MNG-3106 > URL: http://jira.codehaus.org/browse/MNG-3106 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.4 >Reporter: Andy Bryant >Assignee: Paul Gier > Fix For: 2.0.10, 2.1-alpha-1 > > > Having multiple profile activation conditions behaves in an unexpected > manner. It doesn't cause a build failure, but the actual algorithm for > activating a profile is very different from expected. My expectation was that > if you include multiple conditions, they are ANDed together. However what > appears to happen is that the conditions overwrite each other. > If an condition is added, it overrides any or > conditions regardless of their results. > If a condition is added, it overrides any condition > regardless of results > The following table gives a sample of conditions matched, and whether the > profile was activated as a result: > Property File OS Result Expected > T T - TT > T F - FF > F T - TF > F F - FF > T - T TT > T - F FF > F - T TF > F - F FF > F F T TF > T T FFF -- 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: (MASSEMBLY-294) Regression - dependency is skipped?
[
http://jira.codehaus.org/browse/MASSEMBLY-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135012#action_135012
]
Michael Osipov commented on MASSEMBLY-294:
--
I am suffering from the same problem:
http://jira.codehaus.org/browse/MASSEMBLY-309
switching back to beta-1 resolved the issue.
> Regression - dependency is skipped?
> ---
>
> Key: MASSEMBLY-294
> URL: http://jira.codehaus.org/browse/MASSEMBLY-294
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Windows Vista Business, Sun JDK 5
> Fedora Core 4, Sun JDK 5
>Reporter: James Abley
>
> There has been a regression between 2.2-beta-1, which was working for us, and
> 2.2-beta-2, which showed up the problem.
> With 2.2-beta-1, we saw the following output.
> [INFO] [assembly:directory-inline {execution: create-directories}]
> [INFO] Reading assembly descriptor:
> c:\Users\jabley\work\eclipse\workspaces\main\mpinstaller\mpinstaller-dependencies\src\main\assembly\dep.xml
> [INFO] Processing DependencySet (output=/applications)
> [INFO] Expanding:
> C:\Users\jabley\.m2\repository\com\example\serviceoptimizer\serviceoptimizer-webapp\1.17-SNAPSHOT\serviceoptimizer-webapp-1.17-SNAPSHOT.war
> into c:\Users\jabley\
> AppData\Local\Temp\archived-file-set.770382062.tmp
> [INFO] Processing DependencySet (output=/applications)
> [INFO] Expanding:
> C:\Users\jabley\.m2\repository\com\example\contentrepository\gwt-interface\1.16-SNAPSHOT\gwt-interface-1.16-SNAPSHOT.war
> into c:\Users\jabley\AppData\Local\Temp\
> archived-file-set.1945898079.tmp
> [INFO] Processing DependencySet (output=/applications)
> [INFO] Copying 1878 files to
> c:\Users\jabley\work\eclipse\workspaces\main\mpinstaller\mpinstaller-dependencies\target\mpinstaller-dependencies.dir
> [INFO] [antrun:run {execution: default}]
> With 2.2-beta-2, we see the output below.
> [INFO] [assembly:directory-inline {execution: create-directories}]
> [INFO] Reading assembly descriptor: src/main/assembly/dep.xml
> [INFO] Processing DependencySet (output=/applications)
> [WARNING] Cannot include project artifact:
> com.example.mpinstaller:mpinstaller-dependencies:pom:1.14-SNAPSHOT; it
> doesn't have an associated file or directory.
> [INFO] Processing DependencySet (output=/applications)
> [WARNING] Cannot include project artifact:
> com.example.mpinstaller:mpinstaller-dependencies:pom:1.14-SNAPSHOT; it
> doesn't have an associated file or directory.
> [WARNING] Archive:
> C:\Users\jabley\.m2\repository\com\example\contentrepository\gwt-interface\1.16-SNAPSHOT\gwt-interface-1.16-SNAPSHOT.war
> has already been added. Skipping.
> [WARNING] Archive:
> C:\Users\jabley\.m2\repository\com\example\serviceoptimizer\serviceoptimizer-webapp\1.17-SNAPSHOT\serviceoptimizer-webapp-1.17-SNAPSHOT.war
> has already been add
> ed. Skipping.
> [INFO] Processing DependencySet (output=/applications)
> [WARNING] Cannot include project artifact:
> com.example.mpinstaller:mpinstaller-dependencies:pom:1.14-SNAPSHOT; it
> doesn't have an associated file or directory.
> [INFO] Copying files to
> c:\Users\jabley\work\eclipse\workspaces\main\mpinstaller\mpinstaller-dependencies\target\mpinstaller-dependencies.dir
> [INFO] [antrun:run {execution: default}]
> I can provide debug output if you think it would be helpful, for both cases.
> In my pom.xml
>
>
> maven-assembly-plugin
> 2.2-beta-2
>
> false
>
>
> src/main/assembly/dep.xml
>
>
>
>
>
> create-directories
> compile
>
> directory-inline
>
>
>
>
> And in the assembly dep.xml mentioned in the pom.xml
>
> mpinstaller-dependencies
>
> zip
>
> false
>
>
>
> src/site
>
> RELEASE-NOTES.txt
>
> docs
>
>
>
>
>
> serviceoptimizer-*war
>
> ms.war
> /applications
>
> true
> runtime
>
>
>
> gwt-interface*war
>
> mmi.war
> /applications
>
> true
> runtime
>
>
>
> jackrabbit*rar
>
> jcr-repository.rar
> /applications
> false
> runti
Re: please unsubscribe from this group
Unsubscribe instructions are here: http://maven.apache.org/mail-lists.html Ravinder Kankanala wrote: -Original Message- From: Brett Porter (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 14, 2008 12:37 PM To: issues@maven.apache.org Subject: [jira] Moved: (WAGON-140) WAGONFTP Nullpointer Exception [ http://jira.codehaus.org/browse/WAGON-140?page=com.atlassian.jira.plugin.sys tem.issuetabpanels:all-tabpanel ] Brett Porter moved WAGONFTP-21 to WAGON-140: Affects Version/s: (was: 1.0-alpha-6) Component/s: (was: wagon-ftp) wagon-ftp Key: WAGON-140 (was: WAGONFTP-21) Project: Maven Wagon (was: wagon-ftp) WAGONFTP Nullpointer Exception -- Key: WAGON-140 URL: http://jira.codehaus.org/browse/WAGON-140 Project: Maven Wagon Issue Type: Bug Components: wagon-ftp Environment: Solaris Reporter: Jamish Patel Getting the following error similar to this user: http://jira.codehaus.org/browse/WAGONFTP-17 Pretty sure user id and password is correct for the machine that I am trying to ftp to One thing I did not understand in the url above was 'will be thrown if there is a host mismatch' Mismatch with what? Here's the exception: [INFO] Retrieving previous build number from internal-snapshot [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection(FtpWagon.java:1 27) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultW agonManager.java:354) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(De faultWagonManager.java:295) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManag er.resolveAlways(DefaultRepositoryMetadataManager.java:356) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManag er.resolveAlways(DefaultRepositoryMetadataManager.java:310) at org.apache.maven.artifact.transform.SnapshotTransformation.resolveLatestSnap shotBuildNumber(SnapshotTransformation.java:158) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForDeplo yment(SnapshotTransformation.java:97) at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.tra nsformForDeployment(DefaultArtifactTransformationManager.java:61) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArt ifactDeployer.java:68) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162) -- Dennis Lundberg
[jira] Closed: (MNG-3545) Option -P-profile overridden if profile is activebyDefault
[
http://jira.codehaus.org/browse/MNG-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MNG-3545.
--
Resolution: Fixed
Fix Version/s: 2.1-alpha-1
I added an integration test for this and it seems to be working correctly now.
> Option -P-profile overridden if profile is activebyDefault
> --
>
> Key: MNG-3545
> URL: http://jira.codehaus.org/browse/MNG-3545
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.9
>Reporter: David Bernhard
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
> Attachments: maven-profile-bug.zip, MNG-3545-profiles.patch
>
>
> In maven 2.0.9, deactivating a profile "foo" that is declared and marked
> activeByDefault in the local POM does not work, as in
> DefaultProfileManager.java:227 all activeByDefault profiles are added if no
> profile is explicitly given ("-Pbar").
> In the attached zip, run
> mvn -P-foo help:active-profiles
> and note that foo *is* active.
> The patch fixes these issues by checking all default-activated profiles
> against the exclusions list when they are added "by default".
--
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-3571) Allow use of ! when deactivating profiles
[
http://jira.codehaus.org/browse/MNG-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MNG-3571.
--
Resolution: Fixed
> Allow use of ! when deactivating profiles
> -
>
> Key: MNG-3571
> URL: http://jira.codehaus.org/browse/MNG-3571
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
>
> The current syntax for deactivating a profile from the command line is:
> {{mvn -P-myProfile}}
> It would be more intuitive if the exclamation point could be used in addition
> to the dash.
> {{mvn -P!myProfile}}
--
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-3571) Allow use of ! when deactivating profiles
[
http://jira.codehaus.org/browse/MNG-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MNG-3571:
---
Fix Version/s: 2.1-alpha-1
2.0.10
> Allow use of ! when deactivating profiles
> -
>
> Key: MNG-3571
> URL: http://jira.codehaus.org/browse/MNG-3571
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
>
> The current syntax for deactivating a profile from the command line is:
> {{mvn -P-myProfile}}
> It would be more intuitive if the exclamation point could be used in addition
> to the dash.
> {{mvn -P!myProfile}}
--
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-3536) REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore
[
http://jira.codehaus.org/browse/MNG-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3536:
--
Attachment: interpolator.it.patch
Interpolator patch containing IT tests. Apply to
https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests
> REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore
> -
>
> Key: MNG-3536
> URL: http://jira.codehaus.org/browse/MNG-3536
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: MacOSX, Java 6, Maven 2.0.9
>Reporter: Sébastien Arbogast
>Priority: Critical
> Fix For: 2.0.10
>
> Attachments: interpolator.it.patch, test.zip
>
>
> On one of my projects, I have the following property:
>
> file:${project.build.sourceDirectory}/myapp.xmi
>
> Knowing that in the same POM, sourceDirectory is configured that way:
>
> ${project.basedir}/src/main/uml
>
> With Maven 2.0.8, model.uri was correctly mapped to
> /Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi
> But with Maven 2.0.9, now it's mapped to
> /Users/sarbogast/dev/myapp/Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi,
> which is not good at all.
>
> I have attached a test project that builds with Maven 2.0.8 but not with
> Maven 2.0.9.
> It's not the simplest project ever but it's a real AndroMDA skeleton project.
> All the configuration is in mda/pom.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3536) REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore
[
http://jira.codehaus.org/browse/MNG-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3536:
--
Attachment: core-integration-testing-plugins.patch
Test mojo needed to verify patch. Apply to:
https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-testing-plugins
> REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore
> -
>
> Key: MNG-3536
> URL: http://jira.codehaus.org/browse/MNG-3536
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: MacOSX, Java 6, Maven 2.0.9
>Reporter: Sébastien Arbogast
>Priority: Critical
> Fix For: 2.0.10
>
> Attachments: core-integration-testing-plugins.patch,
> interpolator.it.patch, test.zip
>
>
> On one of my projects, I have the following property:
>
> file:${project.build.sourceDirectory}/myapp.xmi
>
> Knowing that in the same POM, sourceDirectory is configured that way:
>
> ${project.basedir}/src/main/uml
>
> With Maven 2.0.8, model.uri was correctly mapped to
> /Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi
> But with Maven 2.0.9, now it's mapped to
> /Users/sarbogast/dev/myapp/Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi,
> which is not good at all.
>
> I have attached a test project that builds with Maven 2.0.8 but not with
> Maven 2.0.9.
> It's not the simplest project ever but it's a real AndroMDA skeleton project.
> All the configuration is in mda/pom.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3536) REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore
[
http://jira.codehaus.org/browse/MNG-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135029#action_135029
]
John Casey commented on MNG-3536:
-
We need to look into converging the interpolation code in this branch with the
code in plexus-interpolation, which is a split-off of the interpolator code
from plexus-utils. It can be found here:
http://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-components/plexus-interpolation
I've already refactored the trunk project builder to use plexus-interpolation,
and the assembly plugin is using the pre-split code in plexus-utils, but will
be updated to use plexus-interpolation once it's released to avoid
inconsistencies with forced versions of plexus-utils from mavens past.
In short, we have interpolation needs that go beyond the project builder, and
need to handle other model class trees than maven-model. If we can use the same
codebase to achieve this, it will help greatly in the consistency department.
We already have an interpolator in maven-project, one in plexus-utils that has
moved into plexus-interpolation, another in plexus-expression-evaluator (not
used in maven, afaik), and now this one...hopefully we can find a way to
consolidate some of this work and realign all of our efforts to some
extent...and maybe refocus on consistency regardless of the model (or file)
being interpolated.
> REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore
> -
>
> Key: MNG-3536
> URL: http://jira.codehaus.org/browse/MNG-3536
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: MacOSX, Java 6, Maven 2.0.9
>Reporter: Sébastien Arbogast
>Priority: Critical
> Fix For: 2.0.10
>
> Attachments: core-integration-testing-plugins.patch,
> interpolator.it.patch, test.zip
>
>
> On one of my projects, I have the following property:
>
> file:${project.build.sourceDirectory}/myapp.xmi
>
> Knowing that in the same POM, sourceDirectory is configured that way:
>
> ${project.basedir}/src/main/uml
>
> With Maven 2.0.8, model.uri was correctly mapped to
> /Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi
> But with Maven 2.0.9, now it's mapped to
> /Users/sarbogast/dev/myapp/Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi,
> which is not good at all.
>
> I have attached a test project that builds with Maven 2.0.8 but not with
> Maven 2.0.9.
> It's not the simplest project ever but it's a real AndroMDA skeleton project.
> All the configuration is in mda/pom.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2609) Mention 'activeByDefault' in the "Introduction to Build Profiles" guide
[ http://jira.codehaus.org/browse/MNG-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MNG-2609: --- Fix Version/s: 2.0.10 > Mention 'activeByDefault' in the "Introduction to Build Profiles" guide > --- > > Key: MNG-2609 > URL: http://jira.codehaus.org/browse/MNG-2609 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Gwyn Evans >Assignee: Paul Gier > Fix For: 2.0.10, Documentation Deficit > > > It appears to be that the primary use-case for someone considering profiles > would be the requirement to modify an existing build in some way to > accomodate a 'special-case'. As such, it seems to me that a mention of the > activation option 'activeByDefault' should be added. > At present, the document implies that there either needs to be a change in > the command line (e,g, "-Denv-prod") or some form of environment parsing to > have the build run as before, whereas 'activeByDefault' show that's not so > but is not mentioned. -- 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-2609) Mention 'activeByDefault' in the "Introduction to Build Profiles" guide
[ http://jira.codehaus.org/browse/MNG-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MNG-2609. -- Resolution: Fixed Added some notes about activeByDefault to the site, and added a better description of activeByDefault to the model. > Mention 'activeByDefault' in the "Introduction to Build Profiles" guide > --- > > Key: MNG-2609 > URL: http://jira.codehaus.org/browse/MNG-2609 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Gwyn Evans >Assignee: Paul Gier > Fix For: 2.0.10, Documentation Deficit > > > It appears to be that the primary use-case for someone considering profiles > would be the requirement to modify an existing build in some way to > accomodate a 'special-case'. As such, it seems to me that a mention of the > activation option 'activeByDefault' should be added. > At present, the document implies that there either needs to be a change in > the command line (e,g, "-Denv-prod") or some form of environment parsing to > have the build run as before, whereas 'activeByDefault' show that's not so > but is not mentioned. -- 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-2060) Need Gnasher 0.2 Bundle to be uploaded into Ibiblio Maven Repository
Need Gnasher 0.2 Bundle to be uploaded into Ibiblio Maven Repository Key: MAVENUPLOAD-2060 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2060 Project: maven-upload-requests Issue Type: New Feature Reporter: Michael Nyika Attachments: gnasher-0.2-bundle.jar Gnasher 0.2 is a Maven Plugin that creates the SHA1 and pom metadata files for artifacts in a local maven repository that are missing. It helps alleviate the "noise" on standard output when building a maven project, especially when multiple dependency artifacts are missing their related pom metadata. I would like Gnasher (0.2) to be available at a location such as: http://repo1.maven.org/maven2/net/sf/gnasher thanks Michael Nyika -- 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-325) PluginXdocGenerator NullPointerException
[ http://jira.codehaus.org/browse/MSITE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135036#action_135036 ] Garvin LeClaire commented on MSITE-325: --- I tried version 2.3 to 2.4.2-SNAPSHOT of the maven-plugin-plugin. I am using Maven 2.0.8 on OSX. > PluginXdocGenerator NullPointerException > > > Key: MSITE-325 > URL: http://jira.codehaus.org/browse/MSITE-325 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Garvin LeClaire > > When creating a site I get the following stack trace: > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > 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:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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) > [INFO] > > [INFO] Total time: 33 seconds > [INFO] Finished at: Wed May 14 23:36:51 EDT 2008 > [INFO] Final Memory: 41M/63M > I have tried and get the same results with version of the site plg-in back to > 2.0-beta-3 > Any suggestions?? -- 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: (ARCHETYPE-169) Archetype:generate Offline mode does not work.
Archetype:generate Offline mode does not work. -- Key: ARCHETYPE-169 URL: http://jira.codehaus.org/browse/ARCHETYPE-169 Project: Maven Archetype Issue Type: Bug Affects Versions: 2.0-alpha-3 Environment: Windows Vista Reporter: Carlus Henry Priority: Minor When trying to run the archetype:generate offline by: mvn -o archetype:generate It fails with the following exception: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] : org.apache.maven.archetype.exception.UnknownArchetype: The desired arch etype does not exist (org.apache.maven.archetypes:maven-archetype-quickstart:REL EASE) The desired archetype does not exist (org.apache.maven.archetypes:maven-archetyp e-quickstart:RELEASE) The desired archetype does not exist (org.apache.maven.archetypes:maven-archetyp e-quickstart:RELEASE) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Thu May 15 22:34:14 EDT 2008 [INFO] Final Memory: 8M/15M [INFO] However running it online works just fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-170) Generator does not handle dot files in module root directories
Generator does not handle dot files in module root directories -- Key: ARCHETYPE-170 URL: http://jira.codehaus.org/browse/ARCHETYPE-170 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.0-alpha-3 Environment: mvn 2.0.9 java 1.6.0_05 maven-archetype-plugin 2.0-alpha-3 Reporter: Alison Priority: Minor Dot files (e.g. ".springBeans") are getting created with strange prefixes (i.e. "__rootArtifactId__-impl.springBeans"). Within my archetype (created from archetype:create-from-project) I have .springBeans and .checkstyle files at the module root level, as per eclipses requirements: ./src/main/resources/archetype-resources/__rootArtifactId__-impl/.springBeans ./src/main/resources/archetype-resources/__rootArtifactId__-impl/.checkstyle Copying of these files in controlled via archetype-metadata.xml as follows: test.properties ... .checkstyle .springBeans When I run archetype:generate using this archetype the following files are created: blah-impl/__rootArtifactId__-impl.springBeans blah-impl/__rootArtifactId__-impl.checkstyle I have tried setting the directory as "." (nothing gets copied) and "./" (same bad file names occur). Will delve into the DefaultFilesetArchetypeGenerator codebase... -- 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-3579) REGRESSION: Using ${project.version} in version tag of extension invalidates pom
REGRESSION: Using ${project.version} in version tag of extension invalidates pom
Key: MNG-3579
URL: http://jira.codehaus.org/browse/MNG-3579
Project: Maven 2
Issue Type: Bug
Components: Bootstrap & Build
Affects Versions: 2.1
Environment: XP, JDK 1.6.0_06, Maven Embedder 2.1 Early Access,
Mevenide 3.1.1, NB 6.1
Reporter: Daniel Mutch
It isn't possible to user ${project.version} in version tag of an extension.
This is a regression as it works fine in 2.0.7
--
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
