[jira] Created: (MENFORCER-118) DependencyConvergence gets better if it doesn't fail on snapshots of same baseVersion

[JIRA]

DependencyConvergence gets better if it doesn't fail on snapshots of same 
baseVersion
-

 Key: MENFORCER-118
 URL: https://jira.codehaus.org/browse/MENFORCER-118
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Improvement
  Components: Standard Rules
Affects Versions: 1.0.1
Reporter: Poul Bildsøe
Priority: Trivial


The DependencyVersionMap used by DependencyConvergense uses 
node.getArtifact().getVersion() when comparing versions. This makes the rule 
fail more often than needed because the version compare doens't ignore the fact 
that some snapshots may have been resolved to timestamp. If the code was 
node.getArtifact().getBaseVersion() instead then DependencyConvergense would 
only fail on real version mismatches.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MCOMPILER-156) Make outputDirectory & testOutputDirectory configurable at the plugin level

[JIRA]

Make outputDirectory & testOutputDirectory configurable at the plugin level
---

 Key: MCOMPILER-156
 URL: https://jira.codehaus.org/browse/MCOMPILER-156
 Project: Maven 2.x Compiler Plugin
  Issue Type: Improvement
Affects Versions: 2.3.2
Reporter: Frédéric Camblor


I'd like to change the test output directory for a particular 
maven-compiler-plugin execution.

Problem is : maven-compiler-plugin is relying on 
/project/build/outputDirectory|testOutputDirectory pom configuration for 
compilation.

It would be nicer to have these parameters configurables (obviously with a 
default value to ${project.build.outputDirectory} or 
${project.build.testOutputDirectory} to keep backward compatibility)

My use case is for some "incubation tests" I'd want to compile but not to 
execute (because, as they are named, they are in failure (incubation) for the 
moment .. test first methodology :)).
I would be able to define this design by executing maven-compiler-plugin on an 
additionnal execution while overriding the testOutputDirectory (because I don't 
want to execute these tests).


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MDEP-316) dependency:copy and dependency:unpack behave differently with M2 and M3 (should always search the reactor for artifacts)

[Stephen Connolly (JIRA)]

dependency:copy and dependency:unpack behave differently with M2 and M3 (should 
always search the reactor for artifacts)


 Key: MDEP-316
 URL: https://jira.codehaus.org/browse/MDEP-316
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: copy, unpack
Affects Versions: 2.2
Reporter: Stephen Connolly
Assignee: Brian Fox


With Maven 3.x the reactor is included when resolving artifacts in the copy and 
unpack goals.

With Maven 2.x the reactor is excluded when resolving artifacts in the copy and 
unpack goals.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MDEP-316) dependency:copy and dependency:unpack behave differently with M2 and M3 (should always search the reactor for artifacts)

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly closed MDEP-316.
-

   Resolution: Fixed
Fix Version/s: 2.3

r1143035

> dependency:copy and dependency:unpack behave differently with M2 and M3 
> (should always search the reactor for artifacts)
> 
>
> Key: MDEP-316
> URL: https://jira.codehaus.org/browse/MDEP-316
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Bug
>  Components: copy, unpack
>Affects Versions: 2.2
>Reporter: Stephen Connolly
>Assignee: Stephen Connolly
> Fix For: 2.3
>
>
> With Maven 3.x the reactor is included when resolving artifacts in the copy 
> and unpack goals.
> With Maven 2.x the reactor is excluded when resolving artifacts in the copy 
> and unpack goals.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MCOMPILER-156) Make outputDirectory & testOutputDirectory configurable at the plugin level

[Stephen Connolly (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272348#comment-272348
 ] 

Stephen Connolly commented on MCOMPILER-156:


FYI. There may be potential classpath issues.

IIRC ${project.build.outputDirectory} is on the classpath that is provided to 
javac.

If the @readonly is removed from the #outputDirectory parameters, then the 
default will still be on the classpath that is provided to javac

That might cause issues if you try to compile the same class twice (as the 
class will already be available on the classpath) This may be the reason why 
the parameter is @readonly (to stop users shooting themselves in the foot)

Thoughts?

> Make outputDirectory & testOutputDirectory configurable at the plugin level
> ---
>
> Key: MCOMPILER-156
> URL: https://jira.codehaus.org/browse/MCOMPILER-156
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.2
>Reporter: Frédéric Camblor
>
> I'd like to change the test output directory for a particular 
> maven-compiler-plugin execution.
> Problem is : maven-compiler-plugin is relying on 
> /project/build/outputDirectory|testOutputDirectory pom configuration for 
> compilation.
> It would be nicer to have these parameters configurables (obviously with a 
> default value to ${project.build.outputDirectory} or 
> ${project.build.testOutputDirectory} to keep backward compatibility)
> My use case is for some "incubation tests" I'd want to compile but not to 
> execute (because, as they are named, they are in failure (incubation) for the 
> moment .. test first methodology :)).
> I would be able to define this design by executing maven-compiler-plugin on 
> an additionnal execution while overriding the testOutputDirectory (because I 
> don't want to execute these tests).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MCOMPILER-156) Make outputDirectory & testOutputDirectory configurable at the plugin level

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly updated MCOMPILER-156:
---

Priority: Trivial  (was: Major)

> Make outputDirectory & testOutputDirectory configurable at the plugin level
> ---
>
> Key: MCOMPILER-156
> URL: https://jira.codehaus.org/browse/MCOMPILER-156
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.2
>Reporter: Frédéric Camblor
>Priority: Trivial
>
> I'd like to change the test output directory for a particular 
> maven-compiler-plugin execution.
> Problem is : maven-compiler-plugin is relying on 
> /project/build/outputDirectory|testOutputDirectory pom configuration for 
> compilation.
> It would be nicer to have these parameters configurables (obviously with a 
> default value to ${project.build.outputDirectory} or 
> ${project.build.testOutputDirectory} to keep backward compatibility)
> My use case is for some "incubation tests" I'd want to compile but not to 
> execute (because, as they are named, they are in failure (incubation) for the 
> moment .. test first methodology :)).
> I would be able to define this design by executing maven-compiler-plugin on 
> an additionnal execution while overriding the testOutputDirectory (because I 
> don't want to execute these tests).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MCOMPILER-156) Make outputDirectory & testOutputDirectory configurable at the plugin level

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly updated MCOMPILER-156:
---

Attachment: MCOMPILER-156.patch

The fix is trivial... the real question is whether we should fix... given that 
fixing this may allow the user to shoot their own foot off

> Make outputDirectory & testOutputDirectory configurable at the plugin level
> ---
>
> Key: MCOMPILER-156
> URL: https://jira.codehaus.org/browse/MCOMPILER-156
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.2
>Reporter: Frédéric Camblor
>Priority: Trivial
> Attachments: MCOMPILER-156.patch
>
>
> I'd like to change the test output directory for a particular 
> maven-compiler-plugin execution.
> Problem is : maven-compiler-plugin is relying on 
> /project/build/outputDirectory|testOutputDirectory pom configuration for 
> compilation.
> It would be nicer to have these parameters configurables (obviously with a 
> default value to ${project.build.outputDirectory} or 
> ${project.build.testOutputDirectory} to keep backward compatibility)
> My use case is for some "incubation tests" I'd want to compile but not to 
> execute (because, as they are named, they are in failure (incubation) for the 
> moment .. test first methodology :)).
> I would be able to define this design by executing maven-compiler-plugin on 
> an additionnal execution while overriding the testOutputDirectory (because I 
> don't want to execute these tests).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MCOMPILER-156) Make outputDirectory & testOutputDirectory configurable at the plugin level

[JIRA]

[ 
https://jira.codehaus.org/browse/MCOMPILER-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272350#comment-272350
 ] 

Frédéric Camblor commented on MCOMPILER-156:


Why wouldn't you provide #outputDirectory parameter to javac instead of 
${project.build.outputDirectory} ?

maven-compiler-plugin wouldn't have rights on this ? (it would be managed by 
maven core ?)

