[JBoss JIRA] (JBIDE-16292) Need to restore ability to select specific archetype version per runtime in Central
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16292?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-16292:
--------------------------------
Description:
The changes done in JBIDE-15645 introduced a regression in the way archetypes are selected.
Basically, we can get different archetype versions depending on the EE version of the runtime (web/full-ee6 vs web/full-ee7) but we lost the ability to pick a different archetype version between 2 different runtimes of the same product and same EE level (eg. EAP 6.1 vs EAP 6.2)
As a consequence, archetype versions designed to run on EAP 6.2 will be selected when EAP 6.1 is selected in the project wizard.
Hopefully EAP 6.2 archetypes will still be able to run on EAP 6.1 so that shouldn't be a problem, but we should fix that for the next minor release.
was:
The changes done in JBIDE-15645 introduced a regression in the way archetypes are selected.
Basically, we can get different archetype versions depending on the EE version of the runtime (web/full-ee6 vs web/full-ee7) but we lost the ability to pick a different archetype version between 2 different runtimes of the same EE level (eg. EAP 6.1 vs EAP 6.2)
As a consequence, archetype versions designed to run on EAP 6.2 will be selected when EAP 6.1 is selected in the project wizard.
Hopefully EAP 6.2 archetypes will still be able to run on EAP 6.1 so that shouldn't be a problem, but we should fix that for the next minor release.
> Need to restore ability to select specific archetype version per runtime in Central
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-16292
> URL: https://issues.jboss.org/browse/JBIDE-16292
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central, project-examples
> Affects Versions: 4.1.1.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Fix For: 4.1.2.Final
>
>
> The changes done in JBIDE-15645 introduced a regression in the way archetypes are selected.
> Basically, we can get different archetype versions depending on the EE version of the runtime (web/full-ee6 vs web/full-ee7) but we lost the ability to pick a different archetype version between 2 different runtimes of the same product and same EE level (eg. EAP 6.1 vs EAP 6.2)
> As a consequence, archetype versions designed to run on EAP 6.2 will be selected when EAP 6.1 is selected in the project wizard.
> Hopefully EAP 6.2 archetypes will still be able to run on EAP 6.1 so that shouldn't be a problem, but we should fix that for the next minor release.
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16292) Need to restore ability to select specific archetype version per runtime in Central
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-16292:
-----------------------------------
Summary: Need to restore ability to select specific archetype version per runtime in Central
Key: JBIDE-16292
URL: https://issues.jboss.org/browse/JBIDE-16292
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: central, project-examples
Affects Versions: 4.1.1.Final
Reporter: Fred Bricon
Assignee: Fred Bricon
Fix For: 4.1.2.Final
The changes done in JBIDE-15645 introduced a regression in the way archetypes are selected.
Basically, we can get different archetype versions depending on the EE version of the runtime (web/full-ee6 vs web/full-ee7) but we lost the ability to pick a different archetype version between 2 different runtimes of the same EE level (eg. EAP 6.1 vs EAP 6.2)
As a consequence, archetype versions designed to run on EAP 6.2 will be selected when EAP 6.1 is selected in the project wizard.
Hopefully EAP 6.2 archetypes will still be able to run on EAP 6.1 so that shouldn't be a problem, but we should fix that for the next minor release.
--
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
12 years, 4 months
[JBoss JIRA] (TOOLSDOC-443) Simple guide to show app signing and deploying for iOS and Android
by Tadeas Kriz (JIRA)
Tadeas Kriz created TOOLSDOC-443:
------------------------------------
Summary: Simple guide to show app signing and deploying for iOS and Android
Key: TOOLSDOC-443
URL: https://issues.jboss.org/browse/TOOLSDOC-443
Project: Documentation for JBoss Tools and Developer Studio
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: User Guide - Hybrid Mobile Tools
Reporter: Tadeas Kriz
Assignee: Michelle Murray
The documentation shows how to export "Mobile Application" in chapter 8.3.7. It says "ready-to-sign applications", but I'd be good to show, what can the user then do with the exported application, as readers of this guide might not be aware of how native packages work.
When export is made for iOS, the output is a single .app package. For Android, it's an .apk archive. It should be made clear to user what those packages are and possibly link to official documentation on given topic if it exists.
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16220?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-16220 at 12/12/13 10:28 AM:
---------------------------------------------------------------
Job updated to run on RHEL6_64 only, as those slaves now have git 1.8.2 installed on them. Also added these to job execution and verified default JDK is 7, not 6 (needed for Forge 2):
{code}
-Djbosstools.test.jre.5=${NATIVE_TOOLS}${SEP}${JAVA15}
-Djbosstools.test.jre.6=${NATIVE_TOOLS}${SEP}${JAVA16}
-Djbosstools.test.jre.7=${NATIVE_TOOLS}${SEP}${JAVA17}
{code}
Respinning:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-submodule... >=8
was (Author: nickboldt):
Job updated to run on RHEL6_64 only, as those slaves now have git 1.8.2 installed on them.
Respinning:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-submodule... >=7
> create an all-in-one build for JBT projects, using submodules
> -------------------------------------------------------------
>
> Key: JBIDE-16220
> URL: https://issues.jboss.org/browse/JBIDE-16220
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Attachments: buildlog_maven311.txt
>
>
> Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs.
> {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188}
> "git submodule" started learning a new mode to integrate with the
> tip of the remote branch (as opposed to integrating with the commit
> recorded in the superproject's gitlink).
> {code}
> Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current.
> If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc.
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16220?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-16220:
------------------------------------
Job updated to run on RHEL6_64 only, as those slaves now have git 1.8.2 installed on them.
Respinning:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-submodule... >=7
> create an all-in-one build for JBT projects, using submodules
> -------------------------------------------------------------
>
> Key: JBIDE-16220
> URL: https://issues.jboss.org/browse/JBIDE-16220
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Attachments: buildlog_maven311.txt
>
>
> Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs.
> {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188}
> "git submodule" started learning a new mode to integrate with the
> tip of the remote branch (as opposed to integrating with the commit
> recorded in the superproject's gitlink).
> {code}
> Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current.
> If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc.
--
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
12 years, 4 months
[JBoss JIRA] (JBDS-2745) Support installation of Early Access / Experimental / Incubating plugins
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2745?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-2745:
----------------------------------
"pre-Tech Preview" == "labelled with '(Experimental)' in JBT, probably not in JBDS, MIGHT be in JBDS Central"
Rules / descriptions of types of 3rd party content (or 1rst party, if we built it but don't yet want it OOTB in JBDS):
https://devstudio.jboss.com/updates/7.0/central/
> Support installation of Early Access / Experimental / Incubating plugins
> ------------------------------------------------------------------------
>
> Key: JBDS-2745
> URL: https://issues.jboss.org/browse/JBDS-2745
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: central, requirements
> Affects Versions: 7.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Burr Sutter
>
> It's been suggested that it would be nice to have Central available to install non-GA content. How might this appear?
> [~burrsutter], [~maxandersen], are we talking about:
> * an additional dialog warning users about untested content? (that might be ignored / blindclicked)
> * an additional tab in Central for this type of content (what label would you use?)
> * relabelling the content's feature descriptions / titles / copyright / license terms to be clear it's unstable content? (might be ignored)
> * some other workflow?
> See also JBDS-2068.
--
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
12 years, 4 months
[JBoss JIRA] (JBDS-2745) Support installation of Early Access / Experimental / Incubating plugins
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-2745?page=com.atlassian.jira.plugin.... ]
Burr Sutter commented on JBDS-2745:
-----------------------------------
[~mmusaji]Think of these items as "pre-Tech Preview", one specific example is the Arquillian tooling only available in JBoss Tools today.
> Support installation of Early Access / Experimental / Incubating plugins
> ------------------------------------------------------------------------
>
> Key: JBDS-2745
> URL: https://issues.jboss.org/browse/JBDS-2745
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: central, requirements
> Affects Versions: 7.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Burr Sutter
>
> It's been suggested that it would be nice to have Central available to install non-GA content. How might this appear?
> [~burrsutter], [~maxandersen], are we talking about:
> * an additional dialog warning users about untested content? (that might be ignored / blindclicked)
> * an additional tab in Central for this type of content (what label would you use?)
> * relabelling the content's feature descriptions / titles / copyright / license terms to be clear it's unstable content? (might be ignored)
> * some other workflow?
> See also JBDS-2068.
--
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
12 years, 4 months