I have created a new Clojure boot-clj project using boot-new. In the 'build.boot' file I see the below line.
[org.clojure/clojure "RELEASE"]
What does the "RELEASE" mean in the above context? And what version that dependency points to? I don't see any files that pass some environment variable or something. If it means "the latest version", won't it cause issues if some backward compatibility breaks?
This is a Maven feature (like all JVM dependency management tools Boot integrates with the Maven infrastructure). RELEASE refers to the latest release (not snapshot) version.
Maven repositories record the latest released version. See for example the metadata for org.clojure/clojure at Maven central, https://repo1.maven.org/maven2/org/clojure/clojure/maven-metadata.xml, at path metadata/versioning/release.
An argument can be made for and against using this. For me, pinning of the version and reproducibility are important, so I avoid this notation.
Related
I made a laucher application in c++ that use direct 2d and 3d. Now i making a installer for this. I followed microsoft docs and i made it but there is a issue.
I use 'Microsoft Visual Studio Installer Projects' extension to make that.
The issue is if i already installed my launcher with a previous installer msi file, if i rebuilt a new installer msi and try to run it it show me this error
This is the microft docs i followed to make this: https://learn.microsoft.com/en-us/cpp/ide/walkthrough-deploying-your-program-cpp?view=msvc-160
In the future maybe i need make a update for my laucher. It isn't good idea everytime need go to control panel, search and delete the previous application and install the new one manually.
Anyone know how can i make it automatic remove old version and install new one? Maybe there is a better way to create a installer?
Major Upgrade: In order to upgrade properly, you need to use a major upgrade so that your new version uninstalls the old one and then installs itself (this can happen in reverse order too: new version installed and old remnants deleted afterwards, but this is another story). There are further upgrade types, but stick to major upgrades for simplicity.
The message you are receiving is basically because you have a different package code for the new MSI, but not a new product code or version number (or just one of those problems). You need to get the settings straight.
Recommended step-by-step:
Set "RemovePreviousVersions" to True in the project properties.
In the same place: bump up your version number (one of the first 3 digits)
Answer yes when asked to change product code, or do so yourself manually.
Keep the UpgradeCode the same - it needs to be stable across releases.
Rebuild your setups. Clean out your box of old remnants before testing or test on a virtual.
Testing: Remember to simulate your full upgrade process from first version installed to the new one with different version numbers for a few core files and also try to add a few files and such things. Very important to verify.
Heads-Up: Before ending, it is standard procedure to warn about the potential limitations of VSInstaller Projects (shorter list form).
MSI Tools: Here is a short "review" of other MSI tools.
MSI Upgrade Types: Shamelessly stolen from the InstallShield help file (towards bottom):
I'm new to Debian packaging and I believe this is a fairly basic question, but I am embarrassed to say I've struck out on Google.
I have a C++ project which builds with CMake and packages a debian with CPack. This project has a service component (systemd style). My goal is to have the service enabled & auto-started upon installation of the package.
My research has yielded two approaches:
1) Run various systemctl commands inside the {pre,post}{inst,rm} scripts in the Debian. Care is required to handle install, remove, and upgrade scenarios properly.
2) Simply put the project.service inside the debian directory and let debhelper (with dh_systemd_enable) handle service installation and start 'automagically'.
Option #2 is obviously preferred because the {pre,post}{inst,rm} is very manual and thus error-prone, but I cannot figure out whether there's a well supported way to leverage debhelper from within CPack.
The Question: I'd like to avoid rewriting the debian packaging stuff in my project's CMake as it's been around for some time and works well. The relationship (if any) between CPackDeb and debhelper is not clear to me -- can CPack take advantage of the dh_systemd_enable features or must I manage the service manually in {pre,post}{inst,rm} scripts?
Hi Fellow Sitecoryians ,
I'm in the process of upgrading a website sitting on Sitecore 7.1 rev140130 webforms to Sitecore 8.2rev160729 MVC-5 / Webforms hybrid. I require to keep the old content running. Because this is just an upgrade of the backend. But plan to start developing in MVC for all new components etc. I will phase out the old web forms as content pages change. This requirement is pushed on me by the business.
The old site used Glass Mapper to generate and map content from sitecore. Using the old Glass.Mapper.Sc.CasteWindsor v3.2.1.21 via t4 scripts in TDS.
I looked over the Glass homepage. Where is states that Glass.Mapper.Sc is all that you require now. But there are conflicting tutorials out there stating you need to install the MVC-4 or MVC-5. I figured I would ignore them for now and stick to the Glass suggested install.
Trouble is that the old Model properties are tagged with attributes like
[SitecoreId] & [SitecoreInfo(SitecoreInfoType.Language)]
Which don't seem to be in the Glass.Mapper.Sc library. The only reference I can find of these attributes in the available nugets packages. Is the Glass.Mapper.Sc.Core package.
I tried to install that package in the models project. Just to see this :
Start package installation to project [project].Logic.Models
Installation failed. Rolling back...
Error: Unable to resolve dependencies. 'Glass.Mapper.Sc.Core 4.2.1.189' is not > compatible with 'Glass.Mapper.Sc 4.3.1.194 constraint: Glass.Mapper.Sc.Core (≥ > 4.3.1.194)'.
Installation finished.
I feel like I might be making a mistake if I down-grade the Glass.Mapper.Sc so I can install the Core library. I might be shooting myself in the foot later on. Because I still have to install WFFM and Social Connection Module being replace with the internal sc8 social components..
My understanding was that the new Glass.Mapper.Sc package should cover all my needs.
So should I down grade and try and use the older version with the Core libraries?
Or should I refactor the models to use a new attribute system. What ever that may be?
(Keep in mind there are around 50+ models in the project. So it's not something that I would like to have to do .. )
Glass Mapper was significantly changed in version 4 and the biggest change was the removal and reliance on Castle Windsor. A list of the changes were listed in the release blog post.
The Nuget package/installer has also been changed so there is now only a single Nuget package instead of the several which you previously had to install. To support this, the Nuget installer checks for the presence of Sitecore.Kernel.dll and System.Web.Mvc:
To make things simpler V4 uses a Powershell script to decided which references to add to your project, it checks both the Sitecore.Kernel version and the System.Web.Mvc version and then installs the appropriate Glass.Mapper.Sc and Glass.Mapper.Sc.Mvc assembly.
My suggestion would be to remove the old V3 assemblies and Nuget references, make sure the above 2 DLLs are correctly referenced in your project(s) and then install Glass V4 Nuget to those projects again.
The SitecoreId and SitecoreInfo attributes are still in the Glass.Mapper.Sc library, the Core library has been removed/refactored. I don't believe this namespace has changed since V3 but make sure you are using the GlassV3Header.tt file and the using Glass.Mapper.Sc.Configuration.Attributes namespace is correct in that file.
https://github.com/HedgehogDevelopment/tds-codegen/blob/master/Sitecore.Master/Code%20Generation%20Templates/GlassV3Header.tt#L32
Is there any way to make maven run ant with a JDK that is defined using maven toolchains plugin?
Why?
I'm testing if I can convert a legacy ant based project to maven based project. Seems parts of it are next to impossible to do with maven so I need to do those with ant. At one point I need to compile using JDK 6 (and it needs to be 6, see e.g. bootstrap class path not set ). Seems maven runs the antrun with the JDK version it is running and toolchains are not taken into consideration (which is ok because the https://maven.apache.org/guides/mini/guide-using-toolchains.html does not display antrun as compatible plugin).
I had maybe a related issue and and least for a subset of Java related Ant tasks the attribute jvm or executable and setting fork=true to set the used JVM might be helpful. I assume the problem in your case might be solved with javac and java. In my example I had to use Java 8 for an older Java program not running with Java 17:
<java classname="com.sun.javacard.converter.Main"
failonerror="true" fork="true"
jvm="${JAVA_8_HOME}/bin/java">
<jvmarg value="-Djc.home=${jc.home}"/>
...
I was going through this tutorial
http://wiki.jetbrains.net/intellij/Getting_started_with_La_Clojure and I got stuck here
http://wiki.jetbrains.net/intellij/Getting_started_with_La_Clojure#Opening_project_in_IntelliJ_IDEA. I don't know way but 'open project' dialog does show the file 'project.clj'. So I'm not able open the clojure project. (And also I don't know how to create new one)
Is this bug of IDEA/La clojure or I did something wrong?
To open/import clj projects, you need to have the Leiningen plugin installed.
Unfortunately, the latest official release of the lein plugin for intellij doesn't work well with Intellij13 (crashed my idea on load every time until removed manually).
I'm guessing that because of Cursive there wasn't a newer release even though the latest version of the plugin on github does work.
I followed the instructions on the lein plugin's git page to create a plugin bundle from the latest version: https://github.com/derkork/intellij-leiningen-plugin
Assuming you're using Intellij13, creating the bundle yourself and then installing it from disk will enable you to open clj project files.