[ https://issues.jboss.org/browse/JBIDE-11734?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11734: ---------------------------------------- Nick, can you please detail the current process to generate sites/TP here, with its current pitfalls? The main one I see is that we often have unusable target platforms. Instead I suggest: # We maintain a site, in the eclipse-repository Tycho way, and manage its content with a category.xml. This site will include a union of all our requirements for dev and builds # We also maintain target platforms (a pom with .target files) as we do now. We try to leverage some validation as suggested in JBIDE-12003 to ensure we can resolve target platforms from the site # CI Build job would be: ## Build site ## Publish site to download.jboss.org ## Validate, Build and publish .target to Nexus This should really improve usability and maintainability of how we manage and consume targets. WDYT? -- 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/JBIDE-11734?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11734: ---------------------------------------- A first increment could be to have a category.xml to define TP site, from composite requirements. A second increment could be to investigate around replacement of requirements by direct definition in category.xml + pom.xml. -- 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/JBIDE-11734?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-11734 at 5/30/12 1:45 PM: ------------------------------------------------------------- (2012-05-30 12:30:03) nboldt: anyway, I agree w/ your idea to instead of generating a p2 mirror script from the .target file that you instead generate a category.xml file (2012-05-30 12:30:14) nboldt: HOWEVER... can the category.xml file include plugins as well as features? (2012-05-30 12:30:25) nboldt: because our TP is plugins and features, not just features (2012-05-30 12:30:47) nboldt: or would you then have to generate BOTH category.xml and p2.inf to handle the two types of IUs? (2012-05-30 12:30:56) nboldt: and ultimately, what would this get us? (2012-05-30 12:31:07) mistria: no, it can't, but we can set up a "featurelessBundlesHostFeature" for bundles that are not part of a feature NOW: (2012-05-30 12:31:17) nboldt: p2 mirror script == runnable artifact w/ a list of IUs and the site from which to get them PROPOSED: (2012-05-30 12:31:37) nboldt: category.xml + pom.xml + p2.inf == runnable artifacts w/ a list of IUs and the site from which to get them (2012-05-30 12:31:56) nboldt: I see more metadata, resulting in the same thing (a p2 repo) (2012-05-30 12:32:05) nboldt: what is the benefit here? (2012-05-30 12:32:15) mistria: I've never succeeded to get p2.inf to work well, but if it can solve this, we should use it (2012-05-30 12:32:33) mistria: the benefit would be a more straightforward approach I feel like your definition of "straightforward" needs straightening. You propose: * more files to maintain/generate * more complexity (using category.xml for features, p2.inf for plugins) * needing to keep BOTH target files and category.xml/pom.xml/p2.inf files in sync All because running ant to call p2 is too convoluted? (2012-05-30 12:32:48) mistria: people would be able to build TP site locally with a "mvn install" This already works. {code} cd ~/33x/build/target-platform; mvn install -Pget.local.target {code} (2012-05-30 12:33:29) mistria: and we have a single entry point for customization of TP site What about https://svn.jboss.org/repos/jbosstools/trunk/build/target-platform/unifie... ? Is that not a single entry point? Note too that other JIRAs have proposed having 2-3 target platforms for JBT and the same for JBDS (with and without sources [JBIDE-11689], using baseline/minimums (SR1)[JBIDE-10312] vs. latest version of deps (SR2) vs. "developer version" [JBIDE-11726]). For each new .target file, you'll need 3 new metafiles (category.xml/pom.xml/p2.inf). (2012-05-30 12:33:33) mistria: which would be category.xml Which you'd have to generate in order to keep in sync w/ the .target file, or else would result in duplication of effort/maintenance. (2012-05-30 12:35:16) mistria: nboldt: also, we could easily put TP site and .target file build/publishing into Jenkins We already do this: http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.target-platfor... was (Author: nickboldt): (2012-05-30 12:30:03) nboldt: anyway, I agree w/ your idea to instead of generating a p2 mirror script from the .target file that you instead generate a category.xml file (2012-05-30 12:30:14) nboldt: HOWEVER... can the category.xml file include plugins as well as features? (2012-05-30 12:30:25) nboldt: because our TP is plugins and features, not just features (2012-05-30 12:30:47) nboldt: or would you then have to generate BOTH category.xml and p2.inf to handle the two types of IUs? (2012-05-30 12:30:56) nboldt: and ultimately, what would this get us? (2012-05-30 12:31:07) mistria: no, it can't, but we can set up a "featurelessBundlesHostFeature" for bundles that are not part of a feature NOW: (2012-05-30 12:31:17) nboldt: p2 mirror script == runnable artifact w/ a list of IUs and the site from which to get them PROPOSED: (2012-05-30 12:31:37) nboldt: category.xml + pom.xml + p2.inf == runnable artifacts w/ a list of IUs and the site from which to get them (2012-05-30 12:31:56) nboldt: I see more metadata, resulting in the same thing (a p2 repo) (2012-05-30 12:32:05) nboldt: what is the benefit here? (2012-05-30 12:32:15) mistria: I've never succeeded to get p2.inf to work well, but if it can solve this, we should use it (2012-05-30 12:32:33) mistria: the benefit would be a more straightforward approach (2012-05-30 12:32:48) mistria: people would be able to build TP site locally with a "mvn install" This already works. http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.target-platfor... {code} cd ~/33x/build/target-platform; mvn install -Pget.local.target {code} (2012-05-30 12:33:29) mistria: and we have a single entry point for customization of TP site What about https://svn.jboss.org/repos/jbosstools/trunk/build/target-platform/unifie... ? (2012-05-30 12:33:33) mistria: which would be category.xml Which you'd have to generate in order to keep in sync w/ the .target file, or else would result in duplication of effort/maintenance. (2012-05-30 12:35:16) mistria: nboldt: also, we could easily put TP site and .target file build/publishing into Jenkins We already do this: http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.target-platfor... -- 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/JBIDE-11734?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-11734 at 5/30/12 1:49 PM: ------------------------------------------------------------- (2012-05-30 12:30:03) nboldt: anyway, I agree w/ your idea to instead of generating a p2 mirror script from the .target file that you instead generate a category.xml file (2012-05-30 12:30:14) nboldt: HOWEVER... can the category.xml file include plugins as well as features? (2012-05-30 12:30:25) nboldt: because our TP is plugins and features, not just features (2012-05-30 12:30:47) nboldt: or would you then have to generate BOTH category.xml and p2.inf to handle the two types of IUs? (2012-05-30 12:30:56) nboldt: and ultimately, what would this get us? (2012-05-30 12:31:07) mistria: no, it can't, but we can set up a "featurelessBundlesHostFeature" for bundles that are not part of a feature NOW: (2012-05-30 12:31:17) nboldt: p2 mirror script == runnable artifact w/ a list of IUs and the site from which to get them PROPOSED: (2012-05-30 12:31:37) nboldt: category.xml + pom.xml + p2.inf == runnable artifacts w/ a list of IUs and the site from which to get them (2012-05-30 12:31:56) nboldt: I see more metadata, resulting in the same thing (a p2 repo) (2012-05-30 12:32:05) nboldt: what is the benefit here? (2012-05-30 12:32:15) mistria: I've never succeeded to get p2.inf to work well, but if it can solve this, we should use it (2012-05-30 12:32:33) mistria: the benefit would be a more straightforward approach I feel like your definition of "straightforward" needs straightening. You propose: * more files to maintain/generate * more complexity (using category.xml for features, p2.inf for plugins) * needing to keep BOTH target files and category.xml/pom.xml/p2.inf files in sync All because running ant to call p2 is too convoluted? (2012-05-30 12:32:48) mistria: people would be able to build TP site locally with a "mvn install" This already works. {code} cd ~/33x/build/target-platform; mvn install -Pget.local.target {code} (2012-05-30 12:33:29) mistria: and we have a single entry point for customization of TP site What about https://svn.jboss.org/repos/jbosstools/trunk/build/target-platform/unifie... ? Is that not a single entry point? Note too that other JIRAs have proposed having 2-3 target platforms for JBT and the same for JBDS (with and without sources *[JBIDE-11689]*, using baseline/minimums (SR1) *[JBIDE-10312]* vs. latest version of deps (SR2) vs. "developer version" *[JBIDE-11726]*). For each new .target file, you'll need 3 new metafiles (category.xml/pom.xml/p2.inf). (2012-05-30 12:33:33) mistria: which would be category.xml Which you'd have to generate in order to keep in sync w/ the .target file, or else would result in duplication of effort/maintenance. (2012-05-30 12:35:16) mistria: nboldt: also, we could easily put TP site and .target file build/publishing into Jenkins We already publish the site: http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.target-platfor... We also publish the JBT .target files & accompanying pom to nexus: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... was (Author: nickboldt): (2012-05-30 12:30:03) nboldt: anyway, I agree w/ your idea to instead of generating a p2 mirror script from the .target file that you instead generate a category.xml file (2012-05-30 12:30:14) nboldt: HOWEVER... can the category.xml file include plugins as well as features? (2012-05-30 12:30:25) nboldt: because our TP is plugins and features, not just features (2012-05-30 12:30:47) nboldt: or would you then have to generate BOTH category.xml and p2.inf to handle the two types of IUs? (2012-05-30 12:30:56) nboldt: and ultimately, what would this get us? (2012-05-30 12:31:07) mistria: no, it can't, but we can set up a "featurelessBundlesHostFeature" for bundles that are not part of a feature NOW: (2012-05-30 12:31:17) nboldt: p2 mirror script == runnable artifact w/ a list of IUs and the site from which to get them PROPOSED: (2012-05-30 12:31:37) nboldt: category.xml + pom.xml + p2.inf == runnable artifacts w/ a list of IUs and the site from which to get them (2012-05-30 12:31:56) nboldt: I see more metadata, resulting in the same thing (a p2 repo) (2012-05-30 12:32:05) nboldt: what is the benefit here? (2012-05-30 12:32:15) mistria: I've never succeeded to get p2.inf to work well, but if it can solve this, we should use it (2012-05-30 12:32:33) mistria: the benefit would be a more straightforward approach I feel like your definition of "straightforward" needs straightening. You propose: * more files to maintain/generate * more complexity (using category.xml for features, p2.inf for plugins) * needing to keep BOTH target files and category.xml/pom.xml/p2.inf files in sync All because running ant to call p2 is too convoluted? (2012-05-30 12:32:48) mistria: people would be able to build TP site locally with a "mvn install" This already works. {code} cd ~/33x/build/target-platform; mvn install -Pget.local.target {code} (2012-05-30 12:33:29) mistria: and we have a single entry point for customization of TP site What about https://svn.jboss.org/repos/jbosstools/trunk/build/target-platform/unifie... ? Is that not a single entry point? Note too that other JIRAs have proposed having 2-3 target platforms for JBT and the same for JBDS (with and without sources *[JBIDE-11689]*, using baseline/minimums (SR1) *[JBIDE-10312]* vs. latest version of deps (SR2) vs. "developer version" *[JBIDE-11726]*). For each new .target file, you'll need 3 new metafiles (category.xml/pom.xml/p2.inf). (2012-05-30 12:33:33) mistria: which would be category.xml Which you'd have to generate in order to keep in sync w/ the .target file, or else would result in duplication of effort/maintenance. (2012-05-30 12:35:16) mistria: nboldt: also, we could easily put TP site and .target file build/publishing into Jenkins We already do this: http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.target-platfor... -- 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/JBIDE-11734?page=com.atlassian.jira.plugi... ] Mickael Istria reassigned JBIDE-11734: -------------------------------------- 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: 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/JBIDE-11734?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11734: ------------------------------------ Another similar approach: https://anonsvn.jboss.org/repos/jbosstools/workspace/dgolovin/new-releng/... -- 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/JBIDE-11734?page=com.atlassian.jira.plugi... ] Mickael Istria edited comment on JBIDE-11734 at 7/16/12 8:08 AM: ----------------------------------------------------------------- I also have some experiments here: https://anonsvn.jboss.org/repos/jbosstools/workspace/mistria/target-platform was (Author: mickael_istria): I also have some experiments here: https://svn.jboss.org/repos/jbosstools/workspace/mistria/target-platform -- 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/JBIDE-11734?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-11734: ----------------------------------- Fix Version/s: 4.0.0.Alpha2 (was: 4.0.0.Alpha1) I'd better see: * multiple "composite" target platform which references all sites * Generate the TP site + unified.target from this multiple.target. So we don't have to maintain a composite + some .target files any more, instead, we get a single entry point: the multiple.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-11734?page=com.atlassian.jira.plugi... ] Mickael Istria closed JBIDE-11734. ---------------------------------- -- 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