I have CCValidator installed in 3 different locations (servers where CC.NET runs).
The problem that I have is that 2 of them do not recognize CC.NET plugins that I have installed - specifically conditional elements within the .config file. One version of CCValidator works as expected with conditional elements, but the other 2 do not.
The conditional elements are coming into use more and more often. I need to find updates for CCValidator to recognize the plugins I have and use regularly.
I did not install the various instances of CCValidator and can find nothing about downloading the newest version or updates. I have checked several posts that included links that did not lead anywhere that helped.
CruiseControl.net configuration validation tool is provided with ccnet installation. It has the same version as ccnet.
You should not install another version, as it is linked to your ccnet installation. If you have warnings or errors with the validator then :
be sure to use the right CCValidator.exe under the server folder (not inside ccvalidator).
upgrade your ccnet installation. v1.6.xxxx is stable enough and fix many thing from v1.5
For your information, I'm using ccnet v1.5.7385.122 and ccnet v1.6.7991.1 without any plugin error/issue.
Related
Hallo I've failed to bind both versions of a LiteDB library to my project. There's a necessity to consume both versions to access old and new databases from GUI though.
Nothing, I've found on internet, functioned. The project took the newest one, 4.1.5.0 every time. Can You post the abrupts from .csproj and .config files which succeed?
I noticed that runtime version of both versions is identical. Can it be the cause?
I have a shopware installation with the dev template. There is no .git folder so I don´t know which Shopware version or commit was/is used. In the composer.json I have something like this: "shopware/platform": "6.4.x#dev" So I know it was 6.4.x But no minor version or which commit.
My plan is to migrate this to the production template but I want to do a diff (with the original version) and migrate some things into plugins (which where changed in the platform).
Is there an other way to determine the shopware version?
You can find the installed version either in the composer.lock by searching e.g. shopware/administration
"name": "shopware/administration",
"version": "6.4.12.0",
or you can login into the admin interface and in the upper left corner you also find the version.
Or if you don't have a composer installation, the only way to find out will be to compare the existing migration files and other recently changing files and folders unfortunatelly.
https://github.com/shopware/platform/tree/trunk/src/Core/Migration
You can pin the Shopware version to a specific release in the composer.json e.g. by setting it to "shopware/platform": "6.4.13.0". You could then run composer install again but there might be differences in the database structure, changed administration builds and so on. So once you pin the version it might be best to run ./psh.phar install which will do all of that (including the composer install step). You can find all available versions over at Packagist.
I want to know how to apply the issue changes done in the Liferay Issues can be applied in our portal.
For example my issues are cleared in the following links,
https://issues.liferay.com/browse/LPS-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
https://issues.liferay.com/browse/LPS-14220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
I want to apply the issue changed in the above links in my portal.
Please some one help me to achieve this.
Thanks in Advance.
Regards,
Dinesh M K
You have to see the resolution and fix version stated.
the second issue says :
Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1
and that means that the issue was solved in all Portals after version 6.1.0 CE.
the first issue , is no longer reproducible, and duplicate of https://issues.liferay.com/browse/LPS-14220 which is again solved in 6.1.0 CE RC1
In other words, If your portal is older than this version, you can't do anything. You'll have to upgrade to version 6.1.0 RC1 or later
It seems that the fixed-in version is a bit weirdly set in those issues - e.g. LPS-14220 is a subtask of a story in LPS-14414, which is stated as completed for 6.2.0. Careful: I did not fully read through all of the issue's descriptions, links and mix what I read with the answer (and comment to) #yannicuLar gave
Basically, this seems to be a new feature. The way to backport it to your installation is to identify the relevant commits (e.g. download the repository from https://github.com/liferay/liferay-portal or https://github.com/liferay/liferay-plugins, identify the relevant commits (they all contain the LPS number), "backport" them (e.g. see if they can just be applied to your codebase or if they need manual adaptation because the whole code changed.
Some features are easier to backport than others, I can't tell about the complexity for this one.
In order to separate your changes from Liferay's core changes, you should try to implement this in plugins (or patched plugins) rather than changing the original code and recompile. Most likely it's only the kaleo-web plugin that's effected, but if there are core changes, you'd be better of having them isolated in plugins.
The simplest (and most futureproof) possibility is to wait a bit for 6.2 (RCs are already out) and upgrade your portal to this version. If you want to stay on a version that gets updates, you should do this soon anyway.
I'm using NuGet to create a 'web framework' package containing code, master pages, css, javascript, etc.
In an attempt to speed up the build / test process I'm running nuget.exe update packages.config but I've noticed that it behaves differently than the package manager console's Update-Package command.
nuget.exe update seems to leave the previous version of the package still installed, resulting in multiple versions of the package installed. This usually doesn't cause problems but the Package-Manager Get-Package command shows many versions installed and sometimes the project will fail to build.
Update-Package actually uninstalls the package then reinstalls it, this is cleaner but slower
My questions are:
1. Is there documentation about the difference / relationship between these commands
2. Is the nuget.exe update behavior of installing multiple versions a bug?
3. Is there a better method for creating a package in one project and updating it in another project in a fast & automated manner?
Unfortunately, there's not much official guidelines or documentation except from piecing together forum and work item threads.
Current package manager console behavior was first included as a result from discussion in this thread, which later derived in a work item (sorry, apparently not enough rep to post more links).
However, as others already noted, behavior is not consistent with nuget.exe, where there's no such switch.
So, in answer to your questions:
VS Package Manager Console and nuget.exe do have different behaviors and seem to be updated independently (which is very unfortunate).
nuget.exe update behavior of installing multiple versions side-by-side has been a design feature from the start, as you can find from a comment on David Ebbo's blog about NuGet command line (again, I would have given you the link, but SO still doesn't trust me).
Unfortunately I haven't found anything about using package manager console cmdlets during build. What you could try is manually deleting all folders with your packageId on a build event and then packaging and installing using nuget.exe. Essentially replicate what Update-Package does manually, since as David Ebbo says, the way you uninstall a package through the command line interface is by, well, deleting the folder (again, can't post a reference, this is a bit annoying...)
I have beeen looking around for a way to add code highlighting to my Subversion and Apache installation that hosts my local subversion projects. It runs on Fedora Core 10 installed in a VM. I would like to use syntaxhighlighter but I have not idea how i can get Apache to automatically insert the required javascript into my source code files (without tainting the source).
It is possible to modify my existing installation of Apache 2.2/SVN 1.5.5 to use syntaxhighlighter? (this is what it looks like)
There is a project called WebSVN hosted by Collabnet that seems to have something similar built in, however after the trouble I've gone to get the web subversion working (And Fedora configured nicely), I don't want to use OpenCollabnet's version of WebSVN. Plus their version does not support the latest subversion and Apache.
How can I add some form of code highlighting to my Apache that serves the subversion source?
I was using Trac for web-based project management software. It does issue tracking and wiki, but it also provides a repository browser which has syntax coloring. It supports a bunch of different syntax colorers. GNU Enscript, SilverCity, Pygments
Trac is installed, I checked out Enscript, SilverCity and Pygments.
There were no packages for FC10 for the first two, but there was a Pygments package.....it looks rather nice.
Demos here
The C++ highlighting is what i'm interested in, it looks decent: C++ Highlighting
Although Pygments is obviously not as nice as syntaxhighlighter, which I would still prefer to use if someone knows an easy way to setup.