# Cpp plugin: baseName with dots, last part gets truncated

**URL:** <https://discuss.gradle.org/t/cpp-plugin-basename-with-dots-last-part-gets-truncated/13876>\
**Category:** Bugs\
**Created:** [January 18, 2016, 1:02pm UTC](https://discuss.gradle.org/t/cpp-plugin-basename-with-dots-last-part-gets-truncated/13876 "2016-01-18T13:02:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![AndreasFagschlunger](https://avatars.discourse-cdn.com/v4/letter/a/fbc32d/32.png) [@AndreasFagschlunger](https://discuss.gradle.org/u/AndreasFagschlunger)\
**Post date:** [January 18, 2016, 1:02pm UTC](https://discuss.gradle.org/t/cpp-plugin-basename-with-dots-last-part-gets-truncated/13876/1 "2016-01-18T13:02:15Z")

</div>

I’m trying to move my projects from Ant/Ivy to Gradle ([https://github.com/AndreasFagschlunger/O2Xfs](https://github.com/AndreasFagschlunger/O2Xfs)). In some projects I also use JNI, so I take advantage of the native software plugins.

Now the point, I have a hard-coded library name “at.o2xfs.win32.dll”. When I set baseName property to this value:

`components { main(NativeLibrarySpec) { baseName = 'at.o2xfs.win32'`  
The output file is “at.o2xfs.dll” and not “at.o2xfs.win32.dll” as expected, so win32 gets truncated. It seems gradle thinks I added a file extension and overwrites it. The workaround is simple to add a trailing dot. But I consider it a Bug, because it is unexpected behavior.

Best regards,  
Andreas Fagschlunger

---

<div class="post-metadata">

**Author:** ![AndreasFagschlunger](https://avatars.discourse-cdn.com/v4/letter/a/fbc32d/32.png) [@AndreasFagschlunger](https://discuss.gradle.org/u/AndreasFagschlunger)\
**Post date:** [January 23, 2016, 9:43pm UTC](https://discuss.gradle.org/t/cpp-plugin-basename-with-dots-last-part-gets-truncated/13876/2 "2016-01-23T21:43:12Z")

</div>

Just wanted to add some more information, removing baseName and changing the component’s name:

`components { 'at.o2xfs.win32'(NativeLibrarySpec) {`

Has the same effect, build outputs a file named at.o2xfs.dll. Since I moved some Java parts to the software model as well, I can also say that JvmLibrarySpec doesn’t show this behavior:

`at.o2xfs.win32'(JvmLibrarySpec) {`

ends up in a at.o2xfs.win32.jar as expected.