[ https://issues.jboss.org/browse/JBIDE-12565?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-12565: ---------------------------------------- I mode some major experiments on target platform to get them deduced from multiple.target and get this workflow to work (for the target-platform job). Proposed workflow, which is meant for easier maintainance and more reliability is: # First build, validate and publish on Nexus multiple.target. This one should almost never fail and is pretty easy to maintain, so we always provide a usable multiple.target # Then generate local.target from it, and materialize target-platform locally (-P get.local.target). Validate materialized local.target (against newly created local repository). The local repo is used as the local cache for Jenkins ( /home/hudson/static_build_env/jbds/tools/sources/REPO_4.0.juno.SR0a/ ) # Publish local repository where expected ( http://download.jboss.org/jbosstools/updates/target-platform_4.0.juno.SR0... ) # Build, validate and publish on Nexus unified.target (which is built upon site publised in step #3). This process ensure any published target-platform can be resolved (thanks to the validation plugin). The new strategy is implemented here: http://anonsvn.jboss.org/repos/jbosstools/workspace/mistria/target-platfo... and a demo job is available here: https://jenkins-test.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-4.0_... . This job does everything except publishing. As you may see, it already spots defect in target-platform which were not detected so far. -- 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

[ https://issues.jboss.org/browse/JBIDE-12565?page=com.atlassian.jira.plugi... ] Mickael Istria edited comment on JBIDE-12565 at 9/7/12 8:51 AM: ---------------------------------------------------------------- I mode some major experiments on target platform to get them deduced from multiple.target and get this workflow to work (for the target-platform job). Proposed workflow, which is meant for easier maintainance and more reliability is: # First build, validate and publish on Nexus multiple.target. This one should almost never fail and is pretty easy to maintain, so we always provide a usable multiple.target # Then generate local.target from it, and materialize target-platform locally (-P get.local.target). Validate materialized local.target (against newly created local repository). The local repo is used as the local cache for Jenkins ( /home/hudson/static_build_env/jbds/tools/sources/REPO_4.0.juno.SR0a/ ) # Publish local repository where expected ( http://download.jboss.org/jbosstools/updates/target-platform_4.0.juno.SR0... ) # Generate (from multiple.target), Build, validate and publish on Nexus unified.target (which is built upon site publised in step #3). This process ensure any published target-platform can be resolved (thanks to the validation plugin). The new strategy is implemented here: http://anonsvn.jboss.org/repos/jbosstools/workspace/mistria/target-platfo... and a demo job is available here: https://jenkins-test.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-4.0_... . This job does everything except publishing. As you may see, it already spots defect in target-platform which were not detected so far. New implementation follows Maven state-of-the-art: artifacts are independant and linkage is expressed using Maven artifacts rather that filesystem. Each target-platform is a module. Also this implementation introduce new artifact groups and ids to avoid collision with current ones, and also to make it clearer. was (Author: mickael_istria): I mode some major experiments on target platform to get them deduced from multiple.target and get this workflow to work (for the target-platform job). Proposed workflow, which is meant for easier maintainance and more reliability is: # First build, validate and publish on Nexus multiple.target. This one should almost never fail and is pretty easy to maintain, so we always provide a usable multiple.target # Then generate local.target from it, and materialize target-platform locally (-P get.local.target). Validate materialized local.target (against newly created local repository). The local repo is used as the local cache for Jenkins ( /home/hudson/static_build_env/jbds/tools/sources/REPO_4.0.juno.SR0a/ ) # Publish local repository where expected ( http://download.jboss.org/jbosstools/updates/target-platform_4.0.juno.SR0... ) # Generate (from multiple.target), Build, validate and publish on Nexus unified.target (which is built upon site publised in step #3). This process ensure any published target-platform can be resolved (thanks to the validation plugin). The new strategy is implemented here: http://anonsvn.jboss.org/repos/jbosstools/workspace/mistria/target-platfo... and a demo job is available here: https://jenkins-test.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-4.0_... . This job does everything except publishing. As you may see, it already spots defect in target-platform which were not detected so far. Please note that current implementation follows Maven state-of-the-art: artifacts are independant and linkage is expressed using Maven artifacts rather that filesystem. -- 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

[ https://issues.jboss.org/browse/JBIDE-12565?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12565 at 9/7/12 11:15 AM: ------------------------------------------------------------- The failure you're seeing... {code} [INFO] Validating /qa/services/test_hudson/hudson_workspace/workspace/jbosstools-4.0_trunk.magic-target-platform/local/target/local/multiple.target... [INFO] {org.osgi.framework.executionenvironment=OSGi/Minimum-1.0,OSGi/Minimum-1.1, osgi.ws=gtk, osgi.os=linux, osgi.arch=x86, org.eclipse.update.install.features=true, org.osgi.framework.system.packages=} [ERROR] Cannot resolve project dependencies: [ERROR] Software being installed: org.eclipse.mylyn.github.feature.feature.group 2.0.0.201206130900-r [ERROR] Missing requirement: org.eclipse.mylyn_feature.feature.group 3.8.1.v20120725-0100 requires 'org.apache.lucene.core [2.9.1,3.0.0)' but it could not be found [ERROR] Cannot satisfy dependency: org.eclipse.mylyn.github.feature.feature.group 2.0.0.201206130900-r depends on: org.eclipse.mylyn_feature.feature.group 3.7.0 [ERROR] [INFO] Failed, see Error log below [ERROR] Validation found errors in 1 .target files: Could not resolve content of multiple.target "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.apache.lucene 2.9.1.v201101211721 to bundle org.apache.lucene.core [2.9.1,3.0.0).", "Unable to satisfy dependency from org.apache.lucene.snowball 2.9.1.v20100421-0704 to bundle org.apache.lucene.core [2.9.1,3.0.0).", "Unable to satisfy dependency from org.eclipse.mylyn.tasks.index.core 3.8.1.v20120725-0100 to bundle org.apache.lucene.core [2.9.1,3.0.0).", "Unable to satisfy dependency from org.eclipse.mylyn_feature.feature.group 3.8.1.v20120725-0100 to org.apache.lucene.core [2.9.1,3.0.0).", "No solution found because the problem is unsatisfiable."] {code} ... simply means "the IUs we're looking for cannot be found on the site(s) listed in the target file (or p2.mirror script generated from the target file). I was getting the same error when I was validating unified.target BEFORE having publishing the JBT JunoSR0a target platform site. Having pushed the site to the URL specified in unified.target... the error is still there. Which means we have at least one missing IU on the target platform. Another case of where we require multiple versions of an IU -- in this case, Mylyn needs lucene.core 2.9.1, and checkstyle needs 3.5. After I add the IU to the unified.target file, I get a different error (when validating both multiple.target and unified.target): {code} cd ~/trunk/build/target-platform; mvn install [INFO] --- target-platform-validation-plugin:0.16.0-SNAPSHOT:validate-target-platform (default) @ org.jboss.tools.target.platform --- [INFO] Validating /home/nboldt/eclipse/workspace-jboss/jbosstools_trunk/build/target-platform/multiple.target... [INFO] OK! [INFO] Validating /home/nboldt/eclipse/workspace-jboss/jbosstools_trunk/build/target-platform/unified.target... [INFO] Failed, see Error log below [ERROR] Validation found errors in 1 .target files: Could not resolve content of unified.target Could not find "org.apache.lucene.core/2.9.1.v201101211721" in the repositories of the current location {code} was (Author: nickboldt): The failure you're seeing... {code} [INFO] Validating /qa/services/test_hudson/hudson_workspace/workspace/jbosstools-4.0_trunk.magic-target-platform/local/target/local/multiple.target... [INFO] {org.osgi.framework.executionenvironment=OSGi/Minimum-1.0,OSGi/Minimum-1.1, osgi.ws=gtk, osgi.os=linux, osgi.arch=x86, org.eclipse.update.install.features=true, org.osgi.framework.system.packages=} [ERROR] Cannot resolve project dependencies: [ERROR] Software being installed: org.eclipse.mylyn.github.feature.feature.group 2.0.0.201206130900-r [ERROR] Missing requirement: org.eclipse.mylyn_feature.feature.group 3.8.1.v20120725-0100 requires 'org.apache.lucene.core [2.9.1,3.0.0)' but it could not be found [ERROR] Cannot satisfy dependency: org.eclipse.mylyn.github.feature.feature.group 2.0.0.201206130900-r depends on: org.eclipse.mylyn_feature.feature.group 3.7.0 [ERROR] [INFO] Failed, see Error log below [ERROR] Validation found errors in 1 .target files: Could not resolve content of multiple.target "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.apache.lucene 2.9.1.v201101211721 to bundle org.apache.lucene.core [2.9.1,3.0.0).", "Unable to satisfy dependency from org.apache.lucene.snowball 2.9.1.v20100421-0704 to bundle org.apache.lucene.core [2.9.1,3.0.0).", "Unable to satisfy dependency from org.eclipse.mylyn.tasks.index.core 3.8.1.v20120725-0100 to bundle org.apache.lucene.core [2.9.1,3.0.0).", "Unable to satisfy dependency from org.eclipse.mylyn_feature.feature.group 3.8.1.v20120725-0100 to org.apache.lucene.core [2.9.1,3.0.0).", "No solution found because the problem is unsatisfiable."] {code} ... simply means "the IUs we're looking for cannot be found on the site(s) listed in the target file (or p2.mirror script generated from the target file). I was getting the same error when I was validating unified.target BEFORE having publishing the JBT JunoSR0a target platform site. Having pushed the site to the URL specified in unified.target... the error is still there. Which means we have at least one missing IU on the target platform. Another case of where we require multiple versions of an IU -- in this case, Mylyn needs lucene.core 2.9.1, and checkstyle needs 3.5. -- 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

[ https://issues.jboss.org/browse/JBIDE-12565?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-12565: ---------------------------------------- Ok, so we'll discuss this one wednesday call to ensure it fits our needs, and if everyone agrees, we can switch to this approach next week. About missing IUs, I think it could appear to work currently because the current aggregated site may not have been cleaned. Do you think it could be a reason why this IU is on the aggregate site whereas is is not aggregated? -- 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

[ https://issues.jboss.org/browse/JBIDE-12565?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-12565: ---------------------------------------- Actually it would first generate the site locally and validate local.target (on the newly built site). If the site can validate, it's published and then we verify unified.target validates against the published site. If local site appears to be missing IUs, build stops and site is not published. That way, all TPs published will be fine: Target-platforms published on Nexus are always in sync and working with the currently published repo. In case of issue (such as the one we experiment with Lucene core), we end up with having multiple.target on Nexus more recent than the unified.target. -- 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

[ https://issues.jboss.org/browse/JBIDE-12565?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-12565: ---------------------------------- Assignee: Mickael Istria (was: Nick Boldt) -- 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

[ https://issues.jboss.org/browse/JBIDE-12565?page=com.atlassian.jira.plugi... ] Mickael Istria closed JBIDE-12565. ---------------------------------- -- 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