I am creating a system that will compile first and second year java programs, at the moment I have it compiling single Java files.
As I was starting to try and get the system to compile projects with multiple classes, it accord to me that being first and second year students they are not going to hand up the projects all in the same format.
I was trying to research this all yesterday but could not find out much of about things like:
What are to main differences between Netbeans and Eclipse projects when compiling
How to compile projects in jar files
Just the different formats in general
So my question is, is there a compiler out there that compiles all the different formats, or do you have to set up the different formats to a certain way to compile them?
Any examples of this as well?
Make it a requirement to use Maven to build (yes it has it's faults, but at least you'll get consistency).
What I understand is you want something that can compile all types of Java projects (NetBeans, Eclipse, etc.)
Sorry to say this but there isn't one that can compile all the formats out there. But you could write your own, for at least the most common types of formats that you receive from the students.
Check out this page for more information: Building Java Projects.
What I suggest is, start by studying the build architecture used by those tools (NetBeans, Eclipse, etc.) and come up with a build script of your own that can extract the class paths of all the classes in the java project. Let your script do the work for you!
If you don't wish to write your own scripts, then you may consider changing the projects you receive into a standard project format. Check out this and this link to see more about migrating from Ant to Maven or Maven to Ant.
Else, you can always manually port your existing projects into other IDE, provided they follow the same build mechanism. Check out this answer to know more.
Related
I want to change literally one word from a java project on github and compile it to .jar
I cloned the code using github desktop app and open it with visual studio code but there are 259 problems I don't know what.
enter image description here
I forced to compile it anyway, this is the result
enter image description here
Before there was a "JAVA_HOME is not in your enviroment", I googled it and added a new environment with C:\Program Files\Java\jdk1.8.0_221
I have contacted the developer but it seems like they get annoyed I'm asking questions. It is my first time compiling java to jar so please teach me kindly, thank you.
but there are 259 problems I don't know what.
Programs don't live in a vacuum. Specifically, this project uses open source libraries. That's common - just about every modern programming project does. Some ecosystems (such as node.js) elevate it to a competition and even the simplest app include thousands of one-liner open source libraries; java (the ecosystem/community), at least, isn't quite that frivolous with its libraries.
Building a project is, as a consequence, not quite as simple as 'just compile all the java files you can find in the repo'. The source code (the stuff you cloned) contains descriptors of libraries, such as org.apache.commons::commons-lang3::3.12.0 (literally that string or something quite similar to it in a file named pom.xml or build.gradle or build.xml or similar - a file that describes how to build, test, and run the project), and the build tool will then go ahead and download these libraries automatically from open source repositories.
That process gets you the libraries that this project is built on top of, such as org.apache.commons.cli. You didn't run this process, hence why your editor is telling you that it can't find org.apache.commons.cli.
I forced to compile it anyway, this is the result
That obviously doesn't work. An error is an error. Programming is a little harder than just doing your best Harry Potter impression and wishing it away. You'll need to fix this.
Figure out what build tool is used to build it, and use that to build it. Generally the project's readme will explain this. If not, if there is a file named build.gradle, it's gradle, if there's build.xml it is likely ant, and if there is a pom.xml, it's maven. These are all widely used open source tools with hundreds of tutorials on how to use them available. Read up, and get to building!
Only when you successfully build this app in vanilla form (fresh off the clone), should you then start on modifying things.
I have a code base scattered across tens of repositories.
I want to standardize names of packages and classes, but it's too tedious to do it by hand in IDE, since I need a dictionary based renaming across repositories.
Is there a way programmatically rename classes and packages across many repositories?
A similar thing for a different language: https://metacpan.org/pod/App::EditorTools
Eclipse, and just about every other major IDE, can do this rather trivially. Load the project into the IDE (most can read the project if it is built by maven or gradle, just by saying you want to 'import an existing maven java project' or some such, possibly after installation a maven and/or gradle plugin - if it's not a project built by such tools, then just import an existing java project and tell eclipse about where the source files live).
Then, right click the package, pick refactor/rename, rename it, and eclipse (or intellij, or any other major java IDE) will rename the directory, update the package statement in every source file inside it, and will update all imports or any other reference, and will even search for strings that contain that exact name in case you're doing weird reflective shenanigans and tell you that those probably also need to be updated.
It's not quite programmatic, but this sounds like it'll be much easier and faster than actually using e.g. ecj or writing an eclipse app that will run without a user interface to apply these refactor scripts.
Currently, every time the source in my ant project is built a java file with a static final variable with the version number is generated. The version number is formatted as yyyyMMdd so that it is always increasing. My problem is that I'm currently checking in the resulting build jar into source control (which I view as a failure, since I don't believe that I should be checking in binaries that are created from the build process).
I was wondering if there was an easy way to generate and write a date based version number to a java file in gradle before compilation, and also if there was a way to somehow only regenerate this version number when I'm building in development and not when someone else is going to rebuild the same version from source. It's a difficult separation of tasks, but I'm hoping someone has had some experience with it before.
You are correct when it comes to not include binaries into source control - of course some type of binaries - I mean, the output of compilation.
Basically modifying sources by build tools is not a good practice, it may cause many problems. Instead, I suggest to add a plain old properties file that will be filtered during build and an entry within it will be substituted with the current date. This file will be included into the binary output of compilation (namely jar file) but can be ignored in source control since it's irrelevant.
What are you asking about can be done in gradle, however it's not a good idea (as I mentioned).
I'm coming from the .NET world where Visual Studio is pretty ubiquitous. VS has a .sln file which pretty exhaustively describes a project, including where to find source files, dependencies, etc.
Now I'm doing some java coding in a team. My problem is this: I'm using intellij and others are using eclipse (while others could be using some other IDE). Is there a standard project description file that can be shared among IDE's? I obviously don't want to put my intellij specific files to source control. So what I'm looking for is a standard that pretty much any self-respecting IDE would recognize which you could point it to and it would be able to interpret the project structure, how to find dependencies, the class paths, etc.
Maven should be able to do it (a project build manager and source control overlay), but alas, there is no standard project file. There are Maven plug-ins available for all the major IDEs. http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
Note quite. But you have a "way out". You can use Maven2. It has a unified pom file which contains all:
source folders (note: maven imposes a default convention on those, but they are still configurable)
compiler level
dependencies
build steps
etc..
(Of course that would require to install the maven plugins for both IDEs)
Another option would be to force either of the IDEs and commit their proprietary descriptors.
As others have posted, Ant and Maven are pretty much the de facto project spec utilities in the Java world. Those are both generally easy to learn -- a fair learning curve, but nothing dramatic -- and are pretty powerful. You could speak to your team members or leader and see how they've dealt with it -- I'm sure it isn't a new problem.
Aside from that, a lot of development teams (in my experience, at least) try to avoid putting project files in source control. The developers are required to basically create their own projects in whatever IDE they're using. It makes getting started on a project a little more difficult for a developer coming fresh into an existing project, but it also helps the developer get a little better acquainted with the project.
At my shop (very, very small team), we use Eclipse, but we still have to manage the workspaces (similar to VS solutions, but not quite the same) ourselves. I've created some Ant scripts for use on our continuous integration server, and that won't necessarily keep problems from arising, but it helps make them more obvious when they do.
There is no such standard project description file as far as I know. But intellij is able to take an eclipse and convert to an intellij project. Also you could look at maven.
There is not one. You could switch to an build system using ANT (similar to Make) but that has pitfalls of it's own. You will get the most mileage if you and your team standardize on an IDE though ...
I think what you want here is for a developer using Eclipse to edit the project settings and have those changes reflected in IDEA for some other developer. If that's the case, then Maven is what you want. IDEA 9.x has great support for Maven, and so does Eclipse. If a developer that uses Eclipse edits the dependencies in the Maven project files (pom.xml files), then IDEA can import the files and change it's project settings.
RE: ANT vs Maven - In this respect (syncing project settings) ANT build files won't work because they are imperative (script-like) rather than declarative.
Maven should be the preferred way but most IDE's now days support some kind of ant based project which is what most of the IDES use internally. Usually called free-form projects.
I'm not a Maven fan myself. I'd recommend Ant long before Maven.
If you're using IntelliJ, I'd argue that it does have a pretty standard idiom. And since it can import any Eclipse project file, you'll be on safe turf laying things out as IntelliJ does it.
I don't check in my IntelliJ project files, but the /src, /lib, /test, /resources etc. are all fair game.
The true answer should be that your team should huddle up and come up with a standard layout that you agree on regardless of IDE. You've got to check code into SVN sometime.
Your question is interesting to me, because I'm trying to go in the other direction (Java->C#, IntelliJ->Visual Studio), and I'm having trouble doing the mapping in the other direction.
I think it's just part of learning a language and its native IDE. I find that it's best to find an experienced guide.
One problem you'll have is that the .NET universe is isotropic (all things Microsoft), where even your small corner of the Java universe is heterogeneous (IntelliJ and Eclipse and NetBeans). You're less likely to find one true answer for all of Java.
What is the best way to allow a team of programmers to use Netbeans, Eclipse and IntelliJ on the same project, thus eliminating the "which IDE is better" question.
Which files should or should not be checked into source code control?
I think the best way is to make the build process independent of IDE. This means that your project should not rely on any IDE-specific files to build, but rather use an external build system, like Apache Maven, Apache Ant, or even make or custom scripts. Maven is supported by most popular Java IDEs, either directly or via plug-ins.
If you don't want to use an external build systems, you should at least make the project as easy to set up as possible (i.e. by having standard folders for shared libraries and other dependencies). When I have working on teams with multiple IDEs in the past, I spent by far the most time on resolving dependencies as the prerequisites for building the project changed over time. In the worst case you may even end up with developers not bothering to get the latest version from the version control repository, since they think setting up the new project is such a hassle.
If your project has many library dependencies, I think its a good idea to make these available in binary form in the version control repository. That way people don't have to resolve all the dependencies of the dependencies and so on just to build a single project. This does however require that you have someone responsible for keeping the "official" binaries up-to-date whenever they change. (This is pretty much the same philosophy used by the Maven repository, but the principles can be applied manually even when not using Maven.)
Well, that's a pretty self-answering question.
The files to not check into source control are files that have to do with the IDEs themselves.
Leave it to the developers to generate these files.
If you use Maven, it can generate the files such as Eclipse's .project and .classpath for you. Eclipse in general is very easy to use with a basic file structure (with the new Java Project option).
I think Maven has Netbeans support as well, not sure about IntelliJ though.
Maven's site is maven.apache.org.
For each IDE that has more than one developer, check-in all the supporting files. Why re-invent the wheel at every desk.
I have done this with many different IDEs, and I have yet to see a filename conflict.
In fact, even when only a single developer uses a particular IDE, it is to his/her advantage to version the supporting files, for the same reason that you version the other files in your development environment: history, diffing, comments, etc.
For Eclipse, that would be .classpath and .project files.
My team uses Maven, and developers are discouraged from checking in Eclipse-specific files. Because they can be generated from Maven, these files are redundant.
Also, checking project-specific files seems like it would save time, but it usually winds up being a pain because of variations in different developers' workstations, resulting in wasted time resolving conflicts in the IDE-specific files. The only way to get around that is to force everyone to set up their environment the same way, which goes against the IDE-agnostic approach.
There are many considerations when using multiple toolsets within the same project team. For example, my team has Java developers using IntelliJ and most of the front end (JSP/CSS/HTML) developers using eclipse. We are in the process of migrating the Eclipse users to IntelliJ because of some IntelliJ plugins that we have developed that provide extended support for our environment. We're not going to develop the plugins for multiple platforms, so we are standardizing on IntelliJ across the board.
In terms of specific files, I can speak to IntelliJ. We have checked in our .ipr files and our .iml files. Do not check in .iws files. If you also have Eclipse users, configure your IntelliJ project to read/store dependency information in the .classpath file and commit that to your VCS.
We intentionally support multiple IDEs from the same SVN repository. Our thinking was that we want to ensure that, if a new person joined the team or someone had to start working on a new machine, we wanted them to be able to checkout the codebase, import it to the IDE and immediately have a work-able configuration.
What that means on the developer end is that they should not commit their changes to the IDE files. Everything else (e.g., src, test, lib and so forth) becomes the set that we normally update and commit every day.
The side benefit is that we have completely eliminated the IDE wars here: Netbeans and Eclipse people live in perfect harmony (looking askance at the IntelliJ people, but hey... ;-).
For more comments and answers on this topic see this question (How do you handle different Java IDEs and svn?)
We rename our IDE files for checkin with an extra extension .deletethis or similar. When a new person checks out the project, they simply strip off the extra extension and are good to go. This way we avoid source control conflicts with the project files as people tweak their environments. And you don't have to worry about educating new developers to not check in those files.
Typically, I would consider this a bad idea. I'm not sure what kind of environment this is (perhaps open source?), but it would really suck to support multiple IDEs. One thing I would recomend if this is unavoidable, would be to standardize your builds in ant scripts. If you have a large set of dependencies, this may be the easiest way to get a predictable build across all platforms.
If one of the IDEs happens to be RAD (based on eclipse), there is an entire folder called .settings that you would not want to include in the SCM.