[jbosstools-issues] [JBoss JIRA] (JBIDE-11734) Create TP site using an "eclipse-repository", <repositories> and category.xml

[ 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