As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
At present my work is a little weird. I work on an unofficial engineering team that creates tools / solutions to problems that arise. A lot of our work is incrementally building on older work from team members for rapid development. But as our codebase grows there is an Informational management nightmare.
At present we're using Ant-Libraries and storing all the libraries for project in an "includes" folder. This means that we have lots of outdated / bad libraries for quick inclusion in projects. I've been looking into a way to incorporate something into Subversion that would keep our libraries up to date and would help get us standardized and up to date with minimal intrusion to workflow (editing pom.xml to make a maven project is somewhat intimidating to people that haven't worked with it before.
Does anyone know of any solutions that handle dependencies and allow simply uploading / downloading of libs / projects for team use / work?
Thanks!
It sounds like you just need a dependency manager. You already referenced one of the most popular, Maven. Maven is easier to use then it may seem. If you use standardized directory structures for source code and test source code, you can build/test/deploy with a single command.
Even if you don't use standardized structure, there are still benefits. My work's development shop also uses Ant for building and our build is very old, brittle, and immobile (lot of hard coded paths). However, there are ant plugins for maven that allow you to use Maven for just dependency management while still using your ant build scripts. This will allow you to eliminate the includes directory and just reference your pom file.
Maven Ant Plugins
Another option that I have heard about is Apache Ivy which works tightly with Ant. I have no experience with that though.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We currently do not use any kind of version control software. We recently started using Eclipse, and our source code is maintained on a network drive. An Eclipse project was created and everyone has imported the project into Eclipse on their machines. Due to the way we are set up, we are always getting stuck in clean/build loops throughout the day which is hurting productivity.
We would like to start using some kind of VCS (most likely GIT). I am envisioning a centralized workflow with each developer having a local copy of the code on his/her machine. We would rather use GitHub Enterprise for the shared repository instead of hosting the code on GitHub.
I am not quite sure where to start in getting this setup correctly. I have been watching videos and reading tutorials, however none seem to directly apply to how we would like to do things. Is GIT the right software to use for the type of setup we desire? Also, how does clean/building work with Eclipse and the local copies vs the shared repository?
First, watch this video.
Second, if you're using Eclipse, you're gonna wanna use EGit. Very detailed tutorial here.
Third, don't throw yourself at GIT. Take SVN into consideration at some point (after documenting on GIT). Maybe a Central Version Control System will do you better than a Distributed Version Control System.
Edit:
Oh and by the way... there's a veeeeeeery long and famous Q&A right here regarding this topic. Best of luck.
Second edit:
As for SVN, here you have an easy tutorial on Subversive, and here you can find the full in-your-face Subversive documentation.
You have your needs now but your needs will change. Save yourself the headache of later moving to Git from SVN and start with Git. Here are the reasons to go with Git over Subversion:
Speed - Git is WAY faster
Disk space - Git history is small. Most of the time it takes up 1/10th the space of SVN history.
No server - DVCS allows no admin and you can skip a centralized server altogether. Your central repository can just be files on a network share.
Integrity - data corruption very easy to detect and correct.
Snapshot history - the whole project is snapshotted for each version. No mixing and matching paths with versions.
Open Source dependencies - most of the projects you may want to use are on Github. You can easily just add a submodule and version that dependency.
Power:
git bisect - find a where a bug was introduced quickly
rerere - reuse how you fixed conflicts if they come up again
supports any workflow
proper 3-way merges - this will save a ton of headaches in the future
rebasing - you can keep your history linear, even after someone merged
My last point is very important. You are just now starting to use source control. Start with the best option. You are at a point where you know the least about your needs. Things you think you don't need right now you will need later - guaranteed.
I would create a git repository on the shared drive, you don't need a server like github at all. After setting it up developers can clone from the shared drive to their local computer and push the changes back when they are done.
Every developer will end up with a local copy of the code where they have their own build environment and never be in each others way anymore.
Start with a sample project with just some files in it and play around with it, since you will need to get some experience with a version control system. Also learn the git command line tools (for windows use msysgit), because most of the examples on the internet are writen for those. For more information on git be sure to read the free git book: http://git-scm.com/book
Also see this question about using git on a windows share: How to git clone a repo in windows from other pc within the LAN?
EGIT for eclipse is the good one to integrate git in your eclipse project environment.
Besides, if you are on windows, you can download the Github for Windows, it's really simple, effective to use.
GIT is certainly the preferred way and nicely integrates with Eclipse IDE. But you could also use Subversion as all you want to have is a local copy of code on user machine(call it subversion branch). I say preferred way because GIT is way too flexible: Offline commits, full copy of body of code versus just branch etc....list is too long.
As you mentioned, you can also use github. Roughly, steps are as follows:
Just signup for it
create a repository.
Get the link to repository and Point it as new git repository in Eclipse
Push your code. Commit it.
You will have your code files in github. This will work provided you have Git installed in Eclipse. I believe Eclipse Juno already is setup with EGit (plugin for Git)
For resolving the build issues, you can use set up some Continuous Integration tools like Jenkins. This can be setup as Eclipse plugin as well.
As some already noted, for question
the best way to use GIT?
in your situation (zero SCM-experience) best and fair unbiased answer will be
Do not use Git at all!
Contrary to "Why is Git better than Subversion?" topic you can also read (some subset as result of fast-recall)
GIT - What gotchas should newcomers to version control be aware of?
What does SVN do better than git?
What are pre-requisites for learning & understanding Git?
and check other topics under git tag with multiple laments of Git-boys.
While Subversion is rather good choice (with some edge corners anyway: you may fall into "Merge Hell" even if you think about development as linear: some branches may and have to happen, into "Refactoring Nightmare" with famous "Tree conflict" error...) you can think about "Usable as Subversion and powerful more than Git" alternatives (even you'll use only small needed part or overall power): - Mercurial "DVCS with a human face, made by software engineers for software engineers, not for fashionable dudes".
MercurialEclipse is answer for Eclipse request (in Aragost recommendation Mercurial users trust)
TortoiseHG is user-friendly cross-platform GUI for all and any Mercurial needs outside Eclipse
Mercurial server require a lot less headache (notably "under Windows"), than equivalent Git-server
Mercurial real experts can be easy found (while Git-boys is more fun-club of rapturous teenagers)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have experience with Ant but not with Maven.
My question is: Why does the Apache Foundation release two build tools (Ant and Maven)?
Why can't the same Ant tool be upgraded to Maven?
What is the benefit of using Maven over Ant or vice versa?
What made to build Maven when Ant works as build tool?
Apache isn't really a "vendor", it's a foundation that hosts and supports open source projects that (in many cases) other people/groups donate to them.
The first release of Ant was back in 2000, so it's a pretty old tool. Maven was an attempt to handle building a project in different ways. It doesn't make any sense to decommission Ant as it still has a lot of value.
Just because something is working doesn't mean that it can't be improved upon.
ANT itself was built as a pure java alternative to MAKE.
See What is ANT for the philosophy behind ANT.
Also look at What is maven for the Maven teams take on what the goals of maven are.
Personally I draw a lot of value from the dependency management capabilities of maven.
The best build tool is the one you write yourself. Every project’s build process is unique, and often individual projects need to be built multiple different ways.
If you don’t want to write your own build tool, then you should use: Ant or Maven
Ant is a build tool; Maven is a build system:
What this means is that with Maven, you don't need to decide your directory layout, build targets, versioning scheme, management of dependencies, etc. This is all designed for you. It also means you will be working against the tool somewhat if you don't like the default.
The benefits are that most of the common tools you want to build into your build system (CheckStyle, FindBugs, Unit Testing, Unit Coverage, JDepened...) are all available without any additional development work. In addition, there is a well-defined framework for extending the build system by building plugins (btw - using Ant to build plugins is trivially easy). Also, there is nice integration with IDEs so that developers are using the same build information as the auto-build system.
The trade-off is that unless you are starting from scratch, you will probably need to refactor your source code to be in line with what Maven expects. The trade-off for not having to build everything from scratch is that you sometimes spend time figuring out how to coax Maven to do what you want, how you want it done.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been using JAR files to export my projects in my Java subject at school. I noticed it's portability (assuming the computer in use has Java installed). However, with that fact, why haven't I seen developers distribute Java programs using a JAR file? What are the pros (besides portability) and cons (aside from using C++) of using the JAR executable?
There are two components to the question. The first is shipping a JAR and using no installer. The second component to the question is the pros and cons of a using just a JAR on the machine once the executable has been deployed. I'm starting to suspect that the OP was asking about the first component. My answer tries to answer the second component.
Pros
Less work. Don't have to make an executable for each platform you want to support.
Cons
If the user doesn't have java installed it can't tell the user why it can't run. An exe can also download java for the user.
If your app requires a specific version of Java it may run with the wrong version. A a native executable can locate the correct one and use it. This point isn't as important as it used to be since Java 6 has been around so long.
Can't have an customized icon for the executable on Windows.
You can't control startup options such as the maximum memory that your app can use. For most apps this is ok but sometimes you need more memory.
A JAR cant be used for a Windows service. There must be an exe wrapper around it (jsmooth has this).
Another alternative to producing an executable is to use JNLP. A web page can check for java before it forwards the user to the .jnlp file.
I'm hoping that the advantages are pretty obvious. The biggest disadvantage I've run into is when there are additional dependencies that are required that aren't included in the JAR. A MANIFEST can be included to set the classpath - but this requires that all of the dependencies exist with pre-defined names in a pre-defined location. This can be worked-around with a loader script (to set the classpath, etc.) - at which point not everything is contained in the single JAR anymore, and most of the advantages are lost.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm not looking for java-web-start, I'm looking for a thick-client application installation toolkit. I've got a stand-alone application that consists of several files (jar files, data files, etc) and would need to do some pretty standard installation tasks, like asking the user for target directories, have them locate some parts of their system - choose some of the per-machine or per-user configuration options and possibly try to detect some of the machine settings for them.
I'm looking for something which is like the MSI or other wizard driven installation applications. What's a good installer for Java? It would be ideal if it were cross-platform capable (Linux, Mac OSX and Windows).
Not an MSI-Installer but crossplatform: izPack
It's xml-file based with it's own GUI or ant task (whtaever you prefer)
Launch4j -- open source -- http://launch4j.sourceforge.net/
InstallJammer -- http://www.installjammer.com/
If you are looking for an Open Source solution, take a look here:
http://java-source.net/open-source/installer-generators
I have used InstallAnywhere and I think that it is a good solution too.
Although it is not Java-based, about half of our customers use BitRock InstallBuilder to package Java applications. It is cross-platform and supports all the OS that you require (Linux, Windows, Mac). The installer is native, so there are certain advantages to it, such as not requiring a self-extraction step or the need to bundle a JRE, so the installers tend to be smaller in size
AntInstaller enables you to create cross-platform installers where the installation itself is performed using an ANT script. The GUI is configured with an XML config file.
We used it to create quite complex installers. For complex GUIs however, the configuration can get very difficult. The next time I would probably try izPack because it seems to support ANT as well but has nicer GUIs.
I suggest izPack
with
packJacket
The Nullsoft Scriptable Install System NSIS (originally used for winamp) creates really nice installers for windows, and it's very powerful. It has a compiler that runs under linux, but the resulting installer is windows-only, unfortunately.
It's pretty heavy-weight, but worth keeping in mind if you might have to do any vaguely complex or non-standard things during installation.
I have used it since it integrates nicely with my (linux) build system, and I'd want to use packages for installing on linux anyway.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm writing a J2SE desktop application that requires one of its components to be pluggable. I've already defined the Java interface for this plugin. The user should be able to select at runtime (via the GUI) which implementation of this interface they want to use (e.g. in an initialisation dialog). I envisage each plugin being packaged as a JAR file containing the implementing class plus any helper classes it may require.
What's the best technology for doing this type of thing in a desktop Java app?
After many tries for plugin-based Java architectures (what is precisely what you seem to look for), I finally found JSPF to be the best solution for Java5 code. it do not have the huge needs of OSGI like solutions, but is instead rather easy to use.
OSGI is certainly a valid way to go. But, assuming you dont need to unload to reload the plugin, it might be using a hammer to crack a nut.
You could use the classes in 'java.util.jar' to scan each JAR file in your plugins folder and then use a 'java.net.URLClassLoader' to load in the correct one.
If you are "just" needing one component to be pluggable, it's enough to simply instantiate the classes based on meta information, e.g. read via a classloaders META-INF/ information from the various jars that are on your classpath or in a certain plugin directory.
OSGi on the other hand provides means to structure your whole application. If you already have a large Desktop application that needs one part pluggable, this would be a steep learning curve. If you start blank with what will be a Desktop app, OSGi provides means to modularizing the whole application. It's about "isolation of components" and independence of modules.
Apache Felix provides a nice start if you want to go down OSGi lane. It might look complicated and heavyweight, but that's only because one is not used to that level of isolation between modules. It used to be so easy to just call any public method...
Did you think of using OSGi as a plugin framework? With OSGi you are able to update/replace, load or unload your modules on demand.
One approach I'm considering is having my application start up a lightweight OSGi container, which if I understand correctly would be able to discover what plugin JAR files exist in a designated folder, which in turn would let me list them for the user to choose from. Is this feasible?
I also found this article by Richard Deadman, but it looks a little dated (2006?) and mentions neither OSGi (at least not by name) nor the java.util.jar package