> Make outputDirectory & testOutputDirectory configurable at the plugin level
> ---
>
> Key: MCOMPILER-156
> URL: https://jira.codehaus.org/browse/MCOMPILER-156
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.2
>Reporter: Frédéric Camblor
>Priority: Trivial
> Attachments: MCOMPILER-156.patch
>
>
> I'd like to change the test output directory for a particular 
> maven-compiler-plugin execution.
> Problem is : maven-compiler-plugin is relying on 
> /project/build/outputDirectory|testOutputDirectory pom configuration for 
> compilation.
> It would be nicer to have these parameters configurables (obviously with a 
> default value to ${project.build.outputDirectory} or 
> ${project.build.testOutputDirectory} to keep backward compatibility)
> My use case is for some "incubation tests" I'd want to compile but not to 
> execute (because, as they are named, they are in failure (incubation) for the 
> moment .. test first methodology :)).
> I would be able to define this design by executing maven-compiler-plugin on 
> an additionnal execution while overriding the testOutputDirectory (because I 
> don't want to execute these tests).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MDEP-124) Dependency incorrectly reported as "Unused declared"

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly updated MDEP-124:
--

Fix Version/s: (was: 2.3)
   2.4

> Dependency incorrectly reported as "Unused declared"
> 
>
> Key: MDEP-124
> URL: https://jira.codehaus.org/browse/MDEP-124
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Reporter: Olivier Dehon
>Assignee: Brian Fox
> Fix For: 2.4
>
>
> When a dependency  is only required for a constant in a JAR, 
> dependency:analyze incorrectly reports the dependency as "Unused declared".
> Example:
> Constants.jar has 1 class called Constants.java:
> {code}
> package com.myco.util;
> public class Constants 
> {
> private Constants() {};
> public static final double PI = 3.14159;
> }
> {code}
> Then App jar has App.java as:
> {code}
> package com.myco.app;
> public class App 
> {
> public static void main( String[] args )
> {
> System.out.println( com.myco.util.Constants.PI );
> }
> }
> {code}
> Since the constant gets optimized away in the generated {{App.class}}, the 
> dependency is not detected, even though the project won't compile without it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MDEP-277) Allow downloading artifact with classifier (e.g. sources jar)

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly closed MDEP-277.
-

Resolution: Duplicate

> Allow downloading artifact with classifier (e.g. sources jar)
> -
>
> Key: MDEP-277
> URL: https://jira.codehaus.org/browse/MDEP-277
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Sub-task
>Affects Versions: 2.1
>Reporter: Ittay Dror
>Assignee: Brian Fox
>
> it is not possible to download an artifact containing a classifier

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MDEP-265) Add classifier option for dependency:get

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly closed MDEP-265.
-

Resolution: Fixed
  Assignee: Stephen Connolly  (was: Brian Fox)

r1143066

> Add classifier option for dependency:get
> 
>
> Key: MDEP-265
> URL: https://jira.codehaus.org/browse/MDEP-265
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andreas Kohn
>Assignee: Stephen Connolly
> Fix For: 2.3
>
> Attachments: MDEP-265.diff, MDEP-265-include-artifact-string.diff
>
>
> The dependency:get mojo is really helpful, but it currently seems to be 
> unable to get an artifact that uses a non-default classifier.
> Please add a classifier configuration option for the get mojo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MDEP-231) Create a single dependency resolution plugin

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly updated MDEP-231:
--

Fix Version/s: (was: 2.3)
   2.4

> Create a single dependency resolution plugin
> 
>
> Key: MDEP-231
> URL: https://jira.codehaus.org/browse/MDEP-231
> Project: Maven 2.x Dependency Plugin
>  Issue Type: New Feature
>  Components: resolve
>Affects Versions: 2.1, 2.2
>Reporter: Marvin Froeder
>Assignee: John Casey
> Fix For: 2.4
>
> Attachments: maven-dependency-plugin.patch, 
> maven-dependency-plugin.patch, maven-dependency-plugin.patch
>
>
> The attached patch has a new goal that allows a single dependency to be 
> resolved, like this:
> mvn 
> org.apache.maven.plugins:maven-dependency-plugin:2.2-SNAPSHOT:resolve-single 
> -DgroupId=com.acme -DartifactId=dummy -Dversion=1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MDEP-166) runtime-scoped dependencies should be specially handled

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly updated MDEP-166:
--

Fix Version/s: (was: 2.3)
   2.4

