I occasionally get name clash errors in a java project built with Jenkins.
I've seen it in a couple places, and it both places it follows the following format:
public class Foo {
public enum FooEnum {
VALUE1("Val1"),
VALUE2("Val2)
private FooEnum(String) { /*code*/}
}
}
And the error output would say:
[javac] /path/Foo.java:6: error: name clash: FooEnum(String) and FooEnum(String) have the same erasure
[javac] private FooEnum(String)
^
Note that there is only one method named FooEnum, so its not a case of type erasure issues or anything like that. The method seems to be somehow conflicting with itself.
I develop the code in Eclipse and my codebase spans multiple Eclipse projects in the same workspace. For my Jenkin's pipeline, I have a job for each Eclipse project.
When each project finishes, it archives the whole project directory (which includes the source and the .class files). Downstream projects then copy the archived objects from the previous builds so that they can use them as dependencies.
I am using ant build.xml files which are auto-generated from eclipse.
These errors don't show up super often, but when they do, they usually persist for a few builds and then go away. I have not been able to figure out any pattern indicating when they occur and when they don't.
I have never had any issues when building within Eclipse, so I think the issue must have more to do with my Jenkins setup or the build files.
Unfortunately, do to my companies strict proprietary information protection policies, I'm a little apprehensive about sharing any actual code or actual ant files here, but I was hoping someone would have an idea they could share with me.
I was able to fix this by explicitly copying in the dependency projects required for each job and making sure that I only copied in those projects.
Previously, I would sometimes copy in all of the artifacts from a few jobs that had the dependencies I needed. I think that something weird was happening in the cases where a dependency was found in multiple jobs that I copied in. I still haven't figured out exactly what's going on, but this seems to have fixed it.
Related
I'm reviewing an isolated Java project in VSCode. By that I mean that I have the project itself, but not any of the projects that it depends on. From what I can tell, the result is that Intellisense has been turned off for the project, which makes navigating around the code a pain.
For example, you can see below that VSCode can't find the definition of a method, even though it's just 3 lines down. On the side, you can see the errors it's encountered trying to load various artifacts.
Is there a way to turn Intellisense back on, at least for the objects that are defined within the project itself? I have the MS Java extension pack installed.
To clarify, these are internal projects that it depends on and I don't have on my machine.
I just noticed there's a feature that might help you get around this. Check out "Lightweight Mode" here: https://code.visualstudio.com/docs/java/java-project
Maybe this will get away from having access to mvn full resources and just get the quick-n-dirty navigation as the docs seem to indicate!
Lightweight Mode
VS Code for Java supports two modes, lightweight and standard. With
lightweight mode, only source files and JDK are resolved by the
language server; with standard mode, imported dependencies are
resolved and the project is built by the language server.
...works best when you need a super quick-to-start and lightweight
environment to work with your source files, for example, reading
source code, navigating among source code and JDK, viewing outline and
Javadoc, and detecting and fixing syntax errors. Also, code completion
is supported within the scope of source files and JDK... Lightweight mode doesn't resolve imported dependencies nor build the project.
Your project throwed project build error: Non resolved parent pom for com.....
When errors are resolved, the intellisense should work as normal.
Please have a look at this question. Try and see if error goes away.
Project build error: Non-resolvable parent POM.
I'm asking and answering this question to save me from going down this rat hole again in the future.
I'm building a cross platform eclipse IDE based software development environment with about 40 plugins. When I installed the latest nightly build and did some testing on my Linux test system the application started throwing the dreaded java.lang.NoClassDefFoundError when I did a certain action. This was not happening on my Windows installation. It did not happen in my development environments on Linux or Windows. This action and the code behind it is new and so not yet covered in our automated test suite.
The plugin throwing the exception was trying to access a static class method in another plugin, but failing to find the class. Things I tried:
First thought: static initializer fails for some reason! Nope. I can see other plugins access this static class and methods prior to the failure (by attaching my debugger to the installed instance of my product and stepping through the code).
The fact that it works from other plugins eliminate the other usual reason for failure, not properly exporting the package. It was exported correctly.
I poured over my plugin dependency list, comparing them to plugins that were able to access the offending class, but with no success. All dependencies were accounted for.
I did a deep dive into my MANFEST.MF. I switched from using "Required-Bundle" to "Import-Package" in the MANIFEST.MF. That created new problems for me so I reverted that change. Everything looked good.
My build.properties looked good. Not too much in there to go wrong. It was consistent with my MANFIEST.MF where it counts.
I deconstructed my plugin on the installed instance to be sure that the class was indeed present. It was.
Everything was configured correctly. Everything!
I poured over many related SO questions and blog posts but none of them offered a solution that worked or any additional insight into the problem.
The next step was to start iterating over my nightly builds to find the build where the problem first showed up. Once I identify that build, I'd be able to iterate over all the commits from the day before, doing full builds, then installs to find the commit that broke it.
I started 10 days prior and installed every nightly build. All the way up to the build that failed in my test environment. Every single one of them worked. Why?. See my answer below (or submit you own).
When testing a new eclipse IDE build make sure you start with a fresh new non-existent workspace directory and use the "-clean" command line parameter to flush any caches that survive from a previous installation.
The failure was happening because I (1) failed to delete my previous workspace directory before starting the application; and (2) did not use the "-clean" command line parameter to delete related cached information; and (3), even "-clean" may not be enough, I also removed the entire application directory (which, in turn, removed the 'configuration' directory and all cached data within that may not have been "cleaned" by the "-clean" command line argument).
I had been refactoring a few class names to have more meaningful names. When I ran the product with an existing environment the product was using cached data, getting the old name of a class that had been renamed, and failing to resolve it. (You might think that seeing the old name was a good clue, but, unfortunately, one of the first things I tried was undoing the class name refactoring, thus restoring the previous name. So the error reported the correct name, but, I suspect, there is a signature of sorts that did not resolve.)
Of course it is a best practice to always start with a new workspace when testing. I've been doing Eclipse IDE development for years and I know this well. But yesterday I forgot (not helped by the fact that my Windows installation did not suffer the same error for whatever reason). You will forget on occasion...and it will bite you.
I fixed my problem but I don't know how/why this fixed it so I am looking for an explanation.
I opened my project yesterday and I could no longer build due to the fact that the java and jsp imports could no longer see javax.* classes. I had another project that worked fine but could find no differences in their build paths.
After reading several threads on build path, etc. and not finding any problems in the configuration file I simply retyped the import in one of the source files, eclipse was able to lookup class tree as I typed in the editor, and once one of the imports was retyped the project would now build.
I would like to understand what in the Eclipse project configuration was hit and why this happened and how this method I used actually resolved the problem.
I have imported apache nutch from http://svn.apache.org/repos/asf/nutch/trunk/ through SVN on eclipse; however, the project I have imported has 10k+ java errors:
Some errors are due to source files being in a package different from what is specified in their source, (e.g. classes in java.org.apache... but it is declared in source that they should be in org.apache..., this is observed in many other packages)
Unimported classes, for example the Class "Context" is used in many of the classes however when looking at the import list, "Context" is not declared there.
Missing classes, though imported, classes still not resolved to a type, most probably because my imported project lacks many of the needed libraries such as hadoop,gora,witty,etc.
(Not familiar with this) Bound mismatch errors like: The generic method createDataStore(Configuration, Class, Class) of type StorageUtils is not applicable for the arguments (Configuration, Class, Class). The inferred type WebPage is not a valid substitute for the bounded parameter
What is the correct way of importing a nutch through eclipse without encountering the errors specified above? Thanks!
Refer to http://wiki.apache.org/nutch/RunNutchInEclipse
These should be followed to the "T" and it works fine.
Specially, pay attention to the manual configuration of the build paths for the plugins.
You may also notice that some library dependancies are not set even after setting the build path,within certain plugins. .. you will need to manually add the ivey dependancies for these plugins into the build patch as well.
For starters, and granted being new to java development, I have a few questions.
I am using the Eclipse IDE, and have downloaded a zip file *com.alvazan.orm library.
Initializing a Java Project from an Existing Ant Buildfile, and using the build.xml file, I get TONS of com.alvazan.orm.api packages, each containing various .java files/test cases and and equal number of .Jar files containing even more packages, etc.
So, right off the bat, I notice several warnings, Java Build Problems
Classpath variable 'JRE_LIB' in project 'std_buildfile' is deprecated: Use the JRE System Library instead
Is this something that will effect the running and debugging of test cases?
Additionally, I have run into Java Problems, upon initial build:
The method translateToColumnImpl(Collection, RowToPersist, Collection) from the type DboColumnToManyMeta is never used locally
The value of the local variable existing is not used
The value of the local variable toBeAdded is not used
The value of the local variable toBeRemoved is not used
While these are currently only errors, since attempting to run various test cases and coming up with even more warnings and errors, I am concerned the looming warnings maybe affecting the outcome.
Please advise if this something which needs addressing or if is generally a common occurrence.
I would be glad to post more information of necessary, just let me know what is necessary.
These "warnings" not errors are a common occurence. You only have issues when you see the red errors. Eclipse likes to tell you about potential problems like generally unused fields should be deleted. Many times fields are not deleted because they are about to be used. None of the warnings ever affect your ability to run or debug the programs though. ONLY the red errors will affect your run AND when you try to run in eclipse with red warnings eclipse will even prompt you saying "this doesn't even compile, are you sure you still want to run" and generally you should not run when you have red errors.