[jira] [Comment Edited] (MNG-3328) Allow multiple profile activation properties.
[
https://issues.apache.org/jira/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375313#comment-16375313
]
Christopher Tubbs edited comment on MNG-3328 at 2/24/18 5:31 AM:
-
This issue currently has 103 votes and 85 watchers. I wonder if this is the
most anticipated backlogged feature of Maven for the last 10 years since it was
initially requested? In any case, MNG-6345 could be a good alternative to the
boolean operations that folks have suggested here.
was (Author: ctubbsii):
This issue currently has 105 votes and 85 watchers. I wonder if this is the
most anticipated backlogged feature of Maven for the last 10 years since it was
initially requested? In any case, MNG-6345 could be a good alternative to the
boolean operations that folks have suggested here.
> Allow multiple profile activation properties.
> -
>
> Key: MNG-3328
> URL: https://issues.apache.org/jira/browse/MNG-3328
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.8
>Reporter: Paul Gier
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> The pom model should be changed to allow multiple properties to activate a
> profile. So the profile activation section could look something like this:
> {code:xml}
>
>
> some-value
> another-value
>
>
> {code}
> This would provide more flexibility in profile activation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-3328) Allow multiple profile activation properties.
[
https://issues.apache.org/jira/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375313#comment-16375313
]
Christopher Tubbs commented on MNG-3328:
This issue currently has 105 votes and 85 watchers. I wonder if this is the
most anticipated backlogged feature of Maven for the last 10 years since it was
initially requested? In any case, MNG-6345 could be a good alternative to the
boolean operations that folks have suggested here.
> Allow multiple profile activation properties.
> -
>
> Key: MNG-3328
> URL: https://issues.apache.org/jira/browse/MNG-3328
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.8
>Reporter: Paul Gier
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> The pom model should be changed to allow multiple properties to activate a
> profile. So the profile activation section could look something like this:
> {code:xml}
>
>
> some-value
> another-value
>
>
> {code}
> This would provide more flexibility in profile activation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6345) Support profile activation via script.
[ https://issues.apache.org/jira/browse/MNG-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375312#comment-16375312 ] Christopher Tubbs commented on MNG-6345: This would solve MNG-3328. > Support profile activation via script. > -- > > Key: MNG-6345 > URL: https://issues.apache.org/jira/browse/MNG-6345 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build >Affects Versions: 3.5.2 >Reporter: Andrei Pozolotin >Priority: Major > > Please consider introduction of new profile activation method: "script". > Here is working prototype which adds required functionality via > PropertyActivator: > [https://github.com/random-maven/profile-activator-extension] > in the final form, this feature usage will look like: > > > >javascript >print("hello-maven"); return true;> > > > Suggested minimal supported script types: > * Groovy > * JavaScript > * MVEL Script -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MDEP-559) Java 9 bytecode cannot be parsed
[
https://issues.apache.org/jira/browse/MDEP-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEP-559.
---
Resolution: Fixed
Fix Version/s: 3.1.0
Fixed in
[8b75d89ab193f835b222b250413a19b1fe92bc81|https://gitbox.apache.org/repos/asf?p=maven-dependency-plugin.git;a=commit;h=8b75d89ab193f835b222b250413a19b1fe92bc81]
> Java 9 bytecode cannot be parsed
>
>
> Key: MDEP-559
> URL: https://issues.apache.org/jira/browse/MDEP-559
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T21:17:27+11:00)
> Maven home: /opt/maven
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-9-jdk
> Default locale: en_AU, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-1-arch", arch: "amd64", family: "unix"
>Reporter: Ben Alex
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
>
> Attempting to run analyze-only against source compiled with Java 9 results in:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.0.0:analyze-only (config-dependency) @
> lmdbjava ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only from
> plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-dependency-plugin:3.0.0,
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@3b764bce]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only' with
> basic configurator -->
> [DEBUG] (f) analyzer = default
> [DEBUG] (f) baseDir = /home/bpa/projects/lmdbjava
> [DEBUG] (f) failOnWarning = true
> [DEBUG] (f) ignoreNonCompile = false
> [DEBUG] (f) outputDirectory = /home/bpa/projects/lmdbjava/target
> [DEBUG] (f) outputXML = false
> [DEBUG] (f) project = MavenProject: org.lmdbjava:lmdbjava:0.0.6-SNAPSHOT @
> /home/bpa/projects/lmdbjava/dependency-reduced-pom.xml
> [DEBUG] (f) scriptableFlag = $$%%%
> [DEBUG] (f) scriptableOutput = false
> [DEBUG] (f) skip = false
> [DEBUG] (f) usedDependencies = [org.lmdbjava:lmdbjava-native-linux-x86_64,
> org.lmdbjava:lmdbjava-native-windows-x86_64,
> org.lmdbjava:lmdbjava-native-osx-x86_64]
> [DEBUG] (f) verbose = false
> [DEBUG] -- end configuration --
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 7.256 s
> [INFO] Finished at: 2017-03-17T17:32:20+11:00
> [INFO] Final Memory: 40M/132M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only
> (config-dependency) on project lmdbjava: Execution config-dependency of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only failed.
> IllegalArgumentException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only
> (config-dependency) on project lmdbjava: Execution config-dependency of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Commented] (MDEP-559) Java 9 bytecode cannot be parsed
[
https://issues.apache.org/jira/browse/MDEP-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374529#comment-16374529
]
Hudson commented on MDEP-559:
-
Build succeeded in Jenkins: Maven TLP » maven-dependency-plugin » master #4
See
https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/4/
> Java 9 bytecode cannot be parsed
>
>
> Key: MDEP-559
> URL: https://issues.apache.org/jira/browse/MDEP-559
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T21:17:27+11:00)
> Maven home: /opt/maven
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-9-jdk
> Default locale: en_AU, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-1-arch", arch: "amd64", family: "unix"
>Reporter: Ben Alex
>Assignee: Robert Scholte
>Priority: Major
>
> Attempting to run analyze-only against source compiled with Java 9 results in:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.0.0:analyze-only (config-dependency) @
> lmdbjava ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only from
> plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-dependency-plugin:3.0.0,
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@3b764bce]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only' with
> basic configurator -->
> [DEBUG] (f) analyzer = default
> [DEBUG] (f) baseDir = /home/bpa/projects/lmdbjava
> [DEBUG] (f) failOnWarning = true
> [DEBUG] (f) ignoreNonCompile = false
> [DEBUG] (f) outputDirectory = /home/bpa/projects/lmdbjava/target
> [DEBUG] (f) outputXML = false
> [DEBUG] (f) project = MavenProject: org.lmdbjava:lmdbjava:0.0.6-SNAPSHOT @
> /home/bpa/projects/lmdbjava/dependency-reduced-pom.xml
> [DEBUG] (f) scriptableFlag = $$%%%
> [DEBUG] (f) scriptableOutput = false
> [DEBUG] (f) skip = false
> [DEBUG] (f) usedDependencies = [org.lmdbjava:lmdbjava-native-linux-x86_64,
> org.lmdbjava:lmdbjava-native-windows-x86_64,
> org.lmdbjava:lmdbjava-native-osx-x86_64]
> [DEBUG] (f) verbose = false
> [DEBUG] -- end configuration --
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 7.256 s
> [INFO] Finished at: 2017-03-17T17:32:20+11:00
> [INFO] Final Memory: 40M/132M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only
> (config-dependency) on project lmdbjava: Execution config-dependency of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only failed.
> IllegalArgumentException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only
> (config-dependency) on project lmdbjava: Execution config-dependency of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Created] (MSHARED-684) Upgrade parent to 31
Karl Heinz Marbaise created MSHARED-684: --- Summary: Upgrade parent to 31 Key: MSHARED-684 URL: https://issues.apache.org/jira/browse/MSHARED-684 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Affects Versions: maven-shared-utils-3.3.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-shared-utils-3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRAR-71) Upgrade parent to 31
[ https://issues.apache.org/jira/browse/MRAR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MRAR-71. --- Resolution: Fixed Done in [ae9e4a6b31ed670db4b2c966e81980527dbc637f|https://gitbox.apache.org/repos/asf?p=maven-rar-plugin.git;a=commitdiff;h=ae9e4a6b31ed670db4b2c966e81980527dbc637f] > Upgrade parent to 31 > > > Key: MRAR-71 > URL: https://issues.apache.org/jira/browse/MRAR-71 > Project: Maven Rar Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSHARED-685) DirectoryScanner#checkSymlinkBehaviour() does not use assert*
Karl Heinz Marbaise created MSHARED-685: --- Summary: DirectoryScanner#checkSymlinkBehaviour() does not use assert* Key: MSHARED-685 URL: https://issues.apache.org/jira/browse/MSHARED-685 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Affects Versions: maven-shared-utils-3.3.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-shared-utils-3.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-502) Succesfull PUT times out on Nexus
[
https://issues.apache.org/jira/browse/WAGON-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kutschke updated WAGON-502:
---
Description:
I am uploading artifacts manually to a raw Nexus repository using
maven-wagon-plugin. After succesfull upload of the first file, nothing happens
until read timeout is hit.
As far as I can tell, this problem happens with both http providers.
I have tried disabling pooling, setting -Dhttp.protocol.expect-continue=false.
I have tried uploading the file with curl, this gives the following output (and
returns!):
{quote} * timeout on name lookup is not supported
* Trying 10.215.60.229...
* Connected to 10.215.60.229 (10.215.60.229) port 9081 (#0)
* Server auth using Basic with user 'deployment'
> PUT /repository/xcit-test/v_5.1.0/web/js.js HTTP/1.1
> Host: 10.215.60.229:9081
> Authorization: Basic ZGVwbG95bWVudDp4Y2l0ZGVwbG95bWVudDEyMw==
> User-Agent: curl/7.50.1
> Accept: */*
> Content-Length: 414
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 201 Created
< Date: Fri, 23 Feb 2018 09:34:46 GMT
< Server: Nexus/3.6.0-02 (OSS)
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< Content-Length: 0
<
* Connection #0 to host 10.215.60.229 left intact{quote}
I looked at the code of maven-wagon-plugin but did not find anything
suspicious, and seeing that both providers seem to be affected, I assume the
problem lies with a shared component of both providers.
Stacktrace:
{code:java}
Caused by: org.apache.maven.wagon.TransferFailedException: Read timed out
at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
(AbstractHttpClientWagon.java:650)
at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
(AbstractHttpClientWagon.java:553)
at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
(AbstractHttpClientWagon.java:535)
at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
(AbstractHttpClientWagon.java:529)
at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
(AbstractHttpClientWagon.java:509)
at org.codehaus.mojo.wagon.shared.DefaultWagonUpload.upload
(DefaultWagonUpload.java:79)
at org.codehaus.mojo.wagon.shared.DefaultWagonUpload.upload
(DefaultWagonUpload.java:89)
at org.codehaus.mojo.wagon.UploadMojo.execute (UploadMojo.java:120)
at org.codehaus.mojo.wagon.AbstractSingleWagonMojo.execute
(AbstractSingleWagonMojo.java:64)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0 (Native Method)
at java.net.SocketInputStream.socketRead (SocketInputStream.java:116)
at java.net.SocketInputStream.read (SocketInputStream.java:171)
at java.net.SocketInputStream.read (SocketInputStream.java:141)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.streamRead
(SessionInputBufferImpl.java:139)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.fillBuffer
(SessionInputBufferImpl.java:155)
at
[jira] [Created] (WAGON-502) Succesfull PUT times out on Nexus
Michael Kutschke created WAGON-502:
--
Summary: Succesfull PUT times out on Nexus
Key: WAGON-502
URL: https://issues.apache.org/jira/browse/WAGON-502
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http, wagon-http-lightweight
Affects Versions: 3.0.0
Environment: Windows 7, Nexus 3.6.0, maven 3.5.2
Reporter: Michael Kutschke
I am uploading artifacts manually to a raw Nexus repository using
maven-wagon-plugin. After succesfull upload of the first file, nothing happens
until read timeout is hit.
As far as I can tell, this problem happens with both http providers.
I have tried disabling pooling, setting -Dhttp.protocol.expect-continue=false.
I have tried uploading the file with curl, this gives the following output (and
returns!):
{quote} * timeout on name lookup is not supported
* Trying 10.215.60.229...
* Connected to 10.215.60.229 (10.215.60.229) port 9081 (#0)
* Server auth using Basic with user 'deployment'
> PUT /repository/xcit-test/v_5.1.0/web/js.js HTTP/1.1
> Host: 10.215.60.229:9081
> Authorization: Basic ZGVwbG95bWVudDp4Y2l0ZGVwbG95bWVudDEyMw==
> User-Agent: curl/7.50.1
> Accept: */*
> Content-Length: 414
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 201 Created
< Date: Fri, 23 Feb 2018 09:34:46 GMT
< Server: Nexus/3.6.0-02 (OSS)
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< Content-Length: 0
<
* Connection #0 to host 10.215.60.229 left intact{quote}
I looked at the code of maven-wagon-plugin but did not find anything
suspicious, and seeing that both providers seem to be affected, I assume the
problem lies with a shared component of both providers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MRELEASE-1000) Property to add release.properties to commit
Archimedes Trajano created MRELEASE-1000: Summary: Property to add release.properties to commit Key: MRELEASE-1000 URL: https://issues.apache.org/jira/browse/MRELEASE-1000 Project: Maven Release Plugin Issue Type: Improvement Components: prepare Reporter: Archimedes Trajano The purpose of this is to allow a release:perform on a tag checkout that contains the release.properties already rather than expecting it to be present. The way it would work is doing a prepare before doing the tag, add the "release.properties" file and before committing the new snapshot poms delete the "release.properties" file. This should be done via a user property. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARCHETYPE-492) Underscore in filenames problematic due to greedy regex
[
https://issues.apache.org/jira/browse/ARCHETYPE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374383#comment-16374383
]
Giovanni Lovato commented on ARCHETYPE-492:
---
This is an issue also for archetypes which contains Flyway database migration
files, which has a specific filename pattern, e.g. \{{V2__my-schema.sql}} (i.e.
version + _ + _ + description). So if I include in the archetype a file named
{{V2rootArtifactId__-schema.sql}} I would expect it to be created as
{{V2__my-artifact-schema.sql}}.
> Underscore in filenames problematic due to greedy regex
> ---
>
> Key: ARCHETYPE-492
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-492
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.4
> Environment: Windows 7, Sun JDK
>Reporter: Oliver Dungey
>Priority: Major
>
> If you have a file in a project with an underscore adjacent to a substitution
> variable, the substitution will fail i.e.
> if {{artifactId}} is 'Test' and a target file is to be named
> {{something_test.txt}} the file in the template should be named
> {{somethingartifactId__.txt}} (3 underscores in the middle) but the
> result is an error stating that the property {{_artifactId}} cannot be found.
> This is because the term inside the regex is a greedy .* - a simple fix
> would be to change this to something like __[^_]*___ which would only match
> non-underscore characters.
> Fixing this issue would allow the use of underscores in filenames in all
> circumstances rather than the current situation where you may get lucky. The
> only down side to fixing this issue is that properties with leading or
> trailing underscores will not be valid - this seems a far more preferable
> situation.
> A patch for this issue was put on this bug back in 01//2009 but somehow got
> ignored - see [~maslovalex] patch and comments at the end of this issue:
> https://issues.apache.org/jira/browse/ARCHETYPE-191
> Apologies for the formatting - it appears double underscores are an issue :-)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARCHETYPE-492) Underscore in filenames problematic due to greedy regex
[
https://issues.apache.org/jira/browse/ARCHETYPE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374383#comment-16374383
]
Giovanni Lovato edited comment on ARCHETYPE-492 at 2/23/18 2:06 PM:
This is an issue also for archetypes which contains Flyway database migration
files, which has a specific filename pattern, e.g. {{V2__my-schema.sql}} (i.e.
version + _ + _ + description). So if I include in the archetype a file named
{{V2rootArtifactId__-schema.sql}} I would expect it to be created as
{{V2__my-artifact-schema.sql}}.
was (Author: heruan):
This is an issue also for archetypes which contains Flyway database migration
files, which has a specific filename pattern, e.g. \{{V2__my-schema.sql}} (i.e.
version + _ + _ + description). So if I include in the archetype a file named
{{V2rootArtifactId__-schema.sql}} I would expect it to be created as
{{V2__my-artifact-schema.sql}}.
> Underscore in filenames problematic due to greedy regex
> ---
>
> Key: ARCHETYPE-492
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-492
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.4
> Environment: Windows 7, Sun JDK
>Reporter: Oliver Dungey
>Priority: Major
>
> If you have a file in a project with an underscore adjacent to a substitution
> variable, the substitution will fail i.e.
> if {{artifactId}} is 'Test' and a target file is to be named
> {{something_test.txt}} the file in the template should be named
> {{somethingartifactId__.txt}} (3 underscores in the middle) but the
> result is an error stating that the property {{_artifactId}} cannot be found.
> This is because the term inside the regex is a greedy .* - a simple fix
> would be to change this to something like __[^_]*___ which would only match
> non-underscore characters.
> Fixing this issue would allow the use of underscores in filenames in all
> circumstances rather than the current situation where you may get lucky. The
> only down side to fixing this issue is that properties with leading or
> trailing underscores will not be valid - this seems a far more preferable
> situation.
> A patch for this issue was put on this bug back in 01//2009 but somehow got
> ignored - see [~maslovalex] patch and comments at the end of this issue:
> https://issues.apache.org/jira/browse/ARCHETYPE-191
> Apologies for the formatting - it appears double underscores are an issue :-)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARCHETYPE-492) Underscore in filenames problematic due to greedy regex
[
https://issues.apache.org/jira/browse/ARCHETYPE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374383#comment-16374383
]
Giovanni Lovato edited comment on ARCHETYPE-492 at 2/23/18 2:07 PM:
This is an issue also for archetypes which contains Flyway database migration
files, which has a specific filename pattern, e.g. {{V2\_\_my-schema.sql}}
(i.e. version + {{\_}} + {{\_}} + description). So if I include in the
archetype a file named {{V2\_\_\_\_rootArtifactId\_\_-schema.sql}} I would
expect it to be created as {{V2\_\_my-artifact-schema.sql}}.
was (Author: heruan):
This is an issue also for archetypes which contains Flyway database migration
files, which has a specific filename pattern, e.g. {{V2__my-schema.sql}} (i.e.
version + _ + _ + description). So if I include in the archetype a file named
{{V2rootArtifactId__-schema.sql}} I would expect it to be created as
{{V2__my-artifact-schema.sql}}.
> Underscore in filenames problematic due to greedy regex
> ---
>
> Key: ARCHETYPE-492
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-492
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.4
> Environment: Windows 7, Sun JDK
>Reporter: Oliver Dungey
>Priority: Major
>
> If you have a file in a project with an underscore adjacent to a substitution
> variable, the substitution will fail i.e.
> if {{artifactId}} is 'Test' and a target file is to be named
> {{something_test.txt}} the file in the template should be named
> {{somethingartifactId__.txt}} (3 underscores in the middle) but the
> result is an error stating that the property {{_artifactId}} cannot be found.
> This is because the term inside the regex is a greedy .* - a simple fix
> would be to change this to something like __[^_]*___ which would only match
> non-underscore characters.
> Fixing this issue would allow the use of underscores in filenames in all
> circumstances rather than the current situation where you may get lucky. The
> only down side to fixing this issue is that properties with leading or
> trailing underscores will not be valid - this seems a far more preferable
> situation.
> A patch for this issue was put on this bug back in 01//2009 but somehow got
> ignored - see [~maslovalex] patch and comments at the end of this issue:
> https://issues.apache.org/jira/browse/ARCHETYPE-191
> Apologies for the formatting - it appears double underscores are an issue :-)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-502) Succesfull PUT times out on Nexus
[
https://issues.apache.org/jira/browse/WAGON-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374304#comment-16374304
]
Michael Kutschke commented on WAGON-502:
After reading a bit more code, it seems that it is not possible to override the
default http.protocol.expect-continue=true for PUT messages. It would be nice
to be able to test if this changes anything, please consider making this
configurable.
> Succesfull PUT times out on Nexus
> -
>
> Key: WAGON-502
> URL: https://issues.apache.org/jira/browse/WAGON-502
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http, wagon-http-lightweight
>Affects Versions: 3.0.0
> Environment: Windows 7, Nexus 3.6.0, maven 3.5.2
>Reporter: Michael Kutschke
>Priority: Major
>
> I am uploading artifacts manually to a raw Nexus repository using
> maven-wagon-plugin. After succesfull upload of the first file, nothing
> happens until read timeout is hit.
>
> As far as I can tell, this problem happens with both http providers.
>
> I have tried disabling pooling, setting -Dhttp.protocol.expect-continue=false.
> I have tried uploading the file with curl, this gives the following output
> (and returns!):
>
> {quote} * timeout on name lookup is not supported
> * Trying 10.215.60.229...
> * Connected to 10.215.60.229 (10.215.60.229) port 9081 (#0)
> * Server auth using Basic with user 'deployment'
> > PUT /repository/xcit-test/v_5.1.0/web/js.js HTTP/1.1
> > Host: 10.215.60.229:9081
> > Authorization: Basic ZGVwbG95bWVudDp4Y2l0ZGVwbG95bWVudDEyMw==
> > User-Agent: curl/7.50.1
> > Accept: */*
> > Content-Length: 414
> > Expect: 100-continue
> >
> < HTTP/1.1 100 Continue
> * We are completely uploaded and fine
> < HTTP/1.1 201 Created
> < Date: Fri, 23 Feb 2018 09:34:46 GMT
> < Server: Nexus/3.6.0-02 (OSS)
> < X-Frame-Options: SAMEORIGIN
> < X-Content-Type-Options: nosniff
> < Content-Length: 0
> <
> * Connection #0 to host 10.215.60.229 left intact{quote}
>
> I looked at the code of maven-wagon-plugin but did not find anything
> suspicious, and seeing that both providers seem to be affected, I assume the
> problem lies with a shared component of both providers.
>
> Stacktrace:
>
> {code:java}
> Caused by: org.apache.maven.wagon.TransferFailedException: Read timed out
> at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:650)
> at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:553)
> at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:535)
> at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:529)
> at org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:509)
> at org.codehaus.mojo.wagon.shared.DefaultWagonUpload.upload
> (DefaultWagonUpload.java:79)
> at org.codehaus.mojo.wagon.shared.DefaultWagonUpload.upload
> (DefaultWagonUpload.java:89)
> at org.codehaus.mojo.wagon.UploadMojo.execute (UploadMojo.java:120)
> at org.codehaus.mojo.wagon.AbstractSingleWagonMojo.execute
> (AbstractSingleWagonMojo.java:64)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at
