I am new to Eclipse plugin development.
I have been modifying a plugin that was used in our team, and i don't want to add new bottle-necks.
Also the eclipse to which i am integrating to is taking too much time to install the plugin. any suggestion on how to identify the reason for that?
So i would like to know some tips on
How to check performance of a plugin - any tools that are available. (like jprofiler in java or any other performance analyser tool)
How to check for bottleneck in my plugin code using some tools.
And is there a doc that tell the do's and don't of the plugin development.
Examining performance of a plugin isnt that much different from any ordinary java program. It works in similar ways. Look at this question for example.
It takes long to install; It seem like that would be an issue of the underlaying program, P2, rather than your plugin. At installation of a plugin your manifest is read, some information about your extensions are saved in Eclipse. The actual plugin is copied. Dependencies checked. It seems like these things shouldn't take that long, unless you have a very large plugin?
Perhaps you are installing the plugin into an environment that already have alot of plugin? Try downloading a clean Eclipse, do you have the same issue there?
Make sure you don't set your plugin to start automatically when the user starts Eclipse. That is bad behaviour that causes clutter and general slowdown for the users. The plugin should be started when the user actually wants to use it, not a second before.
Also my answer to this question might help with the general design of the plugin.
First of all, measure everything, as you should never try to optimize just by guessing performance bottlenecks. I recommend Yourkit for all Java code (Eclipse plugins as well as plain Java code).
The second important thing: If you have functionality that takes more time than the twinkling of an eye, make it a job in Eclipse, so it can run in the background. It is fine for something to run some seconds, if it does not stop the user from working.
I am trying to get up to speed with Java after spending my last couple of years with Python and Perl. And boy is this hard! First of all, there's no easy to use build system that can do only what you want it to do without adding tons of boilerplate. Then, how to add dependencies to your project, how do you run junit tests from the build systems (say ant for example)? How can I make the build system download the dependencies on the fly (or can't I?)
Can I find some docs around that can get me up to speed with this without reading a couple of books ? I am trying to be "agile", but the comeback is hard.
Please feel free to close it if it is too subjective. Thanks!
This question is close to textbook trolling... anyway.
There are a lot of build systems that resolve dependencies for you out there (maven, ant, buildr, etc).
I'd say go with buildr since you are familiar with scripting languages.
NOTE
Though many people pointed out maven, considering your background (perl, python, etc) that will make you hate java even more (it's a sea of <XML> out there dude!). Please consider buildr if you feel frustrated enough
You don't mention which build systems you've tried (other than ant). I feel either Maven or Gradle would meet your needs (although I think Maven might fail your "tons of boilerplate" test; it certainly fails mine).
There are an awful lot of questions here. "Maven" is the Java build system that automatically downloads dependencies; it is based on Ant, which does everything else you ask about (running tests, etc).
If you want to use Maven, get started by using Maven's quickstart docs and examples.
Is it possible to write Jenkins plugins using Python (via Jython), and if so, where would I get started? I don't know Java (and don't have a real interest in learning it at the moment) so being able to use Python would be nice for me.
There's no docs on that. Frankly your problem with be you must understand how the interfaces and extensions map from java to jython to write it.
Here are links on writing Jenkins plugins
Let's you embed either Jython or Python scripts and run them from a plugin If all you nee to do is run a simple script, that be what you need.
If your goal is to execute Jython code within Jenkins, you may want to have a look at the Jython Plugin.
Starting version 1.6, you can actually install Jython packages (say if you have your own library you'd like to use), and it'll automatically sync up the packages across all Jenkins slaves.
Since Jython can produce Java classes I see no reason why this should not work.
Note that you will need to learn at least some things about Java (mostly the platform, not necessarily the language) in order to be able to write plugins for Jenkins.
I've grown disillusioned with Groovy based alternatives to Ant. AntBuilder doesn't work from within Eclipse, the Groovy plugin for Eclipse is disappointing, and Gradle just isn't ready yet.
The Ant documentation has a section titled "Using Ant Tasks Outside of Ant" which gives a teaser for how to use the Ant libraries from Java code. There's another example here:
http://www.mail-archive.com/dev#ant.apache.org/msg16310.html
In theory it seems simple enough to replace build.xml with Build.java. The Ant documentation hints at some undocumented dependencies that I'll have to discover (undocumented from the point of view of using Ant from within Java).
Given the level of disappointment with Ant scripting, I wonder why this hasn't been done before. Perhaps it has and isn't a good build system.
Has anyone tried writing build files in Java using the Ant libraries?
Our build system is primarily based upon exactly what you describe, and it works very well indeed. We use the Ant tasks (especially the file-manipulation tasks) from custom java programs which assemble the application using auto-discovery of convention-based application module layout.
You may need some glue Ant XML, to do things like compile the build scripts themselves, and to actually invoke the java to perform the build, but it's minor.
Not only is java more readable than Ant, especially when it comes to conditional execution, but it's vastly quicker. Our Ant-based build used to take a minute or so to assemble an EAR, now the java based version takes about 5 seconds.
You had a fine idea. Cliff Click had a similar idea: http://blogs.azulsystems.com/cliff/2008/01/i-hate-makefile.html
If you go through with it I advise you to keep it as simple as possible so your build system doesn't need a [non-trivial] build system itself.
Given that Java is compiled, this is kind of a chicken and egg problem. You need to build your Build.java to build your project.
Ant currently supports inline scripting using BeanShell, Groovy and a bunch of others, that can really help reduce the need for that.
EDIT: In response to Dean's multiple comments, if your build consists strictly of a long proceedure, then indeed you don't need ant's build script. However, the power of the build script is that it ensures that dependencies are only executed once while allowing for mulitiple entry points, something that is far from trivial if you roll your own.
If you don't like the XML format, you are not alone, the author of ANT agrees with you. However, if your view of the build process is something that can be launched from your IDE as its only launch point, I would say that your build needs are quite simple.
EDIT2: I upvoted skaffman's answer because it speaks directly to the question. In the comments we seem to agree that the approach is fine for a procedural build, but would not work for a declarative one, and that you need at least a little ANT xml to get the ball rolling with your Build.java to avoid the chicken and egg problem. That seems to get to the crux of the matter.
An important point seems to have gotten lost here.
Ant is written in Java and what I'm looking for is a better way to use the Ant tasks (APIs in the Ant libraries) than through xml. For the life of me I can't see how using xml to invoke Java would ever be better or easier than using Java to invoke Java.
The one obstacle is that the xml approach is documented whereas the Java approach is not documented so I'll have to download and get familiar with the Ant code.
I held back from posting this question for a couple of weeks because I was sure that someone had done this before and that my google-foo just needed improving. It just seems so obvious to use Java to call the Ant APIs instead of xml that I'm still surprised that there wasn't a parallel Java-based approach developed for Ant as well as the xml approach.
Just because it is obvious doesn't mean that someone has done it before, though.
While I suppose its possible, you would probably be better off with shell scripts then writing a full on java program to simply automate builds.
You would be missing out on one of the key uses for ant, which are the easy-to-specify filesets and easy to read in properties.
I have stuck with ant as Groovy is too close to writing an entire application to just build your real application. Too complicated for the trouble.
While using Ant tasks inside Java programs is fairly easy, I probably would stick to Ant build files if I were you. If you're doing some groovy development, if Eclipse doesn't do what you need, maybe you need to look elsewhere(IntelliJ, NetBeans, etc.).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am trying to revamp our build process, which is currently a gigantic Ant build.xml that calls into other ant build files and executes several Java classes to perform more complex logic that would be impossible/scary to attemp in Ant.
Background:
experience in Java and Ant, some Groovy
Windows platforms
Goals:
run as a combination of command line cron and when a servlet is posted to
as simplified as possible, fewest languages and bouncing between techs
I need higher level logical power that a language like Java provides and Ant is pretty easy and we use the filtering to override default properties files for different clients. Mostly I'm wondering if there is something other than Ant/Java that people use.
Except the Ant you mentioned and the scarry make/autotools, the mainstream tools are:
SCons
Jam
CMake
Maven
I use SCons, because it is python based, well-funded and elegant.
Jam seems to be the most pragmatic one.
I don't know too much about CMake.
Maven may be the choice for you as it is Java centric and more high level than Ant.
More you can find at wikipedia: List of built tools
If you pursue Maven, then you will have two problems: a complex build and learning the f#*#ing "magic" of Maven. Maven just makes the problem worse because it is obtuse and overly-complicated.
I inherited a legacy Maven 1.x build at a large Fortune 500 company. I used Maven 2.x by choice on many other projects in recent years. I evaluated Maestro, in hopes that it might make Maven tractable. My conclusion, like many other peoples' (check the 'net), is that Maven is a big step in the wrong direction. It definitely is not an improvement over Ant.
I have used Ant for MANY years, including writing a large open-source library of Ant helper scripts. I have also extensively used its .NET cousin nAnt. However, Ant has two major failings. One, XML is simply not the right place to be doing build tasks. Two, Ant and XML do not scale well to large, complex builds. In fact, I have written a lot here at SO about my experiences in that arena (and with Maven).
Industry leaders have concluded that a build is just another application, and should be approached using general application tools. However, since it involves system-level and cross-platform functionality, most development languages/platforms are not properly suited (which includes Java, and therefore Ant and Maven). That also excludes .NET.
I spent two years looking for an alternative, and I found it: Python. It has the right combination of system-level access, cross-platform portability, simplicity, readability, power, robustness, and maturity. SCons, buildbot, setuptools/easyinstall, and base Python are my current target platform for the build process. When necessary, integration with Ant, Maven, and any other such tool is easy. Meanwhile, I can use these tools for the core of any build on any platform with any source language. No more roadblocks, no more crazy complexity, no more supposedly-helpful "declarative" scripting, no more black-box f#*#ing "magic".
If you can't switch to Python, then try Ant + Ivy (at apache.org). It gives you Maven's cool repository without most of Maven's evils. That is what I am doing as well, where necessary and suitable.
Best wishes.
Also take a look at
Gant
Gradle
While more general purpose build systems like SCons are very powerful, the Java support is somewhat limited in comparison to systems specially tailored to build Java projects.
I like using Rake as you can fall back on the power of the whole Ruby language and it's framework library when needed.
I use Ant, taking advantage of its macro feature. If you layout your project in a consistent mannner, you can eliminate a lot of the duplication by writing macros.
I've been building up an Antlib containing macros and custom tasks that I reuse across multiple projects.
Alternatively, some people swear by Maven. Other people just swear about Maven.
I use Maven, not just for build, I also use their release/dist plugin.
In a pair of commands I can have code that was in a source control to build, package and release.
The release plugin handles updating the version numbers, dist handles how to put everything together and zip it.
Ant looks hard when compared to Maven. Sure there is a learning curve with Maven, but reading a pom.xml is far easier than reading a build.xml.
Maven needs to be far less verbose.
I like Ant but only if you spend the time to write your own Java plugins to encapsulate complex actions. It isn't hard but unfortunately most people try to write their logic in XML w/the ant-contrib stuff. I think this is a huge mistake.
I've heard good things about rake and the groovy tools (mentioned in another comment) but I've got no experience with them.
If you're trying to script together several steps in a life-cycle you might be better off using a process automation based build server like AnthillPro (Cruise, BuildForge and Electric-Commander are the others in this space).
Another place to ask this kind of question is the CITCON mailing list. CITCON is a conference on Continuous Integration and Testing and the associated mailing list has turned into a really great community around these kinds of topics.
(I'm an organizer for CITCON but a labor of love not a profit maker. It really does have a really helpful mailing list. If I was pimping something for money it would be The CI Guys. ;-) )
Stick with Ant since you're building Java. I've mixed Ant/SCons for some JNI work, but in general I'd stay with Ant especially since you've got an existing build setup in Ant. Porting to Maven will be like shoving a square peg through a wall with no holes.
Embrace your custom Java logic for any and consider writing proper Ant tasks instead of executing external Java code. I solved some very complex parts of our build process by simply extending Ant to do exactly what I needed, ex. managing icon resources for a large gui project or injected subversion information directly info jar manifests (thank you SVNKit)
I'd go with Ant any day of the week.
It's not perfect; XML is very verbose and implementing any logic at all is almost impossible, but even the most junior engineer on the team can at least understand what the ant file is doing within a day.
Complex logic can be refactored using java and integrated in ant, if you so wish. Ant gives you all the power of java:)
Dependency resolution is difficult no matter what system you use. With ant, the best solutions seem to be either a lib directory in which all your jars are stored, or an internal web server from which the libraries are copied at build time.
I also have some experience with both Maven 1 and Maven 2. That experience left me with the feeling that Maven is awesome for hobby projects, but can have complications for software you need to maintain over time.
I see two important problems with Maven:
Any dependency you import using Maven may change over time without you knowing it, resulting in weird problems.
You import the licenses of not only the software you import directly using Maven, but also the licenses used by the libraries which are indirectly imported
In short, I dislike the fact that the build depends on the time it is started. That can be a true problem when producing a bugfix release a year after the production release.
These problems can of course be managed (maybe using a nexus proxy) but you need to consider them before rebuilding the build system. At my company we decided to use Ant for all new project and try to port maven 1 and 2 to ant whenever the occasion presents itself. It's just too difficult to keep it working.
My advice, if you and your team know how to deal with ant, try to refactor your ant file and don't jump on some other build tool. It just takes too much time to get it right; time you could spend making money and surviving as a company :)
I use Rake everywhere I can. Where you need to build java code you might use it with jruby, or look at something like: buildr
We use luntbuild. It's a web app that's very easy to use. It will check out from CVS/SVN, automatically increment the version/build number, execute build tasks in ant scripts and tag your repository with the new version. Can schedule automatic builds, have it email you or contact you via IM, also has security and build dependencies.
We're still using version 1.2.3 but I see it's up to 1.6.0. It just works.
http://luntbuild.javaforge.com/
EDIT: Re-reading your question I see now that you're looking for something to replace Ant. In our case Ant is not really a problem. We have projects setup in Netbeans, which uses Ant for building and we just have to implement some hooks into the existing scripts provided by Netbeans which is very easy to do.
EDIT: Looks like you can call Ant from Groovy. That would be nice because then you can re-use all the tasks that already exist for Ant.
http://groovy.codehaus.org/Using+Ant+from+Groovy
Try FinalBuilder
It provides a GUI interface to whatever your build process may be and has a native action for almost everything, plus an action studio where you can create your own.
With a bit of planning can be very streamlined.
I have to add to these one solution that I find I can't live without ... its called Hudson. It only takes a few seconds to setup and you can usually get away with most of whatever your existing ANT files are already doing.
Additionally, Hudson provides a great way to "cron" builds, execute test cases, and generate "artifacts" (e.g. build products) in a way that anyone can download.
It is hard to capture all that it can do for you ... so just try it out ... you will no be disappointed.
Maven is really good choice to do large builds...in the majority of the cases where it doesn't work is very simple. The people misunderstand the concepts of Maven. If your are working with the "maven way" you will end up with smaller modules which gives you a better architecture in your software. On the other hand things like Hudson will support you in reducing build times by using Maven, cause Hudson supports to build only changed modules which is not supported by any other build tool. The problem with Maven is to learn and understand the concepts of Maven for example the structure of a project(folders etc.) or only a single artifact etc. The build-cycle will support you in different areas: compiling, packaging, deployment and release which is not supported by other tools (only if you implement it by hand...I've wrote many large Ant scripts to reach this)...Other problem like changes over the time are caused by ignoring the best practice and pin pointing versions which are used.
I use mainly Ant, but Maven is also a good tool. With ant you can do anything you want.
At our company, we created a general purpose ant builder that does a lot of things: Build, Compess images, minify, generate documentation, pack files.. It is open source and we are open to improvements. You can get it here:
https://github.com/edertone/TurboBuilder