I've a repository containing snapshot artifacts with timestamps.
I want to create an assembly, that contains the dependencies. This works fine. But the artifact names contains the timestamp. So i wonder how to remove the timestamp from filename for the assembly only.
I've used this dependencySet:
<outputFileNameMapping>${artifact.artifactId}-${artifact.version}.${artifact.extension}</outputFileNameMapping>
But version seams to contain already the timestamp. So is there any chance to get a 1.1.1-SNAPSHOT instead of 1.1.1-20100323.071348-182?
I'm using version 2.2-beta-4 of maven-assembly-plugin.
Could you try the following for the outputFileNameMapping:
${artifactId}-${baseVersion}.${extension}
According to issues like MASSEMBLY-67, MASSEMBLY-91:
Using ${baseVersion} for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use ${version} for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.
Update: After feedback from the OP, the exact syntax is (wasn't totally sure of this):
${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}
I faced a similar issue when trying to build a bundle with the assembly plugin which contained a folder with the version number (I'm packaging WSDLs and XSDs).
The workaround I found is quite simple, I put the actual version number in a property (e.g. 1.0), which makes it available in the bundle.xml file for the assembly plugin, and set the pom version's to:
<version>${service.version}-SNAPSHOT</version>
This way the content of my package isn't influenced by the SNAPSHOT marker, in particular it isn't modified when doing the release.
Related
For some projects the standard directory layout module/src/main/scala/com/company/project/module may be an overkill and can be flattened to module/src. I work with the scala language which doesn't force packages to be equal to file paths. IDEA will be unhappy, complain that a package doesn't correspond to a file path, create new classes with wrong packages and so on. To fix that I can specify package prefix for source folders and then it will work fine. However those prefixes are lost on project reimport (from SBT). Can I make IDEA keep them?
sbt-idea plugin has ideaPackagePrefix property. See also the related feature request.
More details can be found here.
I'm looking for a formal definition of version number formats for .NET Core project.json files.
version
Visual studio creates a default version number of "1.0.0-*". I would love for this to mean the * gets updated on successive builds (it doesn't). The build version number is 1.0.0. What does the * mean and what are the legal possibilities?
dependencies
I expected the dependency numbering to follow the nuget versioning rules given that KPM is basically a nuget front-end, but it doesn't appear to support bracket numbering (eg "[1,2)") - I get "not a valid version string" when I try anything other than a blank or x.x-* format.
Outside of the source, does anyone have a link to a formal definition?
I'm not sure what's wrong with looking into the source for a definition. I think that's the most accurate place to search, especially now that vNext is hosted on GitHub.
Looking at the exception described, we're pointed to SemanticVersion.cs.
In the method TryParseInternal, it's fairly obvious why you're running into issues when attempting to declare min/max versions that way. There is simply no handling for [,] or (,) built into that method.
If we look into the regular NuGet version specification, it's obvious that TryParseVersionSpec does have this handling built in.
As for documentation specifying acceptable formats, you'll probably have to wait until it's out of CTP status. If you believe it's an issue, you should document it in GitHub. The contributors are very responsive to these types of issues. Personally I'm not sure if there's a need for setting a maximum version of a dependency when it's deployed with your build.
I want to have these Versions in a format
like this.. {Major}.{Minor}.{Build}.{patch}
how to set this in the assembly info patcher in team city?
so that it will automatically increment the versions for each time it builds...
i want some guidance and help in this...?!?
TeamCity can version assemblies for you with the AssemblyInfo Patcher build feature. To take advantage of this:
Create a build parameter called %Major.Minor%. Set this manually to some value, e.g. 1.0.
On the General Settings tab, set the Build number format to %Major.Minor%.%build.vcs.number%.%build.counter%.
On the Build Steps tabe, scroll to the Additional Build Features at the bottom of the page. Add an Assembly Info Patcher build step. It will default to using the %system.build.number%, which you've defined in step 2.
This will result in all of your assemblies being versioned with the %system.build.number%, which includes the Major and Minor version, the VCS revision, and TeamCity's incremental build number.
Using the File Content Replacer build feature suggested by Paul, we eventually ended up with the following versioning scheme in our project:
http://www.meadow.se/wordpress/generating-semantic-version-build-numbers-in-teamcity/
A little bit complicated to setup but we're happy with the results.
/Emil
Regarding the question from Emil G about keeping the first numbers of the version from AssemblyInfo, it's currently not possible: https://youtrack.jetbrains.com/issue/TW-20475
Would be nice, though.
/Emil Å
It's now possible to be done through the File Content Replacer (available since TeamCity 9.1): https://confluence.jetbrains.com/display/TCD9/File+Content+Replacer
In a POM-file i found a "maven-ear-plugin" configuration that uses "defaultJavaBundleDir", but it seems that "defaultLibBundleDir" is the correct (according to the schema and various documentation).
The Maven POM schema is version 4.0.0.
Is this a remnant from an older version? I couldn't find an explanation for this change, and would like to make sure we are using the correct notation reliably.
In a POM-file i found a "maven-ear-plugin" configuration that uses "defaultJavaBundleDir", but it seems that "defaultLibBundleDir" is the correct (according to the schema and various documentation).
Actually, the configuration element of a plugin can contain anything. So <foo>bar</foo> is valid (and will just be "ignored" by a given plugin if it's an unknown parameter).
Is this a remnant from an older version? I couldn't find an explanation for this change, and would like to make sure we are using the correct notation reliably.
This change has been introduced for the resolution of MEAR-46 as we can read in the (approximative) comment of the svn commit: r471886.
Added defaultLibDir as an alias of defaultJavaBundleDir which is more understable
If you look closer at the diff, you'll see that defaultLibBundleDir is the new name of the parameter and that the old defaultJavaBundleDir is declared as an alias.
So both work, both do the same thing, but only the "new" one is documented in the parameters list of the ear mojo. You can safely change to defaultLibBundleDir and this will make things more clear.
Also worth noting is that the Maven Integration for WTP eclipse plugin (m2e-wtp) only supports the documented defaultLibBundleDir option, not the older defaultJavaBundleDir.
https://github.com/eclipse/m2e.wtp/search?utf8=%E2%9C%93&q=defaultLibBundleDir
https://github.com/eclipse/m2e.wtp/search?utf8=%E2%9C%93&q=defaultJavaBundleDir
I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.
Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?
I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?
Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.
So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.
So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.
(I just added the file to have version information for my c++ dlls).
Why not just fix the errors? On that note, what errors are you getting?
This file provides information such as a version number which is definitely needed in order to use the assembly you have built.