> runtime-scoped dependencies should be specially handled
> ---
>
> Key: MDEP-166
> URL: https://jira.codehaus.org/browse/MDEP-166
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.0
>Reporter: Max Bowsher
>Assignee: Brian Fox
> Fix For: 2.4
>
>
> Currently the plugin warns that runtime-scope dependencies are unused.
> It should understand that the correct status for a runtime-scoped dependency 
> is to *not* be discoverable in the bytecode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MDEP-145) Outputting dependency resolution/tree in a well known _machine readable_ output format

[Stephen Connolly (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly closed MDEP-145.
-

Resolution: Fixed

r1143067 includes the missing documentation update

> Outputting dependency resolution/tree in a well known _machine readable_ 
> output format
> --
>
> Key: MDEP-145
> URL: https://jira.codehaus.org/browse/MDEP-145
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Improvement
>  Components: resolve, tree
>Affects Versions: 2.0
>Reporter: Samuel Le Berrigaud
>Assignee: Brian Fox
> Fix For: 2.3
>
> Attachments: MDEP-145-velocity.patch, MDEP-145.zip, treegraph.patch
>
>
> Currently (at least on trunk) one can output the dependencies in a file. 
> However the file output doesn't follow any specific format, except from being 
> the exact same output than on the console.
> I would be nice to have an easily parse-able, format  so that tools could 
> leverage the dependency resolution/tree. I am thinking for example of 
> continuous integration tools that could report on added/removed/updated 
> dependencies on modules.
> The format could be xml, json or something else. I've been playing with the 
> current output to make it so that:
> * the first line describes the current module for which dependency resolution 
> is done, formatted as such: {{:::}}
> * every following line is a dependency (indented by 2 or more spaces), 
> formatted as such: {{}}
> This already is easy to parse.
> What do you think?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MWAR-256) it's not possible to create classes attachment without classifier

[Rafal Krzewski (JIRA)]

it's not possible to create classes attachment without classifier
-

 Key: MWAR-256
 URL: https://jira.codehaus.org/browse/MWAR-256
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Rafal Krzewski


I would like to package classes in my war-packaged project into a jar, but I 
don't want to use default 'classes' classifier assigned by the plugin. The 
generated artifacts have distinct packaging types, so there is no conflict and 
the classifier provides no useful additional information. Using the following 
configuration:
{quote}
{{}}
{{}}
{{}}
{quote}
Results in "classes" classifier being used anyway. If I understand the behavior 
correctly Plexus assigns the variable it's default value, when presented an 
empty input. I don't think this can be fixed in way that is both clean and 
backward compatible. Either the default value will change, which would break 
existing builds that don't specify plugin version explicitly, or some clunky 
additional parameter like 
{{false}}, or magic value like 
{{NONE}} need to be introduced.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Benson Margulies (JIRA)]

Exception from cyberneko from jenkins repo listing
--

 Key: WAGON-338
 URL: https://jira.codehaus.org/browse/WAGON-338
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-http-lightweight
Affects Versions: 1.0-beta-2
Reporter: Benson Margulies


Trying to use the wagon-maven-plugin to copy from a current jenkins https repo:

[INFO] Error during performing repository copy

Embedded error: -1
[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error during performing 
repository copy
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.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)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
performing repository copy
at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at 
hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
at 
hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
at 
hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
at 
hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
at hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
at hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
at 
org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
at 
org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scan(WagonDirectoryScanner.java:245)
at 
org.codehaus.mojo.wagon.shared.DefaultWagonDownload.getFileList(DefaultWagonDownload.java:51)
at 
org.codehaus.mojo.wagon.shared.DefaultWagonDownload.download(DefaultWagonDownload.java:59)
at 
org.codehaus.mojo.wagon.shared.DefaultWagonCopy.copy(DefaultWagonCopy.java:67)
at org.codehaus.mojo.wagon.CopyMojo.copy(CopyMojo.java:77)
at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:49)
... 19 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (ARCHETYPE-375) display groupId in front of artifactId in list for selection

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/ARCHETYPE-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed ARCHETYPE-375.
--

Resolution: Fixed

fixed [rev 1143098|http://svn.apache.org/viewvc?rev=1143098&view=rev]

> display groupId in front of artifactId in list for selection
> 
>
> Key: ARCHETYPE-375
> URL: https://jira.codehaus.org/browse/ARCHETYPE-375
> Project: Maven Archetype
>  Issue Type: Improvement
>  Components: Plugin
>Affects Versions: 2.0
>Reporter: Herve Boutemy
>Assignee: Olivier Lamy
> Fix For: 2.1
>
>
> as of today, there are more than 400 archetypes in central, with artifactIds 
> not always very easy to differentiate
> {noformat}410: remote -> wikbook.archetype (-)
> 411: remote -> circumflex-archetype (-)
> 412: remote -> javg-minimal-archetype (-)
> Choose a number: 109:{noformat}
> adding groupId in the display could help evaluate:
> {noformat}410: remote -> org.wikbook:wikbook.archetype (-)
> 411: remote -> ru.circumflex:circumflex-archetype (-)
> 412: remote -> se.vgregion.javg.maven.archetypes:javg-minimal-archetype (-)
> Choose a number: 109:{noformat}
> see http://www.mail-archive.com/dev@maven.apache.org/msg88669.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Benson Margulies (JIRA)]

 [ 
https://jira.codehaus.org/browse/WAGON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated WAGON-338:
---

Affects Version/s: 1.0-beta-7

> Exception from cyberneko from jenkins repo listing
> --
>
> Key: WAGON-338
> URL: https://jira.codehaus.org/browse/WAGON-338
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-2, 1.0-beta-7
>Reporter: Benson Margulies
>
> Trying to use the wagon-maven-plugin to copy from a current jenkins https 
> repo:
> [INFO] Error during performing repository copy
> Embedded error: -1
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during 
> performing repository copy
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
> performing repository copy
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
> at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
> at 
> org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scan(WagonDirectoryScanner.java:245)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.getFileList(DefaultWagonDownload.java:51)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.download(DefaultWagonDownload.java:59)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonCopy.copy(DefaultWagonCopy.java:67)
> at org.codehaus.mojo.wagon.CopyMojo.copy(CopyMojo.java:77)
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:49)
> ... 19 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ARCHETYPE-371) Add a command line argument to filter/limit the archetypes returned by mvn archetype:generate

