Currently CloudBees' default Lift version is 2.4, and this is what you get when using the Lift ClickStart. What's the best way to use Lift 2.5-M1 instead? Create a ClickStart and override the default version, or some other way? Thanks!
The Clickstarts are designed to be "forkable" and updatable - if you want to use a newer lift version - take a look at:
https://github.com/CloudBees-community/lift_template
Fork it, change the pom.xml (as it currently uses the maven build type) ** - to use the appropriate version, and push your changes.
You can then rerun the clickstart via pasting a URL like the following into your browser
https://grandcentral.cloudbees.com/#CB_clickstart=https://raw.github.com/YOUR_GITHUB_ACCOUNT/lift_template/master/clickstart.json
and it will use the newer version. Submit a pull request if you like - so it is up to date for future.
If you have an existing app you created - you can just clone the git repo, update the pom.xml and push it - it will then update your app for you.
Here is a guide on making your own ClickStart: http://wiki.cloudbees.com/bin/view/RUN/How+to+make+your+own+Clickstart
Related
I'm currently ugrading all my projects that use Schemacrawler. The last version I used was 15.06.01 and I'm upgrading to 16.9.4.
A lot of changes were done, I'm looking for the object that replace LintedCatalog.java.
The aim is to get the list of lints detected during a db analaysis.
The project I'm currently working on is : https://github.com/adriens/schemacrawler-additional-command-lints-as-csv.git, if you want to have a look.
Thanks in advance
Michèle,
Instead of code like createLintedCatalog, you could use a lint collector.
Sualeh, SchemaCrawler
I have an Ionic app running with the basics of Ionic and running it in the browser by doing ionic serve, but I want some new stuff and run it trough the grunt serve command, also has the feature for JSLint, I am already using this scss this: https://github.com/diegonetto/generator-ionic/ and I see that have everything I want, how do I install that in my project?
Take into account that my project is almost done, I have almost 85 % already done.
Is this the part I need to follow up:
Upgrading
Make sure you've committed (or backed up) your local changes and install the latest version of the generator via npm install -g generator-ionic, then go ahead and re-run yo ionic inside your project's directory.
The handsome devil is smart enough to figure out what files he is attempting to overwrite and prompts you to choose how you would like to proceed. Select Y for overwriting your Gruntfile.js and bower.json to stay up-to-date with the latest workflow goodies and front-end packages.
does this will bring some complications ? is there something else I need to know ?
I use the same generator and enjoy using it. With that said, I would not recommend starting to use a generator until you've made a complete backup of your project.
Even then, I'd recommend creating a brand new project using the generator then migrating your existing code into the newly generated project. While migrating, you should be modifying your code to match the generator conventions as you go. This gives you the most control and will make sure that you learn the conventions of the new project structure. Upgrading instructions are really meant for people who already use the generator and are just upgrading to a new version of the generator. They are not applicable to you.
We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?
I have try a lot to integrate FOSFacebookBundle in my application, but can't get configure it. May be the gitHub instruction is a bit confusion or something else anyhow:
Where to study and know easily integration of FOSFacebookBundle in symfony 2.0 for the facility of login from facebook..
Fatal error: Call to undefined method Symfony\Bundle\SecurityBundle\DependencyInjection\SecurityExtension::addSecurityListenerFactory() in D:.....\projectName\vendor\bundles\FOS\FacebookBundle\FOSFacebookBundle.php on line 25
The master branch of the FOSFacebookBundle tracks the master branch of Symfony, which is currently for the 2.1 release. Since you're using Symfony 2.0, you need to use the 2.0 branch of the bundle. In your deps file, adjust the version line as follows:
[FOSFacebookBundle]
git=git://github.com/FriendsOfSymfony/FOSFacebookBundle.git
target=/bundles/FOS/FacebookBundle
version=origin/2.0
See the 2.0 branch's README for more details on the repository - follow the detailed installation steps given here.
On my website, in the footer, i want to clearly show which version of the code is live.
I am using git as version control. It would be great to get some visual feedback to know which version is actually live.
I want to show some readable number, like a gem version number. I could create a VERSION file, which i manage and increase every time it is needed.
I am curious if there are any existing solutions already out there? It would be preferable if it could e.g. use tag information from git.
I found a gem that actually does exactly what i need: version.
It allows to manage the version dead-easy, with the needed rake-tasks without the coupling to jeweler, and also allows to tag github in the process.
When developing a gem, i keep using jeweler, but for my rails-projects this is just what i need.
For more info see the gem's documentation.
Jeweler has some rake tasks that handle versioning pretty well for you. I have only used it for gems, but you can probably drop in a VERSION file and use the same rake tasks in a rails app. I have actually been thinking about doing the same thing for my app.. I will update this answer with more details if I get to it soon. For my gems I added a few new rake tasks that combine some of the jeweler tasks. Every time I have a new version I run one of the tasks and it increments the version (major,minor or patch), pushes my code to github and tags it all in one operation:
namespace :version do
desc "create a new version, create tag and push to github"
task :github_and_tag do
Rake::Task['github:release'].invoke
Rake::Task['git:release'].invoke
end
desc "bump patch push to github"
task :patch_release do
Rake::Task['version:bump:patch'].invoke
Rake::Task['version:github_and_tag'].invoke
end
desc "bump minor push to github"
task :minor_release do
Rake::Task['version:bump:minor'].invoke
Rake::Task['version:github_and_tag'].invoke
end
desc "bump major push to github"
task :major_release do
Rake::Task['version:bump:major'].invoke
Rake::Task['version:github_and_tag'].invoke
end
end
get jeweler if you dont have it and create a fake gem, put it on github and play around with the tasks until you get a feel for them. I took me a few tries (and peeks at the source) to fully understand what it was doing.
If you run these tasks every time you have a new version, your VERSION file will be in sync with your github project. If it was me, I would just read in the version number from the file and use something like settingslogic to set up a constant.. or you can set it up in an initializer. That way, you know that every time you restart your app, it will read the correct version