[jira] [Updated] (MSHARED-966) Resources are not copied to ${project.build.outputDirectory}

2021-12-22 Thread Sylwester Lachiewicz (Jira)


 [ 
https://issues.apache.org/jira/browse/MSHARED-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylwester Lachiewicz updated MSHARED-966:
-
Affects Version/s: maven-filtering-3.3.0

> Resources are not copied to ${project.build.outputDirectory}
> 
>
> Key: MSHARED-966
> URL: https://issues.apache.org/jira/browse/MSHARED-966
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0, maven-filtering-3.3.0
> Environment: Maven 3.6.3, Java 11, macOS
>Reporter: Ralf Taugerbeck
>Priority: Major
> Attachments: maven-example.tgz, maven.log
>
>
> Hi,
> after upgrading from 3.1.0 to 3.2.0 I get this weird issue. My build fails 
> with a java.nio.file.NoSuchFileException for a file, that actually exists in 
> the resources directory.
> What's special about the file is that it was extracted from a dependency 
> artifact. I know this is a strange use case, but for us it is the only way to 
> supply a common Velocity macro library file to other modules for Velocity 
> template development with IntelliJ (only relative paths supported).
> File content and encoding do not seem to have an impact. Could it be because 
> of an archive flag? If I modify and save the file, the build works fine 
> again...
> If necessary, I can provide a stack trace or detailed log.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (MSHARED-966) Resources are not copied to ${project.build.outputDirectory}

2021-12-22 Thread Sylwester Lachiewicz (Jira)


 [ 
https://issues.apache.org/jira/browse/MSHARED-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylwester Lachiewicz updated MSHARED-966:
-
Fix Version/s: (was: maven-filtering-3.3.0)

> Resources are not copied to ${project.build.outputDirectory}
> 
>
> Key: MSHARED-966
> URL: https://issues.apache.org/jira/browse/MSHARED-966
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0
> Environment: Maven 3.6.3, Java 11, macOS
>Reporter: Ralf Taugerbeck
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Attachments: maven-example.tgz, maven.log
>
>
> Hi,
> after upgrading from 3.1.0 to 3.2.0 I get this weird issue. My build fails 
> with a java.nio.file.NoSuchFileException for a file, that actually exists in 
> the resources directory.
> What's special about the file is that it was extracted from a dependency 
> artifact. I know this is a strange use case, but for us it is the only way to 
> supply a common Velocity macro library file to other modules for Velocity 
> template development with IntelliJ (only relative paths supported).
> File content and encoding do not seem to have an impact. Could it be because 
> of an archive flag? If I modify and save the file, the build works fine 
> again...
> If necessary, I can provide a stack trace or detailed log.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (MSHARED-966) Resources are not copied to ${project.build.outputDirectory}

2021-12-05 Thread Sylwester Lachiewicz (Jira)


 [ 
https://issues.apache.org/jira/browse/MSHARED-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylwester Lachiewicz updated MSHARED-966:
-
Fix Version/s: maven-filtering-3.3.0

> Resources are not copied to ${project.build.outputDirectory}
> 
>
> Key: MSHARED-966
> URL: https://issues.apache.org/jira/browse/MSHARED-966
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0
> Environment: Maven 3.6.3, Java 11, macOS
>Reporter: Ralf Taugerbeck
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: maven-filtering-3.3.0
>
> Attachments: maven-example.tgz, maven.log
>
>
> Hi,
> after upgrading from 3.1.0 to 3.2.0 I get this weird issue. My build fails 
> with a java.nio.file.NoSuchFileException for a file, that actually exists in 
> the resources directory.
> What's special about the file is that it was extracted from a dependency 
> artifact. I know this is a strange use case, but for us it is the only way to 
> supply a common Velocity macro library file to other modules for Velocity 
> template development with IntelliJ (only relative paths supported).
> File content and encoding do not seem to have an impact. Could it be because 
> of an archive flag? If I modify and save the file, the build works fine 
> again...
> If necessary, I can provide a stack trace or detailed log.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (MSHARED-966) Resources are not copied to ${project.build.outputDirectory}

2020-12-20 Thread Michael Osipov (Jira)


 [ 
https://issues.apache.org/jira/browse/MSHARED-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MSHARED-966:
---
Component/s: maven-filtering

> Resources are not copied to ${project.build.outputDirectory}
> 
>
> Key: MSHARED-966
> URL: https://issues.apache.org/jira/browse/MSHARED-966
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0
> Environment: Maven 3.6.3, Java 11, macOS
>Reporter: Ralf Taugerbeck
>Priority: Major
> Attachments: maven-example.tgz, maven.log
>
>
> Hi,
> after upgrading from 3.1.0 to 3.2.0 I get this weird issue. My build fails 
> with a java.nio.file.NoSuchFileException for a file, that actually exists in 
> the resources directory.
> What's special about the file is that it was extracted from a dependency 
> artifact. I know this is a strange use case, but for us it is the only way to 
> supply a common Velocity macro library file to other modules for Velocity 
> template development with IntelliJ (only relative paths supported).
> File content and encoding do not seem to have an impact. Could it be because 
> of an archive flag? If I modify and save the file, the build works fine 
> again...
> If necessary, I can provide a stack trace or detailed log.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)