Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
I've been looking at profiles in maven for selecting different sets of dependencies. This is fine when you want to build say a debug build differently from a release build. My problem is that I want to do a fair bit more than this. For my application (Mobile Java app where J2ME is just one target among many) there may be a large number of possible combinations of variations on a build.
Using some made-up command line syntax to illustrate what I'd like to see, I'd imagine typing in something like
mvn -Pmidp,debug,local-resources
What Maven does in this case is to build three different builds. What I want to do is use those three (Or more, or less) switches to affect just one build. So I'd get a MIDP-targetting debug build with 'local resources' (Whatever that might mean to me - I'm sure you can imagine better examples).
The only way I can think of doing this would be to have lots and lots of profiles which becomes quite problematic. In my example, I'd have
-Pmidp-debug-localresources
-Pmidp-release-localresources
-Pmidp-debug-remoteresources
-Pmidp-release-remoteresources
...
Each with its own frustratingly similar set of dependencies and build tag.
I'm not sure I've explained my problem well enough, but I can re-write the question to clarify it if comments are left.
UPDATE:
The question isn't actually valid since I'd made a false assumption about the way maven works.
-Pmidp,debug,local-resources
does not do 3 builds. It in fact enables those 3 profiles on one build, which was ironically what I was looking for in the first place.
The Maven way is to create a lot of artifacts with less complexity. I'd say your best bet is to abstract the common parts of each build into a separate artifact, then create a project for each build that defines the build specific parts. This will leave you with a lot of projects, but each will be much simpler.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am working on a very old application built using strut 1.1 in 2004. The complete application is made by combining three projects(common, web, and EJB) in Eclipse and all these three are packaged as.EAR file. So here the confusion where to fit the JUnit test cases for this type of structure.
Whether I should create a separate project for writing the test cases. If I create the separate project, I would add the above projects in the build path.
So what is the right way? Any suggestion would be appreciated.
Also, tell me about the way I can check the results on GUI that how many cases are passed and how many are failed.
First of all: in case you intend to write real JUnit unit tests for 14 year old code, the answer is: do not do that.
If at all, you should be using JUnit as environment to automate test case execution, which in this case should be "integration" or "functional" tests.
You see: the only reasonable argument to invest money in old, existing source code is: you intend to refactor/replace that solution with a new implementation. Then your one and only concern is that your new code behaves like the old one. From a functional point of view. It doesn't make sense to invest time/energy into unit testing units you intend to throw away soon.
Beyond that: do whatever works for you. Typically, it would be better to have a complete new project to avoid tampering anything existing.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to import an Eclipse project from GitHub into IntelliJ. I'm however having problems figuring out the correct way of doing that.
I'm following this question to do the importing(I'm leaving everything on default and simply click "Next", since the answer doesn't mention anything else and I have no idea what the other stuff does), but it still doesn't work. The configuration/project structure appears to be seriously broken and I have no idea why.
More exactly, I'm currently stuck at the following screen: The "Problems" tag explains in more detail that both the things in red are "invalid". I tried searching for that error, but it seems that people encounter it on all different project models and build tools like Maven, Spring, or Android. None of them concern Eclipse projects and the solutions vary from issuing a bunch of commands that I don't understand somewhere to deleting this project file or another.
Since there are so many unknowns in play here, I decided to ask, rather than waste days crapshooting only to break something in my IDE or Java installation. How do I get this project to work? It's a simple local machine visual app, it shouldn't be this complicated to import it in an IDE.
Basically the issue is how those two libraries are defined. If you select one and then click on the edit button to the right, a dialog will open and show the path to where those libraries are defined. They are likely configured to find the necessary JARs at a specific path on the (original developers) system. For example, for the jfxrt.jar library, maybe it is configured that the classes/binary JAR is at C:\Program Files\Java\JavaFx\jfxrt.jar or C:\Users\Bob\libs\fx\jfxrt.jar. Wherever they are defined, you either need to put the necessary JARs in that directory, or modify the config to point to the location on your system where you have the JARs. This of course may require you to download the necessary JARs.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I have a project which will have 2 different parts - one part will send messages to rabbitMQ, other one will receive and process messages from rabbitMQ. Both parts uses the same common java classes. For example java class-wrapper which will be sent and received. I think I should create one java project on maven or gradle but build it in 2 different ways - for the first and the second parts. Or may be it`s better to split it to 2 projects, but how to share common java files?
UPDATE:
I have 2 projects: project A sends objects to rabbitMQ queue, project B receives objects from rabbitMQ queue, both A and B uses common classes, so those classes should be shared between A and B. Currently, I created one maven project which includes A and B as modules. And I can compile both of them the same time. So I don't have a mess with third (common java classes) project, and everything is in one place. So I just wanted to ask how to do it correctly and better. Should I separate it to 3 projects or leave as it is or do it somehow else?
You should create 3 projects.
A) one for sending
B) one for receiving and processing
C) one for common code
When you build, you will build A+C, and B+C separately. This keeps everything decoupled from the common code.
The reason to keep the common code in a separate project as it acts as the intermediary that defines the API between the two. Think of deploying on a large scale. You may have separate developers for each of the three projects, so you may choose to version releases to clearly define when dependencies are. If everything is in one project, everything needs to be changed immediately, but you may not want your "common code" developer messing with your sending code (eg. in order for everything to compile). If the different builds are deployed on different machines, only the common code needs to be updated, and not all projects. Having separated projects may take a bit of extra setup work, but will save you from numerous headaches in the future.
Unless you have a specific need to always deploy A+B+C together, 3 projects is the best design. One example is making your own self-contained TX/RX protocol (eg. a walkie-talkie) where the client and server need to be co-located, and there is no central server. But even in this case, to make it compatible with other applications using your protocol, breaking it up into 3 projects still makes a lot of sense.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I started a job in a company where they use Maven in combination with Git. I haven't worked with Maven before and I hope my question isn't too stupid. Why should one use Maven in combination with Git? From what I read Maven has a local, a central and can have a remote repository where it can find it's dependencies. This should enable a team of programmers to work together on the same code. What is the purpose of Git here? Would it be possible to program in a Team just with Maven and without the help of Git?
Well maven and git are for different purposes:
GIT holds the sourcecode of your application
MAVEN is used for dependency management. It holds the binary dependecies of your application. It also creates a abstraction of the used IDE. One developer can use eclipse and another intellij. The project can also be built with the commandline.
I guess it would be possible to work with just Maven. It might even not be totally horrible. However, Maven is system for distributing releases (even if they are snapshots or whatever). It is a totally different tool, than what a version control software is. I guess you could say Maven is the just the "distributed" part without the "version control" part of DVCS systems such as git.
A real version control can do a lot of stuff Maven does not support directly, such as merging, diffs, commit logs. I'm sure it would be possible to build an actual, fully featured version control system on top of Maven, with suitable plugins, but it would be very klunky and awkward to use. The likes of git already do all this, and they have been designed to do it from the start, so they do it better than some hack on top of Maven could ever do, so I doubt nobody has actually tried.
I mean, you could do version control with just shared folder, naming conventions, manual log files, an IM group chat (irc channel) for synchronizing between developers, stock diff tools etc for comparing stuff, etc. It would just be horrible to use and very easy to "break" (in this case, easy to corrupt entire project and all its history). There has been a long evolution of version control systems, you can start reading about it for example here, and starting do it on top of Maven would be like jumping 30 years back in time.
When using Maven, your project's dependencies are well defined in pom.xml which is good for collaborative development as addition of dependencies doesn't require other developers to be informed as Maven automatically handles dependencies itself by downloading dependencies.
Git is used for distributed version control which is very good to keep track code changes in your project.
Basically, these two tools make collaborative development easy. However, this is just a crash course description, there are many of advantages.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a dozen Java projects that depend on each other, and I frequently make changes that cross-cut all of them. However, many of the projects are libraries that could be used independently of each other as well.
Right now I use mercurial subrepos, which works well except that very few third-party tools support it - it's hard to set up code review tools, continuous integration, etc.
What's the best way to address this situation? Split everything into separate projects and build separate JARs? Migrate to git and use git subrepositories? Check everything in to a single repo and accept that I have to check out everything to use anything? Something else?
I would say the best way to do it would be to cut your dependencies so that they can reference as external jars. This way when you make potentially breaking changes you don't necessarily have to fix the affected areas straight away. Since they depend on a previously built jar it allows you to properly isolate your coding. If you use something like Maven to manage your dependencies you will also benefit from the ability to more easily keep track of the different versions of your jars.
If the subprojects are sufficiently autonomous, I would advise setting them up as separate maven projects with separate VCS repos.
This will give you the modularity you need paired with a working dependency management.