According to this article https://py-pkgs.org/07-releasing-versioning.html, versions in pyproject.toml follow the semantic versioning standarts.
So my file looks like :
[tool.poetry]
name = "my_project"
version = "0.1.0"
description = "..."
...
Wanting to build a pre-release, I wrote 0.1.0-1 as version number.
That should be allowed according to https://semver.org/
But my build is rejected and I have to set 0.1.0.1, which doesn't fit standarts.
Is it a misconfiguration of my Jenkins project or another third party tool, or 0.1.0.1 is indeed the intended way to write versions
Related
The following command used to work flawlessly:
C:\tools\apache-cxf-3.3.1\bin\wsdl2java -client -d generated foo.wsdl
It no longer works with the latest version of JDK - 12. I have downloaded the latest version of Apache CXF, and still get the same error:
-Djava.endorsed.dirs=C:\tools\apache-cxf-3.3.1\bin\..\lib\endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Could anyone offer a tip on how to remedy this?
I got the Apache CXF 3.3.1 wsdl2java utility to work with the latest OpenJDK 11 by doing 4 things:
Pull down this jar and place it into the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.jws/jsr181-api/1.0-MR1
Pull down this jar and also place it in the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.xml.ws/jaxws-api/2.3.1
In my case, since I'm running on a Mac, I vi'd the wsdl2java script and made sure these two jars are explicitly being set on the CXF classpath, by doing the following declaration within the script right before the execution of the java command:cxf_classpath=${cxf_classpath}:../lib/jaxws-api-2.3.1.jar:../lib/jsr181-api-1.0-MR1.jar
Lastly, I removed the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' parameter from the java command at the end of the script, since newer JDKs no longer support this argument, so my command now looks like this:$JAVA_HOME/bin/java -Xmx${JAVA_MAX_MEM} -cp "${cxf_classpath}" -Djava.util.logging.config.file=$log_config org.apache.cxf.tools.wsdlto.WSDLToJava "$#"
Now, using OpenJDK11, I'm able to point to an external WSDL file and successfully generate the client code I need to consume this SOAP service with the following command:
./wsdl2java -client -d src https://somewhere.com/service\?wsdl
Whether or not this all works yet is TBD in terms of being able to call and consume the SOAP service I'm coding against, but I've at least now overcome the Java9+ support issue with this tool specific to generating client code from a WSDL.
If your needs are different, I would at least remove the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' JVM parameter and start calling the wsd2java command with the parameters you need set and just start iteratively adding back in the missing libs it starts throwing java.lang.NoClassDefFoundError errors for.
Their FAQ specifically says starting in 3.3.x, Java 9+ will be supported but something clearly dropped the ball between the no-longer-supported hardcoded JVM arguments still being passed in the utility and the missing libraries to support the newer JDKs where these legacy libs have been removed.
Hope this helps someone out there unfortunate enough to ALSO still be programming against SOAP endpoints but trying to at least keep the client-side code you're writing up to date and taking advantage of the newer features of the modern JDK.
With a .NET Framework library you could specify a version with a wildcard and NUGET pack command would append the build date and version automatically when running a NUGET Build Task in VSTS.
[assembly: AssemblyVersion("1.0.*")]
NUGET PACK would generate a NUPKG file with a version like 1.0.6604.1234 appending the date number and a build ID.
NET Standard issues
In .NET Core and .NET standard the new .csproj format does not support this wildcard format.
We can't package with Nuget.exe (reason: this issue) but we can use dotnet pack except I need to auto-increment the build numbers. The dotnet Build Task in VSTS allows me to wholly replace the version number, but I want to retain the version in the csproj file, and just append a build number (as I used to).
I found that using <VersionPrefix>x.y</VersionPrefix> in the csproj file would work with nuget pack and I could then add the additional parameter VersionSuffix=$(Build.BuildNumber) to the pack task.
All looked good until the first dev updated the project version in the project properties dialog. Visual Studio ignored the VersionPrefix and set the <Version> tag - and the build number fix is ignored because a Version tag exists.
Is there a way to read the Version from the csproj? If so I could set the build property to Version=$(ProjectVersion).$(Build.BuildNumber) ?
Or are there alternative ways to handle auto-incrementing the build version when packaging?
First you can select Use an environment variable for Automatic package versioning, use your defined variable such as temp ($(build.buildNumber)) as Environment variable.
More details take a look at this link: Dotnet pack automatic package versioning build number clarification
Another way is using the "arguments" field in the dotnet CLI task, you can pass additional arguments to the dotnet cli.
Using --version-suffix $(Build.BuildNumber) will pass the build
number as version suffix. Make sure you don't have a <version>
element set in your csproj, but rather a <versionprefix> element.
The built version will look like versionprefix-versionsuffix, so for
example, if you have <versionprefix>1.2.3</versionprefix> and build
number 201805002, the built version will be 1.2.3-201805002. In this case do not select the automatic package versioning.
Thanks to #patricklu-msft for his suggestions.
There is it appears no built-in way to emulate the wildcard behaviour we previously had NUGET pack with dotnet pack, nor was there way to get the <Version> tag out of the project file.
So I've created a new VSTS Build task that does this: VersionTaskReader in the MarketPlace.
This extension can be pointed to a .csproj or .vbproj and will set an environment variable VERSION, and VERSION_BUILD which has the BUILDID appended. You can optionally add a prefix to make each instance different if needed.
For example, if your project contains <Version>1.1</Version> then the VERSION_BUILD would be something like 1.1.8680
Then the dotnet pack task can use the environment variable VERSION_BUILD in the versioning options screen, so that the build number automatically increments.
I want to compare values from two different files.
In Notepad++ version 5.0.3 we had shortcut button Alt+d but in version 6.6.8 I cannot find any option to compare.
Also let me know which version is most stable.
There is the "Compare" plugin. You can install it via Plugins > Plugin Manager.
Alternatively you can install a specialized file compare software like WinMerge.
Update:
for Notepad++ 7.5 and above use Compare v2.0.0
for Notepad++ 7.7 and above use Compare v2.0.0 for Notepad++ 7.7, if you need to install manually follow the description below, otherwise use "Plugin Admin".
I use Compare plugin 2 for notepad++ 7.5 and newer versions. Notepad++ 7.5 and newer versions does not have plugin manager. You have to download and install plugins manually. And YES it matters if you use 64bit or 32bit (86x).
So Keep in mind, if you use 64 bit version of Notepad++, you should also use 64 bit version of plugin, and the same valid for 32bit.
I wrote a guideline how to install it:
Start your Notepad++ as administrator mode.
Press F1 to find out if your Notepad++ is 64bit or 32bit (86x), hence you need to download the correct plugin version. Download Compare-plugin 2.
Unzip Compare-plugin in temporary folder.
Import plugin from the temporary folder.
The plugin should appear under Plugins menu.
Note:
It is also possible to drag and drop the plugin .dll file
directly in plugin folder.
64bit: %programfiles%\Notepad++\plugins
32bit: %programfiles(x86)%\Notepad++\plugins
Update
Thanks to #TylerH with this update: Notepad++ Now has "Plugin Admin" as a replacement for the old Plugin Manager. But this method (answer) is still valid for adding plugins manually for almost any Notepad++ plugins.
Disclaimer: the link of this guideline refer to my personal web site.
I give the answer because I need to compare 2 files in notepad++ and there is no option available.
So first enable the plugin manager as asked by question here, Then follow this step to compare 2 files which is free in this software.
1.open notepad++, go to
Plugin -> Plugin Manager -> Show Plugin Manager
2.Show the available plugin list, choose Compare and Install
3.Restart Notepad++.
http://www.technicaloverload.com/compare-two-files-using-notepad/
Alternatively, you can install "SourceForge Notepad++ Compare Plugin 1.5.6".
It provides compare functionality between two files and show the differences between two files.
Link to refer : https://sourceforge.net/projects/npp-compare/files/1.5.6/
Update (2022-09-22): use the ComparePlus plug-in, and not the outdated Compare plug-in.
Demo:
Open 2 files side-by-side
Plug-ins -> ComparePlus -> Compare:
Features:
The Compare plug-in is no longer maintained:
Compare plugin will not be supported anymore (at least by me) because I consider it obsolete and because (as Peter Jones said) I am working on another plugin - ComparePlus that is Compare plugin’s successor.
For example, the Compare plug-in doesn't show the compared text clearly with dark mode:
2018 10 25. Update.
Notepad++ 7.5.8 does not have plugin manager by default. You have to download plugins manually.
Keep in mind, if you use 64 bit version of Notepad++, you should also use 64 bit version of plugin. I had a similar issue here.
If you installed Notepad++ with the Plugin Manager then its easy: open notepad++, go to
Plugin -> Plugin Manager -> Show Plugin Manager and then search/install the Plugin „compare“. Restart Notepad++
Tutorial:
https://youtu.be/8ESbIZbXI7I
If you do not have installed the Plugin Manager:
download the plugin manually :
https://github.com/pnedev/compare-plugin/releases/tag/v2.0.0_npp7.7
-Copy the contents of the zip file into Notepad++'s plugins installation folder (%Notepad++_program_folder%\Plugins). use the correct archive version based on your Notepad++ architecture - x86 or x64.
restart Notepad++
If you are looking for the latest release of Compare, here it is:
https://github.com/pnedev/compare-plugin/releases/latest
After adding Catel implementation to one of my views(mainPage) in my project I have a bug that crashes my Silverlight project. The only indication I have is :" A first chance exception of type 'System.NullReferenceException' occurred in Catel.MVVM " (just about after setting the RootVisual~) - I can't find what I'm doing wrong, and since I am planing on a long-term relationship with Catel I thought that stepping through Catel code might come in handy, so I tried and failed in all the following steps (any help will be appreciated.. because currently I'm stuck and can't find anything):
downloaded catel 3.9 source files (same as my nuget package) and tried building it.. failed with this error :
E:\Dev\Catel-3.9.0\src\Catel.Core\Catel.Core.SL5\Fody.targets(51,5): error MSB4036: The "Fody.WeavingTask" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with in the project file, or in the *.tasks files located in the "E:\WINDOWS\Microsoft.NET\Framework\v4.0.30319" directory. - trying to search and figure the reasons and overcome this, lead me to nowhere. :(
i have followed this "Stepping through the code" instruction in Catel documentation but noting really happened (I'm using VS2010..is this an issue ?? )
I read this article & readme.md at : https://github.com/GeertvanHorrik/GitHubLink about using GitHubLink to help you stepping through Catel code while debugging. I downloaded the release GitHubLink 1.3.0 from https://github.com/GeertvanHorrik/GitHubLink/releases/tag/1.3.0 ... but running this even with just the githublink.exe -help flag had thrown a exception..
I downloaded the Githublink-master source files but 0 projects were loaded (the GithubLink project file is incompatible with the current version of VS - I'm using VS2010)
can anyone help me either shade some light or:
overcome the build error I receive for catel (no.1)
instruct me how to set & step into catel ?
share the pdb files for Catel libs
It completely depends on the version you are using. If you are using the latest official one (3.9), stepping through the code is only possible by cloning the master branch and building the PDB files yourself.
In the latest prerelease versions via NuGet (the upcoming 4.0 version) you only have to enable the source server checkbox.
Note that you should never have to use GitHubLink yourself, that is for developers only (we run it during the build of Catel).
About the Fody task: it looks like the NuGet packages have not yet been restored on your side. In the lib folder there is a RestorePackages.bat which you can run to restore the packages.
I tried debugging on VS2012 and using Catel 4 pre-release (from Nuget)..
although I believe I did all the right things & settings in VS, I didnt get much further..
So I Opened (using a bin editor) the pdb file that was pulled by Nuget with the DLL, and took a look at the bin file.
the file have strings pointing to the source files at this directory :
C:\ci_ws\WS\1629\source\catel\src\catel/mvvm\catel.mvvm.shared..
So I have created a tree that starts with
c:\ci_ws\ws\1629\source
and downloaded the catel folder to that dir, renamed it from
"Catel-Develop" to just "Catel" in order to feet the location the pdb pointed.
To get things going I also had to add a "Symbol File(.pdb) location" in VS
option-> settings->Debugging->Symbols..(location/server list) to where the nuget download the packages.
in my case.. SolutionFolder\Packages\Catel.MVVM.3.9.0.1406062245-beta\lib\sl50..(I'm using Silverlight)
and then I was able to load the symbols and step/break into the code successfully ..
Maybe I missing something and there is a better way, but this the only way that worked for me..
The only question that still remains for me now is : What is the name of the Catel Github source branch that is matching the pre-release dll and pdb that Nuget is publishing at the moment (3.9.0.1406062245) ?
(I unchecked the general debug settings of : require source files to exactly match the original version)
Ref:
Nuget Versioning
SemVer
The nuget versioning documentation reads:
SemVer also introduces the concept of a build number for those creating daily or continous builds. This is not supported in the public NuGet.org gallery.
It says it's not supported in nuget.org gallery but i'm wondering specifically how nuget.exe -update or -install or the Package Console in VS handles it...
Take a look at SemanticVersion.cs in the Nuget codebase. This provides the following regex to validate the provided version. If the regex doesn't match, the version is invalid:
new Regex(#"^(?<Version>\d+(\s*\.\s*\d+){0,3})(?<Release>-[a-z][0-9a-z-]*)?$",
RegexOptions.Compiled
| RegexOptions.IgnoreCase
| RegexOptions.ExplicitCapture);
The format for the prerelease string strictly has to start with a dash, then a letter, then any combination of dashes and alphanumerics. No + or . allowed.
Try and pack with anything other than a valid version and you will get:
Attempting to build package from 'ConsoleApplication1.csproj.nuspec'.
'1.0.1+421.500' is not a valid version string.
Parameter name: version
If you've somehow got a package with an invalid version, then the nuget packaging process must have been bypassed and I can only assume attempting to push it will have unpredictable results.