[JBoss JIRA] (SHRINKWRAP-450) Build not working due to lack of JAVA7_HOME environment variable
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-450?page=com.atlassian.jira.pl... ]
Andrew Rubinger updated SHRINKWRAP-450:
---------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
More upstream: https://github.com/shrinkwrap/shrinkwrap/commit/6ef62449106e15d9f7038caa5...
> Build not working due to lack of JAVA7_HOME environment variable
> ----------------------------------------------------------------
>
> Key: SHRINKWRAP-450
> URL: https://issues.jboss.org/browse/SHRINKWRAP-450
> Project: ShrinkWrap
> Issue Type: Bug
> Reporter: Chris Lowe
> Assignee: Michal Matloka
> Fix For: 1.1.3
>
>
> Shrinkwrap nio2-api fails to compile, resulting in the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building ShrinkWrap NIO.2 API 1.1.3-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ shrinkwrap-api-nio2 ---
> [INFO] Deleting C:\source\external\shrinkwrap\api-nio2\target
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-java-version) @ shrinkwrap-api-nio2 ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-maven-version) @ shrinkwrap-api-nio2 ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-maven-environment) @ shrinkwrap-api-nio2 ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ shrinkwrap-api-nio2 ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory C:\source\external\shrinkwrap\api-nio2\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ shrinkwrap-api-nio2 ---
> [INFO] Compiling 4 source files to C:\source\external\shrinkwrap\api-nio2\target\classes
> [INFO] -------------------------------------------------------------
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] Failure executing javac, but could not parse the error:
> The system cannot find the path specified.
> After some digging into this, it turned out this error was down to a missing environment variable JAVA7_HOME. This is not obvious from the error message.
> Currently in the shrinkwrap parent pom.xml there is a check for the JAVA5_HOME. Could an additional check be added at the same point for JAVA7_HOME?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (SHRINKWRAP-453) Paths in webarchives are not calculated correctly
by Stefan Hösel (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-453?page=com.atlassian.jira.pl... ]
Stefan Hösel commented on SHRINKWRAP-453:
-----------------------------------------
The directory can be copied to another "safe" location before creating the WebArchive but that's not really a good solution since it needs to be removed afterwards, uses additional space etc.
> Paths in webarchives are not calculated correctly
> -------------------------------------------------
>
> Key: SHRINKWRAP-453
> URL: https://issues.jboss.org/browse/SHRINKWRAP-453
> Project: ShrinkWrap
> Issue Type: Bug
> Components: api
> Affects Versions: 1.1.2
> Environment: Win7x64, JDK1.7.0_17x32, JBOSS 7.1.3.Final, Arquillian 1.0.3Final, JUnit 4.11
> Reporter: Stefan Hösel
>
> When creating a WebArchive via ShrinkWrap from a directory that is an exploded war file, paths inside this archive (generated with "arquillian.xml/arquillian/engine/property[deploymentExportPath]->target/deployments") generated invalid in some cases.
> When investigating the sources I found "org.jboss.shrinkwrap.impl.base.importer.ExplodedImporterImpl.calculatePath(File root, File child)" uses "String.replaceFirst" to replace the occurance of rootPath in childPath to create a local war file path. My path of the directory that needs compression contains *brackets*, which (as well as other path elements, e.g. ".") are interpreted as regular expression tokens and therefore don't match.
> The resulting archive can not be delpoyed in AS and tests can not be performed automatically.
> The code to create the WebArchive looks like this:
> {{ShrinkWrap._create_(WebArchive.{color:gray}*class*{color}, resultingWarFileNameAsString)}}
> {{.as(ExplodedImporter.{color:gray}*class*{color}).importDirectory(absolutePathToExplodedWarDirectoryAsFile)}}
> {{.as(WebArchive.{color:gray}*class*{color});}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (SHRINKWRAP-453) Paths in webarchives are not calculated correctly
by Stefan Hösel (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-453?page=com.atlassian.jira.pl... ]
Stefan Hösel updated SHRINKWRAP-453:
------------------------------------
Description:
When creating a WebArchive via ShrinkWrap from a directory that is an exploded war file, paths inside this archive (generated with "arquillian.xml/arquillian/engine/property[deploymentExportPath]->target/deployments") generated invalid in some cases.
When investigating the sources I found "org.jboss.shrinkwrap.impl.base.importer.ExplodedImporterImpl.calculatePath(File root, File child)" uses "String.replaceFirst" to replace the occurance of rootPath in childPath to create a local war file path. My path of the directory that needs compression contains *brackets*, which (as well as other path elements, e.g. ".") are interpreted as regular expression tokens and therefore don't match.
The resulting archive can not be delpoyed in AS and tests can not be performed automatically.
The code to create the WebArchive looks like this:
{{ShrinkWrap._create_(WebArchive.{color:gray}*class*{color}, resultingWarFileNameAsString)}}
{{.as(ExplodedImporter.{color:gray}*class*{color}).importDirectory(absolutePathToExplodedWarDirectoryAsFile)}}
{{.as(WebArchive.{color:gray}*class*{color});}}
was:
When creating a WebArchive via ShrinkWrap from a directory that is an exploded war file, paths inside this archive (generated with "arquillian.xml/arquillian/engine/property[deploymentExportPath]->target/deployments") generated invalid in some cases.
When investigating the sources I found "org.jboss.shrinkwrap.impl.base.importer.ExplodedImporterImpl.calculatePath(File root, File child)" uses "String.replaceFirst" to replace the occurance of rootPath in childPath to create a local war file path. My path of the directory that needs compression contains *brackets*, which (as well as other path elements, e.g. ".") are interpreted as regular expression tokens and therefore don't match.
The resulting archive can not be delpoyed in AS and tests can not be performed automatically.
> Paths in webarchives are not calculated correctly
> -------------------------------------------------
>
> Key: SHRINKWRAP-453
> URL: https://issues.jboss.org/browse/SHRINKWRAP-453
> Project: ShrinkWrap
> Issue Type: Bug
> Components: api
> Affects Versions: 1.1.2
> Environment: Win7x64, JDK1.7.0_17x32, JBOSS 7.1.3.Final, Arquillian 1.0.3Final, JUnit 4.11
> Reporter: Stefan Hösel
>
> When creating a WebArchive via ShrinkWrap from a directory that is an exploded war file, paths inside this archive (generated with "arquillian.xml/arquillian/engine/property[deploymentExportPath]->target/deployments") generated invalid in some cases.
> When investigating the sources I found "org.jboss.shrinkwrap.impl.base.importer.ExplodedImporterImpl.calculatePath(File root, File child)" uses "String.replaceFirst" to replace the occurance of rootPath in childPath to create a local war file path. My path of the directory that needs compression contains *brackets*, which (as well as other path elements, e.g. ".") are interpreted as regular expression tokens and therefore don't match.
> The resulting archive can not be delpoyed in AS and tests can not be performed automatically.
> The code to create the WebArchive looks like this:
> {{ShrinkWrap._create_(WebArchive.{color:gray}*class*{color}, resultingWarFileNameAsString)}}
> {{.as(ExplodedImporter.{color:gray}*class*{color}).importDirectory(absolutePathToExplodedWarDirectoryAsFile)}}
> {{.as(WebArchive.{color:gray}*class*{color});}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (SHRINKWRAP-453) Paths in webarchives are not calculated correctly
by Stefan Hösel (JIRA)
Stefan Hösel created SHRINKWRAP-453:
---------------------------------------
Summary: Paths in webarchives are not calculated correctly
Key: SHRINKWRAP-453
URL: https://issues.jboss.org/browse/SHRINKWRAP-453
Project: ShrinkWrap
Issue Type: Bug
Components: api
Affects Versions: 1.1.2
Environment: Win7x64, JDK1.7.0_17x32, JBOSS 7.1.3.Final, Arquillian 1.0.3Final, JUnit 4.11
Reporter: Stefan Hösel
When creating a WebArchive via ShrinkWrap from a directory that is an exploded war file, paths inside this archive (generated with "arquillian.xml/arquillian/engine/property[deploymentExportPath]->target/deployments") generated invalid in some cases.
When investigating the sources I found "org.jboss.shrinkwrap.impl.base.importer.ExplodedImporterImpl.calculatePath(File root, File child)" uses "String.replaceFirst" to replace the occurance of rootPath in childPath to create a local war file path. My path of the directory that needs compression contains *brackets*, which (as well as other path elements, e.g. ".") are interpreted as regular expression tokens and therefore don't match.
The resulting archive can not be delpoyed in AS and tests can not be performed automatically.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (SHRINKWRAP-449) TarGzExporter wrong packing of paths with more than 100 characters
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-449?page=com.atlassian.jira.pl... ]
Michal Matloka commented on SHRINKWRAP-449:
-------------------------------------------
http://www.delorie.com/gnu/docs/tar/tar_114.html
{quote}
GNU tar was based on an early draft of the POSIX 1003.1 ustar standard. GNU extensions to tar, such as the support for file names longer than 100 characters, use portions of the tar header record which were specified in that POSIX draft as unused. Subsequent changes in POSIX have allocated the same parts of the header record for other purposes. As a result, *GNU tar is incompatible with the current POSIX spec, and with tar programs that follow it*.
{quote}
> TarGzExporter wrong packing of paths with more than 100 characters
> ------------------------------------------------------------------
>
> Key: SHRINKWRAP-449
> URL: https://issues.jboss.org/browse/SHRINKWRAP-449
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Reporter: Matej Lazar
> Assignee: Michal Matloka
>
> Prefixes of long paths (> 100 chars) are ignored when unpacking archives with tar on linux.
> Packing "moreThan100/long/path/to/file.class" with TarGzExporter, is unpacked by linux tar as "long/path/to/file.class".
> Where "long/path/to/file.class" is just bellow 100 chars.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (SHRINKWRAP-390) Build option for building without Java 5
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-390?page=com.atlassian.jira.pl... ]
Michal Matloka commented on SHRINKWRAP-390:
-------------------------------------------
I vote for Aslak proposition - source and target 1.5 + animal sniffer (which does both signature check and check of usage of only jdk5 classes). Currently IDE detects shrinkwrap as java 7. Allows to use Java 7 features and classes. Invalid features are detected during mvn build by <compilerArguments> (now I think it is deprecated, and because of that IDE allows java 7), and invalid classes are detected during tests run by jdk5 usage.
Now:
{noformat}
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<inherited>true</inherited>
<configuration>
<source>1.7</source>
<target>1.7</target>
<showDeprecation>false</showDeprecation>
<showWarnings>true</showWarnings>
<optimize>true</optimize>
<compilerVersion>1.7</compilerVersion>
<fork>true</fork>
<compilerArguments>
<source>1.5</source>
<target>1.5</target>
</compilerArguments>
</configuration>
</plugin>
{noformat}
> Build option for building without Java 5
> ----------------------------------------
>
> Key: SHRINKWRAP-390
> URL: https://issues.jboss.org/browse/SHRINKWRAP-390
> Project: ShrinkWrap
> Issue Type: Task
> Components: build
> Environment: Fedora 17
> Reporter: Carlo de Wolf
> Assignee: Michal Matloka
>
> Fedora 17 does not have a Java 5 JDK, so it is impossible to get through the enforcer check.
> "JAVA5_HOME needs to be set to run some tests in the JRE5 runtime"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (SHRINKWRAP-450) Build not working due to lack of JAVA7_HOME environment variable
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-450?page=com.atlassian.jira.pl... ]
Michal Matloka updated SHRINKWRAP-450:
--------------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/73 (was: https://github.com/shrinkwrap/shrinkwrap/pull/70)
> Build not working due to lack of JAVA7_HOME environment variable
> ----------------------------------------------------------------
>
> Key: SHRINKWRAP-450
> URL: https://issues.jboss.org/browse/SHRINKWRAP-450
> Project: ShrinkWrap
> Issue Type: Bug
> Reporter: Chris Lowe
> Assignee: Michal Matloka
> Fix For: 1.1.3
>
>
> Shrinkwrap nio2-api fails to compile, resulting in the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building ShrinkWrap NIO.2 API 1.1.3-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ shrinkwrap-api-nio2 ---
> [INFO] Deleting C:\source\external\shrinkwrap\api-nio2\target
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-java-version) @ shrinkwrap-api-nio2 ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-maven-version) @ shrinkwrap-api-nio2 ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-maven-environment) @ shrinkwrap-api-nio2 ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ shrinkwrap-api-nio2 ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory C:\source\external\shrinkwrap\api-nio2\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ shrinkwrap-api-nio2 ---
> [INFO] Compiling 4 source files to C:\source\external\shrinkwrap\api-nio2\target\classes
> [INFO] -------------------------------------------------------------
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] Failure executing javac, but could not parse the error:
> The system cannot find the path specified.
> After some digging into this, it turned out this error was down to a missing environment variable JAVA7_HOME. This is not obvious from the error message.
> Currently in the shrinkwrap parent pom.xml there is a check for the JAVA5_HOME. Could an additional check be added at the same point for JAVA7_HOME?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month