[jbosstools-issues] [JBoss JIRA] (JBIDE-12565) Deduce all target-platforms (local + unified) from multiple.target

[ 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