I have an Eclipse project (which is generated via a maven archetype and requires m2e) that I want to deploy to many users. Currently the way I'm telling them to do it is extremely manual, (i.e. download this plugin, download that plugin, download this m2e connector). Is there a way to write down plugin dependencies somewhere in my project so that when the project is imported Eclipse will tell the user "This project depends on you having these Eclipse plugins installed, would you like Eclipse to auto-fetch the plugins for you?"
Please read about deploying eclipse plugins first, all of that is available in the basic infrastructure of eclipse.
Whenever you install something via the update manager in eclipse, you don't install plugins as such, but instead you install features, which are groups of plugins plus dependencies to other features. So you have to do 2 things when creating a feature for your plugin:
List all dependent features in the feature editor.
On the tab "Sites to visit" you have to list the update site URLs of the dependent features.
P2 update manager will auto-magically discover everything needed during the installation process of your plugin afterwards.
Yes there are several tools created by Eclipse member companies (both with free to use and for-pay editions) that will do exactly what you want. Both products have the notion of "profiles" that is a pre-set configuration of Eclipse plugins (basically one of the available packages plus a bunch of plugins). Then once you have this profile configured you can freely share it with our team via email or whatever sharing mechanism the products provide. Once your team members accept and start "using" the profile those software products will provision exactly what dependencies everyone needs to run your Eclipse projects.
Pulse from Genuitec
They have a Community edition and a Managed Team edition based on your team's needs.
Yoxos from EclipseSource
They have a free plan if you want to share your profiles publicly. If you want to keep them private they have a pricing plan for that.
Not sure how much help this is, but why not use the Eclipse Marketplace if it is available. Saves you the effort to manually download and install the plugin.
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
I just started developing a project in Spring MVC and i want to know how important Maven is.
The following are the key features of Maven :
Simple project setup that follows best practices - get a new project or module started in seconds
Consistent usage across all projects - means no ramp-up time for new developers coming onto a project
Superior dependency management including automatic updating, dependency closures (also known as transitive dependencies)
Able to easily work with multiple projects at the same time
A large and growing repository of libraries and metadata to use out of the box, and arrangements in place with the largest Open Source projects for real-time availability of their latest releases
6.Extensible, with the ability to easily write plugins in Java or scripting languages
Instant access to new features with little or no extra configuration
Ant tasks for dependency management and deployment outside of Maven
Model based builds: Maven is able to build any number of projects into predefined output types such as a JAR, WAR, or distribution based on metadata about the project, without the need to do any scripting in most cases.
Coherent site of project information: Using the same metadata as for the build process, Maven is able to generate a web site or PDF including any documentation you care to add, and adds to that standard reports about the state of development of the project. Examples of this information can be seen at the bottom of the left-hand navigation of this site under the "Project Information" and "Project Reports" submenus.
Release management and distribution publication: Without much additional configuration, Maven will integrate with your source control system (such as Subversion or Git) and manage the release of a project based on a certain tag. It can also publish this to a distribution location for use by other projects. Maven is able to publish individual outputs such as a JAR, an archive including other dependencies and documentation, or as a source distribution.
Dependency management: Maven encourages the use of a central repository of JARs and other dependencies. Maven comes with a mechanism that your project's clients can use to download any JARs required for building your project from a central JAR repository much like Perl's CPAN. This allows users of Maven to reuse JARs across projects and encourages communication between projects to ensure that backward compatibility issues are dealt with.
Getting started with maven only takes about 10 minutes. Reasons why you should learn maven:
It helps you manage your dependencies very easily so you don't need to add jars to your project classpath manually
You can run unit tests
Has over 20 useful plugins which you can use. Plugins make up lifecycles like test, package which make your work more efficient
You can use it to build your project
The most important thing about it at the beginning is that you don't need to worry about setting up your project by adding dependencies, maven does it for you automatically.
Read this spring guide for building with maven
Any other guides in this section for spring boot has the same mechanism
I'm looking for some best practices to rollout/setup a complete project setup with Eclipse to my dev team.
It's a maven based project that will work without Eclipse. But we want to distribute a preconfigure Eclipse version that have all plugins installed, we want to have a local update site to rollout update of this setup and so on.
Is there any good way to achieve this kind of setup? I know that i can provide a update site which contain some plugins, but can i define a set of plugins?
Is it possible that Eclipse pmd, Checkstyle, Findbugs and the code formatter use the settings from Maven?
Here are the two most important questions for me:
How to define a plugin set for an Eclipse installation, so that all developers have the same set of plugins installed.
Any way to use the configurations from pmd, Findbugs, Checkstyle and code formatter from Maven to be used inside eclipse
I had similar issues some time ago. Setting up eclipse with a bunch of plugins is really annoying. proko mentioned a plugin I didn't know, so I compared it to the solution I am using right now.
After 15 minutes of installing, trying it out and reading the doc, I gave up because it seems too heavyweighted for my needs.
The solution I am using myself is yatta Profiles: http://profiles.yatta.de
Especially your first requirement can be tackled with it. You can install all the plugins your team needs, click on a button to upload the configuration, and send the link to your team. Your colleagues just have to download your profile. All plugins will be installed automatically.
Here’s a link to an Eclipse profile with the plugins you mentioned (pmd, checkstyle, findbugs, maven): https://marketplace.yatta.de/profiles/a7Ig
Beside of your Eclipse installation via update site, here a possible plugin to manage configurations (question 2):
To distribute any settings of 'window-preference' to your whole dev team I can recomment 'workspace mechanics'.
You can record your settings and then provide them via your dev server.
If you distribute a shared Eclipse it's also easy to provide the proper workspace mechanics URL for any Eclipse installation (see Enterprise Configuration of Workspace mechanic).
Changes to the settings are checked on startup and the developers are always up to date.
Further information can be found on the official project page: https://code.google.com/a/eclipselabs.org/p/workspacemechanic/
This is part of a Development-Handbook in your Team!
All important plugins contains support for external configuration, also checkstyle, code-formatter and findbugs.
Distribute those configurations in a single website.
code-formatter: Open window->preferernces Java>Code-style>formatter -> Import and specify the configuration from a website you created (its a file dialog but you can specify uri's also).
Checkstyle: Open window->preferernces>Checkstyle and press New ... then choose External Configuration File
Findbugs: similar to Checkstyle.
There is no other way. We use a wiki to distribute the Development-Handbook and the Configuration.
I'm looking (if it exists) a way to import few XCode java projects into eclipse, maybe a plugin or something that starting from a pbxproj file, generates an eclipse project (.classpath + .project).
After many searches on the internet I reached this URI:
Migrating from XCode to eclipse.
There you can read this:
Migrating with a script is pretty easy and it is not a complex script, it just copies files and puts Java classes into the package structure. The script does not do everything, it just takes the drudgery out of it. You will want to convert all the frameworks before the applications as the applications will need the frameworks to build.
The first step is to create a new Eclipse project, a Wonder Application or a Wonder Framework, and give it the same name as the Xcode project. This does NOT mean you will be using Project Wonder, it just refers to a project layout developed for Wonder.
cd into your Xcode project, Run ./fleeto /path/to/eclipse/project, Refresh the project in Eclipse (select and press F5 or use the context menu), Repeat for other frameworks and applications.
For working in Eclipse you will want to have the framework projects included as required projects in the applications and frameworks that use them. For each project, Properties - Java Build Path is the central place to manage your project. Select the Projects tab and add the framework projects that this application references.
These project dependencies work in Eclipse but not for deployment. For deployment you need to reference frameworks from their installed location. Install the framework (see Install on the context menu).
Then go to the Properties - Java Build Path - Libraries tab and configure the WO Frameworks library. Expand the nodes and select the installed framework(s).
REMOVE the checkmarks beside the ERJars and ERExtensions framework if you are not using Project Wonder. Finally, adjust the order on the Order and Export tab so that required projects appear before the WO Frameworks Library. Doing this ensures that Eclipse uses the current code and not a previously installed version.
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.