We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

201

There are three major disadvantages to one project per repository, the way you've described it above. These are less true if they are truly distinct projects, but from the sounds of it changes to one often require changes to another, which can really exaggerate these problems: It's harder to discover when bugs were introduced. Tools like git bisect become ...


62

Christopher did a very good job of enumerating the disadvantages of a one-project-per-repository model. I would like to discuss some of the reasons you might consider a multiple-repository approach. In many environments I have worked in, a multi-repository approach has been a reasonable solution, but the decision of how many repositories to have, and where ...


50

As we use GitHub, we actually have multiple projects in one repo but ensure that those projects/modules are properly modularised (we use -api and -core conventions + Maven + static and runtime checking and might even go to OSGi one day to boot). What does it save on? Well we don't have to issue multiple Pull Requests if we're changing something small ...


28

I would suggest doing neither. Trying to enforce a technical layering with a package structure leads to a lot of entanglement in your application. Not to mention the fact that we try so hard to hide everything behind a service interface and the first thing we do (mostly due to packaging) is make everything a public class. This becomes painful when there is ...


23

I agree with others here that Maven seems to have taken over most significant projects that I've looked at. While Ant is highly flexible, the build file is not standardized, so when you move to a new project or company, the targets are named differently, the file is structured differently, the inter-target dependencies may or may not be established, etc. ...


22

For me, the main difference in using one or more than one repository are the answers to the following questions: Are the multiple parts developed by the same team, have the same release cycle, the same customer? Then there are less reasons to split the one repository. Are the multiple parts highly dependent on each other? So splitting model, controller and ...


20

Is it possible ? Yes certainly. I have in the past structure a few projects like this, here some bits I hope will get you started. There are two main features of Maven you will use to weave things together: Normal dependecies Modules Divide and conquer You will need to split your projects in multiple independent projects. Here by independent I mean that ...


19

You have 2 options: 1. by git way: use submodules. Here is a documentation how git manage submodules git submodules. I personally didn't use it but it looks to fit your problem. 2. by maven way: in maven it is not mandatory that your root project (configuration) to be hierarchically the parent directory of all your projects. You can have a structure like ...


16

I feel that you're doing it wrong. You're heading towards a. unmaintainable spaghetti environment. Java projects tend to grow to tens or hunderds of dependencies. You start from Guava, JodaTime, SLF4J some commons and it grows... and it's OK. Just don't try to maintain it manually. Maven/Gradle is a must! Never ever commit Eclipse workspace files. It just ...


11

I'd suggest you look into using Maven as opposed to Ant. If your IDE can build your project in one click, then it's likely that Maven can also build your project with virtually no custom configuration. And to answer the question, simplifying the deployment process is one concrete example. If you're building a distributable locally that means that you have ...


11

