After moving files in and out because I wasn't sure of the structure IntelliJ is just going absolutly mental on me:
My class is situated in main.java.entities.FailedAttempt
Scenario 1
import main.entities.FailedAttempt;
Here it says entities is not found (which is correct) yet it finds the class
Scenario 2
import main.java.entities.FailedAttempt;
Here it finds the import of entities (it should not) but doesn't find the class!
Scenario 3
import main.java.entities.*;
...
private List<FailedAttempt> faList = new ArrayList<FailedAttempt>();
Here the import is correct - no error message - but it's unused and private List<FailedAttempt> cannot be resolved.
What I did:
The package was originally named main.java which contained a bunch of other packages. I renamed it to main, then created another java package in it and put all the other class in that java package. Resulting in exactly what I had at the beggining.. Except for the imports which are totally messed up.
Can I somehow resolve this ? I've a feeling I'll have to manually change the class names, invalidate cache, delete project and reimport the folder into intelliJ. But if there is a better method I'm all for it.
I created an issue on their tracker
Use this icon:
to open the project structure and set it up structure using Project Settings -> Modules under Sources:
Last, you should check, that everything is exported. You can do that under Artifacts.
Hope that helps.
Had to close the project, Import a new project from an earlier git version and work from there. If someone has this in the future and doesn't use cvs I think it's gonna be annoying.
Related
I have a simple program written in Golang. It's an API. So inside the project folder, there's a folder named cmd containing my main package (used to initialise the app and defines the endpoints for the API). There's also a folder named after my program, containing multiple files from a package also named after my program. This package serves as the model to do all the necessary queries and contains all the types I have defined.
I also created a folder called test. It contains all my test files under the package named test. The problem is that to run the tests, I have to access my main package ! Is there a way to do that in Golang ? I tried simply using import "cmd/main" but of course it doesn't work.
I also had an idea. Perhaps I could move all my initialising functions (in the cmd folder) to the package named after my program. This way I could do a regular import in test. And I create, inside of cmd, a main.go in the main package that serves as the entry point for the compiler.
I'm new to Go so I'm not really confident. Do you think it's the right way ?
Thanks.
EDIT : Apparently some people think this question is a duplicate, but it's not. Here's the explanation I gave in on of the comments :
I read this post before posting, but it didn't answer my question
because in that post the person has his tests in the main package. The
reason why I asked my question is because I don't want to have my
tests in the main package. I'd rather have them all in a test folder
inside the same package.
What you want to do is not not possible in GO (assuming you want to test private functions).
because I don't want to have my tests in the main package. I'd rather
have them all in a test folder inside the same package.
Your code belongs to different package if you move it into different folder.
This is how GO defines packages https://golang.org/doc/code.html#Organization:
Each package consists of one or more Go source files in a single
directory.
This is how your code structured:
main
| -- main.go (package main)
+ -- test
| -- main_test.go (package test)
It is idiomatic to keep tests in the same folder with code. It is normal if language or framework set some rules that developer has to follow. GO is pretty strict about that.
This is how you can organize your code:
main
| -- main.go (package main)
| -- main_test.go (package main_test)
| -- main_private_test.go (package main)
Often it makes sense to test code against its pubic interfaces. The best way to do that that, is to put tests into different package. GO convention is to keep tests in the same folder what leads to using the same package name. There is a workaround for that issue. You can add _test (package main_test) prefix to package name for your tests.
If, that is not possible to test your code using public interfaces, you can add another file with tests and use package main in that file.
package com.yada.yada
What happens with IntelliJ when I create Java class 'ss' in com.yada.yada without package statement? - RED "Missing Package Statement".
What happens when I create Kotlin file in com.yada.yada without package statement? - "Keep going bro until your DI framework will fail to scan your deps during runtime"
Why IJ package validation is non-mandatory for Kotlin? I just wasted an hour trying to figure out what's wrong with package scan only to realise this was the show stopper. Would Java 9 jigsaw quadruple the chaos for Kotlin sparked by such malformed files/classes with no warning messages? Well, you bet it will!
Please return back the "warning" statement for Kotlin. P.S. registration/login methods are not sufficient for myself to access Intellij bugtracker(and I am genuinely pissed off with one time access password resets, 1000 resources and 980 passwords I don't remember or care to) therefore making this public on stackoverflow.
If anybody going to defend this behaviour please explain why? Maybe I am missing something, otherwise please reply with open bug(preferably somebody from JetBrains) and I will accept it.
The missing inspection warning for files with no package statement is a bug; the corresponding YouTrack issue is here.
I'm not sure this post is appropriate here, but to answer the actual question, the official documentation states that:
If the package is not specified, the contents of such a file belong to
"default" package that has no name.
Since with Kotlin your files don't have to be in folders that match their packages, not having a package declaration has to be an option so that you can have files that are organized in folders, but you don't wish to put them in packages - this way they can have the same package as if they weren't nested in any folders, and were just in the root of the project.
I do concede that it's a bit odd there is a warning for your package declaration not matching the folder your file is in, but you don't get this if you just omit the package declaration altogether. I suppose this is assumed to be intentional.
This shouldn't generally be a problem because IDEs will generate the appropriate package declaration for the folder you've created your file in by default. I'm not sure how you created a file without a package declaration if you're using IntelliJ, unless you did it in the root src folder instead of inside a package folder.
I am using Xcode 4.6.2 and i believe i am facing circular import issue in my project which i am unable to troubleshoot. Due to which i am not able to access few methods from another class using the class method. See my earlier question here.
Although i am using #class instead of #import in my header files, still i am unable to fine where exactly the problem is. Members of the StackOverflow have suggested me to use Xcode's built in functionality found under Product > Generate Output > Preprocessed File.
I have used this functionality and it generated a file that is too long to follow and i don't know what to do with it.
I have tried searching how to use it to troubleshoot the issue but couldn't find much help. Can anyone help me point out how to use "Preprocessed File" to troubleshoot my issue. Thanks!
I also went through your earlier question you have mentioned inside the question. You have said that you are using #class instead of #import in your header files, the methods that you are trying to access are declared in the header files and there are no typos of any kind.
In such cases, usually no body points this issue but i am going to do it anyway because i have faced such issues many times. You have probably created many copies of your project to work on each functionality and also keeping a working project.
When you do this, sometimes Xcode is still using the older copies of few files. That means it is still using the older copy of the TheFeedStore.h when the methods you are trying to access were not declared by you.
How to solve this problem is very simple. Go to the file from which you are trying to access the methods and the files in which these methods are declared.
In the Utilities section on the right hand side, check the location and full path under "Identity and Type" area.
First check the names of the project, if it is different from the project name that you are working on, that means Xcode is still pulling the old copies of the files from the previous revision of your project. See the blue arrows where the project name is 13SampleMoreRequests in my case.
If this name is same as your project name, then my answer does not solve your problem. If its different, you should use the new copies of the file by browsing the new location using the sign that is pointed out by red arrow.
Once you browse and use the new files, your problem will be solved and you will be able to access the methods. If you still can't, copy these files, delete from the project and then add them again and you won't face this problem.
Hope this helps!
Not having come from a C/compiled languages background, I'm finding it hard to get to grips with using Go's packages mechanism to create modular code.
In Python, to import a module and get access to it's functions and whatnot, it's a simple case of
import foo
where foo.py is the name of the module you want to import in the same directory. Otherwise you can add an empty __init__.py into a subfolder and access the modules via
from subfolder import foo
You can then access functions by simply referencing them through the module name, e.g. y = foo.bar(y). This makes it easy to separate logical pieces of code from one another.
In Go however, you specify the package name in the source file itself, e.g.
package foo
at the top of the 'foo' module, which you can then supposedly import through
import (
"foo"
)
and then refer to it through that, i.e. y := foo.Bar(x) . But what I can't wrap my head around is how this works in practice. The relevant docs on golang.org seem terse, and directed to people with more (any) experience using makefiles and compilers.
Can someone please clearly explain how you are meant to modularise your code in Go, the right project structure to do so, and how the compilation process works?
Wiki answer, please feel free to add/edit.
Modularization
Multiple files in the same package
This is just what it sounds like. A bunch of files in the same directory that all start with the same package <name> directive means that they are treated as one big set of code by Go. You can transparently call functions in a.go from b.go. This is mostly for the benefit of code organization.
A fictional example would be a "blog" package might be laid out with blog.go (the main file), entry.go, and server.go. It's up to you. While you could write a blog package in one big file, that tends to affect readability.
Multiple packages
The standard library is done this way. Basically you create modules and optionally install them into $GOROOT. Any program you write can import "<name>" and then call <name>.someFunction()
In practice any standalone or shared components should be compiled into packages. Back to the blog package above, If you wanted to add a news feed, you could refactor server.go into a package. Then both blog.go and news.go would both import "server".
Compilation
I currently use gomake with Makefiles. The Go installation comes with some great include files for make that simplify the creation of a package or a command. It's not hard and the best way to get up to speed with these is to just look at sample makefiles from open source projects and read "How to Write Go Code".
In addition to the package organisation, Like pip in python, use dep https://github.com/golang/dep for go package management. if you use it on existing go package it will automatically build the dependency tree with versions for all the packages being used. when shifting to production server, dep ensure will use Gopkg.toml to install all the required packages.
Just use dep ensure -add , other commands for dep are:
Commands:
init Set up a new Go project, or migrate an existing one
status Report the status of the project's dependencies
ensure Ensure a dependency is safely vendored in the project
version Show the dep version information
check Check if imports, Gopkg.toml, and Gopkg.lock are in sync
Examples:
dep init set up a new project
dep ensure install the project's dependencies
dep ensure -update update the locked versions of all dependencies
dep ensure -add github.com/pkg/errors add a dependency to the project
I'm in the middle of building an application but found myself too easily creating new packages without keeping the project's structure in mind.
Now, I'm trying to redo the whole project structure on paper first. I am using a Settings class with public properties, accessed as settings for several other classes around the project.
Now, since this Settings class applies for the whole project, I am unsure if it should be packaged and if so, in what kind of package should it exist? Or should it be in the root (the default package) with the main application class?
I've been thinking about putting it in my utils package, then again I don't think it really is an utlity. Any strategies on how to decide on such package structure for example for a Settings class?
Use of the default package is discouraged anyway (in java it is actually enforced as a warning as far as I know), even for the class containing the main.
Other than that, I prefer having a config package, even if it's the only class in there. I don't think it would fit in the utils package.
IMHO you should put it into a separate, low level package, since many other classes depend on it, but it (presumably) doesn't depend on anything. So it should definitely not be put in one package with the main application class. It could be in the utils package though, or in a separate package on the same level (e.g. config).
By "low level" I simply mean "low on the package dependency hierarchy", where a package A which depends on package B is higher than B. So it does not directly relate to the actual package hierarchy. The point is to avoid dependency cycles between your packages, so that you can have such an ordering between your packages.
Btw you should not use the root package in a real application.