[jira] Created: (MDEPLOY-133) Add a configurable parameter to allow retrying deployment
Add a configurable parameter to allow retrying deployment - Key: MDEPLOY-133 URL: http://jira.codehaus.org/browse/MDEPLOY-133 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Components: deploy:deploy, deploy:deploy-file Affects Versions: 2.6 Reporter: Stephen Connolly In quite a number of cases I have had large build releases fail due to a sudden network very temporary outage affecting one upload operation. it would be good if there was a configurable parameter that would allow the user to specify retrying deployment of individual files a couple of times before bombing out with an error. The parameter should default to 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] Closed: (MDEPLOY-133) Add a configurable parameter to allow retrying deployment
[ http://jira.codehaus.org/browse/MDEPLOY-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-133. Resolution: Fixed Fix Version/s: 2.7 Assignee: Stephen Connolly r1126367 > Add a configurable parameter to allow retrying deployment > - > > Key: MDEPLOY-133 > URL: http://jira.codehaus.org/browse/MDEPLOY-133 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy, deploy:deploy-file >Affects Versions: 2.6 >Reporter: Stephen Connolly >Assignee: Stephen Connolly > Fix For: 2.7 > > > In quite a number of cases I have had large build releases fail due to a > sudden network very temporary outage affecting one upload operation. it would > be good if there was a configurable parameter that would allow the user to > specify retrying deployment of individual files a couple of times before > bombing out with an error. > The parameter should default to 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] Created: (MANTTASKS-219) artifact:dependencies and ant's restrict name resource filtering does not work
artifact:dependencies and ant's restrict name resource filtering does not work
--
Key: MANTTASKS-219
URL: http://jira.codehaus.org/browse/MANTTASKS-219
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.0.10
Environment: SUSE Linux Enterprise Server 10 SP1 (x86_64)
Ant 1.7.0
Reporter: Wim Symons
We have an Ant build file which calls maven-ant-tasks's dependencies to copy a
bunch of dependencies.
Since we need to exclude some of those jars, we used Ant's resource selectors
to restrict the fileset produced by maven-ant-tasks.
A small snippet from our build.xml:
{code:xml}
{code}
But when we ran the target, no files at all were copied. After a long time
searching, we stumbled on the fact that it worked when we left out the line
{noformat}{noformat} Our local Maven
repository was located in {{/home/user/maven-repository}}. As it seems the
pattern given doesn't respect the standard Ant patterns and also matches the
directories in between (as {{maven*}} matches {{maven-repository}}).
As a workaround, we renamed the directory containing the Maven repository to
something that doesn't match any of the used patterns.
--
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: (MANTTASKS-219) artifact:dependencies and ant's restrict name resource filtering does not work
[
http://jira.codehaus.org/browse/MANTTASKS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268152#action_268152
]
Wim Symons commented on MANTTASKS-219:
--
Reported bug at https://issues.apache.org/bugzilla/show_bug.cgi?id=51243 as
well.
> artifact:dependencies and ant's restrict name resource filtering does not work
> --
>
> Key: MANTTASKS-219
> URL: http://jira.codehaus.org/browse/MANTTASKS-219
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.0.10
> Environment: SUSE Linux Enterprise Server 10 SP1 (x86_64)
> Ant 1.7.0
>Reporter: Wim Symons
>
> We have an Ant build file which calls maven-ant-tasks's dependencies to copy
> a bunch of dependencies.
> Since we need to exclude some of those jars, we used Ant's resource selectors
> to restrict the fileset produced by maven-ant-tasks.
> A small snippet from our build.xml:
> {code:xml}
>
>
>filesetid="dependencies.core" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> But when we ran the target, no files at all were copied. After a long time
> searching, we stumbled on the fact that it worked when we left out the line
> {noformat}{noformat} Our local Maven
> repository was located in {{/home/user/maven-repository}}. As it seems the
> pattern given doesn't respect the standard Ant patterns and also matches the
> directories in between (as {{maven*}} matches {{maven-repository}}).
> As a workaround, we renamed the directory containing the Maven repository to
> something that doesn't match any of the used patterns.
--
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: (MGPG-35) Add support for MDEPLOY-133
Add support for MDEPLOY-133 --- Key: MGPG-35 URL: http://jira.codehaus.org/browse/MGPG-35 Project: Maven 2.x GPG Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Stephen Connolly Priority: Minor -- 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: (MGPG-36) Add suport for MDEPLOY-48
Add suport for MDEPLOY-48 - Key: MGPG-36 URL: http://jira.codehaus.org/browse/MGPG-36 Project: Maven 2.x GPG Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Stephen Connolly Priority: Minor -- 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: (MGPG-36) Add suport for MDEPLOY-48
[ http://jira.codehaus.org/browse/MGPG-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MGPG-36. Fix Version/s: 1.3 Resolution: Fixed r1126405 > Add suport for MDEPLOY-48 > - > > Key: MGPG-36 > URL: http://jira.codehaus.org/browse/MGPG-36 > Project: Maven 2.x GPG Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Stephen Connolly >Assignee: Stephen Connolly >Priority: Minor > Fix For: 1.3 > > -- 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: (MGPG-35) Add support for MDEPLOY-133
[ http://jira.codehaus.org/browse/MGPG-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MGPG-35. Fix Version/s: 1.3 Resolution: Fixed r1126405 > Add support for MDEPLOY-133 > --- > > Key: MGPG-35 > URL: http://jira.codehaus.org/browse/MGPG-35 > Project: Maven 2.x GPG Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Stephen Connolly >Assignee: Stephen Connolly >Priority: Minor > Fix For: 1.3 > > -- 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: (MDEPLOY-53) Should return an error when deploying a version of SNAPSHOT
[
http://jira.codehaus.org/browse/MDEPLOY-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MDEPLOY-53.
---
Resolution: Not A Bug
I think this is a misunderstanding of how version numbers work in Maven 2+
> Should return an error when deploying a version of SNAPSHOT
> ---
>
> Key: MDEPLOY-53
> URL: http://jira.codehaus.org/browse/MDEPLOY-53
> Project: Maven 2.x Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Kristof Van Cleemput
>
> The snapshot that I want to use in a maven2 project is created by maven1.
> So I deployed it with the following command:
> mvn deploy:deploy-file -DgroupId=GROUP -DartifactId=ARTIFACT
> -Dversion=SNAPSHOT -Dpackaging=jar -Dfile=ARTIFACT -SNAPSHOT.jar
> -DrepositoryId=REPO-Durl=scp://REPO/maven2/dev
> This is NOT correct for maven 2 it should state -Dversion=x.x-SNAPSHOT but
> everything just deployed without errors.
> Later when using ${baseVersion} it doesn't return SNAPSHOT but the number
> After cleaning the repo and redeploying the jar with x.x-SNAPHOT everything
> worked like it should => ${baseVersion} returns x.x-SNAPSHOT
--
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: (MDEPLOY-75) uniqueVersion, includeAttachedArtifacts
[
http://jira.codehaus.org/browse/MDEPLOY-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MDEPLOY-75.
---
Resolution: Won't Fix
A pom based project has http://maven.apache.org/pom.html#Repository which
allows specification of the uniqueVersion parameter in
/project/distributionManagement/snapshotRepository
There is no need for the deploy goal of the maven-deploy-plugin to have this
parameter.
The other feature you were looking for goes against the whole spirit of the
lifecycle, but if you still want it considered please raise it in a separate
JIRA (keep one issue per JIRA)
> uniqueVersion, includeAttachedArtifacts
> ---
>
> Key: MDEPLOY-75
> URL: http://jira.codehaus.org/browse/MDEPLOY-75
> Project: Maven 2.x Deploy Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Francis Korning
> Attachments: MDEPLOY-75-patch.zip
>
>
> by default the maven deploy plugin is inconsistent in its use of the
> uniqueVersion flag, which can be set manually in the explicit deploy-file
> goal but isn't present in the implicit deploy goal.
> another thing we'd like to do is disabling the deployment of deliverable
> attached artifacts, or allowing to select only specific artifacts,
> classifiers, or assemblies. for deployment.
> new configuration parameters include:
> || parameter || type || default || description ||
> | uniqueVersion | boolean | true | use uniqueVersion
> buildnumbers (${artifactId}-mmdd-HHmmss-nn) |
> | includeAttachedArtifacts| boolean | true | also deploy attached
> artifacts |
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-117) Use GAV from specified pomFIle but not deploy the pom
[ http://jira.codehaus.org/browse/MDEPLOY-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-117. Resolution: Duplicate MDEPLOY-48 is essentially a duplicate of a large chunk of this issue and the previously linked issue covers the remainder > Use GAV from specified pomFIle but not deploy the pom > - > > Key: MDEPLOY-117 > URL: http://jira.codehaus.org/browse/MDEPLOY-117 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy-file >Affects Versions: 2.4 > Environment: Windows XP > Sun Java JDK 1.6.0_18 > Maven 3.0-alpha6 >Reporter: Anders Hammar > > For or MRM (Nexus) we have redeployment turned off. When deploying a lot of > 3rd party artifacts to it, we do that by a script using the deploy-file goal. > This works just fine for the jar artifact, but when the artifact is just a > pom or when also trying to deploying a sources artifact, we want to use GAV > from a specified pom. However, deploy-file will then also try to deploy the > pom which makes the plugin fail as redeployment is turned off. > I'll explain through a simple example: > We have a pom artifact that we want to deploy. We do that like this: > mvn deploy:deploy-file -Dfile=abc.pom -DpomFile=abc.pom -DrepositoryId=... > -Durl=... > We want to use GAV from the POM and not specify that through params. > Otherwise we need to parse the pom for that info, which is difficult in > Windows. > What happens is that the pom artifact deploys fine, but then plugin also > tries to deploy the pom which then fails as reployment is turned off in the > repo. This makes it very hard to see if the script executes ok or not. -- 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: (MDEPLOY-95) Rename plugin (and life-cycle phase) from Deploy to Publish
[ http://jira.codehaus.org/browse/MDEPLOY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-95. --- Resolution: Won't Fix These are standardized names from the Maven world. I agree that better names should have been chosen, but we are where we are and they are what they are > Rename plugin (and life-cycle phase) from Deploy to Publish > --- > > Key: MDEPLOY-95 > URL: http://jira.codehaus.org/browse/MDEPLOY-95 > Project: Maven 2.x Deploy Plugin > Issue Type: Wish >Reporter: Neil Crow >Priority: Minor > > Developers often speak about deploying their application to this server or > that server, which does not correspond to the usage that maven has for > "Deploy". > To remedy this situation, and to reduce confusion due to overloaded usage > (Fallacy of Equivocation), I suggest that the Deploy plugin and related > life-cycle phase be renamed to the Publish plugin. > A quick google on "maven deploy publish" shows that many people out there are > using the Deploy plugin to Publish artifacts to a maven repository. > After Publishing to a maven repository, they will deploy to a server. -- 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: (MDEPLOY-124) Deploy without build
[
http://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268170#action_268170
]
Stephen Connolly commented on MDEPLOY-124:
--
so this would be a pair of goals, e.g.
deploy:imprint (which takes persists all the attached artifacts and I'm
guessing checksums of them for safety to a file in ${project.build.directory})
deploy:publish (which reads back in the persisted artifact file and publishes
those artifacts)
> Deploy without build
>
>
> Key: MDEPLOY-124
> URL: http://jira.codehaus.org/browse/MDEPLOY-124
> Project: Maven 2.x Deploy Plugin
> Issue Type: New Feature
>Reporter: Paul Gier
>
> We have a use case where we would like to run a build (up to the install
> phase) and then deploy at a later time. Currently, the deploy plugin
> requires that a full build be re-run in order to deploy. Since the build
> does not record the list of attached artifacts, the deploy plugin would need
> some way to record the list of attached artifacts, and then read them later
> for deployment.
> Possibly a new goal could be introduced which would create a list of attached
> artfiacts. Then the deploy goal could optionally read from this list.
--
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: (MDEPLOY-124) Deploy without build
[ http://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268171#action_268171 ] Wendy Smoak commented on MDEPLOY-124: - It sounds like the release staging feature of one of the various artifact repositories would be useful here. You deploy to one place, do whatever, and then promote the release later. > Deploy without build > > > Key: MDEPLOY-124 > URL: http://jira.codehaus.org/browse/MDEPLOY-124 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature >Reporter: Paul Gier > > We have a use case where we would like to run a build (up to the install > phase) and then deploy at a later time. Currently, the deploy plugin > requires that a full build be re-run in order to deploy. Since the build > does not record the list of attached artifacts, the deploy plugin would need > some way to record the list of attached artifacts, and then read them later > for deployment. > Possibly a new goal could be introduced which would create a list of attached > artfiacts. Then the deploy goal could optionally read from this list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-584) Useless error message "error in opening zip file" in DefaultSiteRenderer.createContextForSkin()
Useless error message "error in opening zip file" in
DefaultSiteRenderer.createContextForSkin()
---
Key: MSITE-584
URL: http://jira.codehaus.org/browse/MSITE-584
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:run
Affects Versions: 3.0-beta-3
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): "error in opening zip file"
Which zip file?
--
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-584) Useless error message "error in opening zip file" in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/MSITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268172#action_268172
]
Aaron Digulla commented on MSITE-584:
-
Here is the full stack trace:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on
project ExBib: Error during site generation: error in opening zip file -> [Help
1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on
project ExBib: Error during site generation
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during site
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:131)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:127)
at java.util.zip.ZipFile.(ZipFile.java:144)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.createContextForSkin(DefaultSiteRenderer.java:616)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:312)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:138)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
... 21 more
{code}
> Useless error message "error in opening zip file" in
> DefaultSiteRenderer.createContextForSkin()
> ---
>
> Key: MSITE-584
> URL: http://jira.codehaus.org/browse/MSITE-584
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:run
>Affects Versions: 3.0-beta-3
>Reporter: Aaron Digulla
>
> When I run {{mvn site}} on my project, I get an exception in
> DefaultSiteRenderer.createContextForSkin(): "error in opening zip file"
> Which zip file?
--
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-584) Useless error message "error in opening zip file" in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/MSITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268173#action_268173
]
Aaron Digulla commented on MSITE-584:
-
Please add a {{try/catch}} in {{createContextForSkin()}} that adds the file
name to the error message (with absolute path).
> Useless error message "error in opening zip file" in
> DefaultSiteRenderer.createContextForSkin()
> ---
>
> Key: MSITE-584
> URL: http://jira.codehaus.org/browse/MSITE-584
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:run
>Affects Versions: 3.0-beta-3
>Reporter: Aaron Digulla
>
> When I run {{mvn site}} on my project, I get an exception in
> DefaultSiteRenderer.createContextForSkin(): "error in opening zip file"
> Which zip file?
--
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-431) Doxia creates illegal URLs from local paths
Doxia creates illegal URLs from local paths --- Key: DOXIA-431 URL: http://jira.codehaus.org/browse/DOXIA-431 Project: Maven Doxia Issue Type: Bug Components: Core Affects Versions: 1.2 Reporter: Aaron Digulla If a local resource contains characters which are illegal in a URL, Doxia creates illegal code or crashes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-431) Doxia creates illegal URLs from local paths
[
http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268177#action_268177
]
Aaron Digulla commented on DOXIA-431:
-
In an external project, there are image files which contain spaces. Instead of
replacing the spaces with %20 or calling {{java.net.URLEncoder.encode()}},
Doxia tries to call {{new java.net.URL("images/The ExTeX Project.png"}} which
fails.
I tried a fix but couldn't get it to work in a couple of hours. The problem is
that you use a lot of Strings when you should be using URLs (or at least a
URL-like type). Without such a type, it's impossible to know when a URL must be
encoded/decoded.
Example stacktrace:
{code}
Caused by: java.lang.IllegalArgumentException
at java.net.URI.create(URI.java:842)
at
org.apache.maven.doxia.site.decoration.inheritance.URIPathDescriptor.(URIPathDescriptor.java:69)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseLink(DefaultDecorationModelInheritanceAssembler.java:361)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseBannerPaths(DefaultDecorationModelInheritanceAssembler.java:162)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:61)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1221)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:458)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:285)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:140)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:124)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
... 20 more
Caused by: java.net.URISyntaxException: Illegal character in path at index 10:
images/The ExTeX Project.png
at java.net.URI$Parser.fail(URI.java:2809)
at java.net.URI$Parser.checkChars(URI.java:2982)
at java.net.URI$Parser.parseHierarchical(URI.java:3066)
at java.net.URI$Parser.parse(URI.java:3024)
at java.net.URI.(URI.java:578)
at java.net.URI.create(URI.java:840)
... 30 more
{code}
> Doxia creates illegal URLs from local paths
> ---
>
> Key: DOXIA-431
> URL: http://jira.codehaus.org/browse/DOXIA-431
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2
>Reporter: Aaron Digulla
>
> If a local resource contains characters which are illegal in a URL, Doxia
> creates illegal code or crashes.
--
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: (MDEPLOY-124) Deploy without build
[ http://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268189#action_268189 ] Paul Gier commented on MDEPLOY-124: --- Maybe instead of a new "imprint" goal, there could just be an option to the existing "deploy" goal which would create the list instead of uploading the artifacts. Something like "-DprepareForPublish". Then the second goal "publish" could read the list of files and actually do the deployment. > Deploy without build > > > Key: MDEPLOY-124 > URL: http://jira.codehaus.org/browse/MDEPLOY-124 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature >Reporter: Paul Gier > > We have a use case where we would like to run a build (up to the install > phase) and then deploy at a later time. Currently, the deploy plugin > requires that a full build be re-run in order to deploy. Since the build > does not record the list of attached artifacts, the deploy plugin would need > some way to record the list of attached artifacts, and then read them later > for deployment. > Possibly a new goal could be introduced which would create a list of attached > artfiacts. Then the deploy goal could optionally read from this list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268196#action_268196 ] S Daigle commented on SUREFIRE-742: --- Hi Kristian. It's Monday morning here and I tried reproducing the failure on the same machine we were consistently seeing the failure on late last week and its not crashing at the moment. I can get you the -X run if you still like but I dont know if it would help without the error condition. Please let me know and Ill get you what I can. If we can reproduce the problem again, I will get you the information you requested. > Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException > errors > --- > > Key: SUREFIRE-742 > URL: http://jira.codehaus.org/browse/SUREFIRE-742 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: Backlog > Environment: Linux x64 >Reporter: S Daigle > Attachments: sf.txt, sf2.txt, sf3.txt > > > We're using the latest 2.8.2-SNAPSHOT > (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic > errors with some of our tests: > Exception in thread "ThreadedStreamConsumer" java.lang.RuntimeException: > java.util.StringTokenizer@5051207c > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.util.NoSuchElementException > at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) > ... 3 more > We've also noted, when run individually, maven reports FAILED but when run > with a group of tests, we still see the failures but maven reports SUCCESS. I > attached a log with the individual test run using "mvn -e". -- 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: (MRELEASE-521) release:perform does not take the settings specified by the -s option
[ http://jira.codehaus.org/browse/MRELEASE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268199#action_268199 ] Christoph Kutzinski commented on MRELEASE-521: -- I've just confirmed that it still happens with release-plugin 2.1. Another workaround is to append -Darguments="-s" to the release:perform call. E.g. mvn -s release:prepare release:perform -Darguments="-s" See also http://maven.40175.n5.nabble.com/mvn-release-perform-does-not-honor-servers-server-in-alternate-settings-location-td70612.html > release:perform does not take the settings specified by the -s option > -- > > Key: MRELEASE-521 > URL: http://jira.codehaus.org/browse/MRELEASE-521 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.0-beta-7 >Reporter: Kay Kay > > # mvn -s release:perform > does not take the settings. > If we copy the same to - ~/.m2/settings.xml > # mvn release:perform > works fine. > Something does not add up. -- 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-5099) Issue with properties inherited from parent POM
Issue with properties inherited from parent POM
---
Key: MNG-5099
URL: http://jira.codehaus.org/browse/MNG-5099
Project: Maven 2 & 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0.3
Environment: java 1.6.0_24
Reporter: Dan Checkoway
This worked absolutely fine in 2.2.1. Fails in 3.0.3.
./deps/pom.xml has:
5.1.16
./library/pom.xml has:
com.mycompany
base
1.0
../deps/pom.xml
...
mysql
mysql-connector-java
${mysql.connector.version}
runtime
./otherlib/pom.xml has:
com.mycompany
mycompany-library
1.0
compile
cd library
mvn deploy (all good)
cd otherlib
mvn compile (fails)
[ERROR] Failed to execute goal on project mycompany-otherlib: Could not resolve
dependencies for project com.mycompany:mycompany-otherlib:jar:1.0: Failure to
find mysql:mysql-connector-java:jar:${mysql.connector.version} in
http://repo1.maven.org/maven2 was cached in the local repository, resolution
will not be reattempted until the update interval of central has elapsed or
updates are forced -> [Help 1]
It's as if it's treating the ${mysql.connector.version} in the runtime
dependency literally, instead of resolving that property.
I can work around this by adding this to library/pom.xml:
5.1.16
Please let me know if I'm missing something simple, but it worked fine without
the workaround in 2.2.1, and this looks like a bug to me!
--
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: (DOXIASITETOOLS-60) Useless error message "error in opening zip file" in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl moved MSITE-584 to DOXIASITETOOLS-60:
---
Component/s: (was: site:run)
Site renderer
Affects Version/s: (was: 3.0-beta-3)
1.2
Issue Type: Improvement (was: Bug)
Key: DOXIASITETOOLS-60 (was: MSITE-584)
Project: Maven Doxia Sitetools (was: Maven 2.x and 3.x Site
Plugin)
> Useless error message "error in opening zip file" in
> DefaultSiteRenderer.createContextForSkin()
> ---
>
> Key: DOXIASITETOOLS-60
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.2
>Reporter: Aaron Digulla
>
> When I run {{mvn site}} on my project, I get an exception in
> DefaultSiteRenderer.createContextForSkin(): "error in opening zip file"
> Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIASITETOOLS-60) Useless error message "error in opening zip file" in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268207#action_268207
]
Lukas Theussl commented on DOXIASITETOOLS-60:
-
What skin are you using (mvn site:effective-site)? Can you check if that skin
jar is not corrupt?
> Useless error message "error in opening zip file" in
> DefaultSiteRenderer.createContextForSkin()
> ---
>
> Key: DOXIASITETOOLS-60
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.2
>Reporter: Aaron Digulla
>
> When I run {{mvn site}} on my project, I get an exception in
> DefaultSiteRenderer.createContextForSkin(): "error in opening zip file"
> Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268209#action_268209 ] Kristian Rosenvold commented on SUREFIRE-742: - Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one -unlikely- culprit but I'd really like to see a likely culprit that I can understand) So please let me know how this works out, any which direction. > Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException > errors > --- > > Key: SUREFIRE-742 > URL: http://jira.codehaus.org/browse/SUREFIRE-742 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: Backlog > Environment: Linux x64 >Reporter: S Daigle > Attachments: sf.txt, sf2.txt, sf3.txt > > > We're using the latest 2.8.2-SNAPSHOT > (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic > errors with some of our tests: > Exception in thread "ThreadedStreamConsumer" java.lang.RuntimeException: > java.util.StringTokenizer@5051207c > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.util.NoSuchElementException > at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) > ... 3 more > We've also noted, when run individually, maven reports FAILED but when run > with a group of tests, we still see the failures but maven reports SUCCESS. I > attached a log with the individual test run using "mvn -e". -- 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: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268209#action_268209 ] Kristian Rosenvold edited comment on SUREFIRE-742 at 5/23/11 1:03 PM: -- Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one /unlikely/ culprit but I'd really like to see a /likely/ culprit that I can understand) So please let me know how this works out, any which direction. was (Author: krosenvold): Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one -unlikely- culprit but I'd really like to see a likely culprit that I can understand) So please let me know how this works out, any which direction. > Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException > errors > --- > > Key: SUREFIRE-742 > URL: http://jira.codehaus.org/browse/SUREFIRE-742 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: Backlog > Environment: Linux x64 >Reporter: S Daigle > Attachments: sf.txt, sf2.txt, sf3.txt > > > We're using the latest 2.8.2-SNAPSHOT > (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic > errors with some of our tests: > Exception in thread "ThreadedStreamConsumer" java.lang.RuntimeException: > java.util.StringTokenizer@5051207c > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.util.NoSuchElementException > at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) > ... 3 more > We've also noted, when run individually, maven reports FAILED but when run > with a group of tests, we still see the failures but maven reports SUCCESS. I > attached a log with the individual test run using "mvn -e". -- 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: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268209#action_268209 ] Kristian Rosenvold edited comment on SUREFIRE-742 at 5/23/11 1:04 PM: -- Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one /unlikely/ culprit but I'd really like to see a /likely/ culprit that I can understand) So please let me know how this works out, any which direction. The -X log is only useful when the problem occurs. was (Author: krosenvold): Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one /unlikely/ culprit but I'd really like to see a /likely/ culprit that I can understand) So please let me know how this works out, any which direction. > Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException > errors > --- > > Key: SUREFIRE-742 > URL: http://jira.codehaus.org/browse/SUREFIRE-742 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: Backlog > Environment: Linux x64 >Reporter: S Daigle > Attachments: sf.txt, sf2.txt, sf3.txt > > > We're using the latest 2.8.2-SNAPSHOT > (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic > errors with some of our tests: > Exception in thread "ThreadedStreamConsumer" java.lang.RuntimeException: > java.util.StringTokenizer@5051207c > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.util.NoSuchElementException > at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) > ... 3 more > We've also noted, when run individually, maven reports FAILED but when run > with a group of tests, we still see the failures but maven reports SUCCESS. I > attached a log with the individual test run using "mvn -e". -- 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: (DOXIASITETOOLS-60) Useless error message "error in opening zip file" in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIASITETOOLS-60.
---
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Lukas Theussl
Improved error message:
[r1126622|http://svn.apache.org/viewvc?rev=1126622&view=rev]
> Useless error message "error in opening zip file" in
> DefaultSiteRenderer.createContextForSkin()
> ---
>
> Key: DOXIASITETOOLS-60
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.2
>Reporter: Aaron Digulla
>Assignee: Lukas Theussl
> Fix For: 1.3
>
>
> When I run {{mvn site}} on my project, I get an exception in
> DefaultSiteRenderer.createContextForSkin(): "error in opening zip file"
> Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-585) site-deploy: empty deploy protocol when properties are used
site-deploy: empty deploy protocol when properties are used --- Key: MSITE-585 URL: http://jira.codehaus.org/browse/MSITE-585 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.3 Reporter: Lukas Theussl See http://www.mail-archive.com/dev@maven.apache.org/msg88029.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: (DOXIA-431) Doxia creates illegal URLs from local paths
[ http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268215#action_268215 ] Lukas Theussl commented on DOXIA-431: - Can you be more specific: where does this image come from, from an apt/xdoc source file or site.xml? Doxia 1.2 is not used yet in any site release so I assume you are using a snapshot? Is this a regression then? Is it documented somewhere that image/file references may contain spaces (just for my education, I don't think eg that the apt reference is sufficiently precise in many respects)? > Doxia creates illegal URLs from local paths > --- > > Key: DOXIA-431 > URL: http://jira.codehaus.org/browse/DOXIA-431 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.2 >Reporter: Aaron Digulla > > If a local resource contains characters which are illegal in a URL, Doxia > creates illegal code or crashes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268216#action_268216 ] S Daigle commented on SUREFIRE-742: --- My nexus server is definitely pulling in your latest version(s). When you initially flagged this for me before, I'm always looking in my Nexus repo and my M2 cache to make sure we're getting the latest/greatest version you post. It could be that there were some code changes on our end since last Friday that could be masking the problem we were seeing. Ill keep my eye on it and if I can get you a -X run of the crash, Ill definitely get it to you. > Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException > errors > --- > > Key: SUREFIRE-742 > URL: http://jira.codehaus.org/browse/SUREFIRE-742 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: Backlog > Environment: Linux x64 >Reporter: S Daigle > Attachments: sf.txt, sf2.txt, sf3.txt > > > We're using the latest 2.8.2-SNAPSHOT > (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic > errors with some of our tests: > Exception in thread "ThreadedStreamConsumer" java.lang.RuntimeException: > java.util.StringTokenizer@5051207c > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.util.NoSuchElementException > at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) > ... 3 more > We've also noted, when run individually, maven reports FAILED but when run > with a group of tests, we still see the failures but maven reports SUCCESS. I > attached a log with the individual test run using "mvn -e". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268225#action_268225 ] Kristian Rosenvold commented on SUREFIRE-742: - A few potential problems fixed in r1126700 and 1126701 > Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException > errors > --- > > Key: SUREFIRE-742 > URL: http://jira.codehaus.org/browse/SUREFIRE-742 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: Backlog > Environment: Linux x64 >Reporter: S Daigle > Attachments: sf.txt, sf2.txt, sf3.txt > > > We're using the latest 2.8.2-SNAPSHOT > (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic > errors with some of our tests: > Exception in thread "ThreadedStreamConsumer" java.lang.RuntimeException: > java.util.StringTokenizer@5051207c > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.util.NoSuchElementException > at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) > ... 3 more > We've also noted, when run individually, maven reports FAILED but when run > with a group of tests, we still see the failures but maven reports SUCCESS. I > attached a log with the individual test run using "mvn -e". -- 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-5100) Hints for setting mem options of maven&plug-ins (for parallel builds)
Hints for setting mem options of maven&plug-ins (for parallel builds) - Key: MNG-5100 URL: http://jira.codehaus.org/browse/MNG-5100 Project: Maven 2 & 3 Issue Type: Improvement Components: Documentation: Guides Affects Versions: 3.0.3 Reporter: Kari J. Niemi (I enabled parallel builds of maven3 for my project in CI server, it was running quite nicely giving me much faster builds for a multi-module build. But... it brought our CI server on it's knees, other projects suffered from this and the CI build server admin bashed me to get back to serial build :D... oh, he's such a nice guy :D...) I did some googling around and found out that in Linux, forking new processes may be extremely slow in case the parent that forks, has a great memory print. Well, in the past I had (of course) optimized my build for maven2 by throwing it more (some? no,no... _lots_ of) memory with MAVEN_OPTS by setting both Xms and Xms to the same huge value, not forgetting the MaxPermSize and PermSize. I suppose this, together with the linux forking "feature", might cause the extreme cpu load? And of course the CI server process itself has an even bigger memory print, times ten or something, fortunately I suppose it's not doing so much forking... I suppose the memory tuning should/could be done quite differently when using parallel build feature because the mem is then used in the forked processes which are smaller? So in parallel build I might set those mem options pretty low, I guess? And also I could be setting "-client"-mode manually -because otherwise jvm would think it should be running in server mode (due to running in server HW. Actually I don't quite understand why jvm anyway decides based on HW whether it should be running in server or client mode - there's no such relation -not every jvm running on server HW is really a server process...) Is there anything that we could be improve in maven/maven documentation in this respect? -- 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-5100) Hints for setting mem options of maven&plug-ins (for parallel builds)
[ http://jira.codehaus.org/browse/MNG-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268239#action_268239 ] Kari J. Niemi commented on MNG-5100: ( If in doubt about forking being slow in Linux: http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html http://www.google.fi/search?q=fork+is+so+slow+on+Linux+is+because+the+default+page+size+is+4k&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fi:official&client=firefox-a https://github.com/rtomayko/posix-spawn#readme http://stackoverflow.com/questions/2731531/faster-forking-of-large-processes-on-linux/2874009#2874009 http://kirkwylie.blogspot.com/2008/11/linux-fork-performance-redux-large.html http://kirkwylie.blogspot.com/2008/10/linux-less-terrible-choice-for-java.html http://kirkwylie.blogspot.com/2008/09/solaris-10-terrible-choice-for-java.html#disqus_thread ) > Hints for setting mem options of maven&plug-ins (for parallel builds) > - > > Key: MNG-5100 > URL: http://jira.codehaus.org/browse/MNG-5100 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Documentation: Guides >Affects Versions: 3.0.3 >Reporter: Kari J. Niemi > > (I enabled parallel builds of maven3 for my project in CI server, it was > running quite nicely giving me much faster builds for a multi-module build. > But... it brought our CI server on it's knees, other projects suffered from > this and the CI build server admin bashed me to get back to serial build > :D... oh, he's such a nice guy :D...) > I did some googling around and found out that in Linux, forking new processes > may be extremely slow in case the parent that forks, has a great memory > print. Well, in the past I had (of course) optimized my build for maven2 by > throwing it more (some? no,no... _lots_ of) memory with MAVEN_OPTS by setting > both Xms and Xms to the same huge value, not forgetting the MaxPermSize and > PermSize. I suppose this, together with the linux forking "feature", might > cause the extreme cpu load? And of course the CI server process itself has an > even bigger memory print, times ten or something, fortunately I suppose it's > not doing so much forking... > I suppose the memory tuning should/could be done quite differently when using > parallel build feature because the mem is then used in the forked processes > which are smaller? So in parallel build I might set those mem options pretty > low, I guess? And also I could be setting "-client"-mode manually -because > otherwise jvm would think it should be running in server mode (due to running > in server HW. Actually I don't quite understand why jvm anyway decides based > on HW whether it should be running in server or client mode - there's no such > relation -not every jvm running on server HW is really a server process...) > Is there anything that we could be improve in maven/maven documentation in > this respect? -- 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: (MINDEXER-26) NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
[
http://jira.codehaus.org/browse/MINDEXER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268241#action_268241
]
Jesse Glick commented on MINDEXER-26:
-
http://statistics.netbeans.org/exceptions/exception.do?id=509289 shows an
apparently similar NPE - {{indexDirectory}} null in
{{DefaultIndexingContext.deleteIndexFiles}} - which is not inside the
constructor.
> NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
> -
>
> Key: MINDEXER-26
> URL: http://jira.codehaus.org/browse/MINDEXER-26
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: VM: Java HotSpot(TM) 64-Bit Server VM, 19.0-b09,
> Java(TM) SE Runtime
> Environment, 1.6.0_23-b05
> OS: Windows 7
>Reporter: Jesse Glick
>
> http://netbeans.org/bugzilla/show_bug.cgi?id=197346 reported by a NetBeans
> user in a build embedding Maven Indexer 4.0.0.
> {noformat}
> if ( IndexWriter.isLocked( indexDirectory ) )
> {
> IndexWriter.unlock( indexDirectory );
> }
> {noformat}
> Looks like {[indexDirectory}} is null, perhaps due to {{close}} having been
> called, and this code does not check for that (other code in the same class
> does). Can probably be guarded with a simple null 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: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268246#action_268246 ] S Daigle commented on SUREFIRE-742: --- Thanks again Kristian. Got your latest version 2.8.2-20110523.212645-39 and will give it a try. > Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException > errors > --- > > Key: SUREFIRE-742 > URL: http://jira.codehaus.org/browse/SUREFIRE-742 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: Backlog > Environment: Linux x64 >Reporter: S Daigle > Attachments: sf.txt, sf2.txt, sf3.txt > > > We're using the latest 2.8.2-SNAPSHOT > (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic > errors with some of our tests: > Exception in thread "ThreadedStreamConsumer" java.lang.RuntimeException: > java.util.StringTokenizer@5051207c > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.util.NoSuchElementException > at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) > ... 3 more > We've also noted, when run individually, maven reports FAILED but when run > with a group of tests, we still see the failures but maven reports SUCCESS. I > attached a log with the individual test run using "mvn -e". -- 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-5101) Declare artifact is a replacement to avoid excessive exclusions
Declare artifact is a replacement to avoid excessive exclusions
---
Key: MNG-5101
URL: http://jira.codehaus.org/browse/MNG-5101
Project: Maven 2 & 3
Issue Type: Wish
Components: Dependencies
Affects Versions: 2.2.1
Reporter: Anthony Whitford
Priority: Minor
For those of us using something like [SLF4J|http://slf4j.org/] and including a
[legacy API bridge|http://slf4j.org/legacy.html] like {{jcl-over-slf4j}} as a
replacement to {{commons-logging}}, it would be nice to be able to have the
{{jcl-over-slf4j}} artifact declare in its POM that it is a logical replacement
to {{commons-logging}}, so that one can avoid the excessive {{}}
for the numerous artifacts that still reference the legacy api:
{code}
commons-logging
commons-logging
{code}
One work-around that one can use is to declare {{commons-logging}} as
{{provided}} in a project's pom -- but then it appears in the dependency tree,
which is not really nice.
--
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-5102) Mixin POM fragments
Mixin POM fragments --- Key: MNG-5102 URL: http://jira.codehaus.org/browse/MNG-5102 Project: Maven 2 & 3 Issue Type: Wish Components: POM Affects Versions: 2.2.1 Reporter: Anthony Whitford I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _"everything but the kitchen sink"_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _"it does it all"_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating one. -- 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-5102) Mixin POM fragments
[ http://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-5102: -- Fix Version/s: 3.1 yes, surprisingly there doesn't appear to be an issue for it, though lots of related ones. Adding to that version. > Mixin POM fragments > --- > > Key: MNG-5102 > URL: http://jira.codehaus.org/browse/MNG-5102 > Project: Maven 2 & 3 > Issue Type: Wish > Components: POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford > Fix For: 3.1 > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- 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-5102) Mixin POM fragments
[ http://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268268#action_268268 ] Brett Porter commented on MNG-5102: --- I've been in greater need of this lately - I'll kick a discussion on the development list > Mixin POM fragments > --- > > Key: MNG-5102 > URL: http://jira.codehaus.org/browse/MNG-5102 > Project: Maven 2 & 3 > Issue Type: Wish > Components: POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford > Fix For: 3.1 > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- 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