I've been working with Ant and with Maven. In my experience, Maven has a very strong edge over Ant. All the projects I've seen last 2 or 3 years seem to be using maven. About 3 years ago this made me wonder because maven versions used then (2.0.something) seemed to be quite unreliable and buggy. At some point though (2.1 or 2.2 I don't recall) maven became ...


10

I'm going to take a quick first cut at this (great Q BTW!): Would imposing a structure on the large project (i.e. into smaller sub-projects) slow the compiler down? Not by enough that it matters, the overhead is actually in Maven invocations. Also, I have a slight concern on what impact this might have editing time in IDEs (we principally use ...


10

Since you already have your projects ready for Maven and Jenkins is installed, you may go one step further and install Sonar. It is an incredible code quality related tool, it performs Cobertura, Checkstyle, FindBug, and many other analysis tools at the same time. That way, the code quality reporting is done by Sonar, not by Maven or Jenkins. You can ...


9

They both have their main strength and will both be sufficient to fill your needs. Here is my own little comparison with both hopefully will allow you to choose. Maven The more advanced of the two and certainly one of the most advanced build tool I have used. But to call it a built tool is not truly describing it as one of the most innovative feature of ...


8

Clear the cache or reimport Sometimes Intellij gets in a tangle with projects. When that happens the general approach is as follows: Try Build | Rebuild Project If no, check that the project will compile from the command line If yes, then use File | Invalidate Caches followed by Build | Rebuild All If no, then delete your local project files and check ...


8

I'm answering this considering your specific situation. I would say it's fine to use those libraries. Just make sure your slf4j-api doesn't bring along the implementation with it. By that, I mean mark the implementation dependency as "test". EG: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</...


8

The short answer is that the new version could introduce new bugs, as Robert Harvey mentioned in the comments. To be honest, I think you are approaching this the wrong way. In my experience, the better approach is to default to sticking with the version you have. Presumably, your team has already tested the version you use and how it integrates with your ...


7

I'm not aware of any best practices for this situation, so here's my take: An updated dependency should be reflected in your version; let's take the example of MAJOR.MINOR.REVISION numbering scheme. Any version change in a dependency should at least increment your REVISION number, but a bigger change, such as a MAJOR or MINOR change in the dependency ...


7

As long as your code is in source control, using the IDE to make your distributables is fine. As a one man shop, is your time better spent adding new features to your product, or writing build scripts? Something tells me its not writing build scripts.


7

I find the management of dependencies a big win even for solo projects. Adding some XML to the pom.xml and letting Maven worry about downloading the JAR, and putting it in the right place is really convenient. Using the command line for building and deploying is usually much quicker. Once you have some commands in the history, six keystrokes can build, run ...


6

We use maven as our core build system on our huge enterprise system. It is worth its weight in gold. We use it to manage dependencies, both for third party libraries and internal modules, to package the application for deployment, to version the application, and generally to do everything else we don't feel like doing manually :-) When coupled with ...


6

If all projects have to be (always, or almost always) released simultaneously, like service-a-1.2.3, service-b-1.2.3, service-c-1.2.3 etc, then multi-module project is what doctor ordered because it gives you these simultaneous releases out of the box, instead of having to manually repeat releases for each module every time. Otherwise, you better think ...


6

We have a similar situation here, but the schemas don't change that often so the Java doesn't need to be regenerated very often. The way we deal with it is to create a new Maven project with just the schema files as source and generate Java code from that. We then deploy the generated Java as a jar to a local Nexus repository, but the only things that go ...


6

If it is just a single JAR file, then I don't think version controlling it will be apocalyptic. If however, you start adding more and more external JAR files to your app, then you should consider using a repo manager like artifactory to deal with this whether you opt to use Gradle/Maven/ANT. If you have a build script, you can further simplify the task ...


5

Sure, it's harder to see the benefits when you're working alone. Personally, I've worked on plenty of solo projects and not only would I write a build script, I go through the trouble of setting up a CI Server (like Jenkins). There's overhead of course, why would it be worth it? A reproducible build, not tied to the IDE (or your machine, if you run it ...


5

Using the Maven License Plugin, you can generate a text file with all the licenses (license:add-third-party). This file can then be included as a resource into your project or your bundled zip.


5

A "plugin" is a piece of code that's meant to be integrated with a specific application, and cannot be reused elsewhere. A "library" is some code that's meant to be used by other programmers for a specific purpose, but could be useful for many different applications. For example, AdBlock for Google Chrome is a plugin. It needs to be hooked up to the full ...


5

There are two problems that it solves, and both have work-arounds, but neither work-around is always available to real-world projects. But first, for those who aren't familiar with the Maven dependencies mechanism: Maven allows you to specify the specific versions of your application's dependencies in the POM (project descriptor). Your dependencies may ...


4

Benefits of Build Tools It's a short summary just showing the tip of the iceberg, and you won't necessarily notice the important of all this unless you need to do with a combination of many projects, large projects and medium to big team. But if you have faith and try, you'll reap the benefits. They facilitate your development lifecycle and as they allow ...


4

It might be that git-subtree (see Atlassian blog, medium blog, or kernel link) would be a good fit for that you have. So, each of your top level project would use a set of subtree at possibly different version(s).


Only top voted, non community-wiki answers of a minimum length are eligible