[Olivier Lamy (JIRA)]

[ 
https://jira.codehaus.org/browse/ARCHETYPE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272356#comment-272356
 ] 

Olivier Lamy commented on ARCHETYPE-371:


an idea I have is to have the possibility of more "complicated" search query
{code}
// g for groupId a for artifactId
-Dfilter=g:maven,a:plugin
// default on artifactId
-Dfilter=plugin
{code}
WDYT ?


> Add a command line argument to filter/limit the archetypes returned by mvn 
> archetype:generate
> -
>
> Key: ARCHETYPE-371
> URL: https://jira.codehaus.org/browse/ARCHETYPE-371
> Project: Maven Archetype
>  Issue Type: New Feature
>  Components: Plugin
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/local/maven
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "linux", version: "2.6.35.12-90.fc14.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Fred Bricon
>Assignee: Olivier Lamy
> Fix For: 2.1
>
>
> Currently, running mvn archetype:generate returns 390 archetypes, on my 
> machine.
> By default, th window buffer of my terminal isn't set big enough so I can see 
> the first archetypes in the list.
> So, I think it would be really useful to have a CLI arg allowing us to filter 
> the archetypes containing a string.
> Ex: running {code}mvn archetype:generate -Dfilter=webapp{code} would return 
> only the archetypes having webapp in their artifactId.
> What do you think?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ARCHETYPE-371) Add a command line argument to filter/limit the archetypes returned by mvn archetype:generate

[Fred Bricon (JIRA)]

[ 
https://jira.codehaus.org/browse/ARCHETYPE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272357#comment-272357
 ] 

Fred Bricon commented on ARCHETYPE-371:
---

Could be useful indeed. 
I'm sorry I didn't follow up on this issue so far, I've been swamped IRL :-)
I haven't lost hope of being able to provide a patch yet :-)

> Add a command line argument to filter/limit the archetypes returned by mvn 
> archetype:generate
> -
>
> Key: ARCHETYPE-371
> URL: https://jira.codehaus.org/browse/ARCHETYPE-371
> Project: Maven Archetype
>  Issue Type: New Feature
>  Components: Plugin
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/local/maven
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "linux", version: "2.6.35.12-90.fc14.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Fred Bricon
>Assignee: Olivier Lamy
> Fix For: 2.1
>
>
> Currently, running mvn archetype:generate returns 390 archetypes, on my 
> machine.
> By default, th window buffer of my terminal isn't set big enough so I can see 
> the first archetypes in the list.
> So, I think it would be really useful to have a CLI arg allowing us to filter 
> the archetypes containing a string.
> Ex: running {code}mvn archetype:generate -Dfilter=webapp{code} would return 
> only the archetypes having webapp in their artifactId.
> What do you think?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (ARCHETYPE-376) port used in unit test is hardcoded so can cause port allocation issue on ci machine

[Olivier Lamy (JIRA)]

port used in unit test is hardcoded so can cause port allocation issue on ci 
machine


 Key: ARCHETYPE-376
 URL: https://jira.codehaus.org/browse/ARCHETYPE-376
 Project: Maven Archetype
  Issue Type: Bug
  Components: Generator
Affects Versions: 2.0
Reporter: Olivier Lamy




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (ARCHETYPE-376) port used in unit test is hardcoded so can cause port allocation issue on ci machine

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/ARCHETYPE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy updated ARCHETYPE-376:
---

Fix Version/s: 2.1
 Assignee: Olivier Lamy

> port used in unit test is hardcoded so can cause port allocation issue on ci 
> machine
> 
>
> Key: ARCHETYPE-376
> URL: https://jira.codehaus.org/browse/ARCHETYPE-376
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 2.0
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 2.1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ARCHETYPE-371) Add a command line argument to filter/limit the archetypes returned by mvn archetype:generate

[Olivier Lamy (JIRA)]

[ 
https://jira.codehaus.org/browse/ARCHETYPE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272358#comment-272358
 ] 

Olivier Lamy commented on ARCHETYPE-371:


no worries I will push the first simple implementation 

> Add a command line argument to filter/limit the archetypes returned by mvn 
> archetype:generate
> -
>
> Key: ARCHETYPE-371
> URL: https://jira.codehaus.org/browse/ARCHETYPE-371
> Project: Maven Archetype
>  Issue Type: New Feature
>  Components: Plugin
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/local/maven
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "linux", version: "2.6.35.12-90.fc14.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Fred Bricon
>Assignee: Olivier Lamy
> Fix For: 2.1
>
>
> Currently, running mvn archetype:generate returns 390 archetypes, on my 
> machine.
> By default, th window buffer of my terminal isn't set big enough so I can see 
> the first archetypes in the list.
> So, I think it would be really useful to have a CLI arg allowing us to filter 
> the archetypes containing a string.
> Ex: running {code}mvn archetype:generate -Dfilter=webapp{code} would return 
> only the archetypes having webapp in their artifactId.
> What do you think?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ARCHETYPE-371) Add a command line argument to filter/limit the archetypes returned by mvn archetype:generate

[Olivier Lamy (JIRA)]

[ 
https://jira.codehaus.org/browse/ARCHETYPE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272359#comment-272359
 ] 

Olivier Lamy commented on ARCHETYPE-371:


first simple impl in [rev 
1143127|http://svn.apache.org/viewvc?rev=1143127&view=rev]
I leave the issue open until :
* filtering with g: and a:
* provide test.

> Add a command line argument to filter/limit the archetypes returned by mvn 
> archetype:generate
> -
>
> Key: ARCHETYPE-371
> URL: https://jira.codehaus.org/browse/ARCHETYPE-371
> Project: Maven Archetype
>  Issue Type: New Feature
>  Components: Plugin
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/local/maven
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "linux", version: "2.6.35.12-90.fc14.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Fred Bricon
>Assignee: Olivier Lamy
> Fix For: 2.1
>
>
> Currently, running mvn archetype:generate returns 390 archetypes, on my 
> machine.
> By default, th window buffer of my terminal isn't set big enough so I can see 
> the first archetypes in the list.
> So, I think it would be really useful to have a CLI arg allowing us to filter 
> the archetypes containing a string.
> Ex: running {code}mvn archetype:generate -Dfilter=webapp{code} would return 
> only the archetypes having webapp in their artifactId.
> What do you think?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Benson Margulies (JIRA)]

