[JBoss JIRA] (JBDS-3281) Screencasts: Git
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3281?page=com.atlassian.jira.plugin.... ]
Len DiMaggio commented on JBDS-3281:
------------------------------------
+1 on a user moving between multiple branches!
> Screencasts: Git
> ----------------
>
> Key: JBDS-3281
> URL: https://issues.jboss.org/browse/JBDS-3281
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: documentation
> Reporter: Burr Sutter
>
> As a Java EE developer, new to Eclipse + Git, I need educational, 5 minute screencasts on the most common uses of Git inside of Eclipse.
> Use cases include:
> 1) as a new member of the team, just having only installed JBDS, I need to add an element to the project
> assume a clone, add (or modify), commit, push workflow
> a- Getting started as a new member of an existing git project (I need to clone a repo, import the project, insure my facets/Maven are set correctly)
> b- navigate/browse an existing repository
> c- git add - for a newly added class or file
> d- git commit -a
> e- git push
> as a new member of the team, just having only installed JBDS, I need to resolve a pull request.
> 2) other scenarios
> - git init a current project that I have in my workspace (and should I move it outside of my workspace first)
> - git checkout for a specific branch - getting Maven and Eclipse Facets to properly recognize my newly checked out branch
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18678) Make dependencies to org.jboss.tools.usage optional
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18678?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-18678:
-------------------------------------
There's another possibility, but it's a bit of a workaround.
We could have 3 plugins:
1) org.jboss.tools.usage
2) org.jboss.tools.usage.api
3) org.jboss.tools.usage.impl
Plugin 1) would be practically empty, and have two hard dependencies, pulling in both the api and the impl
Plugin 2) Could be used by plugins who want to migrate to JUST api.
So in this case,
- astools/server for example would still depend on org.jboss.tools.usage, which pulls in both api and impl
- cordova / browser sim plugins could make the following changes:
1) depend only on api
2) Update feature.xml to pull in the impl
In this way, our projects can slowly migrate away from a dependency on o.j.t.usage (empty stub with 2 deps) to just the api plugin, and, at the same time, update their feature xml's to drag in the impl.
Package names would not need to be changed for the api, and the o.j.t.usage plugin could simply re-export the api only, but still depend on the impl. This may be a bit confusing, bc to find an api named "org.jboss.tools.usage.SomeClass', they would have to browse to the api plugin. It wouldn't be intuitive, but it *is* a possible solution. Aside from having to know where to find the code, I don't see any problem with this idea.
> Make dependencies to org.jboss.tools.usage optional
> ---------------------------------------------------
>
> Key: JBIDE-18678
> URL: https://issues.jboss.org/browse/JBIDE-18678
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: browsersim, usage
> Affects Versions: 4.2.0.CR1
> Reporter: Kaloyan Raev
> Assignee: Alexey Kazakov
> Fix For: 4.3.x
>
>
> I am interested in adopting the CordovaSim feature in our product. However, most of the browsersim bundles have a strong dependency to org.jboss.tools.usage bundle, which force a Usage Reporting popup on startup. I want to avoid this and have the org.jboss.tools.usage excluded from my build.
> Is it possible to make the dependencies to org.jboss.tools.usage optional?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3284) Ionic Palette - version selection, detection
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3284?page=com.atlassian.jira.plugin.... ]
Len DiMaggio commented on JBDS-3284:
------------------------------------
So - we will have the capability in place to handle multiple versions - before they even have more than one version?
They seem to have older versions still available for download (http://code.ionicframework.com/#) so we should be able to test for this.
> Ionic Palette - version selection, detection
> --------------------------------------------
>
> Key: JBDS-3284
> URL: https://issues.jboss.org/browse/JBDS-3284
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: jsp/jsf/xml/html source editing
> Reporter: Burr Sutter
> Assignee: Alexey Kazakov
> Fix For: 9.0.0.Alpha1
>
>
> As a Cordova-focused hybrid mobile app developer, I need to be able to import existing Ionic projects and modify the version of the Ionic framework, where the Palette is flexible enough to handle version changes, including addition/subtraction of specific widgets only available in particular versions.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3285) Git: Easy Import
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Len DiMaggio edited comment on JBDS-3285 at 1/14/15 3:45 PM:
-------------------------------------------------------------
QE review comment: We need details to be added to this JIRA - What specific changes/improvements will be made?
Burr - Can you specify some sample projects (maven projects, I assume) that cannot be easily imported into JBDS today (with 8.x)? It would have in the testing to have some troublesome projects defined - so we can identify the characteristics that make them troublesome.
was (Author: ldimaggio):
QE review comment: We need details to be added to this JIRA - What specific changes/improvements will be made?
> Git: Easy Import
> ----------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Assignee: Burr Sutter
> Labels: requirements, usability
> Fix For: 9.0.x
>
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3306) Create Deployment from Template
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3306?page=com.atlassian.jira.plugin.... ]
Len DiMaggio commented on JBDS-3306:
------------------------------------
QE review comments:
What are the substeps that are performed to fulfill this step in the use case:
??h) Create a new openshift deployment based on selected template??
> Create Deployment from Template
> -------------------------------
>
> Key: JBDS-3306
> URL: https://issues.jboss.org/browse/JBDS-3306
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Priority: Blocker
>
> Use Case #3
> Create Deployment from Template
> a) Assume OpenShift is started remotely and provides an entrypoint URL
> b) Assume end-user is logged in (ignore auth for now)
> c) Eclipse user will open a dialog and enter the URL from step a
> d) Eclipse user will then be presented with a list of templates from the template library
> (initially a set of files on the local filesystem until openshift has a real template library api)
> e) The template list should allow sorting so that higher priority items are at the top
> We will likely need some form of categorization for templates also
> f) The template list should be searchable by keyword
> g) Eclipse user will select a particular template and
> h) Create a new openshift deployment based on selected template
> i) follow steps JBDS-3297 f through j (clone, import, project facets, etc)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18869) migrate Thym from TP to being an aggregated component
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18869?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-18869:
------------------------------------
I've updated https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-requireme... so that it can now publish from any source URL (defaults to the value in [1], which is [2]) to one of 3 different destination [3] URLs [4], including the builds/staging/JOB_NAME URL [5]:
[1] http://download.jboss.org/jbosstools/updates/requirements/thym/build.xml
[2] http://download.eclipse.org/thym/snapshots/
[3] http://download.jboss.org/jbosstools/updates/integration/luna/core/thym/
[4] http://download.jboss.org/jbosstools/updates/requirements/thym/
[5] http://download.jboss.org/jbosstools/builds/staging/jbosstools-requiremen...
So, now all we need to do is set the default path for the latest Thym to be what's in [3] and the latest version published there will be composited into a site that all downstream users can enjoy.
> migrate Thym from TP to being an aggregated component
> -----------------------------------------------------
>
> Key: JBIDE-18869
> URL: https://issues.jboss.org/browse/JBIDE-18869
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: aerogear-hybrid, build, target-platform, updatesite
> Affects Versions: 4.2.0.Final
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP.
> This would allow it to be incorporated into builds more easily and would avoid TP churn.
> This should be fixed in master then backported for 4.2.2 (or 4.2.3).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-19025) Separate JBT and JBDS Central and EA sites
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19025?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19025:
------------------------------------
Seems a reasonable approach, but with a couple caveats/changes:
* JBIDE-19036 reminds us we have to be careful w/ forge.feature and forge.m2e.feature
* I'm not convinced we need another jbdevstudio-* repo. Rather, why don't we add the discovery site / target platform / update site definitions into jbdevstudio-product, and move the JBT stuff into jbosstools-build-sites ?
> Separate JBT and JBDS Central and EA sites
> ------------------------------------------
>
> Key: JBIDE-19025
> URL: https://issues.jboss.org/browse/JBIDE-19025
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: discovery
> Reporter: Mickael Istria
>
> Currently, we have to repeat (and update very often) some JBT artifacts in the Central .target files because JBDS needs them.
> This adds some long steps to the JBT staging process ( https://github.com/jbdevstudio/jbdevstudio-devdoc/blob/master/release_gui... ), whereas this is a JBDS need.
> So we should split the content of Central/EA update sites for JBT and JBDS, and have them separated in distinct .target files: a Central/EA couple for JBT and another Central/EA couple for JBDS. JBDS only would add the necessary addition that are part of JBT but not part of JBDS.
> Since we're there, it would even be cleaner to have those artifacts in distinct repo, so that JBDS wouldn't leak in JBT.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18869) migrate Thym from TP to being an aggregated component
by Gorkem Ercan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18869?page=com.atlassian.jira.plugi... ]
Gorkem Ercan commented on JBIDE-18869:
--------------------------------------
How close are we to implementing this? Our FH support need a newer Thym to be included in the builds just curious should I wait or send a TP update request?
> migrate Thym from TP to being an aggregated component
> -----------------------------------------------------
>
> Key: JBIDE-18869
> URL: https://issues.jboss.org/browse/JBIDE-18869
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: aerogear-hybrid, build, target-platform, updatesite
> Affects Versions: 4.2.0.Final
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP.
> This would allow it to be incorporated into builds more easily and would avoid TP churn.
> This should be fixed in master then backported for 4.2.2 (or 4.2.3).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months