[JBoss JIRA] (JBIDE-20100) how to make users aware of fuse and other tooling only being available from earlyaccess?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20100?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-20100:
------------------------------------
To see the IS content, you need to add the IS content to JBT/JBDS via a -D flag, since the content is *not yet released*.
Thus, you can launch Eclipse w/ JBT installed into it against the latest CI snapshot...
{code}./eclipse -vmargs \
-Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/mars/snapshots/builds/integration-stack/discovery/4.3.0.Alpha2/jbosstools-integration-stack-directory.xml \
-Djboss.discovery.site.integration-stack.url=http://download.jboss.org/jbosstools/mars/snapshots/builds/integration-stack/discovery/4.3.0.Alpha2/
{code}
or launch JBDS
{code}./jbodevstudio -vmargs \
-Djboss.discovery.directory.url=https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discovery/9.0.0.Alpha2/devstudio-integration-stack-directory.xml \
-Djboss.discovery.site.integration-stack.url=https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discovery/9.0.0.Alpha2/
{code}
However, not all JBT/JBDS content will be available because those sites don't contain all the latest JBT/JBDS CR1a content, only the latest Beta2 + some of the CR1a content / TP. I'll open another JIRA to get that fixed. Not sure why Paul's including such a weird hodgepodge.
But using those -D flags you can see the IS content, and probably install it too! Not sure about missing dependencies - didn't test that yet.
So, when we releaase JBDS 9 CR1 and JBT 4.3 CR1, users will see NONE OF THE IS STUFF until Paul updates the released discovery sites to include his plugins. But using the above -D flags you can preview what users WILL SEE once the Alpha2 content is through QE and is released.
Make sense?
> how to make users aware of fuse and other tooling only being available from earlyaccess?
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-20100
> URL: https://issues.jboss.org/browse/JBIDE-20100
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Priority: Critical
> Labels: new_and_noteworthy, respin-a
> Fix For: 4.3.0.CR1
>
> Attachments: 20100_JBDS_CR1_fuse_ea_popup.png, 20100_JBDS_CR1_fuse_unavail.png, 20100_JBDS_CR1_fuse_unavail_popup.png, 20100_JBT_Core_vs_EA_versions_of_Fuse_Connector.png, 20100_JBT_latest_no_checkbox.png, fuse-icon-fixed.png, JBDS_9_CR1a_No_Fuse.png, JBIDE-20100-2.png, JBIDE-20100-disc1.png, JBoss_-_JBoss_Central_-_Eclipse_-__Users_max_workspaces_forjoshua.png, not-yet.png, _JBIDE-20100__how_to_make_users_aware_of_fuse_and_other_tooling_only_being_available_from_earlyaccess__-_JBoss_Issue_Tracker_and_JBoss_-_JBoss_Central_-_Eclipse_-__Users_max_workspaces_forjoshua.png
>
>
> [~jtyrrell] find it confusing when he cannot see Fuse and other earlyaccess features immediately on the install page.
> Some comments:
> "I install JBDS 8.1 and click on the JBoss Integration and SOA Development, but where is the Fuse tooling in that list."
> "<without earlyaccess> why doesn’t my screen shot tell me to use an older version of JBDS or something."
> Suggestion:
> "when I picked the Integration Stack a greyed out Fuse IDE thingy in the list of choices, and something like (Select early Access) to enable this feature."
> I'm fine exploring options to show early access features more prominently but would prefer we would not need to treat Fuse "special" so maybe we should have a "Early Access" section at the bottom instead of filtered in between everything else ?
> and for any connectors that has additional/different features just add a "Extra features available in Early access " comment ?
> But what to do when Fuse or others dont even have an earlyaccess out yet ? (like is currently the state for devstudio 9)
> [~crobson], [~aileenc] and [~lhein] got any suggestions ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (JBIDE-10788) Server Adapter: Add setting ui for openshift source servers to use wtp context root if required
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-10788?page=com.atlassian.jira.plugi... ]
Rob Stryker edited comment on JBIDE-10788 at 9/21/15 5:00 PM:
--------------------------------------------------------------
I'm linking this to JBIDE-473
Current suggestion is to add some type of marker provider which will check if a given WTP-style project is targeted to a jboss-as / wf / eap / etc runtime. If it is, we can check if the context root in the wtp project matches what we expect (via deployment preferences) for the actual context root to be on the server. If they don't match, we can add a marker on the project.
This won't be of use to you if your project is targeting an openshift server / runtime combination, though, or if your project isn't a wtp-style project... but odds are your validator would need to do different tasks anyway (check the openshift project's various build config files instead) so the patches probably won't match or be re-usable, but can simply serve as instruction on what to do.
was (Author: rob.stryker):
I'm linking this to JBIDE-473
Current suggestion is to add some type of marker provider which will check if a given WTP-style project is targeted to a jboss-as / wf / eap / etc runtime. If it is, we can check if the context root in the wtp project matches what we expect (via deployment preferences) for the actual context root to be on the server. If they don't match, we can add a marker on the project.
This won't be of use to you if your project is targeting an openshift server / runtime combination, though, and odds are your validator would need to do different tasks (check the openshift project's various build config files instead) so the patches probably won't match or be re-usable, but can simply serve as instruction on what to do.
> Server Adapter: 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: openshift, server
> Affects Versions: 3.3.0.M5
> Reporter: Rob Stryker
> Priority: Minor
> Labels: server_adapter
> Fix For: LATER
>
>
> 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 was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (JBIDE-10788) Server Adapter: Add setting ui for openshift source servers to use wtp context root if required
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-10788?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-10788:
-------------------------------------
I'm linking this to JBIDE-473
Current suggestion is to add some type of marker provider which will check if a given WTP-style project is targeted to a jboss-as / wf / eap / etc runtime. If it is, we can check if the context root in the wtp project matches what we expect (via deployment preferences) for the actual context root to be on the server. If they don't match, we can add a marker on the project.
This won't be of use to you if your project is targeting an openshift server / runtime combination, though, and odds are your validator would need to do different tasks (check the openshift project's various build config files instead) so the patches probably won't match or be re-usable, but can simply serve as instruction on what to do.
> Server Adapter: 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: openshift, server
> Affects Versions: 3.3.0.M5
> Reporter: Rob Stryker
> Priority: Minor
> Labels: server_adapter
> Fix For: LATER
>
>
> 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 was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (JBIDE-10788) Server Adapter: Add setting ui for openshift source servers to use wtp context root if required
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-10788?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-10788:
-------------------------------------
[~adietish] As far as I can tell, we do get the project's context root as declared in the wtp preference page for the project, and we do this for all modules if possible. Can you please elaborate on your step 4) 4. Change your context root to match what your setting is in the build ?
None of your steps seem to include right-clicking on the project and browsing to the place to modify context root? This is the "Web Project Settings" preference page...
> Server Adapter: 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: openshift, server
> Affects Versions: 3.3.0.M5
> Reporter: Rob Stryker
> Priority: Minor
> Labels: server_adapter
> Fix For: LATER
>
>
> 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 was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (JBIDE-20664) create discovery site for testing only that merges latest IS discovery jars with Core discovery jars
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20664?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-20664:
------------------------------------
To recap what was decided (again) in IRC (again) and further clarify the language above (again) here's what I re-titled this issue:
*JBT & JBDS discovery sites (CI only) should include latest IS jars too so QE can better see the combined site in one place*
The discovery site that I will produce using this mechanism will include:
* JBT directory.xml
* JBT Central discovery plugin
* JBT EA discovery plugin
(no change from before)
And, now, this NEW site will also include in addition to the artifacts above:
* JBT IS Central discovery plugin
* JBT IS EA discovery plugin
* updated directory.xml listing all 4 plugins
I will do the same for JBDS / JBDS IS.
These sites will look very similar to what Paul produces here: http://download.jboss.org/jbosstools/mars/snapshots/builds/integration-st...
But they'll be:
* self-cleaning (instead of having 100s of near-identical plugins in the plugins/ folder)
* contain all 4 plugins in a single folder (rather than a URL reference)
This way, IF the IS plugins are found on a /development/ site (via the ide-config.properties file), the resulting site can be compared to the previously released discovery site and it'll be much easier to do a release without the danger of:
* getting the wrong IS plugin versions
* removing IS plugins (xml overwrite)
> create discovery site for testing only that merges latest IS discovery jars with Core discovery jars
> ----------------------------------------------------------------------------------------------------
>
> Key: JBIDE-20664
> URL: https://issues.jboss.org/browse/JBIDE-20664
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: discovery
> Affects Versions: 4.3.0.CR1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.0.CR1
>
>
> Now that IS has published some plugins, we can start aggregating them into the output of the JBT CI buils for discovery.central and discovery.earlyaccess.
> Here's where I found some jars:
> http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta...
> http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta...
> http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta...
> http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta...
> http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta...
> https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov...
> https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov...
> https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov...
> Not sure why there's JBDS IS jars on the JBT server, or why there's no Alpha1a for JBDS. [~pleacu] can you help me know which jars to collect into the JBT / JBDS sites? If you need help doing cleanup of old artifacts, let me know.
> Also, can you change your publishing process so that you're not dumping dozens of old jars into the same folder?
> Have a look here:
> http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta...
> https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov...
> And contrast that with the way the JBT & JBDS discovery jars are done:
> http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-dis...
> https://devstudio.redhat.com/9.0/snapshots/builds/jbosstools-discovery.ce...
> (using rsync.sh, you get automated build folder cleanup every time you publish a new build, or you can force cleanup it with this job [1]).
> [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-cleanup/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months