[ 
https://jira.codehaus.org/browse/WAGON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272362#comment-272362
 ] 

Benson Margulies commented on WAGON-338:


r1143141 | bimargulies | 2011-07-05 12:56:17 -0400 (Tue, 05 Jul 2011) | 8 lines

[WAGON-338] Exception from cyberneko from jenkins repo listing

the html listing parser was coded to use Cyberneko. This orphaned ball of 
complexity crashes on some things
it does not understand, including some output from the Jenkins CI system when 
it is serving as a repository.

A maintained, superior alternative is Jsoup. This change switches 
wagon-http-shared4 to use it.
It passes all the tests.





> Exception from cyberneko from jenkins repo listing
> --
>
> Key: WAGON-338
> URL: https://jira.codehaus.org/browse/WAGON-338
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-2, 1.0-beta-7
>Reporter: Benson Margulies
>Assignee: Benson Margulies
>
> Trying to use the wagon-maven-plugin to copy from a current jenkins https 
> repo:
> [INFO] Error during performing repository copy
> Embedded error: -1
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during 
> performing repository copy
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
> performing repository copy
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
> at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
> at 
> org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scan(WagonDirectoryScanner.java:245)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.getFileList(DefaultWagonDownload.java:51)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.download(DefaultWagonDownload.java:59)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonCopy.copy(DefaultWagonC

[jira] Commented: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Mark Struberg (JIRA)]

[ 
https://jira.codehaus.org/browse/WAGON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272364#comment-272364
 ] 

Mark Struberg commented on WAGON-338:
-

Hi Benson!

Go on with the upgrade. jsoup is MIT, so this should be fine also.
Please note that we need to fix this in both wagon-http-shared4 and 
wagon-http-shared. Both contain the identical HtmlFileListParser. Those two 
libs only differ in the httpclient implementation, but we sadly cannot get rid 
of the httpclient-3 based wagon-http-shared yet since jackrabbit is still using 
it internally and is externalizing those classes :/

> Exception from cyberneko from jenkins repo listing
> --
>
> Key: WAGON-338
> URL: https://jira.codehaus.org/browse/WAGON-338
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-2, 1.0-beta-7
>Reporter: Benson Margulies
>Assignee: Benson Margulies
>
> Trying to use the wagon-maven-plugin to copy from a current jenkins https 
> repo:
> [INFO] Error during performing repository copy
> Embedded error: -1
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during 
> performing repository copy
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
> performing repository copy
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
> at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
> at 
> org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scan(WagonDirectoryScanner.java:245)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.getFileList(DefaultWagonDownload.java:51)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.download(DefaultWagonDownload.java:59)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonCopy.copy(DefaultWagonCopy.java:67)
> at org.codehaus.mojo.wagon.CopyMojo.copy(CopyMojo.java:77)
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(Abs

[jira] Issue Comment Edited: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Mark Struberg (JIRA)]

[ 
https://jira.codehaus.org/browse/WAGON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272364#comment-272364
 ] 

Mark Struberg edited comment on WAGON-338 at 7/5/11 12:07 PM:
--

Hi Benson!

Go on with the upgrade. jsoup is MIT, so this should be fine also.
Please note that we need to fix this in both wagon-http-shared4 and 
wagon-http-shared. Both contain the identical HtmlFileListParser. Those two 
libs only differ in the httpclient implementation, but we sadly cannot get rid 
of the httpclient-3 based wagon-http-shared yet since jackrabbit (used in the 
webdav wagon) is still using it internally and is externalizing those classes :/

  was (Author: struberg):
Hi Benson!

Go on with the upgrade. jsoup is MIT, so this should be fine also.
Please note that we need to fix this in both wagon-http-shared4 and 
wagon-http-shared. Both contain the identical HtmlFileListParser. Those two 
libs only differ in the httpclient implementation, but we sadly cannot get rid 
of the httpclient-3 based wagon-http-shared yet since jackrabbit is still using 
it internally and is externalizing those classes :/
  
> Exception from cyberneko from jenkins repo listing
> --
>
> Key: WAGON-338
> URL: https://jira.codehaus.org/browse/WAGON-338
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-2, 1.0-beta-7
>Reporter: Benson Margulies
>Assignee: Benson Margulies
>
> Trying to use the wagon-maven-plugin to copy from a current jenkins https 
> repo:
> [INFO] Error during performing repository copy
> Embedded error: -1
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during 
> performing repository copy
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
> performing repository copy
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
> at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
> at 
> org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryS

[jira] Updated: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Benson Margulies (JIRA)]

 [ 
https://jira.codehaus.org/browse/WAGON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated WAGON-338:
---

Affects Version/s: 2.0

> Exception from cyberneko from jenkins repo listing
> --
>
> Key: WAGON-338
> URL: https://jira.codehaus.org/browse/WAGON-338
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-2, 1.0-beta-7, 2.0
>Reporter: Benson Margulies
>Assignee: Benson Margulies
>
> Trying to use the wagon-maven-plugin to copy from a current jenkins https 
> repo:
> [INFO] Error during performing repository copy
> Embedded error: -1
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during 
> performing repository copy
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
> performing repository copy
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
> at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
> at 
> org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scan(WagonDirectoryScanner.java:245)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.getFileList(DefaultWagonDownload.java:51)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.download(DefaultWagonDownload.java:59)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonCopy.copy(DefaultWagonCopy.java:67)
> at org.codehaus.mojo.wagon.CopyMojo.copy(CopyMojo.java:77)
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:49)
> ... 19 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (WAGON-339) Run out of heap looking at contents of a Jenkins repo

[Benson Margulies (JIRA)]

Run out of heap looking at contents of a Jenkins repo
-

 Key: WAGON-339
 URL: https://jira.codehaus.org/browse/WAGON-339
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-http-lightweight
Affects Versions: 2.0
Reporter: Benson Margulies


Reading from 
https://builds.apache.org/job/Lucene-Solr-Maven-trunk/lastSuccessfulBuild/artifact/maven_artifacts,
there's an out of memory. Looks a bit like an infinte recursion, don't it?

