[JBoss JIRA] (SHRINKRES-93) Tests fails under windows and RHEL 6
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-93?page=com.atlassian.jira.plug... ]
Michal Matloka commented on SHRINKRES-93:
-----------------------------------------
win7 jdk7 fails, win7 jdk6 works, no profiles enabled
> Tests fails under windows and RHEL 6
> ------------------------------------
>
> Key: SHRINKRES-93
> URL: https://issues.jboss.org/browse/SHRINKRES-93
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-5
> Environment: win7 x64
> RHEL 6
> Reporter: Michal Matloka
> Assignee: Andrew Rubinger
>
> I've tried to build today resolvers from both linux and windows.
>
> On Linux build successfully! On Eclipse on windows all tests passes! but, when building on windows from maven (cmd/cygwin) some tests fails.
> {noformat}
> Tests in error:
> shouldBeAbleToLoadArtifactDirectlyFromClassPath(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase): Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> shouldFailWhileNotReadingReactor(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase): Unexpected exception, expected<org.jboss.shrinkwrap.resolver.api.NoResolvedResultException> but was<org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException>
> shouldHaveCentralMavenRepositoryDisabled(org.jboss.shrinkwrap.resolver.impl.maven.integration.DisabledCentralRepositoryTestCase): Unexpected exception, expected<org.jboss.shrinkwrap.resolver.api.NoResolvedResultException> but was<org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException>
> control(org.jboss.shrinkwrap.resolver.impl.maven.integration.DisabledCentralRepositoryTestCase): Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> offlineProgramatically(org.jboss.shrinkwrap.resolver.impl.maven.integration.OfflineRepositoryTestCase): Unable to collect dependency tree for given dependencies, reason: Failed to collect dependencies for [junit:junit:jar:3.8.2 (compile)]
> {noformat}
> e.g.
> {noformat}
> shouldBeAbleToLoadArtifactDirectlyFromClassPath(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase) Time elapsed: 0.696 sec <<< ERROR!
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> 1/ [FATAL] Non-resolvable parent POM for org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-parent:2.0.0-alpha-6-SNAPSHOT: Failed to resolve POM for org.jboss:jboss-parent:8 due to Could not find artifact org.jboss:jboss-parent:pom:8 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-parent:2.0.0-alpha-6-SNAPSHOT, I:\Dev\JBoss\shrinkwrap resolver\pom.xml
> {noformat}
--
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, 5 months
[JBoss JIRA] (SHRINKRES-93) Tests fails under windows and RHEL 6
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-93?page=com.atlassian.jira.plug... ]
Michal Matloka edited comment on SHRINKRES-93 at 12/13/12 7:20 AM:
-------------------------------------------------------------------
win7 jdk7 fails, win7 jdk6 works, ubuntu jdk7 works, no profiles enabled
was (Author: mmatloka):
win7 jdk7 fails, win7 jdk6 works, no profiles enabled
> Tests fails under windows and RHEL 6
> ------------------------------------
>
> Key: SHRINKRES-93
> URL: https://issues.jboss.org/browse/SHRINKRES-93
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-5
> Environment: win7 x64
> RHEL 6
> Reporter: Michal Matloka
> Assignee: Andrew Rubinger
>
> I've tried to build today resolvers from both linux and windows.
>
> On Linux build successfully! On Eclipse on windows all tests passes! but, when building on windows from maven (cmd/cygwin) some tests fails.
> {noformat}
> Tests in error:
> shouldBeAbleToLoadArtifactDirectlyFromClassPath(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase): Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> shouldFailWhileNotReadingReactor(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase): Unexpected exception, expected<org.jboss.shrinkwrap.resolver.api.NoResolvedResultException> but was<org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException>
> shouldHaveCentralMavenRepositoryDisabled(org.jboss.shrinkwrap.resolver.impl.maven.integration.DisabledCentralRepositoryTestCase): Unexpected exception, expected<org.jboss.shrinkwrap.resolver.api.NoResolvedResultException> but was<org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException>
> control(org.jboss.shrinkwrap.resolver.impl.maven.integration.DisabledCentralRepositoryTestCase): Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> offlineProgramatically(org.jboss.shrinkwrap.resolver.impl.maven.integration.OfflineRepositoryTestCase): Unable to collect dependency tree for given dependencies, reason: Failed to collect dependencies for [junit:junit:jar:3.8.2 (compile)]
> {noformat}
> e.g.
> {noformat}
> shouldBeAbleToLoadArtifactDirectlyFromClassPath(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase) Time elapsed: 0.696 sec <<< ERROR!
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> 1/ [FATAL] Non-resolvable parent POM for org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-parent:2.0.0-alpha-6-SNAPSHOT: Failed to resolve POM for org.jboss:jboss-parent:8 due to Could not find artifact org.jboss:jboss-parent:pom:8 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-parent:2.0.0-alpha-6-SNAPSHOT, I:\Dev\JBoss\shrinkwrap resolver\pom.xml
> {noformat}
--
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, 5 months
[JBoss JIRA] (SHRINKRES-94) Shrinkwrap creates zip files respecting the FileSystem delimiter when resolving dependencies as files
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-94?page=com.atlassian.jira.plug... ]
Karel Piwko reassigned SHRINKRES-94:
------------------------------------
Assignee: Karel Piwko (was: Andrew Rubinger)
> Shrinkwrap creates zip files respecting the FileSystem delimiter when resolving dependencies as files
> -----------------------------------------------------------------------------------------------------
>
> Key: SHRINKRES-94
> URL: https://issues.jboss.org/browse/SHRINKRES-94
> Project: ShrinkWrap Resolvers
> Issue Type: Feature Request
> Affects Versions: 2.0.0-alpha-5
> Environment: Windows 7, mvn 3.0.4 and eclipse indigo
> Reporter: José Freitas
> Assignee: Karel Piwko
>
> Shrinkwrap-maven-resolver does a zip file manually when resolving a dependency as a file, and it respect the FS delimiter.
> When the user is on a windows machine and probably gets both \ and / delimeters at the project, the classpath gets wrong and thus the generated file does not work.
> https://github.com/kpiwko/resolver/blob/master/impl-maven/src/main/java/o...
> above you can see the conversation where we found the bug:
> <jose_freitas> kpiwko, I'm using shinrkwrap maven resolver 2.0.0-alpha-1
> <jose_freitas> and I noticed that when it's resolving a workspace dependency
> <jose_freitas> for some reason the generated jar doesn't work as expected
> <jose_freitas> what are you using to generate the archive in the workspace?
> <jose_freitas> when running the test outside eclipse, it works. Inside it, the deployed jar have some weird behaviours
> <jose_freitas> like CNF when class is there, and recently I had a problem when JSFAnnotationProccess run through the assembled class
> <kpiwko> jose_freitas: hello
> <jose_freitas> hello
> <jose_freitas> :)
> <kpiwko> jose_freitas: so your jar depends on other module of a project?
> <jose_freitas> yeah, the @deployment archive is resolving a dependency that's on my workspace
> <kpiwko> shrinkwrap has nothing in common with [x] resolve dependencies from workspace
> <kpiwko> it uses classpath
> <kpiwko> I have no idea how it works in case of eclipse
> <jose_freitas> hm...
> <kpiwko> is it possible that you have your workspace dependency in a local maven repository with a same version but different content?
> <jose_freitas> nope
> <kpiwko> let me guess another try
> <kpiwko> if it works on cli, but not in ide
> <jose_freitas> so the maven-resolver is resolving the snapshot by itself?
> <kpiwko> yes
> <jose_freitas> what's very weird, that apparently, the jar is ok
> <jose_freitas> all the classes are there
> <kpiwko> well, if a snapshot is another module, it goes through classpath trying to find out a pom.xml file and use it
> <kpiwko> in that case, what happens if you disable autocompiling feature?
> <kpiwko> (it works by importing from filesystem and maybe ide accessed the same files during packaging)
> <jose_freitas> I was thinking about the compilation problem, and I was wondering that when publishing to jboss through jbosstools, the jar generation works
> <jose_freitas> I changed the IDE mvn version to the same I use at cli
> <jose_freitas> still, when it generates the jar it's broken
> <jose_freitas> https://dl.dropbox.com/u/3092390/notworking.war
> <jose_freitas> https://dl.dropbox.com/u/3092390/working.war
> <jose_freitas> try it yourself
> <jose_freitas> they are basically the same
> <jose_freitas> with the same files
> <jose_freitas> there are some little differences in size though
> <kpiwko> my jardiff tool says that there's a different z???-faces in there
> <jose_freitas> yes
> <jose_freitas> the z???-faces was generated through maven-resolver
> <jose_freitas> to create the test
> <kpiwko> let me check how z??? faces differ themselves
> <jose_freitas> .addAsLibraries(
> <jose_freitas> DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("pom.xml")
> <jose_freitas> .artifact("br.com.????.pd.z???:z???-faces")
> <jose_freitas> .resolveAsFiles())
> <jose_freitas> notworking.war was generated in IDE
> <jose_freitas> working.war in CLI
> <jose_freitas> the same test
> <kpiwko> damn, my tool is not working
> <kpiwko> it complains jar is using backslashes instead of slashes
> <kpiwko> give me a few secs
> <jose_freitas> yeap
> <jose_freitas> I didn't find why there's a difference though
> <kpiwko> so if you unzip the jar a package it with jar tool, it works?
> <kpiwko> do you have code snippet that generates jar handy?
> <jose_freitas> manually, you mena?
> <jose_freitas> mean*
> <kpiwko> yes
> <jose_freitas> no, but I can generate it through jdk
> <jose_freitas> lemme try
> <kpiwko> jose_freitas: I think this will happen in newer versions as well
> <jose_freitas> kpiwko, I made two tests
> <kpiwko> in alpha-6, there is PackageDirHelper
> <kpiwko> which transform a directory into a jar
> <jose_freitas> hmm
> <kpiwko> a which respects filesystem path delimiter
> <jose_freitas> but then I would need to resolve its dependencies as well
> <kpiwko> which is wrong for jar
> <kpiwko> I have to check where is the impl in alpha-1
> <jose_freitas> ok
> <jose_freitas> I made two tests with it
> <jose_freitas> 1) generated a jar from "eclipse -> export "
> <jose_freitas> and the generated jar worked
> <jose_freitas> 2) I unzipped the jar and then created a new one with extracted folder "jar cvf zf.jar foldername"
> <jose_freitas> it didn't work
> <jose_freitas> and it had a similar error
> <jose_freitas> for some reason, I think that the problem is the generated classes
> <jose_freitas> not the archive
> <jose_freitas> gut feeling
> <kpiwko> jose_freitas: I think that in alpha-1, the problem lies here ./impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/util/IOUtil.java
> <kpiwko> jose_freitas: we do a zip file manually, but we respect fs delimiter
> <jose_freitas> hm...
> <kpiwko> as you get both \ and / delimeters in your project, the classpath is wrong and thus the war does not wrong
> <kpiwko> *work
> <kpiwko> (my suggestion)
> <kpiwko> your test case 2) actually confirms my suggestion
> <kpiwko> eclipse exporter correctly ignores \ and simply puts /, as recommended in java
> <kpiwko> we can easily fix that in ShrinkWrap
> <jose_freitas> that would be nice
> <kpiwko> can you file a bug here at issues.jboss.org/browse/SHRINKRES and preferably paste our conversation? I think we can get it into next release
> <jose_freitas> thanks
--
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, 5 months
[JBoss JIRA] (SHRINKRES-94) Shrinkwrap creates zip files respecting the FileSystem delimiter when resolving dependencies as files
by José Freitas (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-94?page=com.atlassian.jira.plug... ]
José Freitas updated SHRINKRES-94:
----------------------------------
Description:
Shrinkwrap-maven-resolver does a zip file manually when resolving a dependency as a file, and it respect the FS delimiter.
When the user is on a windows machine and probably gets both \ and / delimeters at the project, the classpath gets wrong and thus the generated file does not work.
https://github.com/kpiwko/resolver/blob/master/impl-maven/src/main/java/o...
above you can see the conversation where we found the bug:
<jose_freitas> kpiwko, I'm using shinrkwrap maven resolver 2.0.0-alpha-1
<jose_freitas> and I noticed that when it's resolving a workspace dependency
<jose_freitas> for some reason the generated jar doesn't work as expected
<jose_freitas> what are you using to generate the archive in the workspace?
<jose_freitas> when running the test outside eclipse, it works. Inside it, the deployed jar have some weird behaviours
<jose_freitas> like CNF when class is there, and recently I had a problem when JSFAnnotationProccess run through the assembled class
<kpiwko> jose_freitas: hello
<jose_freitas> hello
<jose_freitas> :)
<kpiwko> jose_freitas: so your jar depends on other module of a project?
<jose_freitas> yeah, the @deployment archive is resolving a dependency that's on my workspace
<kpiwko> shrinkwrap has nothing in common with [x] resolve dependencies from workspace
<kpiwko> it uses classpath
<kpiwko> I have no idea how it works in case of eclipse
<jose_freitas> hm...
<kpiwko> is it possible that you have your workspace dependency in a local maven repository with a same version but different content?
<jose_freitas> nope
<kpiwko> let me guess another try
<kpiwko> if it works on cli, but not in ide
<jose_freitas> so the maven-resolver is resolving the snapshot by itself?
<kpiwko> yes
<jose_freitas> what's very weird, that apparently, the jar is ok
<jose_freitas> all the classes are there
<kpiwko> well, if a snapshot is another module, it goes through classpath trying to find out a pom.xml file and use it
<kpiwko> in that case, what happens if you disable autocompiling feature?
<kpiwko> (it works by importing from filesystem and maybe ide accessed the same files during packaging)
<jose_freitas> I was thinking about the compilation problem, and I was wondering that when publishing to jboss through jbosstools, the jar generation works
<jose_freitas> I changed the IDE mvn version to the same I use at cli
<jose_freitas> still, when it generates the jar it's broken
<jose_freitas> https://dl.dropbox.com/u/3092390/notworking.war
<jose_freitas> https://dl.dropbox.com/u/3092390/working.war
<jose_freitas> try it yourself
<jose_freitas> they are basically the same
<jose_freitas> with the same files
<jose_freitas> there are some little differences in size though
<kpiwko> my jardiff tool says that there's a different z???-faces in there
<jose_freitas> yes
<jose_freitas> the z???-faces was generated through maven-resolver
<jose_freitas> to create the test
<kpiwko> let me check how z??? faces differ themselves
<jose_freitas> .addAsLibraries(
<jose_freitas> DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("pom.xml")
<jose_freitas> .artifact("br.com.????.pd.z???:z???-faces")
<jose_freitas> .resolveAsFiles())
<jose_freitas> notworking.war was generated in IDE
<jose_freitas> working.war in CLI
<jose_freitas> the same test
<kpiwko> damn, my tool is not working
<kpiwko> it complains jar is using backslashes instead of slashes
<kpiwko> give me a few secs
<jose_freitas> yeap
<jose_freitas> I didn't find why there's a difference though
<kpiwko> so if you unzip the jar a package it with jar tool, it works?
<kpiwko> do you have code snippet that generates jar handy?
<jose_freitas> manually, you mena?
<jose_freitas> mean*
<kpiwko> yes
<jose_freitas> no, but I can generate it through jdk
<jose_freitas> lemme try
<kpiwko> jose_freitas: I think this will happen in newer versions as well
<jose_freitas> kpiwko, I made two tests
<kpiwko> in alpha-6, there is PackageDirHelper
<kpiwko> which transform a directory into a jar
<jose_freitas> hmm
<kpiwko> a which respects filesystem path delimiter
<jose_freitas> but then I would need to resolve its dependencies as well
<kpiwko> which is wrong for jar
<kpiwko> I have to check where is the impl in alpha-1
<jose_freitas> ok
<jose_freitas> I made two tests with it
<jose_freitas> 1) generated a jar from "eclipse -> export "
<jose_freitas> and the generated jar worked
<jose_freitas> 2) I unzipped the jar and then created a new one with extracted folder "jar cvf zf.jar foldername"
<jose_freitas> it didn't work
<jose_freitas> and it had a similar error
<jose_freitas> for some reason, I think that the problem is the generated classes
<jose_freitas> not the archive
<jose_freitas> gut feeling
<kpiwko> jose_freitas: I think that in alpha-1, the problem lies here ./impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/util/IOUtil.java
<kpiwko> jose_freitas: we do a zip file manually, but we respect fs delimiter
<jose_freitas> hm...
<kpiwko> as you get both \ and / delimeters in your project, the classpath is wrong and thus the war does not wrong
<kpiwko> *work
<kpiwko> (my suggestion)
<kpiwko> your test case 2) actually confirms my suggestion
<kpiwko> eclipse exporter correctly ignores \ and simply puts /, as recommended in java
<kpiwko> we can easily fix that in ShrinkWrap
<jose_freitas> that would be nice
<kpiwko> can you file a bug here at issues.jboss.org/browse/SHRINKRES and preferably paste our conversation? I think we can get it into next release
<jose_freitas> thanks
was:
Shrinkwrap-maven-resolver does a zip file manually when resolving a dependency as a file, and it respect the FS delimiter.
When the user is on a windows machine and probably gets both \ and / delimeters at the project, the classpath gets wrong and thus the generated file does not work.
https://github.com/kpiwko/resolver/blob/master/impl-maven/src/main/java/o...
above you can see the conversation where we found the bug:
<jose_freitas> kpiwko, I'm using shinrkwrap maven resolver 2.0.0-alpha-1
<jose_freitas> and I noticed that when it's resolving a workspace dependency
<jose_freitas> for some reason the generated jar doesn't work as expected
<jose_freitas> what are you using to generate the archive in the workspace?
<jose_freitas> when running the test outside eclipse, it works. Inside it, the deployed jar have some weird behaviours
<jose_freitas> like CNF when class is there, and recently I had a problem when JSFAnnotationProccess run through the assembled class
<kpiwko> jose_freitas: hello
<jose_freitas> hello
<jose_freitas> :)
<kpiwko> jose_freitas: so your jar depends on other module of a project?
<jose_freitas> yeah, the @deployment archive is resolving a dependency that's on my workspace
<kpiwko> shrinkwrap has nothing in common with [x] resolve dependencies from workspace
<kpiwko> it uses classpath
<kpiwko> I have no idea how it works in case of eclipse
<jose_freitas> hm...
<kpiwko> is it possible that you have your workspace dependency in a local maven repository with a same version but different content?
<jose_freitas> nope
<kpiwko> let me guess another try
<kpiwko> if it works on cli, but not in ide
<jose_freitas> so the maven-resolver is resolving the snapshot by itself?
<kpiwko> yes
<jose_freitas> what's very weird, that apparently, the jar is ok
<jose_freitas> all the classes are there
<kpiwko> well, if a snapshot is another module, it goes through classpath trying to find out a pom.xml file and use it
<kpiwko> in that case, what happens if you disable autocompiling feature?
<kpiwko> (it works by importing from filesystem and maybe ide accessed the same files during packaging)
<jose_freitas> I was thinking about the compilation problem, and I was wondering that when publishing to jboss through jbosstools, the jar generation works
<jose_freitas> I changed the IDE mvn version to the same I use at cli
<jose_freitas> still, when it generates the jar it's broken
<jose_freitas> https://dl.dropbox.com/u/3092390/notworking.war
<jose_freitas> https://dl.dropbox.com/u/3092390/working.war
<jose_freitas> try it yourself
<jose_freitas> they are basically the same
<jose_freitas> with the same files
<jose_freitas> there are some little differences in size though
<kpiwko> my jardiff tool says that there's a different z???-faces in there
<jose_freitas> yes
<jose_freitas> the z???-faces was generated through maven-resolver
<jose_freitas> to create the test
<kpiwko> let me check how zion faces differ themselves
<jose_freitas> .addAsLibraries(
<jose_freitas> DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("pom.xml")
<jose_freitas> .artifact("br.com.????.pd.z???:z???-faces")
<jose_freitas> .resolveAsFiles())
<jose_freitas> notworking.war was generated in IDE
<jose_freitas> working.war in CLI
<jose_freitas> the same test
<kpiwko> damn, my tool is not working
<kpiwko> it complains jar is using backslashes instead of slashes
<kpiwko> give me a few secs
<jose_freitas> yeap
<jose_freitas> I didn't find why there's a difference though
<kpiwko> so if you unzip the jar a package it with jar tool, it works?
<kpiwko> do you have code snippet that generates jar handy?
<jose_freitas> manually, you mena?
<jose_freitas> mean*
<kpiwko> yes
<jose_freitas> no, but I can generate it through jdk
<jose_freitas> lemme try
<kpiwko> jose_freitas: I think this will happen in newer versions as well
<jose_freitas> kpiwko, I made two tests
<kpiwko> in alpha-6, there is PackageDirHelper
<kpiwko> which transform a directory into a jar
<jose_freitas> hmm
<kpiwko> a which respects filesystem path delimiter
<jose_freitas> but then I would need to resolve its dependencies as well
<kpiwko> which is wrong for jar
<kpiwko> I have to check where is the impl in alpha-1
<jose_freitas> ok
<jose_freitas> I made two tests with it
<jose_freitas> 1) generated a jar from "eclipse -> export "
<jose_freitas> and the generated jar worked
<jose_freitas> 2) I unzipped the jar and then created a new one with extracted folder "jar cvf zf.jar foldername"
<jose_freitas> it didn't work
<jose_freitas> and it had a similar error
<jose_freitas> for some reason, I think that the problem is the generated classes
<jose_freitas> not the archive
<jose_freitas> gut feeling
<kpiwko> jose_freitas: I think that in alpha-1, the problem lies here ./impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/util/IOUtil.java
<kpiwko> jose_freitas: we do a zip file manually, but we respect fs delimiter
<jose_freitas> hm...
<kpiwko> as you get both \ and / delimeters in your project, the classpath is wrong and thus the war does not wrong
<kpiwko> *work
<kpiwko> (my suggestion)
<kpiwko> your test case 2) actually confirms my suggestion
<kpiwko> eclipse exporter correctly ignores \ and simply puts /, as recommended in java
<kpiwko> we can easily fix that in ShrinkWrap
<jose_freitas> that would be nice
<kpiwko> can you file a bug here at issues.jboss.org/browse/SHRINKRES and preferably paste our conversation? I think we can get it into next release
<jose_freitas> thanks
> Shrinkwrap creates zip files respecting the FileSystem delimiter when resolving dependencies as files
> -----------------------------------------------------------------------------------------------------
>
> Key: SHRINKRES-94
> URL: https://issues.jboss.org/browse/SHRINKRES-94
> Project: ShrinkWrap Resolvers
> Issue Type: Feature Request
> Affects Versions: 2.0.0-alpha-5
> Environment: Windows 7, mvn 3.0.4 and eclipse indigo
> Reporter: José Freitas
> Assignee: Andrew Rubinger
>
> Shrinkwrap-maven-resolver does a zip file manually when resolving a dependency as a file, and it respect the FS delimiter.
> When the user is on a windows machine and probably gets both \ and / delimeters at the project, the classpath gets wrong and thus the generated file does not work.
> https://github.com/kpiwko/resolver/blob/master/impl-maven/src/main/java/o...
> above you can see the conversation where we found the bug:
> <jose_freitas> kpiwko, I'm using shinrkwrap maven resolver 2.0.0-alpha-1
> <jose_freitas> and I noticed that when it's resolving a workspace dependency
> <jose_freitas> for some reason the generated jar doesn't work as expected
> <jose_freitas> what are you using to generate the archive in the workspace?
> <jose_freitas> when running the test outside eclipse, it works. Inside it, the deployed jar have some weird behaviours
> <jose_freitas> like CNF when class is there, and recently I had a problem when JSFAnnotationProccess run through the assembled class
> <kpiwko> jose_freitas: hello
> <jose_freitas> hello
> <jose_freitas> :)
> <kpiwko> jose_freitas: so your jar depends on other module of a project?
> <jose_freitas> yeah, the @deployment archive is resolving a dependency that's on my workspace
> <kpiwko> shrinkwrap has nothing in common with [x] resolve dependencies from workspace
> <kpiwko> it uses classpath
> <kpiwko> I have no idea how it works in case of eclipse
> <jose_freitas> hm...
> <kpiwko> is it possible that you have your workspace dependency in a local maven repository with a same version but different content?
> <jose_freitas> nope
> <kpiwko> let me guess another try
> <kpiwko> if it works on cli, but not in ide
> <jose_freitas> so the maven-resolver is resolving the snapshot by itself?
> <kpiwko> yes
> <jose_freitas> what's very weird, that apparently, the jar is ok
> <jose_freitas> all the classes are there
> <kpiwko> well, if a snapshot is another module, it goes through classpath trying to find out a pom.xml file and use it
> <kpiwko> in that case, what happens if you disable autocompiling feature?
> <kpiwko> (it works by importing from filesystem and maybe ide accessed the same files during packaging)
> <jose_freitas> I was thinking about the compilation problem, and I was wondering that when publishing to jboss through jbosstools, the jar generation works
> <jose_freitas> I changed the IDE mvn version to the same I use at cli
> <jose_freitas> still, when it generates the jar it's broken
> <jose_freitas> https://dl.dropbox.com/u/3092390/notworking.war
> <jose_freitas> https://dl.dropbox.com/u/3092390/working.war
> <jose_freitas> try it yourself
> <jose_freitas> they are basically the same
> <jose_freitas> with the same files
> <jose_freitas> there are some little differences in size though
> <kpiwko> my jardiff tool says that there's a different z???-faces in there
> <jose_freitas> yes
> <jose_freitas> the z???-faces was generated through maven-resolver
> <jose_freitas> to create the test
> <kpiwko> let me check how z??? faces differ themselves
> <jose_freitas> .addAsLibraries(
> <jose_freitas> DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("pom.xml")
> <jose_freitas> .artifact("br.com.????.pd.z???:z???-faces")
> <jose_freitas> .resolveAsFiles())
> <jose_freitas> notworking.war was generated in IDE
> <jose_freitas> working.war in CLI
> <jose_freitas> the same test
> <kpiwko> damn, my tool is not working
> <kpiwko> it complains jar is using backslashes instead of slashes
> <kpiwko> give me a few secs
> <jose_freitas> yeap
> <jose_freitas> I didn't find why there's a difference though
> <kpiwko> so if you unzip the jar a package it with jar tool, it works?
> <kpiwko> do you have code snippet that generates jar handy?
> <jose_freitas> manually, you mena?
> <jose_freitas> mean*
> <kpiwko> yes
> <jose_freitas> no, but I can generate it through jdk
> <jose_freitas> lemme try
> <kpiwko> jose_freitas: I think this will happen in newer versions as well
> <jose_freitas> kpiwko, I made two tests
> <kpiwko> in alpha-6, there is PackageDirHelper
> <kpiwko> which transform a directory into a jar
> <jose_freitas> hmm
> <kpiwko> a which respects filesystem path delimiter
> <jose_freitas> but then I would need to resolve its dependencies as well
> <kpiwko> which is wrong for jar
> <kpiwko> I have to check where is the impl in alpha-1
> <jose_freitas> ok
> <jose_freitas> I made two tests with it
> <jose_freitas> 1) generated a jar from "eclipse -> export "
> <jose_freitas> and the generated jar worked
> <jose_freitas> 2) I unzipped the jar and then created a new one with extracted folder "jar cvf zf.jar foldername"
> <jose_freitas> it didn't work
> <jose_freitas> and it had a similar error
> <jose_freitas> for some reason, I think that the problem is the generated classes
> <jose_freitas> not the archive
> <jose_freitas> gut feeling
> <kpiwko> jose_freitas: I think that in alpha-1, the problem lies here ./impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/util/IOUtil.java
> <kpiwko> jose_freitas: we do a zip file manually, but we respect fs delimiter
> <jose_freitas> hm...
> <kpiwko> as you get both \ and / delimeters in your project, the classpath is wrong and thus the war does not wrong
> <kpiwko> *work
> <kpiwko> (my suggestion)
> <kpiwko> your test case 2) actually confirms my suggestion
> <kpiwko> eclipse exporter correctly ignores \ and simply puts /, as recommended in java
> <kpiwko> we can easily fix that in ShrinkWrap
> <jose_freitas> that would be nice
> <kpiwko> can you file a bug here at issues.jboss.org/browse/SHRINKRES and preferably paste our conversation? I think we can get it into next release
> <jose_freitas> thanks
--
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, 5 months
[JBoss JIRA] (SHRINKRES-94) Shrinkwrap creates zip files respecting the FileSystem delimiter when resolving dependencies as files
by José Freitas (JIRA)
José Freitas created SHRINKRES-94:
-------------------------------------
Summary: Shrinkwrap creates zip files respecting the FileSystem delimiter when resolving dependencies as files
Key: SHRINKRES-94
URL: https://issues.jboss.org/browse/SHRINKRES-94
Project: ShrinkWrap Resolvers
Issue Type: Feature Request
Affects Versions: 2.0.0-alpha-5
Environment: Windows 7, mvn 3.0.4 and eclipse indigo
Reporter: José Freitas
Assignee: Andrew Rubinger
Shrinkwrap-maven-resolver does a zip file manually when resolving a dependency as a file, and it respect the FS delimiter.
When the user is on a windows machine and probably gets both \ and / delimeters at the project, the classpath gets wrong and thus the generated file does not work.
https://github.com/kpiwko/resolver/blob/master/impl-maven/src/main/java/o...
above you can see the conversation where we found the bug:
<jose_freitas> kpiwko, I'm using shinrkwrap maven resolver 2.0.0-alpha-1
<jose_freitas> and I noticed that when it's resolving a workspace dependency
<jose_freitas> for some reason the generated jar doesn't work as expected
<jose_freitas> what are you using to generate the archive in the workspace?
<jose_freitas> when running the test outside eclipse, it works. Inside it, the deployed jar have some weird behaviours
<jose_freitas> like CNF when class is there, and recently I had a problem when JSFAnnotationProccess run through the assembled class
<kpiwko> jose_freitas: hello
<jose_freitas> hello
<jose_freitas> :)
<kpiwko> jose_freitas: so your jar depends on other module of a project?
<jose_freitas> yeah, the @deployment archive is resolving a dependency that's on my workspace
<kpiwko> shrinkwrap has nothing in common with [x] resolve dependencies from workspace
<kpiwko> it uses classpath
<kpiwko> I have no idea how it works in case of eclipse
<jose_freitas> hm...
<kpiwko> is it possible that you have your workspace dependency in a local maven repository with a same version but different content?
<jose_freitas> nope
<kpiwko> let me guess another try
<kpiwko> if it works on cli, but not in ide
<jose_freitas> so the maven-resolver is resolving the snapshot by itself?
<kpiwko> yes
<jose_freitas> what's very weird, that apparently, the jar is ok
<jose_freitas> all the classes are there
<kpiwko> well, if a snapshot is another module, it goes through classpath trying to find out a pom.xml file and use it
<kpiwko> in that case, what happens if you disable autocompiling feature?
<kpiwko> (it works by importing from filesystem and maybe ide accessed the same files during packaging)
<jose_freitas> I was thinking about the compilation problem, and I was wondering that when publishing to jboss through jbosstools, the jar generation works
<jose_freitas> I changed the IDE mvn version to the same I use at cli
<jose_freitas> still, when it generates the jar it's broken
<jose_freitas> https://dl.dropbox.com/u/3092390/notworking.war
<jose_freitas> https://dl.dropbox.com/u/3092390/working.war
<jose_freitas> try it yourself
<jose_freitas> they are basically the same
<jose_freitas> with the same files
<jose_freitas> there are some little differences in size though
<kpiwko> my jardiff tool says that there's a different z???-faces in there
<jose_freitas> yes
<jose_freitas> the z???-faces was generated through maven-resolver
<jose_freitas> to create the test
<kpiwko> let me check how zion faces differ themselves
<jose_freitas> .addAsLibraries(
<jose_freitas> DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("pom.xml")
<jose_freitas> .artifact("br.com.????.pd.z???:z???-faces")
<jose_freitas> .resolveAsFiles())
<jose_freitas> notworking.war was generated in IDE
<jose_freitas> working.war in CLI
<jose_freitas> the same test
<kpiwko> damn, my tool is not working
<kpiwko> it complains jar is using backslashes instead of slashes
<kpiwko> give me a few secs
<jose_freitas> yeap
<jose_freitas> I didn't find why there's a difference though
<kpiwko> so if you unzip the jar a package it with jar tool, it works?
<kpiwko> do you have code snippet that generates jar handy?
<jose_freitas> manually, you mena?
<jose_freitas> mean*
<kpiwko> yes
<jose_freitas> no, but I can generate it through jdk
<jose_freitas> lemme try
<kpiwko> jose_freitas: I think this will happen in newer versions as well
<jose_freitas> kpiwko, I made two tests
<kpiwko> in alpha-6, there is PackageDirHelper
<kpiwko> which transform a directory into a jar
<jose_freitas> hmm
<kpiwko> a which respects filesystem path delimiter
<jose_freitas> but then I would need to resolve its dependencies as well
<kpiwko> which is wrong for jar
<kpiwko> I have to check where is the impl in alpha-1
<jose_freitas> ok
<jose_freitas> I made two tests with it
<jose_freitas> 1) generated a jar from "eclipse -> export "
<jose_freitas> and the generated jar worked
<jose_freitas> 2) I unzipped the jar and then created a new one with extracted folder "jar cvf zf.jar foldername"
<jose_freitas> it didn't work
<jose_freitas> and it had a similar error
<jose_freitas> for some reason, I think that the problem is the generated classes
<jose_freitas> not the archive
<jose_freitas> gut feeling
<kpiwko> jose_freitas: I think that in alpha-1, the problem lies here ./impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/util/IOUtil.java
<kpiwko> jose_freitas: we do a zip file manually, but we respect fs delimiter
<jose_freitas> hm...
<kpiwko> as you get both \ and / delimeters in your project, the classpath is wrong and thus the war does not wrong
<kpiwko> *work
<kpiwko> (my suggestion)
<kpiwko> your test case 2) actually confirms my suggestion
<kpiwko> eclipse exporter correctly ignores \ and simply puts /, as recommended in java
<kpiwko> we can easily fix that in ShrinkWrap
<jose_freitas> that would be nice
<kpiwko> can you file a bug here at issues.jboss.org/browse/SHRINKRES and preferably paste our conversation? I think we can get it into next release
<jose_freitas> thanks
--
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, 5 months
[JBoss JIRA] (SHRINKRES-81) Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-81?page=com.atlassian.jira.plug... ]
Andrew Rubinger updated SHRINKRES-81:
-------------------------------------
Fix Version/s: (was: 2.0.0-alpha-6)
> Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own
> --------------------------------------------------------------------------------------------
>
> Key: SHRINKRES-81
> URL: https://issues.jboss.org/browse/SHRINKRES-81
> Project: ShrinkWrap Resolvers
> Issue Type: Task
> Components: api-maven, impl-maven
> Reporter: Michal Matloka
> Assignee: Michal Matloka
>
> TODO located in MavenStrategyBaseImpl
> // TODO Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own
> // representation
> and
> MavenWorkingSession
> // TODO We're not really encapsulating much here, as we expose out Aether and Maven classes. Refactor this class and
> // usages to hide all implementation details of Maven and Aether *behind* this SPI facade
> Some of this refactors has to be made for SHRINKRES-27
--
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, 5 months
[JBoss JIRA] (SHRINKRES-18) MavenImporter on war files should support a configuration that supports "skipping the build" in the IDE (and preferably use it by default)
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-18?page=com.atlassian.jira.plug... ]
Andrew Rubinger updated SHRINKRES-18:
-------------------------------------
Fix Version/s: (was: 2.0.0-alpha-6)
> MavenImporter on war files should support a configuration that supports "skipping the build" in the IDE (and preferably use it by default)
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SHRINKRES-18
> URL: https://issues.jboss.org/browse/SHRINKRES-18
> Project: ShrinkWrap Resolvers
> Issue Type: Enhancement
> Affects Versions: 2.0.0-alpha-1
> Reporter: Geoffrey De Smet
> Assignee: Karel Piwko
>
> Currently the MavenImporter on war files requires "mvn package" to be run every time (not only the first time), to update the exploded directory at "target/{finalName}".
> This means if you change something in your code and want to (re)run a test,
> and forget to run "mvn package" first, you're running the old code (and the results are not representative of the changed code).
> Karel and Geoffrey discussed this at JUDCon London.
> The following things can be probably presumed:
> - The IDE compiles all classes from src/main/java to target/classes.
> - The IDE copies all non-filtered resources from src/main/resources to target/classes.
> - That target/classes is copied into the war at WEB-INF/classes.
> - Most src/main/webapp dirs are copied unaltered into the root of the war. (*)
> - "mvn compile" is run once after any "mvn clean": in other words, all src/main/filtered-resources are in target/classes
> So MavenImporter doesn't have to require "mvn package" to build the exploded dir first (which it then zips, enriches and sends to arquillian).
> Instead, it can construct the war zip directly from target/classes and src/main/webapp.
> That is at least one less copy and more importantly, to run the test from the IDE without having to build first.
> Note: all examples above used the explicit directory locations, but in reality the pom.xml's <build> section should be used to determinate the directory locations for a certain project.
--
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, 5 months
[JBoss JIRA] (SHRINKRES-93) Tests fails under windows and RHEL 6
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-93?page=com.atlassian.jira.plug... ]
Andrew Rubinger commented on SHRINKRES-93:
------------------------------------------
Will leave unresolved for the time-being until all parties here confirm we're fixed.
Upstream attempt: https://github.com/shrinkwrap/resolver/commit/4c8e592e7c2532ed2758a67d4fa...
> Tests fails under windows and RHEL 6
> ------------------------------------
>
> Key: SHRINKRES-93
> URL: https://issues.jboss.org/browse/SHRINKRES-93
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-5
> Environment: win7 x64
> RHEL 6
> Reporter: Michal Matloka
> Assignee: Andrew Rubinger
>
> I've tried to build today resolvers from both linux and windows.
>
> On Linux build successfully! On Eclipse on windows all tests passes! but, when building on windows from maven (cmd/cygwin) some tests fails.
> {noformat}
> Tests in error:
> shouldBeAbleToLoadArtifactDirectlyFromClassPath(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase): Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> shouldFailWhileNotReadingReactor(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase): Unexpected exception, expected<org.jboss.shrinkwrap.resolver.api.NoResolvedResultException> but was<org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException>
> shouldHaveCentralMavenRepositoryDisabled(org.jboss.shrinkwrap.resolver.impl.maven.integration.DisabledCentralRepositoryTestCase): Unexpected exception, expected<org.jboss.shrinkwrap.resolver.api.NoResolvedResultException> but was<org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException>
> control(org.jboss.shrinkwrap.resolver.impl.maven.integration.DisabledCentralRepositoryTestCase): Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> offlineProgramatically(org.jboss.shrinkwrap.resolver.impl.maven.integration.OfflineRepositoryTestCase): Unable to collect dependency tree for given dependencies, reason: Failed to collect dependencies for [junit:junit:jar:3.8.2 (compile)]
> {noformat}
> e.g.
> {noformat}
> shouldBeAbleToLoadArtifactDirectlyFromClassPath(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase) Time elapsed: 0.696 sec <<< ERROR!
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> 1/ [FATAL] Non-resolvable parent POM for org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-parent:2.0.0-alpha-6-SNAPSHOT: Failed to resolve POM for org.jboss:jboss-parent:8 due to Could not find artifact org.jboss:jboss-parent:pom:8 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-parent:2.0.0-alpha-6-SNAPSHOT, I:\Dev\JBoss\shrinkwrap resolver\pom.xml
> {noformat}
--
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, 5 months
[JBoss JIRA] (SHRINKRES-93) Tests fails under windows and RHEL 6
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-93?page=com.atlassian.jira.plug... ]
Andrew Rubinger commented on SHRINKRES-93:
------------------------------------------
Working for me under JDK7:
Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
Maven home: /opt/apache/maven/apache-maven-3.0.4
Java version: 1.7.0_09, vendor: Oracle Corporation
Java home: /opt/oracle/java/jdk1.7.0_09/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.6.6-1.fc17.x86_64", arch: "amd64", family: "unix"
> Tests fails under windows and RHEL 6
> ------------------------------------
>
> Key: SHRINKRES-93
> URL: https://issues.jboss.org/browse/SHRINKRES-93
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha-5
> Environment: win7 x64
> RHEL 6
> Reporter: Michal Matloka
> Assignee: Andrew Rubinger
>
> I've tried to build today resolvers from both linux and windows.
>
> On Linux build successfully! On Eclipse on windows all tests passes! but, when building on windows from maven (cmd/cygwin) some tests fails.
> {noformat}
> Tests in error:
> shouldBeAbleToLoadArtifactDirectlyFromClassPath(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase): Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> shouldFailWhileNotReadingReactor(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase): Unexpected exception, expected<org.jboss.shrinkwrap.resolver.api.NoResolvedResultException> but was<org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException>
> shouldHaveCentralMavenRepositoryDisabled(org.jboss.shrinkwrap.resolver.impl.maven.integration.DisabledCentralRepositoryTestCase): Unexpected exception, expected<org.jboss.shrinkwrap.resolver.api.NoResolvedResultException> but was<org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException>
> control(org.jboss.shrinkwrap.resolver.impl.maven.integration.DisabledCentralRepositoryTestCase): Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> offlineProgramatically(org.jboss.shrinkwrap.resolver.impl.maven.integration.OfflineRepositoryTestCase): Unable to collect dependency tree for given dependencies, reason: Failed to collect dependencies for [junit:junit:jar:3.8.2 (compile)]
> {noformat}
> e.g.
> {noformat}
> shouldBeAbleToLoadArtifactDirectlyFromClassPath(org.jboss.shrinkwrap.resolver.impl.maven.integration.ClasspathWorkspaceReaderTestCase) Time elapsed: 0.696 sec <<< ERROR!
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Found 1 problems while building POM model from I:\Dev\JBoss\shrinkwrap resolver\impl-maven\pom.xml
> 1/ [FATAL] Non-resolvable parent POM for org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-parent:2.0.0-alpha-6-SNAPSHOT: Failed to resolve POM for org.jboss:jboss-parent:8 due to Could not find artifact org.jboss:jboss-parent:pom:8 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-parent:2.0.0-alpha-6-SNAPSHOT, I:\Dev\JBoss\shrinkwrap resolver\pom.xml
> {noformat}
--
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, 5 months