We Keep Coding

"Cannot find declaration to go" protos declaration in IntelliJ IDEA

I am trying to use gRPC proto file to generate stub code for inter-service communication. Everything is okay and when I run mvn clean install, it installs everything and builds successfully.
But still now protos files are in red color and can’t go definition when I click to go to it’s definition. It says me Cannot find declaration to go. When build is successful then why it is not possible to find declaration in IntelliJ IDEA?
I clean every cached on IDE and indexing is also successful. I also cleared m2 cache.
Is there anything to find this solution so that I can go to proto class definition?
Any help will be appreciated.
Thanks.

Your IntelliJ IDEA  needs to generate Project setup. So you need to execute the main plugin goal, which is idea:idea.
Use this command. It will helped me.
mvn -U idea:idea
Here
-U = Forces a check for missing releases and updated snapshots on remote repositories

How do I know which project is requesting a specific jar from Maven

I'm using Eclipse and recently upgraded all my projects to use the latest version of a library.
However in the Maven repository I can still see the old version of the library.
I've deleted manually the old library from the Maven repository, but it keeps coming back.
I am sure all the projects in Eclipse point to the new version: I've checked all my pom.xml, I've used the "Dependency Hierarchy" tool, etc.
Is there a way to know which project is telling Maven to download the old version of the library?
Many thanks!

You can use the Maven dependency plugin's tree goal:
mvn dependency:tree
and filter using the includes option which uses the pattern [groupId]:[artifactId]:[type]:[version].

Re: "and I have many". Perform the following in the topmost directory:
find . -name "pom.xml" -type f -exec mvn dependency:tree -f {} ';' | grep '^\[.*\] [-+\\\|].*'
Syntax details may vary from Bash to Bash.
Hint: Try it in a bottommost project directory first to ensure that it runs properly as intended. Since you have many projects it may take a while to finish and to recognize possible errors only then.

You can use below command to get a tree of all dependencies and then find out where the specific artifact is coming from.
You can pipe with grep to show only the related ones if you you are on linux/unix based os.
mvn dependency:tree

Thanks guys, appreciated, but it certainly is not an easy way. It looks like you have to do project by project (and I have many). Plus most of my pom reference poms in other folders and it's not able to process that either.

Maven class name collision in Stanford-CoreNLP and Stanford-Parser

My (maven)project is dependent on both stanford-CoreNLP and stanford-Parser and apparently the (lexicalized)parser of each dependency is producing different outputs, they are not alike.
My question is that how can I determine which package the parser should be loaded from ? the parser class has a same name in both packages:
edu.stanford.nlp.parser.lexparser.LexicalizedParser
and maven automatically loads the class from stanford-coreNLP package while I want it to be loaded from stanford-Parser.
I'd appreciate if you please help me with your suggestions.

I would raise a bug asking them to move the lexical parser into a new maven artifact (or several of them), so you can distinguish them.
If that doesn't happen, you have two options:
Use the Maven shade plugin (as suggested by ooxi)
Delete the offending classes
Breakdown of the second approach:
Use you favorite ZIP tool to open the JAR archive.
Delete the offending packages.
Copy the original POM
Change the version version to something like 1.1.MythBuster.1 or 1.1.no-lexer.1
Use mvn file:install to install the modified artifact in your local repo
Test it
Use mvn deploy:deploy-file to install the modified artifact in your company's repo
I prefer the second approach since it makes sure the build has a clean classpath, people know that you messed with the original file and it's pretty obvious what is going on.

I once had this problem and could solve it by using a virtual package depending on the two conflicting dependencies (in your case stanford-CoreNPL and stanford-Parser) and merging them using the Maven shade plugin.
When shading only one class will be in the virtual package, depending on the order of <dependency /> tags.

Does Maven remember its state so I can easily rerun last command?