[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOfRange(Arrays.java:3209)
at java.lang.String.(String.java:215)
at java.lang.StringBuffer.toString(StringBuffer.java:585)
at sun.net.www.ParseUtil.toString(ParseUtil.java:315)
at sun.net.www.ParseUtil.createURI(ParseUtil.java:289)
at sun.net.www.ParseUtil.toURI(ParseUtil.java:266)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:905)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at 
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at 
org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:129)
at 
org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:328)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
at 
org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MINDEXER-34) Order of IndexCreator's passed to addIndexingContextForced affects whether MavenPluginArtifactInfoIndexCreator has any effect

[Jesse Glick (JIRA)]

Order of IndexCreator's passed to addIndexingContextForced affects whether 
MavenPluginArtifactInfoIndexCreator has any effect
-

 Key: MINDEXER-34
 URL: https://jira.codehaus.org/browse/MINDEXER-34
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 4.1.0
 Environment: JDK 6, Ubuntu, Maven 3.0.3; actually Indexer 4.1.1 but 
that is not listed as an option here
Reporter: Jesse Glick
Priority: Critical


While working on a utility inside NetBeans to look up all plugins using a given 
goal prefix, I found unreliable behavior. To investigate, I wrote a unit test 
that used Maven Indexer (along with some NB helper classes) that:

1. Creates a fresh local repository.
2. Installs a trivial "plugin" ({{maven-plugin}} POM + JAR) with just a 
{{META-INF/maven/plugin.xml}} containing 
{{stuff}}.
3. Indexes the repository, using all available {{IndexCreator}} instances.
4. Runs a search like {{ArtifactInfo.PLUGIN_PREFIX="stuff"}} and checks that 
there is one hit.

This test passed sometimes - including always when run from the debugger - but 
usually failed. Eventually I found that the order of {{IndexCreator}} instances 
returned from the Plexus container mattered: if {{min}} preceded 
{{maven-plugin}} then the test passed, whereas if {{min}} followed 
{{maven-plugin}} then the test failed. Furthermore, despite 
{{META-INF/plexus/components.xml}} listing these implementations in a 
particular order (seemingly arbitrary at build time), the actual order returned 
by {{PlexusContainer.lookupList}} seemed to vary randomly from run to run.

The problem may have to do with 
{{MinimalArtifactInfoIndexCreator.updateLegacyDocument}}, which does something 
with {{PLUGIN_PREFIX}} and {{PLUGIN_GOALS}} for reasons unclear to me. When the 
creators were in the "wrong" order, http://code.google.com/p/luke/ confirmed 
that {{px}} and {{gx}} fields were just not present.

I can work around this issue in the NetBeans code which indexes the local 
repository, using a hardcoded list of indexers (or rather, indexer IDs) as 
{{AbstractIndexCreatorHelper}} in the Indexer test sources does. But that does 
not help for downloaded remote indices, which might have been created by a 
faulty version of Indexer - since {{NexusIndexerCli.getIndexers}} uses 
{{lookupList}} when {{--type full}} is used. This means that any queries about 
plugin prefixes or goals may return results only for plugins which happen to 
have been downloaded locally. Indeed this is exactly what seems to happen when 
I try it, i.e. the Central index I am getting (via a proxy in Nexus 1.9.1.1) 
has no {{PLUGIN_*}} fields.

The less desirable workaround would be to run a search on 
{{ArtifactInfo.PACKAGING="maven-plugin"}}, and for each hit, download the 
actual JAR and parse {{plugin.xml}} myself.

I am not sure whether the position of 
{{MavenArchetypeArtifactInfoIndexCreator}} also matters, but it seems 
plausible, since it overrides a field normally stored in 
{{MinimalArtifactInfoIndexCreator}}.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (WAGON-339) Run out of heap looking at contents of a Jenkins repo

[Benson Margulies (JIRA)]

 [ 
https://jira.codehaus.org/browse/WAGON-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies closed WAGON-339.
--

Resolution: Not A Bug

oops, this is probably a problem with the mojo.

> Run out of heap looking at contents of a Jenkins repo
> -
>
> Key: WAGON-339
> URL: https://jira.codehaus.org/browse/WAGON-339
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 2.0
>Reporter: Benson Margulies
>
> Reading from 
> https://builds.apache.org/job/Lucene-Solr-Maven-trunk/lastSuccessfulBuild/artifact/maven_artifacts,
> there's an out of memory. Looks a bit like an infinte recursion, don't it?
> [INFO] Trace
> java.lang.OutOfMemoryError: Java heap space
>   at java.util.Arrays.copyOfRange(Arrays.java:3209)
>   at java.lang.String.(String.java:215)
>   at java.lang.StringBuffer.toString(StringBuffer.java:585)
>   at sun.net.www.ParseUtil.toString(ParseUtil.java:315)
>   at sun.net.www.ParseUtil.createURI(ParseUtil.java:289)
>   at sun.net.www.ParseUtil.toURI(ParseUtil.java:266)
>   at 
> sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:905)
>   at 
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
>   at 
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
>   at 
> java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
>   at 
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
>   at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:129)
>   at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:328)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
>   at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Benson Margulies (JIRA)]

 [ 
https://jira.codehaus.org/browse/WAGON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies closed WAGON-338.
--

Resolution: Fixed


r1143148 | bimargulies | 2011-07-05 13:26:11 -0400 (Tue, 05 Jul 2011) | 4 lines

[WAGON-338] Exception from cyberneko from jenkins repo listing

backport of change from trunk.




> Exception from cyberneko from jenkins repo listing
> --
>
> Key: WAGON-338
> URL: https://jira.codehaus.org/browse/WAGON-338
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-2, 1.0-beta-7, 2.0
>Reporter: Benson Margulies
>Assignee: Benson Margulies
> Fix For: 2.0, 1.0-beta-7
>
>
> Trying to use the wagon-maven-plugin to copy from a current jenkins https 
> repo:
> [INFO] Error during performing repository copy
> Embedded error: -1
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during 
> performing repository copy
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
> performing repository copy
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
> at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
> at 
> org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scan(WagonDirectoryScanner.java:245)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.getFileList(DefaultWagonDownload.java:51)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.download(DefaultWagonDownload.java:59)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonCopy.copy(DefaultWagonCopy.java:67)
> at org.codehaus.mojo.wagon.CopyMojo.copy(CopyMojo.java:77)
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:49)
> ... 19 more

