i am looking to make our deployments here not suck and i need some help, if you can help me with these few things i owe you beer
right now whenever i make a change thats not to the jsps i need to clean-including-tomcat otherwise my change doesnt take. this is really annoying.
any clues as to what i can change to make it work?
my current build is really simple, just the regular old, javac, war, deploy
one thing that isnt done is that there is no build dir, the project itself contains a web-inf and the javac is done in place, then the war excludes all the .java resources and wars the project.
edit:
I am looking to fix this problem with least amount of effort - so while switching to maven and learning how to use it might solve this problem, but it will create another problem ;)
You've already identified some of the weaknesses, in your current build.
The easiest way that I can suggest to clean it up would be to start with the directory structure.
I highly recommend using the maven directory structure, I would go further to suggest using maven as a build tool instead of ant, however for some folk that remains open for debate.
The maven directory structure has been well thought out, I really like working on projects that use the maven directory structure, because they follow a convention that allows me to save a lot of time, by knowing from previous experience where to find the application components
java source
unit test source
resources etc.
Also by following the convention, the maven plugins work with less configuration required.
Another useful advantage that I get from working on maven based projects is good code metrics, to measure the health of the application. There are various report available as maven plugins, which will give you new insight into your codebase, including:
checkstyle
pmd
findbugs
and more.
Created a build directory where everything got copied before build
Added some flags to not copy over things that rarely change, like images (also to not remove them on clean)
Started using ant-reload task after deploying code
Now i don't need to restart tomcat on every build, and build takes much less time.
Related
I have an infrastructure project that contains other projects as resources. (Because it compiles them on the fly). One of those contained projects is deliberately one that fails to compile.
This makes the entire project show in eclipse as "with errors".
How can I make sbt-eclipse configure eclipse such that e.g. anything under src/main/resources/foo should be ignored?
Of course this isn't exactly the scenario eclipse was built for, but might there be some clean way around it? as much as it matters, sbt itself does not try to compile these resources.
If not, maybe a way to tell eclipse to not even load source
directories under src/main/resources?
Thanks!
I'm a newbie to J2ee though not a complete newbie. I'm unable to find a good resource (book or video) that could help me understand what exactly happens when we build, deploy and publish. I have a fair idea though. So my questions are -
Is there a good resource out there that can help me understand these concepts? I've read some books on struts and servlets/jsp but they don't delve into eclipse and how/what it does. The eclipse documentation has been helpful but only slightly.
When we build an application the the java files are converted into the class files and stored in the java build path. What else happens during build? Many people use the term 'library dependencies', what does this mean? Also, when people refer to dependencies do they refer to files like xml and tld?
At what stage (build or run on server) does the container check to see if the dependencies are alright? Say for instance, if the servlet class/name in the web.xml file.
Is it appropriate to say that build is basically compilation while deploying the project and running it is the same as executing it?
Familiarity with the servlet specification would help you (perhaps some older version would be quicker to read like 2.4), but general understanding of what you build and how you do it in Eclipse is what you are after.
The way I see it is that during the build Eclipse creates almost complete version of WAR (or some other archive, if you use EJBs for instance) and by publishing you deploy it to some server (this is practically the same thing although Eclipse might just configure the server to use exploded WAR that it just prepared instead of copying it to some "deploy" dir that you are supposed to do if you work without an IDE).
If you configure your project well, the build can only mean compilation, but if you have more ceremony in it, then some source generation and moving files around might happen too.
To address your second question, library dependencies can be files that reside in WEB-INF/lib for instance. Read the spec to know what should be there and what should not. Eclipse tries to copy there all defined dependencies of your project.
I use Java/Eclipse for development and I've never really used any conventional build tools like ant or maven. I generally just rely on building projects through eclipse and I rarely use commandline. I don't really want to spend time getting to know ant/maven, but I'd like to know whether eclipse can really substitute all functionality of ant/maven through its .classpath file any other settings.
(Please don't suggest me some tutorial that makes it really easy to learn ant).
Eclipse knows how to build a project based on the .project and .classpath files.
build.xml is the default filename of build rules used by Ant, so that when you run ant without parameters, it will use this file to figure out what to do.
pom.xml is the default filename to describe a Maven project, so that when you run mvn compile, it will use this file to figure out how to build the project.
Eclipse can import a project based on an Ant build file or a POM file, and create the appropriate .project and .classpath files.
Eclipse, Ant, Maven are all different tools that cannot replace each other. They have some overlapping functions, but also some unique functions.
Being able to build a project using the command line is a very useful skill, and part of being a good programmer. In the Programmer Competency Matrix, being able to build your software using the command line is considered Level 1 (out of Level 0, 1, 2, 3), if you cannot do this, that's not so good.
http://www.indiangeek.net/programmer-competency-matrix/
I strongly recommend to learn Maven.
If your applications have little existence outside of Eclipse then maybe you should keep using Eclipse in that way. But Eclipse is a developer tool (developer as in the person who writes the code). Any other than the most trivial projects have to deal with roles other than developers. and applications go through an entire life cycle. In fact, different axes of life cycles exist, whether it being from a project management perspective, from the perspective of deliverables traversing a number of phases such as coding, compiling, assembling dependencies, packaging, deployment, or from other perspectives.
When you look at those deliverables traversing phases, a lot of these steps can be done (manually) from within Eclipse. So, again, if that works for you, praise. However, it misses automation and for some steps (phases) Eclipse just ain't the right tool. For example: Continuous Integration is not something Eclipse is built for. A CI server may want to checkout your sources and build stuff from scratch. It needs to find dependencies and such, may do so on basis of Eclipse's .classpath file, but that introduces a dependency on Eclipse. Now, I've seen large companies do it exactly that way, but it's a bit clunky because that's again not what Eclipse was meant for.
Instead there's tools that are great at dealing with the entire* life cycle.
*Note that "entire" is a very subjective matter. From a developer's perspective the life cycle may be nicely split up in phases, but other people in your larger organization may find that their duties are underrepresented in any given breakdown of life cycle phases.
Maven or Gradle are such tools. Look at them as an assembly line with a number of stations. The developer is at one of the stations, using Eclipse, but underneath the assembly line keeps rolling. CI is another station, using Bamboo, Hudson, Jenkins or similar, but underneath still the assembly line at work. Within Eclipse the m2e plugin is the connector between Eclipse and the assembly line Maven.
A different approach to the matter is to use scripts, either to replace the manual steps that you're doing in Eclipse, to hook them together, or to complement them. There is clearly many languages that can be used, but within the build tooling domain Ant is wildly popular because its functionality aligns well with exactly this purpose.
If you're a professional software factory (which might already be the case for a single developer project) you need an assembly line. Maven or Gradle give you one out of the box. If you want to swim upstream you build your own, using Ant or other stuff. And if you really have no requirements in this area to speak of, keep doing things manually in Eclipse.
Even though being defined in XML, Ant comes naturally to us as developers, since it has much of traditional sequential programming languages. Maven and Gradle have a different approach, and have thus a steeper learning curve. But it is definitely worth it. If you do it their way things become a breeze and you don't have to code every other thing you want to add to your assembly line. This hand-crafted scripts always start small, but they never stay that way, do they? :)
In addition to all this, I'd like to mention that Maven is also really good at resolving dependencies. That's what it's most known for, but that's not what this question was about, and it is in fact only such a small part of what it can do for you.
I want my Ant build to take all Java sources from src/main/*, compile them, and place them inside bin/main/. I also want it to compile src/test/* sources to bin/test/. I wan this behavior because I want to package the binaries into different JARs, and if they all just go to a single bin/ directory it will be impossible* (extremely difficult!) to know which class files belong where.
When I go to configure my build path and then click the Source tab I see an area toward the bottom where it reads Default output folder: and then allows you to browser for its location.
I'm wondering how to create bin/main and bin/test in an existing project without "breaking" Eclipse (it happens). I'm also wondering that if I just have my Ant build make and delete those directories during the clean-n-build process, that Eclipse might not care what the default output is set to. But I can't find any documentation either way.
Thanks in advance for any help here.
In Eclipse, you can only have one output folder per project for your compiled Java files. So you cannot get Eclipse to do the split you want (i.e. compile src/main to bin/main and src/test to bin/test).
You can, if you want, create two Eclipse projects, one main project and one test project, where the test project depends on (and tests) the main project. However, in that case, each project should be in its own directory structure, which is not what you are asking for. But this is a common approach.
Another way, which I would recommend, would be to not mix Ant compilation and Eclipse's compilation. Make the Ant script the way you describe (i. e. compile the main and test directories separately and create two separate jar files). Change the Eclipse compile directory to something different, for instance bin/eclipse. Use the Ant script when making official builds or building for release. Use Eclipse's building only for development/debugging. This way, your two build systems will not get in each other's way and confuse each other.
Hope this answers your question and I understood it correctly. Good luck!
I've got a simple Dynamic Web project set up in Eclipse 3.6 Helios, but am having trouble getting it to make use of the code in another project that I've got.
I've added a reference to my other project to the build path of my web project, and I've got no problems in terms of compiling, only in terms of deploying and testing the result. The built web application doesn't have a jar in the WEB-INF/lib directory, so fair enough it can't find the code. The question is how I set this up. I've looked through the help that I can find and googled a bit but can't find anything obvious that helps out.
How do I set up my web project so that on deploying it it magically has the code from my dependent project inside it?
Thanks.
Note: Ideally I'd like a solution that doesn't involve setting up some kind of build tool. The web project deploys itself without recourse to any build tool (or at least none visible to end user), so was rather hoping that a references project could be integrated into that easily.
What goes in the deployment is determined not by the build path but by the Deployment Assembly entry in Preferences for the dynamic web project.
Use some build tool like ANT or Ivy or Maven that, on build, copies all the dependencies to WEB-INF/lib
Using a build tool is a good practice to automate build, test and deployment. You may also be interested in plug-ins like Maven Reactor.