I am using Maven multi module project. When I run maven and one of the modules fails I get the error messages and then the following line
After correcting the problems, you can resume the build with the command
mvn <goals> -rf :my.module.name
Does Maven hold any state? Is it possible to run
mvn <goal> `start from where we left off`
The reason I ask is that some of my module names are quite long. I can copy from the cmd prompt but I'd just like a quicker / shorter command. Often saving a couple of seconds may not seem much but over the course of my maven usage it could save me a lot.
The question is
does maven hold state?
if so can I quickly rerun from where I left off?
Thanks

You can use Maven Shell to execute maven goals/phases in a pre-loaded shell environment, significantly reducing the build time.

No, but you could go into the individual modules and build them - this is in essence what maven does, you just need to go through them in the correct order otherwise you might get confusing results (i.e old dependent-module builds etc). The reactor build summary shows you the module build order that maven will run through and is displayed at the start of the build.
In the end though you will always need to do a full build from the parent module in order to build your final artifact. And it's often easiest just to run from the top anyway.

No - at least in my experience, Maven does not hold its state. This is especially important if you are running mvn package. Whereas running mvn package on a multi-module project will work fine (all modules will be able to use the produced artifact of a previous module), if the build is interrupted, resuming from your build mid-way will cause artifact not found errors when referring to previously successfully built modules.
Two ways around this. Rebuild everything, or use mvn install to require maven to install to your local repo (if you are not ready to deploy). In such a case, resuming your build will not fail as it will find the previously built modules in your local repo.
Just as a personal pet peeve, you need to know the module artifact name when using the -rf flag. Maven will show you the display name, which may or may not be the artifact name. -rf requires the artifact name.

could the first ever maven build be made offline?

The problem: you have a zipped java project distribution, which depends on several libraries like spring-core, spring-context, jacskon, testng and slf4j. The task is to make the thing buildable offline. It's okay to create project-scope local repo with all required library jars.
I've tried to do that. Looks like even as the project contains the jars it requires for javac and runtime, the build would still require internet access. Maven would still lurk into network to fetch most of its own plugins it requires for the build. I assume that maven is run with empty .m2 directory (as this may be the first launch of the build, which may be an offline build). No, I am not okay with distributing full maven repo snapshot along the project itself, as this looks like an utter mess for me.
A bit of backround: the broader task is to create windows portable-style JDK/IntelliJ Idea distribution which goes along the project and allows for some minimal java coding/running inside IDE with minimal configuration and minimal internet access. The project is targeted towards students in a computer class, with little or no control over system configuration. It is desirable to keep console build system intact for the offline mode, but I guess that maven is overly dependent on the network, so I have to ditch it in favor of good old ant.
So, what's your opinion, could we move first maven build in offline mode completely? My gut feeling is that initial maven distribution just contains the bare minimum required to pull essential plugins off the main repo and is not fully functional without seeing the main repo at least once.

Maven has a '-o' switch which allows you to build offline:
-o,--offline Work offline
Of course, you will need to have your dependencies already cached into your $HOME/.m2/repository for this to build without errors. You can load the dependencies with:
mvn dependency:go-offline
I tried this process and it doesn't seem to fully work. I did a:
rm -rf $HOME/.m2/repository
mvn dependency:go-offline # lot of stuff downloaded
# unplugged my network
# develop stuff
mvn install # errors from missing plugins
What did work however is:
rm -rf $HOME/.m2/repository
mvn install # while still online
# unplugged my network
# develop stuff
mvn install

You could run maven dependency:go-offline on a brand new .m2 repo for the concerned project. This should download everything that maven needs to be able to run offline. If these are then put into a project-scope local repo, you should be able to achieve what you want. I haven't tried this though

Specify a local repository location, either within settings.xml file with <localRepository>...</localRepository> or by running mvn with -Dmaven.repo.local=... parameter.
After initial project build, all necessary artifacts should be cached locally, and you can reference this repository location the same ways, while running other Maven builds in offline mode (mvn -o ...).