[ https://issues.jboss.org/browse/SOLDER-301?page=com.atlassian.jira.plugin... ] Geoffrey De Smet updated SOLDER-301: ------------------------------------ Description: I got org.jboss.seam:seam-parent:pom:16 in my local repo. The solder parent pom builds (that one uses the seam-parent pom version 16 too), but when I do a "mvn clean install -DskipTests -Djboss-public-repository", it still complains that the seam-parent pom version 16 does not exist: {code} [INFO] --- maven-shade-plugin:1.4:shade (default) @ solder-logging --- [INFO] Including org.jboss.logging:jboss-logging:jar:3.1.0.Beta3 in the shaded jar. [INFO] Replacing original artifact with shaded artifact. [INFO] Replacing /home/gdesmet/projects/jboss/seam/solder/logging/target/solder-logging.jar with /home/gdesmet/projects/jboss/seam/solder/logging/target/solder-logging-3.1.0-SNAPSHOT-shaded.jar Downloading: http://repo1.maven.org/maven2/org/jboss/seam/seam-parent/16/seam-parent-1... ... [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project solder-logging: Error creating shaded jar: 1 problem was encountered while building the effective model for org.jboss.solder:solder-logging:3.1.0-SNAPSHOT [ERROR] [FATAL] Non-resolvable parent POM for org.jboss.solder:solder-parent:3.1.0-SNAPSHOT: Could not find artifact org.jboss.seam:seam-parent:pom:16 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.jboss.solder:solder-parent:3.1.0-SNAPSHOT, /home/gdesmet/projects/jboss/seam/solder/pom.xml, line 21, column 12 [ERROR] for project org.jboss.solder:solder-logging:3.1.0-SNAPSHOT at /home/gdesmet/projects/jboss/seam/solder/logging/dependency-reduced-pom.xml for project org.jboss.solder:solder-logging:3.1.0-SNAPSHOT at /home/gdesmet/projects/jboss/seam/solder/logging/dependency-reduced-pom.xml {code} was: I got org.jboss.seam:seam-parent:pom:16 in my local repo. The solder parent pom builds (that one uses the seam-parent pom version 16 too), but when I do a "mvn clean install -DskipTests -Djboss-public-repository", it still complains that the seam-parent pom version 16 does not exist: {code} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project solder-logging: Error creating shaded jar: 1 problem was encountered while building the effective model for org.jboss.solder:solder-logging:3.1.0-SNAPSHOT [ERROR] [FATAL] Non-resolvable parent POM for org.jboss.solder:solder-parent:3.1.0-SNAPSHOT: Could not find artifact org.jboss.seam:seam-parent:pom:16 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.jboss.solder:solder-parent:3.1.0-SNAPSHOT, /home/gdesmet/projects/jboss/seam/solder/pom.xml, line 21, column 12 [ERROR] for project org.jboss.solder:solder-logging:3.1.0-SNAPSHOT at /home/gdesmet/projects/jboss/seam/solder/logging/dependency-reduced-pom.xml for project org.jboss.solder:solder-logging:3.1.0-SNAPSHOT at /home/gdesmet/projects/jboss/seam/solder/logging/dependency-reduced-pom.xml {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SOLDER-301?page=com.atlassian.jira.plugin... ] Christian Kaltepoth commented on SOLDER-301: -------------------------------------------- This seems to be related to [MSHADE-103|https://jira.codehaus.org/browse/MSHADE-103]. The pom of the logging module contains a profile for the JBoss repositories that somehow doesn't get activated by default. Resolving the parent pom seems to work if I enable this profile manually. {code} $ mvn -Pjboss-public-repository install {code} The build works fine now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SOLDER-301?page=com.atlassian.jira.plugin... ] Christian Kaltepoth commented on SOLDER-301: -------------------------------------------- I think I can bring some more light into this issue. The shade plugin is configured to create a "dependency reduced pom.xml" which is a copy of the original pom but with all dependencies removed that have been shaded into the JAR. For some reason the "activation" part of the jboss-public-repository profile is missing in this new pom. So activating the profile via properties doesn't work. Even if I add "activeByDefault" it doesn't work as this also gets removed. So currently the only way to build the module is to manually activate the profile like described in my last post. Another possible fix would be to move the repository declaration out of the profile directly to the pom. But this would also include the repositories in the distributed pom which isn't very nice I think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SOLDER-301?page=com.atlassian.jira.plugin... ] Geoffrey De Smet edited comment on SOLDER-301 at 12/6/11 9:06 AM: ------------------------------------------------------------------ @Christian Why use shaded jars in the first place? Afaik, shaded jars bring nothing but trouble: - If jar B shades jar A and both A and B end up in the same classpath (very likely in big projects that indirectly depend on A and B) and they are different versions (again likely), then the classes of the first jar on the classpath will be used at runtime (which is in practice means you don't know). Furthermore, the exceptions raised are unclear (NoSuchMethodError, ClassCastException: cannot cast Dog to Animal (but Dog does extend Animal), ...). - the Red Hat guys that do RPM repackaging of our projects in http://www.jpackage.org/ absolute hate shaded jars as they can't deal with them - OSGi doesn't like shaded jars. - Once JDK 8 Jigsaw is out, you won't be able to shade any more anyway. So instead of shading to create "dependency reduced pom.xml" and "shade the dependencies in the jar", can't the jar not shade those dependencies and simply depend on them in it's pom? was (Author: ge0ffrey): @Christian Why use shades jars in the first place? Afaik, shaded jars bring nothing but trouble: - If jar B shades jar A and both A and B end up in the same classpath (very likely in big projects that indirectly depend on A and B) and they are different versions (again likely), then the classes of the first jar on the classpath will be used at runtime (which is in practice means you don't know). Furthermore, the exceptions raised are unclear (NoSuchMethodError, ClassCastException: cannot cast Dog to Animal (but Dog does extend Animal), ...). - the Red Hat guys that do RPM repackaging of our projects in http://www.jpackage.org/ absolute hate shaded jars as they can't deal with them - OSGi doesn't like shaded jars. - Once JDK 8 Jigsaw is out, you won't be able to shade any more anyway. So instead of shading to create "dependency reduced pom.xml" and "shade the dependencies in the jar", can't the jar not shade those dependencies and simply depend on them in it's pom? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SOLDER-301?page=com.atlassian.jira.plugin... ] Geoffrey De Smet edited comment on SOLDER-301 at 12/6/11 9:07 AM: ------------------------------------------------------------------ @Christian Why use shaded jars in the first place? Afaik, shaded jars bring nothing but trouble: - If jar B shades jar A and both A and B end up in the same classpath (very likely in big projects that indirectly depend on A and B) and they are different versions (again likely), then the classes of the first jar on the classpath will be used at runtime (which is in practice means you don't know which one). Furthermore, the exceptions raised are unclear (NoSuchMethodError, ClassCastException: cannot cast Dog to Animal (but Dog does extend Animal), ...). - the Red Hat guys that do RPM repackaging of our projects in http://www.jpackage.org/ absolute hate shaded jars as they can't deal with them - OSGi doesn't like shaded jars. - Once JDK 8 Jigsaw is out, we won't be able to shade any more anyway. So instead of shading to create "dependency reduced pom.xml" and "shade the dependencies in the jar", can't the jar not shade those dependencies and simply depend on them in it's pom? was (Author: ge0ffrey): @Christian Why use shaded jars in the first place? Afaik, shaded jars bring nothing but trouble: - If jar B shades jar A and both A and B end up in the same classpath (very likely in big projects that indirectly depend on A and B) and they are different versions (again likely), then the classes of the first jar on the classpath will be used at runtime (which is in practice means you don't know which one). Furthermore, the exceptions raised are unclear (NoSuchMethodError, ClassCastException: cannot cast Dog to Animal (but Dog does extend Animal), ...). - the Red Hat guys that do RPM repackaging of our projects in http://www.jpackage.org/ absolute hate shaded jars as they can't deal with them - OSGi doesn't like shaded jars. - Once JDK 8 Jigsaw is out, you won't be able to shade any more anyway. So instead of shading to create "dependency reduced pom.xml" and "shade the dependencies in the jar", can't the jar not shade those dependencies and simply depend on them in it's pom? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SOLDER-301?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on SOLDER-301: ----------------------------------------- @Christian I agree: most of the pain of shading goes away if you also relocate all the classes and all the resources. However, relocating resources is a PITA. I presume Solder doesn't have to deal with relocating any resources (yet?). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SOLDER-301?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on SOLDER-301: ----------------------------------------- @Jason If you decide to keep the shading, yes it can be closed. But I personally would much rather see all shading go away :) Just reuse classes the normal way. If you close it, that "-Pjboss-public-repository" trick should be noted somewhere that anyone's who's going to build solder from source would read. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira