[jbosstools-issues] [JBoss JIRA] (JBIDE-11734) Create TP site using an "eclipse-repository", <repositories> and category.xml
Nick Boldt (JIRA)
jira-events at lists.jboss.org
Wed May 30 13:52:18 EDT 2012
[ https://issues.jboss.org/browse/JBIDE-11734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697261#comment-12697261 ]
Nick Boldt edited comment on JBIDE-11734 at 5/30/12 1:51 PM:
-------------------------------------------------------------
(2012-05-30 12:30:14) nboldt: 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/unified.target ? 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-platform/configure
We also publish the JBT .target files & accompanying pom to nexus:
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jboss/tools/org.jboss.tools.target.platform/3.4.0.M1-SNAPSHOT/
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/unified.target ? 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-platform/configure
We also publish the JBT .target files & accompanying pom to nexus:
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jboss/tools/org.jboss.tools.target.platform/3.4.0.M1-SNAPSHOT/
> Create TP site using an "eclipse-repository", <repositories> and category.xml
> -----------------------------------------------------------------------------
>
> Key: JBIDE-11734
> URL: https://issues.jboss.org/browse/JBIDE-11734
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 3.4.0.M1
>
>
> Instead of parsing and tweaking a .target file to generate the "requirement" repository, we could make it a normal "eclipse-repository" artifact. We would manage versions in it.
> Then we know the versions of deps in that site, and we can create target platform using 0.0.0 for versions since we are sure they are resolved against our site.
--
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
More information about the jbosstools-issues
mailing list