--
This message is automatically generated by JIRA.
For 

[jira] Updated: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Benson Margulies (JIRA)]

 [ 
https://jira.codehaus.org/browse/WAGON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated WAGON-338:
---

Fix Version/s: 1.0-beta-7
   2.0

> Exception from cyberneko from jenkins repo listing
> --
>
> Key: WAGON-338
> URL: https://jira.codehaus.org/browse/WAGON-338
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-2, 1.0-beta-7, 2.0
>Reporter: Benson Margulies
>Assignee: Benson Margulies
> Fix For: 1.0-beta-7, 2.0
>
>
> Trying to use the wagon-maven-plugin to copy from a current jenkins https 
> repo:
> [INFO] Error during performing repository copy
> Embedded error: -1
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during 
> performing repository copy
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
> performing repository copy
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
> at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
> at 
> org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scan(WagonDirectoryScanner.java:245)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.getFileList(DefaultWagonDownload.java:51)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.download(DefaultWagonDownload.java:59)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonCopy.copy(DefaultWagonCopy.java:67)
> at org.codehaus.mojo.wagon.CopyMojo.copy(CopyMojo.java:77)
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:49)
> ... 19 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (WAGON-338) Exception from cyberneko from jenkins repo listing

[Dennis Lundberg (JIRA)]

 [ 
https://jira.codehaus.org/browse/WAGON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated WAGON-338:
--

Fix Version/s: (was: 1.0-beta-7)
   1.0-beta-8

> Exception from cyberneko from jenkins repo listing
> --
>
> Key: WAGON-338
> URL: https://jira.codehaus.org/browse/WAGON-338
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-2, 1.0-beta-7, 2.0
>Reporter: Benson Margulies
>Assignee: Benson Margulies
> Fix For: 1.0-beta-8, 2.0
>
>
> Trying to use the wagon-maven-plugin to copy from a current jenkins https 
> repo:
> [INFO] Error during performing repository copy
> Embedded error: -1
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during 
> performing repository copy
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during 
> performing repository copy
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:53)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer$InfoStack.pop(HTMLTagBalancer.java:1262)
> at 
> hidden.org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:669)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2489)
> at 
> hidden.org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1950)
> at hidden.org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:872)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:496)
> at 
> hidden.org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:449)
> at 
> org.apache.maven.wagon.shared.http.HtmlFileListParser.parseFileList(HtmlFileListParser.java:71)
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.getFileList(LightweightHttpWagon.java:343)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:283)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scandir(WagonDirectoryScanner.java:322)
> at 
> org.codehaus.mojo.wagon.shared.WagonDirectoryScanner.scan(WagonDirectoryScanner.java:245)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.getFileList(DefaultWagonDownload.java:51)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonDownload.download(DefaultWagonDownload.java:59)
> at 
> org.codehaus.mojo.wagon.shared.DefaultWagonCopy.copy(DefaultWagonCopy.java:67)
> at org.codehaus.mojo.wagon.CopyMojo.copy(CopyMojo.java:77)
> at org.codehaus.mojo.wagon.AbstractCopyMojo.execute(AbstractCopyMojo.java:49)
> ... 19 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRELEASE-690) Check the repository if the version has already been released before

[Christopher Cudennec (JIRA)]

Check the repository if the version has already been released before


 Key: MRELEASE-690
 URL: https://jira.codehaus.org/browse/MRELEASE-690
 Project: Maven 2.x Release Plugin
  Issue Type: New Feature
  Components: prepare
Reporter: Christopher Cudennec


The plugin does not check the repository if the version to be released is 
already in the repository. Instead you get a couple of SCM changes and a failed 
build.
Each module of the project must be checked to prevent that some modules were 
released and some were not.

This feature would really add to the robustness and quality of the plugin. At 
the moment the plugin lets you deal with the mess in case anything went wrong.

In my opinion this issue is connected to MRELEASE-572 / MRELEASE-165 (checking 
if the tag already exists in the SCM).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ARCHETYPE-371) Add a command line argument to filter/limit the archetypes returned by mvn archetype:generate

[Olivier Lamy (JIRA)]

[ 
https://jira.codehaus.org/browse/ARCHETYPE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272382#comment-272382
 ] 

Olivier Lamy commented on ARCHETYPE-371:


for simplicity something like -Dfilter=groupId:artifactId 
Both must be included in groupId and artifactId.
Seems more simple than the g:,a:

> Add a command line argument to filter/limit the archetypes returned by mvn 
> archetype:generate
> -
>
> Key: ARCHETYPE-371
> URL: https://jira.codehaus.org/browse/ARCHETYPE-371
> Project: Maven Archetype
>  Issue Type: New Feature
>  Components: Plugin
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/local/maven
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "linux", version: "2.6.35.12-90.fc14.x86_64", arch: "amd64", family: 
> "unix"
>Reporter: Fred Bricon
>Assignee: Olivier Lamy
> Fix For: 2.1
>
>
> Currently, running mvn archetype:generate returns 390 archetypes, on my 
> machine.
> By default, th window buffer of my terminal isn't set big enough so I can see 
> the first archetypes in the list.
> So, I think it would be really useful to have a CLI arg allowing us to filter 
> the archetypes containing a string.
> Ex: running {code}mvn archetype:generate -Dfilter=webapp{code} would return 
> only the archetypes having webapp in their artifactId.
> What do you think?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (SUREFIRE-750) Add custom name suffix for surefire-reports (xml and txt)

