[jira] Commented: (MAVENUPLOAD-2005) Hessian Flex 3.1.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130357#action_130357 ] evgeny commented on MAVENUPLOAD-2005: - Sorry, new bundle is valid. > Hessian Flex 3.1.5 > -- > > Key: MAVENUPLOAD-2005 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2005 > Project: maven-upload-requests > Issue Type: Task >Reporter: evgeny > Attachments: hessian-flex-3.1.5-bundle.jar, > hessian-flex-3.1.5-bundle.jar > > > The Hessian binary web service protocol makes web services usable without > requiring a large framework, and without learning yet another alphabet soup > of protocols. Because it is a binary protocol, it is well-suited to sending > binary data without any need to extend the protocol with attachments. -- 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-8) maven-resources-plugin ignores configuration/resources property
[
http://jira.codehaus.org/browse/MRESOURCES-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130356#action_130356
]
Salvador Diaz commented on MRESOURCES-8:
I just ran into this issue, I was willing to submit a patch but I saw that it
was already submitted, any chance to release the patched version of the plugin
to the central repository ?
> maven-resources-plugin ignores configuration/resources property
> ---
>
> Key: MRESOURCES-8
> URL: http://jira.codehaus.org/browse/MRESOURCES-8
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Reporter: Leszek Gawron
>Assignee: Brett Porter
> Attachments: example.zip, MRESOURCES-8-workaround.patch, pom.xml
>
>
> I am evaluating maven + eclipse combo. In a trivial POM filtered resources
> exist only in target/classes. If one executes Project -> Clean under eclipse
> this information is lost. If filtered resources would appear as source folder
> they would survive cleaning and not got overriden by unfiltered ones.
> I have been trying to implement a scenario which would allow filtered
> resources to appear as "static" source folder under eclipse.
> The POM explains it best:
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.mobilebox.squash.client
> squash-client
> jar
> 1.0-SNAPSHOT
> Maven Quick Start Archetype
> http://maven.apache.org
>
>
>
> maven-resources-plugin
>
>
> prefilter-resources
> generate-resources
>
> resources
>
>
>
> target/generated-resources
>
>
>
> src/main/resource-templates
> true
>
>
>
>
>
>
>
>
> ${ffile}
>
>
>
> src/main/resources
>
>
> target/generated-resources
>
>
>
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> filter.properties
>
>
> thing is this part:
>
>
> src/main/properties
> true
>
>
> is completely ignored. Instead for both maven-resource-plugin executions (the
> one in generate-resources phase and the default one) this config is used:
>
>
> src/main/resources
>
>
> target/generated-resources
>
>
> which of course breaks the whole idea.
> Is this a bug or a design decision. In latter case is there any equivalent
> approach I might take?
--
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: (MAVENUPLOAD-2005) Hessian Flex 3.1.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evgeny updated MAVENUPLOAD-2005: Attachment: hessian-flex-3.1.5-bundle.jar > Hessian Flex 3.1.5 > -- > > Key: MAVENUPLOAD-2005 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2005 > Project: maven-upload-requests > Issue Type: Task >Reporter: evgeny > Attachments: hessian-flex-3.1.5-bundle.jar, > hessian-flex-3.1.5-bundle.jar > > > The Hessian binary web service protocol makes web services usable without > requiring a large framework, and without learning yet another alphabet soup > of protocols. Because it is a binary protocol, it is well-suited to sending > binary data without any need to extend the protocol with attachments. -- 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: (MRM-728) After successful admin login archiva reacts as if user is guest
[ http://jira.codehaus.org/browse/MRM-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130354#action_130354 ] oching edited comment on MRM-728 at 4/10/08 3:34 AM: --- Hmm, it worked for me in IE6. I was still able to login as admin with the correct permissions. The IE6 version I was using was 6.0.2900.2180.xpsp_sp2_qfe.070227-2300. In both tests, I was using the standalone Archiva 1.0.1. The java version installed in the linux machine where Archiva is installed is java 1.5.0_11. Btw, you could set the log level to DEBUG in apps/archiva/webapp/WEB-INF/classes/log4j.xml. was (Author: oching): Hmm, it worked for me in IE6. The IE6 version I was using was 6.0.2900.2180.xpsp_sp2_qfe.070227-2300. In both tests, I was using the standalone Archiva 1.0.1. The java version installed in the linux machine where Archiva is installed is java 1.5.0_11. Btw, you could set the log level to DEBUG in apps/archiva/webapp/WEB-INF/classes/log4j.xml. > After successful admin login archiva reacts as if user is guest > --- > > Key: MRM-728 > URL: http://jira.codehaus.org/browse/MRM-728 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: linux >Reporter: Robin Roos >Priority: Critical > Fix For: 1.0.x > > Attachments: archiva.log > > > I ran Archiva on my windows box and, after configuring the admin user, I was > able to login. The header of the web page identified me as Administrator > (admin) and I could see all the expected functions on the left hand frame. > So far so good. > I had Archiva installed on a linux box and started. I surfed to the box from > Windows and configured the admin user. But when I logged in as admin I got a > page with only Search/FindArtifact/Browse functions. The header page reads > "Login - Register". It is as if I am not logged in and am seeing the guest > functions. Note that if I log in with a deliberately incorrect password then > I get an error message as expected. But logging in with the right > credentials appears to fail silently. > As a result I cannot deploy any artifacts into Archiva, I cannot roll out the > maven/subversion/archiva based edition of our in-house project, and I fear my > time is limited! -- 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: (MPXDOC-206) Including DTD breaks xdoc
Including DTD breaks xdoc -- Key: MPXDOC-206 URL: http://jira.codehaus.org/browse/MPXDOC-206 Project: Maven 1.x XDoc Plugin Issue Type: Bug Affects Versions: 1.10.1 Environment: WindowsXP SP2 x86, JDK6 build 1.6.0_05-b13 Reporter: Gregor B. Rosenauer Priority: Minor Attachments: error-report.txt When including the XDoc-DTD as mentioned in issue MPXDOC-192 site generation fails with a Jelly-Exception. I cannot say if this is an issue with the xdoc-plugin or with jelly. My document starts with http://maven.apache.org/dtd/xdoc_1_0.dtd";> When invoking the goal xdoc:generate-from-pom (called through a custom goal ta30:doku) I get a Jelly-Exception (full report attached): Caused by: org.apache.commons.jelly.JellyTagException: file:C:/Dokumente und Einstellungen/Orth/.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources/sitemap.jsl:84:51: Connection timed out: connect Nested exception: Connection t imed out: connect at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo rt.java:186) at org.apache.commons.jelly.tags.xml.ParseTag.getXmlDocument(ParseTag.ja va:106) at org.apache.commons.jelly.tags.xml.ParseTag.doTag(ParseTag.java:55) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.ja va:68) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java: 160) at org.dom4j.rule.Mode.fireRule(Mode.java:59) at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:185) at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:159) at org.apache.commons.jelly.tags.jsl.ApplyTemplatesTag.doTag(ApplyTempla tesTag.java:67) ... 112 more Caused by: org.dom4j.DocumentException: Connection timed out: connect Nested exc eption: Connection timed out: connect at org.dom4j.io.SAXReader.read(SAXReader.java:484) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo rt.java:168) ... 126 more Leaving out the DTD "fixes" the issue, but then I cannot edit the xdoc-file in an XML-editor like the excellent visual XMLmind-editor (with xdoc-type-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] Created: (DOXIA-235) Confluence parser doesn't strip leading spaces for list items
Confluence parser doesn't strip leading spaces for list items - Key: DOXIA-235 URL: http://jira.codehaus.org/browse/DOXIA-235 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.0-alpha-10 Reporter: Vincent Massol For example: * item 1 generates a text of " item 1" instead of "item 1". -- 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-2971) Variables are not replaced into installed pom file
[
http://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130371#action_130371
]
Marco Lessard commented on MNG-2971:
Using maven 2.0.8, we still have the problem with the tag.
com.mycompany.odp
ocs-core
${ocs.release.version}
Properties in "project.parent.version" do NOT get substituted but properties in
"project.version" do.
We are on the process of migrating our 900 artifacts project to maven. Most of
those artifacts will share the same release version and inherit from the same
parent, so it is out of question to do a "search and replace".
Looks like a substitution bug to me.
For the moment, it is a show stopper for us that blocks the migration of our
900 artifacts.
> Variables are not replaced into installed pom file
> --
>
> Key: MNG-2971
> URL: http://jira.codehaus.org/browse/MNG-2971
> Project: Maven 2
> Issue Type: Bug
> Components: Deployment, Inheritance and Interpolation
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
> Fix For: 2.0.x
>
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.xxx.root
> root
> pom
> ${prop.version}
> My Project
> ...
>
> 3.0.20
>
>
> The installed pom is into
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> Thanks in advance
--
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-3513) Add filtering to determine if a artifact should be downloaded from a repository.
Add filtering to determine if a artifact should be downloaded from a repository. Key: MNG-3513 URL: http://jira.codehaus.org/browse/MNG-3513 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Reporter: Marco Beelen Then the settings.xml starts to contain various repositories maven will try to download artifacts from all defined repository until it is found. Since the central repo is the last repo being queried all other repositories will be queried for all artifacts as well. This causes the build to take extra unneccesary time and additional load on some repository servers. In order to prevent this I would like to be able to specify some filters on the repostories, so maven can check whether or not to ask a repository for a certain component. Suggestion for adjustments in settings.xml: atlassian Atlassian Repository http://repository.atlassian.com legacy com.atlassion codehaus Codehaus Repository http://repository.codehaus.org// org.codehaus central The default maven2 repository http://repo1.maven.org/maven2/ com.atlassion org.codehaus Maven should only attempt to download a certain artifact from a defined repository if the groupId of the artifact could be found on that server. If a repository contains an includes-filter, then only those groupId's configured should be downloaded there. If a repository contains an excludes-filter, then everything except those should be downloaded there. -- 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-25) Filtering of property values containing backslashes in path names still does not escape them?
[
http://jira.codehaus.org/browse/MRESOURCES-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130373#action_130373
]
Guillaume Wallet commented on MRESOURCES-25:
Hello,
I think it would be great if that issue could be solved, because it will enable
ability to share project between unix/linux and windows developpers.
Thx in advance for this work (I can't vote for this Issue)
Guillaume WALLET.
> Filtering of property values containing backslashes in path names still does
> not escape them?
> -
>
> Key: MRESOURCES-25
> URL: http://jira.codehaus.org/browse/MRESOURCES-25
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Environment: Windows
>Reporter: Bryan Carpenter
>
> This was originally reported as MRESOURCES-17, and I understood from the
> comments
> there it was fixed in version 2.2 of the plugin. But I have tried using that
> version of the
> resources plugin, and I am still seeing the same problem.
> My source property file contains:
> org.apache.ws.security.crypto.merlin.file=${basedir}/keys/x509.PFX.MSFT
> After filtering it looks like this:
>
> org.apache.ws.security.crypto.merlin.file=D:\cygwin\home\dbc\cvs\omii-packaging\source\ws-wss4j/keys/x509.PFX.MSFT
> and when the this is read in by `Properties.load()' the value ends up as:
> d:cygwinhomedbccvsomii-packagingsourcews-wss4j/keys/x509.PFX.MSFT
--
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-2756) parent resolution is done first before property interpolation
[
http://jira.codehaus.org/browse/MNG-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130377#action_130377
]
Marco Lessard commented on MNG-2756:
Using maven 2.0.8, we still have the problem with the tag.
com.mycompany.odp
ocs-core
${ocs.release.version}
Properties in "project.parent.version" do NOT get substituted but properties in
"project.version" do.
We are on the process of migrating our 900 artifacts project to maven. Most of
those artifacts will share the same release version and inherit from the same
parent, so it is out of question to do a "search and replace".
Looks like a substitution bug to me.
For the moment, it is a show stopper for us that blocks the migration of our
900 artifacts.
> parent resolution is done first before property interpolation
> -
>
> Key: MNG-2756
> URL: http://jira.codehaus.org/browse/MNG-2756
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.x, 2.1
>Reporter: Franz Allan Valencia See
> Fix For: 2.0.x
>
> Attachments: parent-filtering.zip
>
>
> Possible problems
> * using properties in the parent tag
> * using proeprties in the repositories tag with the parent being unknown
> except to that repo
> Attach is a sample project whose child project does not get built.
--
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: (MSOURCES-34) Allow change artifact type
Allow change artifact type -- Key: MSOURCES-34 URL: http://jira.codehaus.org/browse/MSOURCES-34 Project: Maven 2.x Source Plugin Issue Type: Improvement Affects Versions: 2.0.4 Environment: Any Reporter: Marvin Froeder At current time the type generated by this plugin is hard coded: AbstractSourceJarMojo line 177: projectHelper.attachArtifact( project, "java-source", getClassifier(), outputFile ); If this "java-source" is moved to some getType it will allow me to extends this abstract class instead of duplicating this source. Then I use org.ops4j.maven-inherit-plugin. I can provide patch if required. VELO -- 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-59) filtering with @property@
[ http://jira.codehaus.org/browse/MRESOURCES-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130398#action_130398 ] Denis Sadowski commented on MRESOURCES-59: -- I filter a number of property files with @property@ using version 2.2, and it usually works fine. For example if a file has the following line: Current Version : @property@ or [EMAIL PROTECTED]@.jar However, filtering becomes an issue if @ symbols are present inside of the file and are not indicative of a property. Example: [EMAIL PROTECTED] filters @property@ in file The property will fail to filter, but in the following only one of the two properties filter: [EMAIL PROTECTED] filters @property@ @ @property@ in file The first will still fail to filter, but the second will filter. >From what I can see when it finds an @, it pairs it with the next @ and >evaluates whats in between as a property, then continues to filter from the >next character after the second @. Also, if the last character in a filtered file is an upaired @, example: [EMAIL PROTECTED] @property@ @ the following exception is thrown during Maven execution: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.charAt(String.java:687) at org.apache.maven.plugin.resources.util.InterpolationFilterReader.read (InterpolationFilterReader.java:193) at org.apache.maven.plugin.resources.util.InterpolationFilterReader.read (InterpolationFilterReader.java:201) at org.apache.maven.plugin.resources.util.InterpolationFilterReader.read (InterpolationFilterReader.java:162) at java.io.Reader.read(Reader.java:123) at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212) at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200) at org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMoj o.java:269) at org.apache.maven.plugin.resources.ResourcesMojo.copyResources(Resourc esMojo.java:183) at org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo .java:100) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.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(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > filtering with @property@ > - > > Key: MRESOURCES-59 > URL: http://jira.codehaus.org/browse/MRESOURCES-59 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Stefano Fornari > > From the source code, it looks like @property@ should be expanded as well. It > does not work with the tests I've done -- 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: (MANTTASKS-108) Maven Ant Tasks are switching the Classloader of the Main Ant Thread
[
http://jira.codehaus.org/browse/MANTTASKS-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MANTTASKS-108.
---
Assignee: Herve Boutemy
Resolution: Fixed
Fix Version/s: 2.0.9
fixed in r646946
> Maven Ant Tasks are switching the Classloader of the Main Ant Thread
>
>
> Key: MANTTASKS-108
> URL: http://jira.codehaus.org/browse/MANTTASKS-108
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: deploy task
>Affects Versions: 2.0.8
> Environment: I have testet it on windows as well as linux.
>Reporter: Thomas Tardy
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: 2.0.9
>
>
> There is a thread on the user mailing list which describes the problem.
> http://www.nabble.com/Using-Maven-Ant-Tasks-in-a-CI-Environment-with-IBM-Jazz-tt16556859s177.html#a16574083
> The problem can be reproduced with the following script.
> The ant build script:
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> description
>
> classname="maven.test.task.MavenTestTask" />
>
>
>
>
>
>
> />
>
>
>
>
>
>
> The simple Ant Task:
> package maven.test.task;
> import org.apache.tools.ant.BuildException;
> import org.apache.tools.ant.Task;
> /**
> * Test task demonstrating Maven switching the class loader.
> */
> public class MavenTestTask extends Task {
> /* (non-Javadoc)
> * Intentionally not documented. See parent.
> */
> @Override
> public void execute() throws BuildException {
> log("Current Class Loader: " +
> Thread.currentThread().getContextClassLoader());
> }
>
> The output when run in Ant:
> Buildfile: C:\Maven\Test\build.xml
> default:
> [echo] Invoking test class that does nothing but echo the classloader
> [mavenTestTask] Current Class Loader: [EMAIL PROTECTED]
> [echo] Invoking maven artifact:pom task
> [echo] Invoking test class again that does nothing but echo the
> classloader
> [mavenTestTask] Current Class Loader: [EMAIL PROTECTED]
> BUILD SUCCESSFUL
> Total time: 871 milliseconds
> Thanks for your support!
--
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] Moved: (MNG-3514) MPIR ignores reports set declared in child modules
[ http://jira.codehaus.org/browse/MNG-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved MPIR-93 to MNG-3514: -- Affects Version/s: (was: 2.0.1) Complexity: Intermediate Key: MNG-3514 (was: MPIR-93) Project: Maven 2 (was: Maven 2.x Project Info Reports Plugin) > MPIR ignores reports set declared in child modules > -- > > Key: MNG-3514 > URL: http://jira.codehaus.org/browse/MNG-3514 > Project: Maven 2 > Issue Type: Bug >Reporter: Michael Osipov > > I have declared my parent POM to produce selective reports only, see > [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/pom.xml#L114]. > Then I reclared the child modules to produces less reports but they still > produce the same reports as the parent pom. See > [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/fckeditor-java/pom.xml#L127] > and > [there|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/fckeditor-java-demo/pom.xml#L105]. > this is a bug to me, breaking inheritance override. > You may [checkout|http://svn.fckeditor.net/FCKeditor.Java/branches/2.4/] my > project and try yourself. -- 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: (MPIR-93) MPIR ignores reports set declared in child modules
[ http://jira.codehaus.org/browse/MPIR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130418#action_130418 ] Dennis Lundberg commented on MPIR-93: - Yes, I think that this issue should be moved to the core Maven project in JIRA. I don't think it will/can be fixed in the 2.0.x series though. > MPIR ignores reports set declared in child modules > -- > > Key: MPIR-93 > URL: http://jira.codehaus.org/browse/MPIR-93 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug >Reporter: Michael Osipov > > I have declared my parent POM to produce selective reports only, see > [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/pom.xml#L114]. > Then I reclared the child modules to produces less reports but they still > produce the same reports as the parent pom. See > [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/fckeditor-java/pom.xml#L127] > and > [there|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/fckeditor-java-demo/pom.xml#L105]. > this is a bug to me, breaking inheritance override. > You may [checkout|http://svn.fckeditor.net/FCKeditor.Java/branches/2.4/] my > project and try yourself. -- 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-3515) Allow several synonymous main artifacts, e.g. zip and tar.gz, just like you can have with a classifier
Allow several synonymous main artifacts, e.g. zip and tar.gz, just like you can have with a classifier -- Key: MNG-3515 URL: http://jira.codehaus.org/browse/MNG-3515 Project: Maven 2 Issue Type: New Feature Reporter: David Jencks It's possible for a project to generate several synonymous main artifacts that are different packagings of the same content. The specific case I ran across is in https://svn.apache.org/repos/asf/activemq/branches/activemq-4.1 assembly module rev 646965. The build happily constructs apache-activemq-4.1-SNAPSHOT.tar.gz/tar.bz2/zip artifacts in target but does not install or deploy them. However if I add a "bin" classifier all the artifacts are installed/deployed. Another possible example that jdcasey suggested would be a project that constructs both dll and so files. I don't see how this could introduce any ambiguity since any dependency on a non-jar artifact has to AFAIK specify the type explicitly. -- 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-3497) rar, par and ejb3 archives should not be added to classpath
[
http://jira.codehaus.org/browse/MNG-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MNG-3497.
--
Assignee: Herve Boutemy
Resolution: Fixed
Fix Version/s: 2.0.10
fixed in r646967
> rar, par and ejb3 archives should not be added to classpath
> ---
>
> Key: MNG-3497
> URL: http://jira.codehaus.org/browse/MNG-3497
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.9
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.0.10
>
>
> like war files, should be declared in {{components.xml}} as
> {code:xml}true
> java
> false{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] Created: (MNG-3516) Make dependencies on javaee artifacts such as war, ear, rar get the contents into the classpath.
Make dependencies on javaee artifacts such as war, ear, rar get the contents into the classpath. Key: MNG-3516 URL: http://jira.codehaus.org/browse/MNG-3516 Project: Maven 2 Issue Type: New Feature Reporter: David Jencks Some javaee servers such as geronimo and IIRC jboss let you construct classloader hierarchies where the classes from one javaee app can be available in another javaee app's classloader. Maven ought to be able to support stuff like this by having a more flexible model of how to get the classes from something more complicated than a jar into a classpath. This is most important for war files where the WEB-INF/classes directory generally contains stuff that won't be available anywhere else in a maven repo. For ear libs and rars presumably the contents are available as independent artifacts in a repo. -- 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-2014) http://repo1.maven.org/maven2/javax/activation/activation/1.0.2/ is missing the jars
http://repo1.maven.org/maven2/javax/activation/activation/1.0.2/ is missing the jars Key: MAVENUPLOAD-2014 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2014 Project: maven-upload-requests Issue Type: Bug Reporter: SebbASF http://repo1.maven.org/maven2/javax/activation/activation/1.0.2/ has POM and metadata - but no jars - neither binary nor source. -- 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-2015) Maven1 Clover 2 Plugin 2.2.0 release
Maven1 Clover 2 Plugin 2.2.0 release Key: MAVENUPLOAD-2015 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2015 Project: maven-upload-requests Issue Type: Task Reporter: James William Dumay Clover is a code coverage tool for Java Please upload :) -- 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: (MJAR-102) Using ${artifcactId}-Extention-Name in MANIFEST file can create invalid MANIFEST files
[
http://jira.codehaus.org/browse/MJAR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sridhar Komandur updated MJAR-102:
--
Attachment: nautilus-debug-log.txt
Please find the attached patch file that fixes this issue by replacing '.' with
'_' in the artifactId
> Using ${artifcactId}-Extention-Name in MANIFEST file can create invalid
> MANIFEST files
> --
>
> Key: MJAR-102
> URL: http://jira.codehaus.org/browse/MJAR-102
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.0, 2.1, 2.2
> Environment: Java HotSpot(TM) Client VM (build 1.5.0_13-121)
>Reporter: Todd Caine
> Attachments: nautilus-debug-log.txt
>
>
> If you have a maven dependency on an something with an artifactId that
> contains a '.' in it, it creates an illegal manifest file when trying to
> create an executable jar file (java -jar foo.jar).
> Exception in thread "main" java.io.IOException: invalid header field name:
> geronimo-jms_1.1_spec-Extension-Name
> at java.util.jar.Attributes.read(Attributes.java:409)
> at java.util.jar.Manifest.read(Manifest.java:167)
> at java.util.jar.Manifest.(Manifest.java:52)
> at java.util.jar.JarFile.getManifestFromReference(JarFile.java:158)
> at java.util.jar.JarFile.getManifest(JarFile.java:145)
> Here's my configuration:
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> my.class.Test
> true
> true
> ./lib/
>
>
>
>
> I added the following dependency:
>
> org.apache.geronimo.specs
> geronimo-jms_1.1_spec
>
> When the maven-archiver tries to create a manifest file with the JARs
> dependencies it adds the following to the META-INF/MANIFEST.MF file:
> geronimo-jms_1.1_spec-Extension-Name: geronimo-jms_1.1_spec
> geronimo-jms_1.1_spec-Implementation-Version: 1.0
> After digging around a bit it turns out that '.' is an illegal character in
> the "Extension-Name" and "Implementaion-Version" header fields, which leads
> to the following exception when I try to run "java -jar Test.jar"
> java.io.IOException: invalid header field name:
> geronimo-jms_1.1_spec-Extension-Name
--
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: (NMAVEN-117) The project generated by the NMaven netexecutable archetype defaults to version 0.14-incubating-SNAPSHOT when it should be 1.0-SNAPSHOT
[ http://jira.codehaus.org/browse/NMAVEN-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Napoleon Esmundo C. Ramirez updated NMAVEN-117: --- Summary: The project generated by the NMaven netexecutable archetype defaults to version 0.14-incubating-SNAPSHOT when it should be 1.0-SNAPSHOT (was: The project generated by the NMaven netexecutable archetype defaults to version 0.14-maestro-1.5 when it should be 1.0-SNAPSHOT) > The project generated by the NMaven netexecutable archetype defaults to > version 0.14-incubating-SNAPSHOT when it should be 1.0-SNAPSHOT > --- > > Key: NMAVEN-117 > URL: http://jira.codehaus.org/browse/NMAVEN-117 > Project: NMaven > Issue Type: Bug >Affects Versions: 0.14 (Unreleased) > Environment: Windows XP SP2, VS2005, JDK 1.5, Maven 2.0.7 >Reporter: Napoleon Esmundo C. Ramirez > Attachments: NMAVEN-117.patch > > > The project generated by the NMaven netexecutable archetype defaults to > version 0.14-maestro-1.5 when it should be 1.0-SNAPSHOT. It should probably > be filtered out. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
