I found that the problem is with the last commit where Stuart set copy-module-artifacts=false in core-build/server-build.xml.

Not sure why that caused me a problem.  I'll look closer tomorrow.

On 8/18/2014 3:11 PM, Eduardo Martins wrote:
Perhaps a clean local build of WFLY Core will help?

—E

On 18 Aug 2014, at 19:33, Brian Stansberry <brian.stansberry@redhat.com> wrote:

On 8/18/14, 12:44 PM, Stan Silvert wrote:
No joy.


Sorry, I don't know what your issue is then. :(

Does that build use the core snapshot?


Yes. It uses the most recent result of [1] if the code that produced 
that result matches wildfly-core/master's HEAD, and if it doesn't match 
it runs that job first.

[1] 
http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WildFlyCore_MasterLinux

On 8/18/2014 1:39 PM, Brian Stansberry wrote:
Perhaps do a full clean and install?

The CI test with the latest WildFly core master is working fine -- I
kicked it off when I got your last email and it's through the build and
into the testsuite:

http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WF_WildFlyCoreIntegration&buildId=20129

On 8/18/14, 12:24 PM, Stan Silvert wrote:
When I do that it gets worse:

[ERROR] Failed to execute goal
org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build
(create-server) on project wildfly-web-build: Execution create-server of
goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build
failed: java.lang.RuntimeException: Could not extract resources from
artifact org.slf4j:slf4j-api:1
.7.7.jbossorg-1 contents
{org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s
pec:jar:1.0.0.Final:compile,
org.wildfly:wildfly-security=org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile,
org.wildfly.security:wildfly-security-manager=or
g.wildfly.security:wildfly-security-manager:jar:1.0.0.Final:compile,
org.jboss.aesh:aesh=org.jboss.aesh:aesh:jar:0.33.12:compile,
org.wildfly.core:wildfly-domain-http-int
erface:1.0.0.Alpha5-SNAPSHOT=org.wildfly.core:wildfly-domain-http-interface:jar:1.0.0.Alpha5-SNAPSHOT:compile,
io.undertow:undertow-core:1.1.0.Beta6=io.undertow:undertow-
core:jar:1.1.0.Beta6:compile,
org.jboss.sasl:jboss-sasl:1.0.4.Final=org.jboss.sasl:jboss-sasl:jar:1.0.4.Final:compile,
org.wildfly:wildfly-security:9.0.0.Alpha1-SNAPSHOT=
org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile,
org.picketbox:picketbox=org.picketbox:picketbox:jar:4.0.21.Beta3:compile, org.fusesource.jansi:jansi=org.f
usesource.jansi:jansi:jar:1.9:compile,
org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.2.Beta1=org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar
:1.1.2.Beta1:compile,
org.jboss.logmanager:log4j-jboss-logmanager=org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.0.Final:compile,
org.picketbox:picketbox-infinispan:
4.0.21.Beta3=org.picketbox:picketbox-infinispan:jar:4.0.21.Beta3:compile, org.wildfly.core:wildfly-io=org.wildfly.core:wildfly-io:jar:1.0.0.Alpha5-SNAPSHOT:compile,
org.j

On 8/18/2014 1:18 PM, Brian Stansberry wrote:
When you build master, include -Dskip-enforce in your args to maven.
That turns off the problematic transitive dependency enforcement, which
is more trouble than it is worth when dealing with snapshots.

When we bring the next release of core in, the master pom will be
updated to include the org.wildfly.core:wildfly-launcher dependency.

On 8/18/14, 12:09 PM, Stan Silvert wrote:
Build the latest WildFly Core master.

In WildFly Full master, change the root pom to use latest core:
<version.org.wildfly.core>1.0.0.Alpha5-SNAPSHOT</version.org.wildfly.core>

When you build full, you will get:
[WARNING] Rule 0:
org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with
message:
org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT
org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile
has transitive dependencies:
org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile

If you exclude the wildfly-launcher dependency, the build gets even uglier.

Should these two builds stay in sync somehow?  For some features, we
need to be able to make changes to both builds at the same time and see
them work together.

Stan



_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev