[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=16292219#comment-16292219
]
Matthias Hanisch edited comment on ARCHETYPE-492 at 12/15/17 9:19 AM:
--
Just to let everybody else know my workaround:
In archetype-metadata I created a requiredProperty like this:
{noformat}
_${artifactId}
{noformat}
The above filename can be now written as
{noformat}
errors__underscoreArtifactId__.properties
{noformat}
This avoids the triple-underscore-problem. Ugly, but works.
was (Author: matze):
Just to let everybody else know my workaround:
In archetype-metadata I created a requiredProperty like this:
{noformat}
_${artifactId}
{noformat}
The above filename can be now written as
errors___underscoreArtifactId___.properties.
This avoids the triple-underscore-problem
> 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
>
> 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
(v6.4.14#64029)
[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=16290895#comment-16290895
]
Matthias Hanisch edited comment on ARCHETYPE-492 at 12/15/17 9:17 AM:
--
Got the same problem today. Wanted to generate a file
{noformat}
errors_${artifactId}.properties
{noformat}
so I chose the filename
{noformat}
errors___artifactId__.properties
{noformat}
in the archetype.
The placeholder in the file name was not resolved.
was (Author: matze):
Got the same problem today. Wanted to generate a file
errors_${artifactId}.properties, so I chose the filename
errorsartifactId___.properties in the archetype.
The placeholder in the file name was not resolved.
> 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
>
> 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
(v6.4.14#64029)
[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=16292219#comment-16292219
]
Matthias Hanisch commented on ARCHETYPE-492:
Just to let everybody else know my workaround:
In archetype-metadata I created a requiredProperty like this:
{noformat}
_${artifactId}
{noformat}
The above filename can be now written as
errors___underscoreArtifactId___.properties.
This avoids the triple-underscore-problem
> 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
>
> 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
(v6.4.14#64029)
[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=16290895#comment-16290895
]
Matthias Hanisch edited comment on ARCHETYPE-492 at 12/14/17 2:20 PM:
--
Got the same problem today. Wanted to generate a file
errors_${artifactId}.properties, so I chose the filename
errorsartifactId___.properties in the archetype.
The placeholder in the file name was not resolved.
was (Author: matze):
Got the same problem today. Wanted to generate a file
errors_${artifactId}.properties, so I chose the filename
errors___artifactId__.properties in the archetype.
The placeholder in the file name was not resolved.
> 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
>
> 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
(v6.4.14#64029)
[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=16290895#comment-16290895
]
Matthias Hanisch commented on ARCHETYPE-492:
Got the same problem today. Wanted to generate a file
errors_${artifactId}.properties, so I chose the filename
errors___artifactId__.properties in the archetype.
The placeholder in the file name was not resolved.
> 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
>
> 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
(v6.4.14#64029)
[jira] [Commented] (MDEPLOY-202) deploy-file goal insists on deploying source file for previous deploy-file execution
[
https://issues.apache.org/jira/browse/MDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15346398#comment-15346398
]
Matthias Hanisch commented on MDEPLOY-202:
--
Looking at the commit for this issue it seems to me that this really does not
fix my case where the attachment was not added within a deploy-file
configuration but within the normal project lifecycle - in my case by
maven-source-plugin and maven-javadoc-plugin.
> deploy-file goal insists on deploying source file for previous deploy-file
> execution
>
>
> Key: MDEPLOY-202
> URL: https://issues.apache.org/jira/browse/MDEPLOY-202
> Project: Maven Deploy Plugin
> Issue Type: Sub-task
> Components: deploy:deploy-file
>Affects Versions: 2.8.1, 2.8.2
>Reporter: Stephan Leicht Vogt
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
> Attachments: MDEPLOY-202-DeployFileMojo.patch
>
>
> In a releng pom I deploy various files to a repository. Each file is in its
> own execution. Beside the binary file I also want to deploy the source jar:
> {code:xml}
>
> deploy-equinox-snapshots
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
>
>
> deploy-osgi
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.osgi_${org.eclipse.osgi}.jar
>
> ${downloaded}/org.eclipse.osgi.source_${org.eclipse.osgi}.jar
>
> ${project.build.outputDirectory}/org.eclipse.osgi.pom
>
>
>
> deploy-equinox-common
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.equinox.common_${org.eclipse.equinox.common}.jar
>
> ${downloaded}/org.eclipse.equinox.common.source_${org.eclipse.equinox.common}.jar
>
> ${project.build.outputDirectory}/org.eclipse.equinox.common.pom
>
>
>
> deploy-equinox-security
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.equinox.security_${org.eclipse.equinox.security}.jar
>
> ${downloaded}/org.eclipse.equinox.security.source_${org.eclipse.equinox.security}.jar
>
> ${project.build.outputDirectory}/org.eclipse.equinox.security.pom
>
>
>
> deploy-equinox-registry
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.equinox.registry_${org.eclipse.equinox.registry}.jar
>
> ${downloaded}/org.eclipse.equinox.registry.source_${org.eclipse.equinox.registry}.jar
>
> ${project.build.outputDirectory}/org.eclipse.equinox.registry.pom
>
>
>
> deploy-equinox-preferences
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.equinox.preferences_${org.eclipse.equinox.preferences}.jar
>
> ${downloaded}/org.eclipse.equinox.preferences.source_${org.eclipse.equinox.preferences}.jar
>
> ${project.build.outputDirectory}/org.eclipse.equinox.preferences.pom
>
>
>
>
>
>
>
> {code}
> The first execution works fine but every other execution deploys again the
> source files from all past executions. Although this works for SNAPSHOTS it
> breaks for RELEASES as a released file shouldn't/can't be overwritten.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MDEPLOY-202) deploy-file goal insists on deploying source file for previous deploy-file execution
[
https://issues.apache.org/jira/browse/MDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15346270#comment-15346270
]
Matthias Hanisch edited comment on MDEPLOY-202 at 6/23/16 12:55 PM:
Sorry to jump in late.
We got also hit by the issue above and I gave it a quick try to check if our
scenario is really solved with the upcoming 3.0.0 of deploy plugin.
I created a very simple jar project with a hello world class and a accompanying
bill of materials which should be additionally uploaded using deploy-file goal.
The pom attaches sources and javadoc jar, executes "default-deploy" to upload
the "hello world" jar and also executes a deploy-file to upload the
corresponding bom.
The "deploy-bom" still uploads sources and javadoc jar again, even with
3.0.0-SNAPSHOT.
Let me just attach the relevant plugin configurations. If more information is
required or if I should create a new issue just let me know.
{code:xml}
maven-javadoc-plugin
2.10.4
attach-javadocs
jar
maven-source-plugin
3.0.0
attach-sources
jar
maven-deploy-plugin
3.0.0-SNAPSHOT
${project.distributionManagementArtifactRepository.url}
${project.distributionManagementArtifactRepository.id}
deploy-bom
deploy
deploy-file
${project.basedir}/bom/pom.xml
${project.basedir}/bom/pom.xml
{code}
was (Author: matze):
Sorry to jump in late.
We got also hit by the issue above and I gave it a quick try to check if our
scenario is really solved with the upcoming 3.0.0 of deploy plugin.
I created a very simple jar project with a hello world class and a accompanying
bill of materials which should be additionally uploaded using deploy-file goal.
The pom attaches sources and javadoc jar, executes "default-deploy" to upload
the "hello world" jar and also executes a deploy-file to upload the
corresponding bom.
The "deploy-bom" still uploads sources and javadoc jar again, even with
3.0.0-SNAPSHOT.
Let me just attach the relevant plugin configurations. If more information is
required or if I should create a new issue just let me know.
maven-javadoc-plugin
2.10.4
attach-javadocs
jar
maven-source-plugin
3.0.0
attach-sources
jar
maven-deploy-plugin
3.0.0-SNAPSHOT
${project.distributionManagementArtifactRepository.url}
${project.distributionManagementArtifactRepository.id}
deploy-bom
deploy
deploy-file
${project.basedir}/bom/pom.xml
${project.basedir}/bom/pom.xml
> deploy-file goal insists on deploying source file for previous deploy-file
> execution
>
>
> Key: MDEPLOY-202
> URL: https://issues.apache.org/jira/browse/MDEPLOY-202
> Project: Maven Deploy Plugin
> Issue Type: Sub-task
> Components: deploy:deploy-file
>Affects Versions: 2.8.1, 2.8.2
>Reporter: Stephan Leicht Vogt
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
> Attachments: MDEPLOY-202-DeployFileMojo.patch
>
>
> In a releng pom I deploy various files to a repository. Each file is in its
> own execution. Beside the binary file I also want to deploy the source jar:
> {code:xml}
>
> deploy-equinox-snapshots
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
>
>
> deploy-osgi
>
> deploy-file
>
[jira] [Commented] (MDEPLOY-202) deploy-file goal insists on deploying source file for previous deploy-file execution
[
https://issues.apache.org/jira/browse/MDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15346270#comment-15346270
]
Matthias Hanisch commented on MDEPLOY-202:
--
Sorry to jump in late.
We got also hit by the issue above and I gave it a quick try to check if our
scenario is really solved with the upcoming 3.0.0 of deploy plugin.
I created a very simple jar project with a hello world class and a accompanying
bill of materials which should be additionally uploaded using deploy-file goal.
The pom attaches sources and javadoc jar, executes "default-deploy" to upload
the "hello world" jar and also executes a deploy-file to upload the
corresponding bom.
The "deploy-bom" still uploads sources and javadoc jar again, even with
3.0.0-SNAPSHOT.
Let me just attach the relevant plugin configurations. If more information is
required or if I should create a new issue just let me know.
maven-javadoc-plugin
2.10.4
attach-javadocs
jar
maven-source-plugin
3.0.0
attach-sources
jar
maven-deploy-plugin
3.0.0-SNAPSHOT
${project.distributionManagementArtifactRepository.url}
${project.distributionManagementArtifactRepository.id}
deploy-bom
deploy
deploy-file
${project.basedir}/bom/pom.xml
${project.basedir}/bom/pom.xml
> deploy-file goal insists on deploying source file for previous deploy-file
> execution
>
>
> Key: MDEPLOY-202
> URL: https://issues.apache.org/jira/browse/MDEPLOY-202
> Project: Maven Deploy Plugin
> Issue Type: Sub-task
> Components: deploy:deploy-file
>Affects Versions: 2.8.1, 2.8.2
>Reporter: Stephan Leicht Vogt
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
> Attachments: MDEPLOY-202-DeployFileMojo.patch
>
>
> In a releng pom I deploy various files to a repository. Each file is in its
> own execution. Beside the binary file I also want to deploy the source jar:
> {code:xml}
>
> deploy-equinox-snapshots
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
>
>
> deploy-osgi
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.osgi_${org.eclipse.osgi}.jar
>
> ${downloaded}/org.eclipse.osgi.source_${org.eclipse.osgi}.jar
>
> ${project.build.outputDirectory}/org.eclipse.osgi.pom
>
>
>
> deploy-equinox-common
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.equinox.common_${org.eclipse.equinox.common}.jar
>
> ${downloaded}/org.eclipse.equinox.common.source_${org.eclipse.equinox.common}.jar
>
> ${project.build.outputDirectory}/org.eclipse.equinox.common.pom
>
>
>
> deploy-equinox-security
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.equinox.security_${org.eclipse.equinox.security}.jar
>
> ${downloaded}/org.eclipse.equinox.security.source_${org.eclipse.equinox.security}.jar
>
> ${project.build.outputDirectory}/org.eclipse.equinox.security.pom
>
>
>
> deploy-equinox-registry
>
> deploy-file
>
> deploy
>
>
> ${downloaded}/org.eclipse.equinox.registry_${org.eclipse.equinox.registry}.jar
>
> ${downloaded}/org.eclipse.equinox.registry.source_${org.eclipse.equinox.registry}.jar
>
> ${project.build.outputDirectory}/org.eclipse.equinox.registry.pom
>
>
>
>
