[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:47: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:46 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/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 do this:

http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.target-platform/configure

                
      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 do this:

http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.target-platform/configure

                  
> 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