Uploaded image for project: 'ShrinkWrap Resolvers'
  1. ShrinkWrap Resolvers

Shrinkwrap creates zip files respecting the FileSystem delimiter when resolving dependencies as files


    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Major Major
    • 2.0.0-alpha-7
    • 2.0.0-alpha-5
    • None
    • None

      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.


      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

      <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

            kpiwko Karel Piwko
            spinner_jira José Freitas (Inactive)
            0 Vote for this issue
            2 Start watching this issue