how to create a project from a template within youtrack with external hub integration? - youtrack

I am experimenting with latest hub and youtrack on a linux machine,
I installed latest versions (2019.2 and 2019.1 respectively) and enabled the hub integration in youtrack. (not using https for the moment, old plain http is used)
What happened is this:
When I try to create a project i am always switched to Hub (is this correct? i did not find anything on JetBrains docs)
If I create a project from the hub interface and then click on the left panel to add a "Youtrack service" then i am offered the option to create only "default, scrum and kanban" projects that are the standard ones provided by JetBRains, however if i had already created a project and saved as template that project is not offered to me as an option to be the base of the new one.
If i use youtrack with the internal hub, all works as expected and the template projects are available as a starting point for new projects.
This happens as well with older versions (2018.4) of hub and youtrack.

As far as I recall this is bug in Hub yet to be fixed.
It seems correct, as with an external Hub installed projects are always created from there
2-3. There's known issue with that: https://youtrack.jetbrains.com/issue/JPS-9928

Related

Does Opendaylight still have a UI

I try to get the web interface of OpenDaylight controller (Magnesium Version).
But I cannot install the features odl-restconf odl-l2switch-switch odl-mdsal-apidocs odl-dlux-all
A web interface is still available in ODL controller?
This question comes up periodically. the DLUX GUI project as well as
the spanning-tree l2switch project are no longer maintained or part of
an OpenDaylight release. You can try an older version of OpenDaylight. Or,
if you are the developer type, you can try to bring DLUX and/or l2switch
up to speed with the current ODL project and possibly get it to build and
install.

I want virtocommerce in my own local repository.(include storefront, platform and modules). How to setup all of these in my solutions?

I want virtocommerce in my own local repository.
storefront is a solution that will configure it according to the following link:
Storefront Source Code Getting Started
And it works.
But I want to have a solution For platforms and modules,
Like the link below:
vc-integrations
But I need the platform and modules to be connected to the github for the latest changes.
I've studied the link below:
Source Code Getting Started
but I do not understand how should I configure for my goals (one solution for platfrom and modules and fork, clone ,upstream for all for get latest versions of them)
We've used to have a single repository and single solution for Virto Commerce Manager and modules (vc-integrations). It was difficult to maintain and release often. That's why the single repository was split into many "1 module per repository" pieces.
We consider that in most cases having only Virto Commerce Manager configured should be sufficient. What's your scenario? Check "Manual module installation from source code" section in Source Code Getting Started to get started.

Unable to set up jquery mobile project with worklight 6.1

I am unable to set-up a IBM Worklight project involving jquery-mobile. Here are my environment details:
eclipse Version: Juno Service Release 2 (32-bit version since I am using jre1.6.0_41)
Worklight version: 6.1.0.01
jquery-mobile: 1.3.1
I can create a new worklight project (called MyLab1) and associate jquery-mobile CSS and JS files to it. However the problems are:
The default .html file gets created as index.html (under 'apps->MyLab1->common') while my expectation is it should be MyLab1.html (as per the training material I have from IBM Worklight)
The 'Mobile Navigation' pane is completely blank while my expectation (again as per training material) is I will see a 'page(default)' control there
Whenever I try to create a new control (under 'Mobile Navigation' pane) I get the error 'Mobile Navigation controls cannot be added to the current page. This feature is only enabled for projects which have jQuery Mobile or Dojo mobile available'
I do not see any option (under eclipse menu) to start or stop Worklight sever (that comes with Developer studio version)
I am fairly new to Mobile application development space (just started with IBM worklight set up this week) and given the above issues I believe I may be doing something fundamentally wrong.
Starting Worklight 6.1, it is very much expected for a new application filenames' to be main.js, main.css and index.html.
Additionally, while you can do the adding of jQuery Mobile by yourself, you should instead use the wizard Worklight Studio provides for you.
This way not only will the files you choose be added properly to your project, but the HTML file will be updated accordingly as well (HEAD references, initial jQuery Mobile template in the body element).
The Palette view should then also list the relevant jQuery Mobile widgets you can use in your app.
Please follow the Worklight 6.1 training modules if you intend on using Worklight 6.1.
My impression is that you are reading the Worklight 5.0.x training modules.
To start or stop the Worklight Server, you need to open the Servers view and click either the play or stop buttons.
Use the keyboard shortcut Ctrl+3 and write "server".
Everything works: http://i.stack.imgur.com/K1G8O.png
I found the solution after trying out a few things. It turned out that WL-6.1.x doesn't work well with JRE 6 (32 bit) and eclipse Juno (32 bit) combination. Once I switched to JRE7/Juno-64 bit; things apparently started to work (for now at least).
Thanks Idan for your helpful comments

IBM Worklight 6.0 - Dojo library uses localhost after deploy

I have a Worklight 6.0 project that uses the new Dojo 1.9 libs, I created an external dojo project, like the documentation suggested, then, in the main project properties, under "Dojo toolkit", it references this dojo19 project.
The project works on the local server, then I did "Run As" | "Build for Remote Server...", and entered the correct domain:port and context path, clicked Build, the *.wlapp files were updated. (I've also updated the settings for publicWorkLightHostname / publicWorkLightPort / publicWorkLightProtocol in the "Environment Entries for Web Modules" in the installed war to match the remote server names/port/protocol.)
But, after deploying both war and -all.wlapp file, accessing the app I get JS errors when it tries to refer to the dojo19 library:
The page at
https://<myIP>:9443/<myproject>/apps/services/www/ /mobilewebapp/default/IODMobile.html
ran insecure content from http://localhost:64441/dojo19/<myproject>/IODMobile/mobilewebapp/dojo/nls/core-web-layer_en-us.js.
The dojo19 is the project name in my Worklight developer workspace that I referred to above.
Why is it trying localhost? Seems there's a missing step here in deploying the dojo library project into Worklight.
Where are you trying to preview the application when you get the error message?
See the changes in Dojo in Worklight 6.0
If launching the application in emulator/simulator/device, see Billy Rowe's answer in this question
Partial copy/paste:
Step 1: Verify your application works in the Mobile Browser Simulator
with Provide Library Resources checked. If the Console log is showing
resources being served from the server, then these have to be copied
to your application before deploying to AVD or a device
Step 2: After you think you have all Dojo/resources within your
project, uncheck Provide Library Resources and test it again in MBS.
If it fails in MBS, then something is missing in your application that
is in the library/server. You can check Provide Library Resources and
retest to see if it shows you what that is. Not all resources are
shown, e.g. if there's a missing CSS file.
Also I would suggest to do all of this in the Development environment (that is, in Eclipse) before starting to deploy the .war file and .wlapp file etc... (which, BTW, I hope you're doing based on the new instructions for Worklight 6.0)
In the information center, it will show you how to uncheck the Provide Library Resources in the Console Log.
I think what you're running into is:
1) Something is being served from the Dojo Library/Server
2) A bug in 6.0 that used "localhost" instead of the IP of the host (your machine running eclipse). This is fixed in the 6.0 iFix. With this fix, you can run your app external to Studio and still use the Dojo Library/Server. Without this fix, you must have everything you need within your app.
Can you install the iFix and let us know if that fixed the problem?

How do you distribute the IDE and it's configuration within your Team?

I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.