[Paul Gier (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Gier updated SUREFIRE-750:
---

Fix Version/s: 2.10
 Assignee: Paul Gier

> Add custom name suffix for surefire-reports (xml and txt)
> -
>
> Key: SUREFIRE-750
> URL: https://jira.codehaus.org/browse/SUREFIRE-750
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml 
> generation
>Reporter: Rostislav Svoboda
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 2.10
>
> Attachments: reportNameSuffix.patch, reportNameSuffix-remake.patch, 
> reportNameSuffix-tests.patch
>
>
> Hi. 
> I'd to add support in surefire for custom name suffix for tests in 
> surefire-reports.
> Motivation 1):
> I have more modules, some modules are sharing tests from another using 
> org.codehaus.mojo:build-helper-maven-plugin.
> I'd like to have txt and xml files with some differentiator to determine in 
> which module tests were executed.
> Motivation 2):
> I have defined several executions where I use different parameters and 
> execute the same tests in each execution.
> Again, I'd like to have txt and xml files with some differentiator.
> Solution:
> Introduce new configuration property reportNameSuffix.
> Patch for this improvement is included.
> Tested:
> Yes, customText added into surefire 
> plugin configuration and received these files:
>  org.xyz.test.componentA.ComponentAUnitTest-customText-output.txt  
>  org.xyz.test.componentA.ComponentAUnitTest-customText.txt 
>  org.xyz.test.componentB.ComponentBUnitTest-customText-output.txt
>  org.xyz.test.componentB.ComponentBUnitTest-customText.txt
>  TEST-org.xyz.test.componentA.ComponentAUnitTest-customText.xml
>  TEST-org.xyz.test.componentB.ComponentBUnitTest-customText.xml
> Tested without  defined too, original file names and 
> content generated.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (SUREFIRE-750) Add custom name suffix for surefire-reports (xml and txt)

[Paul Gier (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Gier closed SUREFIRE-750.
--

Resolution: Fixed

Applied patch in 
[r1143207|http://svn.apache.org/viewvc?view=revision&revision=1143207].  Thanks!

> Add custom name suffix for surefire-reports (xml and txt)
> -
>
> Key: SUREFIRE-750
> URL: https://jira.codehaus.org/browse/SUREFIRE-750
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml 
> generation
>Reporter: Rostislav Svoboda
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 2.10
>
> Attachments: reportNameSuffix.patch, reportNameSuffix-remake.patch, 
> reportNameSuffix-tests.patch
>
>
> Hi. 
> I'd to add support in surefire for custom name suffix for tests in 
> surefire-reports.
> Motivation 1):
> I have more modules, some modules are sharing tests from another using 
> org.codehaus.mojo:build-helper-maven-plugin.
> I'd like to have txt and xml files with some differentiator to determine in 
> which module tests were executed.
> Motivation 2):
> I have defined several executions where I use different parameters and 
> execute the same tests in each execution.
> Again, I'd like to have txt and xml files with some differentiator.
> Solution:
> Introduce new configuration property reportNameSuffix.
> Patch for this improvement is included.
> Tested:
> Yes, customText added into surefire 
> plugin configuration and received these files:
>  org.xyz.test.componentA.ComponentAUnitTest-customText-output.txt  
>  org.xyz.test.componentA.ComponentAUnitTest-customText.txt 
>  org.xyz.test.componentB.ComponentBUnitTest-customText-output.txt
>  org.xyz.test.componentB.ComponentBUnitTest-customText.txt
>  TEST-org.xyz.test.componentA.ComponentAUnitTest-customText.xml
>  TEST-org.xyz.test.componentB.ComponentBUnitTest-customText.xml
> Tested without  defined too, original file names and 
> content generated.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MASSEMBLY-230) not filtering resources, but does filter

[Jon Travis (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272418#comment-272418
 ] 

Jon Travis commented on MASSEMBLY-230:
--

FWIW, I am still seeing this in Maven 2.2.1

>  not filtering resources, but  does filter
> --
>
> Key: MASSEMBLY-230
> URL: https://jira.codehaus.org/browse/MASSEMBLY-230
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: Windows XP Maven 2.0.5
>Reporter: Mick Knutson
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
>
> In my assembly descriptor, this does not filter my resources:
>   
> ${basedir}/src/main/resources/deploy
> true
> true
> /
> 
>   *.sh
>   *.bat
> 
> 0544
>   
> But this DOES filter the same resources just fine:
>   
>   
> 
> ${basedir}/src/main/resources/deploy/deploy.sh.txt
> deploy
> test.sh
> true
> unix
> 0554
>   
>
> I have tried 2.2-beta-1 and 2.1 of the plugin and it acts the same way.
> A workaround is to just specify each file individually, but I have dozens of 
> files and the descriptor is going to get quite cluttered.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSITE-594) release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects

[Lukas Theussl (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-594.
---

Resolution: Incomplete
  Assignee: Lukas Theussl

John: I'm closing this as incomplete as I am unable to reproduce without 
detailed version information of the plugins involved. Note that current 
site-plugin-2.3 has seen several fixes wrt stage(-deploy), see in particular 
MSITE-534, MSITE-535, MSITE-537 and related tickets. Please test with latest 
plugins and open another jira with a reproducible test case if the issue 
persists.

> release:stage does not properly compute new distroManagement.site.URL or 
> project.URLs for projects
> --
>
> Key: MSITE-594
> URL: https://jira.codehaus.org/browse/MSITE-594
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>  Components: site:stage(-deploy)
>Reporter: John Allen
>Assignee: Lukas Theussl
>Priority: Blocker
>
> In the case where you have a multi-module project and each module has its own 
> distributionManagement.site.url which is common with projects that like their 
> sites to be version numbered (see example beolw) the release:stage plugin 
> fails to get the project's site properly deployed. From a brief look it seems 
> release:sxtage is only computing a new URL for the owning project and not all 
> the child projects. What's more it looks like its changing the site 
> deployment URL and not the project's corresponding project URL. This results 
> in the site deployment for children going to their original pom.xml specific 
> locations regardless of them being 'staged' (i.e. they're not staged, they've 
> just gone live!). Nearly as bad is that all the relative links for connecting 
> modules and parents and banners together are broken too, as they are based 
> upoin the project.URL which hasnt been touched by the release:stage mojo. 
> site:stage makes a better fist of this, basically you need to remap the 
> entire URL domain (site distro and project url) to be under some other parent 
> space for you to successfully stage sites (see site:stage)
> This kind of mistake has come up in the past, simply put a project can define 
> all its own settings for everything so anything that makes assumptions based 
> on inheritence or 'defaults' is just gonna break the system. 
> Example of how sub-project's defining their own site deployemtn and project 
> URL information:
> {noformat}
> 
>   
> dav:https://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}
> 
> http://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}/
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira