[JBoss JIRA] (JBIDE-13316) Imporve versioning for TP using standard Maven way
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13316?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13316 at 12/17/12 3:01 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*
> Imporve 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
13 years, 4 months
[JBoss JIRA] (JBIDE-10788) Add setting ui for openshift source servers to use wtp context root if required
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-10788?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-10788:
-------------------------------------
Component/s: openshift
> Add setting ui for openshift source servers to use wtp context root if required
> -------------------------------------------------------------------------------
>
> Key: JBIDE-10788
> URL: https://issues.jboss.org/browse/JBIDE-10788
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: JBossAS/Servers, openshift
> Affects Versions: 3.3.0.M5
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Priority: Minor
> Fix For: 4.0.x
>
>
> link to JBIDE-10514 , a UI is required for this setting.
> 1. Create a new application in wizard and allow to create a new project in the workspace
> 2. Fix all the bugs so that it compiles (delete modules.jsp, add java version 1.6 to pom.xml, reload project configuration)
> 3. Modify all your build stuff so the project does NOT deploy to root
> 4. Change your context root to match what your setting is in the build
> 5. Right click the project and select Run as... + Run on server
> 6. Choose associated openshift server
> 7. Result - No page found due to the incorrect URL. It's still using root instead of your new custom context root
> A UI is required for this setting
--
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
13 years, 4 months
[JBoss JIRA] (JBIDE-13316) Imporve versioning for TP using standard Maven way
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13316?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13316:
------------------------------------
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*
> Imporve 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
13 years, 4 months
[JBoss JIRA] (JBIDE-10052) New Maven Project Dialog
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-10052?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-10052:
--------------------------------
Fix Version/s: LATER
(was: 4.1.0.Alpha1)
> New Maven Project Dialog
> ------------------------
>
> Key: JBIDE-10052
> URL: https://issues.jboss.org/browse/JBIDE-10052
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Labels: eap6-ux
> Fix For: LATER
>
> Attachments: New_Maven_Project.odp
>
>
> Many of our end-users have not yet fully embraced and learned Maven. The New Maven Project Wizard can derail the novice user.
> two suggestions:
> - prepopulate the artifactid
> - sync up groupid and java package
> - find a way to make picking the right archetype easy
> see screenshots in attachment
--
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
13 years, 4 months