I am building a plugin for Eclipse - but as we use Maven as a standard build platform I would like to be able to build the plugin using Maven.
I have found a previous question about using Maven with Eclipse Plugins - but as it is a year old I thought it was worthwhile collecting some new answers:
Is it currently possible to build Eclipse Plugins by Maven AND have nice IDE Integration?
It seems that Tycho has not been driven forward much in the last year - but has anything else been created that fulfils this need or is there an easier way?
Does anyone recommend still the Maven PDE plugin? Is this a cumbersome solution as it is just a wrapper for ANT scripts?
I'm on the Tycho mailing list and I see plenty of feedback that suggests that people are successfully building plug-ins using Maven. My current project isn't doing OSGi development, so I can't vouch from personal experience with the latest version of Tycho. It's also worth pointing out that Tycho currently supports (to the best of my knowledge) a manifest-first approach to building plug-ins (as apposed to POM-first) - this might be a factor in deciding if Maven/Tycho fits your project.
It seems that Tycho has not been driven forward much in the last year - but has anything else been created that fulfils this need or is there an easier way?
The project is definitely active (have a look at the git repository), regardless of the updates of its website and AFAIK Sonatype is using it (successfully) for m2eclipse.
Related
So I installed Apache Netbeans. Installed some of the plugins and instead of just seeing the Java folder in the categories when I want to create a new Project, I see this:
What is Gradle, Ant, and Maven? I am not familiar with Java and wanted to study the language, but I have no idea of what these are.
I keep seeing that I need to have certain plug ins installed and active.
Here they are.
Ant, Maven and Gradle are Java build tools. You don't really need to know the exact differences though.
Java with Ant
The "Java with Ant" option uses NetBeans' own internal project format (based on Ant). In older NetBeans versions this category was simply called "Java"
If you don't need to share your project with non-NetBeans users, use that option.
You will have to manage dependent libraries yourself (download, add them to the project) unless you are only using libraries and frameworks that are bundled with NetBeans. The turnaround times (the time it takes between you hit "Run" and the application actually starts) are the shortest with this option, as Maven and Gradle add substantial overhead to that.
Java with Maven
Maven is a standardized dependency and build management tool. A project defined with Maven can be used by everybody else as it automatically manages (and downloads) any dependency.
Use that option if you know you need to share your project with other people (e.g. hand it in your school or university).
Java with Gradle
Gradle is yet another build tool, which also manages dependencies for your and has more flexibility than Maven. However the build scripts are less standardized than in Maven. But that is also a good option if you know that you need to share your project with other people.
Unless you are using NetBeans 11.1 (which is currently in Beta) I would not use this option as Gradle support in older versions is not as good as Ant or Maven support.
You might want to go through the tutorials on the NetBeans homepage:
http://netbeans.apache.org/help/index.html
There are lot of Answers on how to use Maven in Android and work with it.
However, As Gradle being already available, which manages the build process of Android projects and support complex scenarios in creating Android applications, such as Multi-distribution and Multi-apk,
What exactly is the role of Maven in Android Studio?
And how is it different from Gradle?
The short answer is: The tools do the same thing but in different ways. The difference is how you can use them to build your project. Apache Maven goes for "follow our convention" way and Gradle gives you flexibility. Some devs don't want a new tool or don't have time to learn how to use it properly.
Now the long answer...
To understand properly why some devs are attached to Apache Maven, we have to look at some years in the past.
Apache Maven is a build automation tool just like Gradle.
Maven got released on 2004. Gradle first version got out on 2007 but it did not become as popular as Maven in the early days.
Some devs don’t like having to learn anything new and most companies don't want to risk the exchange of an already running and mastered tool (Maven) for the new kid on the block.
Gradle became popular when the Android development raised. Android's project has a different project structure from Java EE/Web projects. Trying to use Maven on Android's project just feels unnatural, the tool was not prepared to provide flexibility.
Until now, Apache Maven can be used on simple Java EE projects without being a pain in the ass if you already know the forced conventions. So devs that aren't aware of Gradle/did not get in touch with Android apps don't have motivation to change to another tool.
In my opinion, Gradle is better than Apache Maven in every way that you could imagine. It gives you flexibility and tries not to get in your way, a "feature" that you cannot find in Apache Maven. If you don't follow Apache Maven life cycle, your build will fail, that's it.
For example, your code can be spread across many directories in any kind of layout if you are using Gradle. If you are on Maven and you don't follow the 'convention', you'll lose some hours changing your pom (Maven's build file) to be able to understand and handle your folder structure.
E.g.: Java source code must be on src/main/java folder. If you got an old project and the structure is src/java, sorry, You have no guarantee that all Maven plugins will run as expected.
Gradle does us a favor and puts more features for comparison in a very organized chart. Take a look. https://gradle.org/maven_vs_gradle/
Maven is just a tool that manages and simplifies how you build your project. Among many other things (running tests, managing conflicts, documentation, modularization), its most useful purpose is that of automatically fetching dependencies that your project needs and dependencies of those dependencies (transitive dependencies) if any. Dependencies are usually just JAR files that contain re-usable code.
So what does this mean. Suppose you want to use a library such as OpenCSV to generate a CSV file in your application. Non-Maven way: Google search for the library, check if it needs other libraries and if so download them, put them in your project's classpath then build. When you move your project to another PC, copy all the JAR's or it won't work. Maven way: insert something like this in a file named pom.xml:
<dependency>
<groupId>net.sf.opencsv</groupId>
<artifactId>opencsv</artifactId>
<version>2.3</version>
</dependency>
Done. Maven will do the rest for you when you build (download to local cache if not already existing, fetch dependencies, javadoc etc). Even if you were to copy your project to another PC without the JAR's, delete the JAR's etc, if Maven is present it will re-download them automatically when you build.
For more: Link
Today, i donwloaded Spring Framework 4.0.6 latest version but unable to locate the jar files, and i donwloaded eclipse plugin for spring too, here i find nothing and looking for a way to include these jar files into eclipse, here is a pic.
Some tutorials website refers that it contains into lib folder but i can't see it, please help!
It sounds like you have a number of hurdles to overcome:
How to use Eclipse
How to manage Java dependencies
How to use Spring
I'm not sure what your level of experience is, but you may wish to consider using Spring Tool Suite as your IDE - it's based on Eclipse with additonal plugins to aid Spring development.
I also urge you to use Maven or Gradle to manage your dependencies. The Spring documentation provides the configuration for adding the dependencies in both. I'd recommend Maven as a starting point as it is easy to use with little knowledge and is well suited to small, standard projects. Gradle is worth a look once you are comfortable with Maven.
Work though the Guides - I'd start with 'Building Java Projects with Maven'.
Edit
Maven is a dependency management and build tool that favours convention over configuration. Dependency management is powerful in that you can declare a dependency on Spring Core, for example, and it will download all the related dependencies for you.
Gradle performs similar functions to Maven but also provides the ability to use scripting. Gradle is seen by many as Maven's predecessor and has been adopted by Spring over Maven.
In my opinion Maven is easier for you at this stage.
I'm trying to understand what's the best way to setup a project
that is a mix of java and scala and that will use lift.
Lift is intended to run embedded by jetty in another application.
I'm comfortable to work in Eclipse and also used to how it
works with ant as build tool.
I'm a relatively newbie in both scala and lift and get confused
about the different build tool and how to set up things.
I don't really understand maven and haven't really looked at sbt,
but it seem to be the choice of scala developers, but I'm also
dependent on quite some javacode.
Any suggestions, links, tutorials or else on how to setup
the best environment so I can work comfortably in Eclipse
and also build releases quite easily given my scala/java/lift/jetty
enrironment?
I would say that if you are comfortable using Ant as a build tool, Maven should be a piece of cake to use instead. It's main advantage is encouraging conforming to conventions rather than lots of configuration meaning that as long as you follow the standards, setup and usage of any most maven projects is a breeze. I strongly recommend that you invest the time to become familiar with this build tool because it will be very valuable experience/knowledge you can continue to use in your Java career.
With Maven aside, if you are convinced that you and the rest of the project's devs will all be using Eclipse, I would recommend using Eclipse's built in project management infrastructure. It uses Ant under the hood so you will be able to leverage you experience to also run/release from the command-line. All you need to do is set up a eclipse Lift project normally and then to add the scala integration, check out Scala IDE for pretty good IDE support of scala development inside of eclipse.
Good luck!
This screencast is what I used to get started. It starts with a git repository for an SBT template and then adds the Eclipsify sbt plugin to make it into an Eclipse project.
We have several products which have a lot of shared code and which must be maintained several versions back.
To handle this we use a lot of Eclipse projects, some contain library jars, and some contain shared source code (in several projects to avoid getting a giant heap with numerous dependencies while being able to compile everything from scratch to ensure that source and binaries are consistent). We manage those with projectSet.psf's as these can directly pull all projects out from CVS and leave a fully prepared workspace. We do not do ant builds directly or use maven.
We now want to be able to put all these projects and their various versions in a Continous Integration tool - I like Hudson but this is just a matter of taste - which essentially means that we need to get an automatic way to check out the projects to a fresh workspace, and compile the source folders as described in the project-files in each project. Hudson does not provide such an approach to build a project, so I have been considering what the best way to approach this would be.
Ideas have been
Find or write an ant plugin/converter that understands projectSet.psf's and map to cvs-checkout and compile tags.
Create the build.xml files from within Eclipse and use those. I tried this, and found the result to be verbose and with absolute locations which is not good with automatic tools putting files where they want to.
Write a Hudson plugin which understands projectSet.psf's to derive a configuration and build it.
Just bite the bullet and manually create and update the CI configuration whenever stuff breaks - I don't like this :)
I'd really like to hear about other peoples experiences so I can decide how to approach this.
Edit: Another option might be using a CI which knows better about Eclipse projects and/or project sets. We are not religious - this is just a matter of getting stuff running without having to do everything ourselves. Would Cruise Control be a better option perhaps? Others?
Edit: Found that ant4eclipse has a "Team Project Set" facility. http://ant4eclipse.sourceforge.net/
Edit: Used the ant4eclipse and ant-contrib ant extensions to build a complete workspace as a sjgned runnable jar file similar to the Runnable Jar facility in Eclipse 3.5M6. I am still depending on Eclipse to create the initial empty workspace, and extract the ProjectSet, so that is the next hurdle.
Edit: Ended up with a dual configuration, namely that Hudson extracts the same set of modules as listed in the ProjectSet.pdf file from CVS (which needs to have the same tag) causing them to be located next to each other. Then ant4eclipse works well with the projectSet.psf file embedded in the main module. Caveat: Module list in Hudson must be manually updated, and it appears that a manual workspace cleanup is needed afterwards to let Hudson "discover" that there is more projects now than earlier. This has now worked well for us for a couple of months, but it was quite tedious to get everything working inside the ant file.
Edit: The "Use Team Projects" with ant4eclipse and a Ctrl-A, Ctrl-C in Project Panel with a Ctrl-V in the CVS projects in Hudson has turned out to work well enough for us to live with (for mature projects this is very rarely changed). I am awaiting the release of ant4eclipse 1.0 - http://www.ant4eclipse.org/, currently in milestone 2 - to see how much homegrown functionality can be replaced with ant4eclipse things.
Edit: ant4eclipse is as of 20100609 in M4 so the schedule at http://www.ant4eclipse.org/node?page=1 is slipping somewhat.
Edit: My conclusion after using our ant4eclipse approach for a longer period is that the build script get very gnarly and is hard to maintain. Also the Team ProjectSet facility (which ant4eclipse use to locate the projects) which works well for CVS based repositories, but not after we migrated to git (which is a big thing in itself). New projects will most likely be based on maven, as this has good support in Jenkins.
I'm not completely sure I understand the problem, but it sounds like the root issue is that you have many projects, some of which are dependent on others. Some of the projects that are closer to the "leaf" of the dependency tree need to be able to use "stable" (or previously "released") versions of the more "core" projects.
I solve exactly this problem using Hudson, ant, and ivy. I follow a pattern demonstrated by Clark in Pragmatic Project Automation (he doesn't demonstrate the dependency problems and solutions, and he uses CruiseControl rather than hudson.)
I have a hand-written ant build file (we call it "cc-build.xml", because of our CruiseControl roots.) This file is responsible for refreshing the working space for the project from the CM repository and labeling the contents for future reference. It then hands off control to another hand-written ant build file (build.xml) that is provided by each project's developers. This project is responsible for the traditional build steps (compile, packaging, etc.) It is required to spit out the installable artifacts, unit test reports, etc, to the Hudson artifacts directory. It is my experience that automatically generated build files (by Eclipse or other similar IDE's) will never get close to getting this sufficiently robust for use in a CI scenario.
Additionally, it uses ivy to resolve its own dependencies. Ivy supports precisely-specified dependency versions (e.g. "use version 1.1") and it supports "fuzzy versions" (e.g. "use version 1.1+" or "use the latest version in integration status.") Our projects typically start out specifying a very "fuzzy" version for internal projects under ongoing development, and as they get close to a release point, they "freeze" the dependency version so that stuff stops moving underneath them.
The non-leaf projects (projects that are dependents for other projects) also use ivy to publish their artifacts to our internal ivy repository. That repository keeps all past builds of the dependents, so that any project can always depend on any other previous version.
Lastly, each project in Hudson is configured to have a build trigger that causes a rebuild when any of its dependent projects successfully build. This causes them to get built again with the (possibly) new ivy dependent version.
It is worth noting that once you get this up and running, consistent automated "labeling" or "tagging" of an automated build's inputs is going to be critical for you - otherwise troubleshooting post-build problems is going to result in having to untangle a hornet's nest to find the original source.
Getting all of this setup for our environment took quite a bit of effort (primarily in setting up the ivy repository and ant build files,) but it has paid for itself many times over in saved headaches in manually managing the dependencies and decreased troubleshooting effort.
Write a Hudson plugin which
understands projectSet.psf's to derive
a configuration and build it.
That seems like the winning answer to me.
I work with CruiseControl rather than Hudson but in my experience if you can create a plugin that solves your problem it will quickly payoff. And it is generally pretty easy to write a plugin that is custom fit for your solution as opposed to one that needs to work for everyone in a similar situation.
I have tried both Cruise Control (CC) and Hudson for our CI solution. We (as a company) decided on Hudson. But for your question "Does CC support Eclipse project build" the answer is no as far as I know. CC supports many more different build tools and Source Control systems but it is a bit more difficult to configure and use. As for Hudson, it is more simple to configure and use it. We developed our custom plugins for both CC and Hudson for the parts of our build cycle that they do not provide as is. As for plugin development, if you know / use Maven, Hudson is simpler too. But if you are not familiar to Maven, first you need to learn the basic usage of maven to successfully develop a Hudson plugin. But once you understand the basic usage of maven, plugin development, test and even debug is simpler in Hudson.
For your specific problem, I can think of a solution that makes use of Eclipse plugins as well. You can develop your own Eclipse plugin that for instance gets the psf files from a (configurable) folder, and use Eclipse internals to process these psf's. I mean you can use existing Eclipse source codes that takes a psf file, check-outs it's project definitions and compile these projects. This Eclipse plugin of yours may have a preference page (which you can access by Eclipse -> Window -> Preferences) and configure which folder it will use to look for psf files. Your Eclipse plugin should also have a way to start psf processing without user interaction. For this, you can use ipc to trigger your process. I mean your Eclipse plugin can listen for a port, and you can write another java application that will connect to your plugin through this port and trigger its process. As for CI part, you can use either CC or Hudson and use their external process execution support. If you are using Windows, you can write a bat file (for Linux sh file) that first launchs Eclipse that has your plugin installed. Then it launches your java application that will communicate with your Eclipse plugin to trigger your process. From your CI tool you will need to run your bat / sh file to trigger your process.