[jbosstools-issues] [JBoss JIRA] (JBIDE-13316) Improve versioning for TP using standard Maven way

Nick Boldt (JIRA) jira-events at lists.jboss.org
Mon Dec 17 15:28:08 EST 2012


    [ https://issues.jboss.org/browse/JBIDE-13316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741953#comment-12741953 ] 

Nick Boldt edited comment on JBIDE-13316 at 12/17/12 3:26 PM:
--------------------------------------------------------------

Pros:

If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.

Cons:

If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in {WORKSPACE}, just as local dev would need to do. Could then build in series.

I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?

Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*

                
      was (Author: nickboldt):
    Pros:

If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.

Cons:

If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in ${WORKSPACE}, just as local dev would need to do. Could then build in series.

I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?

Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*

                  
> Improve versioning for TP using standard Maven way
> --------------------------------------------------
>
>                 Key: JBIDE-13316
>                 URL: https://issues.jboss.org/browse/JBIDE-13316
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: target-platform
>            Reporter: Mickael Istria
>            Assignee: Mickael Istria
>             Fix For: 4.1.0.Alpha1
>
>
> Currently, we deal with explicit versions in folder names that make it confusing to understand how target-platforms are versioned.
> Instead, we should use usual Maven way and Git branches: one Git branch for each version of TPs.

--
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


More information about the jbosstools-issues mailing list