[JBoss JIRA] (JBDS-3547) Eloqua tracking of Eloqua tracked links
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3547?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3547:
----------------------------------
Does this change apply to ALL download links, including those referring to content published before Feb 2014? Or just the newer ones?
> Eloqua tracking of Eloqua tracked links
> ---------------------------------------
>
> Key: JBDS-3547
> URL: https://issues.jboss.org/browse/JBDS-3547
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: website
> Affects Versions: 9.0.0.GA
> Reporter: David Hladky
> Assignee: Alexey Kazakov
> Fix For: 7.1.1.GA, 8.0.0.GA, 8.1.0.GA, 8.1.1.GA, 9.0.0.GA, 9.1.0.Beta1
>
>
> I noticed, that all [downloads|http://tools.jboss.org/downloads] have Eloqua tracking link added. This is wrong, because Download Manager also adds Eloqua tracking, so each download goes through the Eloqua twice.
> I also noticed, that "http" is used in the links which should be replaced with "https". Apache does the redirect, but it is one unnecessary redirect in the process.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBIDE-20609) More accessible and visible Early Access content
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20609?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-20609:
----------------------------------------
{quote}The video don't show what happens if I disable earlyaccess - will I still be proposed earlyaccess content when installing ?{quote}
Yes, you get asked about Early-Access or not whenever you have choice between 2 "flavours" of the same connector, independently of whether Early-Access sites are enabled or not.
{quote}Also how does it handle when there is a "non-installable connector" vs "earlyaccess connector" ? {quote}
I need to check this scenario. I'm not sure it's correctly handled with suggested implementation.
What do you think is user expectation in that case?
{quote}Suggestion: don't force users to see the detailed earlyaccess info just to turn it off. Have a checkbox with "Show earlyaccess" and earlyaccess underlined.
Have it on by default (opposite to what we had until now), clicking earlyaccess get you to the detailed dialog for more info and unchecking the checkbox = disable earlyaccess and after that EA won't be suggested to install.
WDYT ?{quote}
Can you give details about the "turn if off" ? For this installation process, it can mean several things (hide EA connectors and/or remove EA sites). The benefit of the dialog is that is comes with some clearer explanation of the action user can perform on EA.
With my proposed change change, instead of dealing with filtering in the viewer, user is facing the choice of regular vs EA in a pop-up only when it makes sense for them. What you suggest seems to remove this popup and to stick with a concept of early-access "state" in the viewer which I believe is not necessary at that time and is more complex than asking the question to user as part of the installation process.
Also, I do not see a reason for hiding Early-Access content when there is no "regular" one.
{quote}On video EA connector installed, but after restart it looks like normal connector was installed not EA.{quote}
It's because in that example, the normal connector is a subset of EA connector. So installing content of EA installs the content of normal and the discovery mechanism assumes that both are installed.
> More accessible and visible Early Access content
> ------------------------------------------------
>
> Key: JBIDE-20609
> URL: https://issues.jboss.org/browse/JBIDE-20609
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: central
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> In order to make early-access content more accessible, we can improve the workflow of making EA connectors visible
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBIDE-20845) Unable to install breakpoint even if line number set to be generated
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20845?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-20845:
---------------------------------------------
How can disable the warning make what Martin see works ?
His issue is not that the warning is shown, it is that even when saying ok to the warning the breakpoint is still not hit.
> Unable to install breakpoint even if line number set to be generated
> --------------------------------------------------------------------
>
> Key: JBIDE-20845
> URL: https://issues.jboss.org/browse/JBIDE-20845
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.3.0.CR2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.x, 4.4.0.Alpha1
>
> Attachments: breakpoint-error.png, compiler-settings.png, lineNumber.png
>
>
> I am unable to get breakpoints to work for a html5 project running on WildFly.
> I tried to verify JBIDE-20804 so I created the html5 project from central, set a breakpoint in MemberService.listAllMembers() (line 72) and then selected Debug on server -> WildFly. The server was started in debugging mode and the project started deploying, but then I got an error:
> Unable to install breakpoint in org.jboss.tools.example.html5.rest.MemberService$$$view3 due to missing line number attributes. Modify compiler options to generate line number attributes.
> Reason: Absent Line Number Information
> !breakpoint-error.png!
> I checked and this option was checked in Preferences -> Java -> Compiler. Also, I even checked the project settings (.settings/org.eclipse.jdt.core.prefs) and it has:
> org.eclipse.jdt.core.compiler.debug.lineNumber=generate
> This happened to me on Mac with WildFly 8, 9 and 10. And psrna checked this for me on Linux and the result was the same.
> I'm not really sure which component this should belong to, it looks like an upstream issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (TOOLSDOC-307) Document OpenShift Drag and Drop functionality
by Supriya Bharadwaj (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-307?page=com.atlassian.jira.plug... ]
Supriya Bharadwaj updated TOOLSDOC-307:
---------------------------------------
Attachment: openshift_importapp.adoc
Hi [~mhusnain], can you please create a PR for this? Thanks - supriya
> Document OpenShift Drag and Drop functionality
> ----------------------------------------------
>
> Key: TOOLSDOC-307
> URL: https://issues.jboss.org/browse/TOOLSDOC-307
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Feature Request
> Components: User Guide
> Affects Versions: 4.1.0
> Reporter: Michelle Murray
> Assignee: Supriya Bharadwaj
> Fix For: 4.2.0.Beta1
>
> Attachments: openshift_importapp.adoc
>
>
> Need to document this:
> Drag and Drop
> http://docs.jboss.org/tools/whatsnew/openshift/openshift-news-2.3.0.Beta1...
> In addition we now also support you to drag any existing deployable artifact such as WTP projects, deployable datasources etc. to the OpenShift server. If these artifacts are not part of the "source" project the server adapter will package them up and place by default inside the /deployments folder of the project. Then when git push occurs these binaries will be part of the deployments on OpenShift for the "source" project.
> This is what we call "binary" deployment and is useful for applications that for any reasons or another cannot be build remotely.
> Note: OpenShift have a storage limit thus storing to many binaries or doing too many binary changes will make you reach this limit faster so be careful.
> http://docs.jboss.org/tools/whatsnew/openshift/openshift-news-2.4.0.Alpha...
> Previously, when a user performed a drag-and-drop action to publish a project it was ignored. In Alpha1 you'll now be able to publishing your project to your OpenShift cloud by drag and dropping your project to the OpenShift server adapter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (TOOLSDOC-307) Document OpenShift Drag and Drop functionality
by Supriya Bharadwaj (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-307?page=com.atlassian.jira.plug... ]
Supriya Bharadwaj commented on TOOLSDOC-307:
--------------------------------------------
> Added the info in the portal version of the doc at: https://access.redhat.com/node/1295883/draft#republishmodifiedapp in section 3 step 1.
> Added info in the community doc
> Requested Misha to create a PR
> Document OpenShift Drag and Drop functionality
> ----------------------------------------------
>
> Key: TOOLSDOC-307
> URL: https://issues.jboss.org/browse/TOOLSDOC-307
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Feature Request
> Components: User Guide
> Affects Versions: 4.1.0
> Reporter: Michelle Murray
> Assignee: Supriya Bharadwaj
> Fix For: 4.2.0.Beta1
>
>
> Need to document this:
> Drag and Drop
> http://docs.jboss.org/tools/whatsnew/openshift/openshift-news-2.3.0.Beta1...
> In addition we now also support you to drag any existing deployable artifact such as WTP projects, deployable datasources etc. to the OpenShift server. If these artifacts are not part of the "source" project the server adapter will package them up and place by default inside the /deployments folder of the project. Then when git push occurs these binaries will be part of the deployments on OpenShift for the "source" project.
> This is what we call "binary" deployment and is useful for applications that for any reasons or another cannot be build remotely.
> Note: OpenShift have a storage limit thus storing to many binaries or doing too many binary changes will make you reach this limit faster so be careful.
> http://docs.jboss.org/tools/whatsnew/openshift/openshift-news-2.4.0.Alpha...
> Previously, when a user performed a drag-and-drop action to publish a project it was ignored. In Alpha1 you'll now be able to publishing your project to your OpenShift cloud by drag and dropping your project to the OpenShift server adapter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (TOOLSDOC-307) Document OpenShift Drag and Drop functionality
by Supriya Bharadwaj (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-307?page=com.atlassian.jira.plug... ]
Supriya Bharadwaj edited comment on TOOLSDOC-307 at 10/26/15 5:22 AM:
----------------------------------------------------------------------
> Checked where can the info be added in the existing artilces for OS2
> Decided on > https://access.redhat.com/articles/1295883#republishmodifiedapp
> Add a note or another sentence in the task (and not in the DYK section since the info will be easily spotted in the task)
> Tried the same steps on OS3 to confirm if the addition must be made in OS3 docs too
was (Author: supriya.bharadwaj):
> Chaecked where can the info be added in the existing artilces for OS2
> Decided on > https://access.redhat.com/articles/1295883#republishmodifiedapp
> Add a note or another sentence in the task (and not in the DYK section since the info will be easily spotted in the task)
> Tried the same steps on OS3 to confirm if the addition must be made in OS3 docs too
> Document OpenShift Drag and Drop functionality
> ----------------------------------------------
>
> Key: TOOLSDOC-307
> URL: https://issues.jboss.org/browse/TOOLSDOC-307
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Feature Request
> Components: User Guide
> Affects Versions: 4.1.0
> Reporter: Michelle Murray
> Assignee: Supriya Bharadwaj
> Fix For: 4.2.0.Beta1
>
>
> Need to document this:
> Drag and Drop
> http://docs.jboss.org/tools/whatsnew/openshift/openshift-news-2.3.0.Beta1...
> In addition we now also support you to drag any existing deployable artifact such as WTP projects, deployable datasources etc. to the OpenShift server. If these artifacts are not part of the "source" project the server adapter will package them up and place by default inside the /deployments folder of the project. Then when git push occurs these binaries will be part of the deployments on OpenShift for the "source" project.
> This is what we call "binary" deployment and is useful for applications that for any reasons or another cannot be build remotely.
> Note: OpenShift have a storage limit thus storing to many binaries or doing too many binary changes will make you reach this limit faster so be careful.
> http://docs.jboss.org/tools/whatsnew/openshift/openshift-news-2.4.0.Alpha...
> Previously, when a user performed a drag-and-drop action to publish a project it was ignored. In Alpha1 you'll now be able to publishing your project to your OpenShift cloud by drag and dropping your project to the OpenShift server adapter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBDS-3547) Eloqua tracking of Eloqua tracked links
by David Hladky (JIRA)
[ https://issues.jboss.org/browse/JBDS-3547?page=com.atlassian.jira.plugin.... ]
David Hladky commented on JBDS-3547:
------------------------------------
It was not always there. The Eloqua tracking was added in February 2014 as an optional feature (the one adding the product downloads was able set Eloqua tracking on per product base). From what I remember the Eloqua tracking was added to all product downloads.
> Eloqua tracking of Eloqua tracked links
> ---------------------------------------
>
> Key: JBDS-3547
> URL: https://issues.jboss.org/browse/JBDS-3547
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: website
> Affects Versions: 9.0.0.GA
> Reporter: David Hladky
> Assignee: Alexey Kazakov
> Fix For: 7.1.1.GA, 8.0.0.GA, 8.1.0.GA, 8.1.1.GA, 9.0.0.GA, 9.1.0.Beta1
>
>
> I noticed, that all [downloads|http://tools.jboss.org/downloads] have Eloqua tracking link added. This is wrong, because Download Manager also adds Eloqua tracking, so each download goes through the Eloqua twice.
> I also noticed, that "http" is used in the links which should be replaced with "https". Apache does the redirect, but it is one unnecessary redirect in the process.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months