we are using the spotless plugin within a java multi module maven project and for two modules (and all its sub modules) mvn spotless:check suggests changing the line ending from CRLF to LF on all of our windows machines.
we have the .gitattributes file configured with core.autocrlf=true and the spotless is not configured to handle line endings in another way then default.
For all other modules beside the named two modules it is working perfectly fine, only those two modules are causing troubles. There is nothing (obvious) which is changing the configuration only for those modules. Freshly checked out, all files are encoded as CRLF, so this looks correct to me.
I also checked, that there are no special non-printed characters like described in
Git checking out a specific file only with LF line endings on Windows despite core.autocrlf=true
Does anyone has other hints what could cause this problem (on directory/module base)?
Related
My projects that are programmed in Ubuntu, where VSCode is configured in LF work perfectly.
When I clone on Windows even with the .editorconfig configured only for lf, it modifies the entire code of a file when saving, needing to commit the files again just because it reconfigured the lf.
The problem is that I have already configured editorconfig, vscode, git global to lf and nothing solved, whenever saved it modifies the file.
I use eslint, prettier and editorconfig in the code. I wanted a solution to be able to program on both operating systems.
When installing Git for Windows it asks you how you want to handle this situation (line endings). Usually it gives 3 options. Once you choose one, every time you clone a repo it applies that option.
So, say the repo uses LF and you specified that you want to use CRLF during your Git installation, it will make all the files CRLF.
I am not sure if that option is configurable post install. You can uninstall Git and reinstall it and you'll see that option. From there, if you Unix is your primary development environment I would say choose the option that says "Check out Unix style, commit Unix style".
I attempted to install the Traffic library for the book "A Touch of Class" but was not able to compile the examples. EiffelStudio complained about a base2.ecf file.
Error code: VD00
General configuration parsing error.
What to do: fix the configuration file.
Could not open file: \base2.ecf
$EIFFELBASE2\base2.ecf
base2.ecf is found in where Windows installed Eiffel: C:\Program Files\Eiffel Software\EiffelStudio 18.11 GPL\unstable\library\base2.ecf The offending line of code seems to be this in the Traffic configuration files:
I have attempted to change this configuration file pointing directly to where the file is, using the actual path, to no avail.
Setting the variable EIFFELBASE2 might help:
set "EIFFELBASE2=C:\Program Files\Eiffel Software\EiffelStudio 18.11 GPL\unstable\library"
Then, EiffelStudio should be started from the environment where the variable is set.
(However, I wonder if this is the library to be used with the examples, or if there is another one that comes together with the examples.)
I'm trying to set up a React dev environment, and one instruction I've been given is to enter my directory in Terminal and type this code:
touch .gitignore
The touch command works fine when I'm making a file with a name and extension (e.g. index.html) but since this appears to be only an extension, nothing is happening.
Apparently it's an important file regarding uploading to GitHub - can anyone help?
Update: I created x.gitignore, and then tried deleting the x, and it OSX throws up a dialog saying:
You can’t use a name that begins with a dot “.”, because these names are reserved for the system. Please choose another name.
You can see all of the visible files within a folder by typing
ls
into your terminal (assuming OSX from your comment). However, you will only see a list of the non-hidden files. You can see all files by typing
ls -a
Your .gitignore file basically tells git which folders and files to disregard when packaging everything up to be stored. For example, in ReactJS projects you are probably going to be using a lot of NPM packages and you wouldn't want to include them in your git repository. So, in your .gitignore file, you would include a line that says
node_modules
and then none of the files or folders within node_modules would be included when you push to Github (or Bitbucket or wherever).
If you are having trouble finding the .gitignore file, first run the ls -a and make sure that you see the file listed. After that, if you are having trouble seeing the file in your text editor, you may want to check the preferences in the text editor.
In Atom, you need to unselect "View VCS Ignored Paths" to see the "ignored" files.
type in terminal
npx touch .gitignore
I have a project which has three project files targeting various .net versions (mylib.net20.csproj, mylib.net40.csproj, and mylib.net40-client.csproj). I have a single nuspec file named mylib.nuspec for packaging them all together.
It might help to see the files section of the nuspec file, so here it is:
<files>
<file src="bin\net20\*.dll" target="lib\net20\" />
<file src="bin\net40-client\*.dll" target="lib\net40-client\" />
<file src="bin\net40\*.dll" target="lib\net40\" />
</files>
Right now I use a static version number in the nuspec file and I can successfully package everything by running nuget pack mylib.nuspec. However, I would like to start using $version$ so I don't have to remember to update the version number in two places.
If I simply change the version number to $version$, and build in the same way I get the predictable error:
Attempting to build package from 'mylib.nuspec'.
The replacement token 'version' has no value.
If I use $version$ and package with nuget pack mylib.net40.csproj, it is successful, but I get a package that completely ignores the nuspec file.
Q: What can I do to get the $version$ variable to work?
Technically, I could rename my nuspec file to mylib.net20.nuspec and then package with nuget pack mylib.net20.nuspec. I really don't want to rename my nuspec file in this way though.
creating a package can be done two ways
Using nuspec directly
Using your csproj file , which in fact uses your nuspec file at run time.
First case is pretty straight forward where all metadata defined in nuspec file will be considered for package creation.
nuget pack nuspecfilename.nuspec
On executing above command all hard coded values in your nuspec file will be used for package creation
Above Procedure uses nuspec file directly.
Now let come to your requirement , Using token $version$ in your nuspec files.
In order to work with tokens rather than hard coded values , we need to use csproj file while running nuget pack command.
nuget pack nameofyourprojectfile.csproj -p "configuration=Release;platform=x64"
I'll explain the command i have used ,the concept of using csproj file while generating a package is it will replace all tokens in nuspec file at the run time.
Your corresponding assembly info file to your csproj file will contain required metadata of version which will be replaced at run time.
-p is parameters to be used at run time , here i have assumed that my proj file builds in release and x64 platform so i have passed that at run time so nuget which for artifacts to bundle accordingly.
please refer Here for more details on how to create nuget packages from csproj.
But Ideally when you package from csproj file your nuspec file will be used at run time so ,technically nuspec file should have same name as that of your csproj file.
so requirement of dealing with multiple project files with different frame work may not be achieved with single nuspec file. you need to have individual nuspec accordingly to achieve this.
But if you still want to stick with same nuspec file with out renaming it or making changes to it.
i would suggest passing version at run time
nuget pack nameofnuspec.nuspec -v 1.3.4.5
-v - is version , or you can use -version as well followed by the version of your choice.
after running above command nuget package will be created with the version specified.
to check nuget package created , rename it .zip file and check ...)
I'm getting errors when I attempt to run my project deployed to app engine. I see issues like:
java.lang.ClassNotFoundException: com.seattleglassware.AuthServletSupport$$anonfun$finishOAuth2Dance$1$$anonfun$apply$33$$anonfun$apply$34$$anonfun$apply$37$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42$$anonfun$apply$45$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$49
The class name looks reasonable (well, for certain values of reasonable - this is code generated by the Scala compiler). I see the file in my local web/WEB-INF/classes/com directory and I can decompile it with javap (so I don't think it's corrupt or anything silly like that.) Everything works fine running on a local debug server.
Even more strange, I can pour all the .class files in web/WEB-INF/classes into a jar file like this:
cd to the web/WEB-INF/classes directory
jar cf ../lib/classes.jar .
And now, if I upload the project (pressing the deploy button in Eclipse), I don't see those ClassNotFoundException errors. Delete the jar file, re-upload the project, get the errors again.
I'm wondering if there's some sort of limit on the names of .class files? Or something else happening in the deployment process that's causing this to happen?
EDIT: running from the command line made this much more clear (using maven now):
SEVERE: Invalid character in filename: WEB-INF/classes/com/seattleglassware/AuthServletSupport$$anonfun$finishOAuth2Dance$1$$anonfun$apply$33$$anonfun$apply$34$$anonfun$apply$37$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42$$anonfun$apply$45$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$49.class
But it still looks to me like that's a valid filename.
The inclusion of "special" characters in the file name may be the issue here.
There is currently an open issue regarding "special" characters in project file names.
Issue 2211: Special characters are not supported in the filenames in the project
The original issue was reported by a Python App Engine user, however if you look in the comments you'll see that it apparently affects Java users as well.