I have a couple of projects in eclipse which I now manually export as plugins from eclipse with the following steps:
1) Right click on example_project_plugin_1 in the Project Explorer View
2) Select Export
3) Select Plugin Development > Deployable plug-ins and fragments
Then in the folder eclipse>plugins folder, I can see the archive/jar file of these plugins.
However I want to automate this system.
These plugins are required by another project (say project_to_test) which I'm trying to run and test and I am using Maven to automatically build test cases written using RCPTT running on a jenkins server.
So basically what I want is, without having to manually export as plugins from eclipse, it should be automatically exported as plugins when I call project_to_test from the jenkins server.
I found Tycho but it seems very complicated. (Maybe there's an easier way or tutorial somewhere of how to use Tycho for my particular use?) I tried Ant too but it's also manual work. Is there any easier way to do this? I am quite new to this so I need some direction.
Thanks in advance!
Tycho is probably the best way to do it, as you are already using Maven you should be well on your way. Tycho is simply an extension of Maven (plug-ins, but I am afraid to say plug-ins too many times with different meanings :-).
There is an excellent Tycho tutorial out there: http://codeandme.blogspot.co.at/p/tycho-articles.html so that is the place to start.
However, if you really really don't want to do that, then you probably want to use PDE Build. That is the traditional build system of Eclipse, but it has its weaknesses. You should know that Eclipse does not even use PDE Build to build itself anymore, it uses Tycho.
To use PDE Build from a command line you need to use Ant. The manual work that you refer to is (mostly) automated through a PDE feature that creates that Ant files for you. Right-click on a project, select Plug-in Tools -> Create Ant Build File
Once again, I feel compelled to encourage you to take the plunge into Tycho now, rather than invest more time in the PDE Build way. You are clearly ahead of the curve in other areas (you are doing GUI testing!) so now is the time for automating your builds too.
Related
I started a Java project without using any project manager, because I didn't know about them and also I don't really like any of the IDE that are out there. But then I discovered Maven and that VSCode, which is the editor I'm using now, supports it, and I thought that this tool might be handy to debug, run and build my project. So I thought that it would be a good idea to use this tool to manage my project. The problem is that this project is in a pretty advanced state, so I can't afford to start it over right now, and I couldn't find the way to make maven use the folder structure that I want. So my question is how can I force maven to use a folder structure that I want.
I am looking to make my development life a little easier. Currently I have to go through multiple steps to deploy my code base to a test environment to allow for QA to do their work. These steps are not difficult just that I want to automate it so that it can auto run twice a day.
One thing that I am having trouble figuring out what to do is to automate my build artifacts phase in IntelliJ. I have two modules in my IntelliJ projects and I build artifacts for one of them.
The steps I go to build the artifacts are
Build --> Build artifacts --> Select Artifact to build
I was wondering if something like Ant would be able to do the job? I am not familiar with Ant, so I thought I was ask people opinions on it first.
Ant can do what you want, but personally I prefer Gradle or Maven to build my projects. You can use them even to deploy your app into test servers. Here's a simple tutorial for you to start learning gradle (my favorite one at the moment)
Usually what I do is have my run/debug also build my artifacts. On the bottom of "Run/Debug Configurations" in Intellij you can add "Build Artifact" to "Before launch: Make, Activate tool window".
You can probably build the artifact with ant by generating build.xml through Menu --> Generate Ant Build but would have to keep it updated. Maven or Gradle is a better option in this regard.
Ideally though, you would want a CI tool like Jenkins (there are others) to deploy your code to your environments. So when you push (with your VCS) or trigger it, everything is built by Jenkins and sent to where it needs to be for the QA team.
http://codurance.com/2014/10/03/guide-to-deploying-artifacts-with-jenkins/
To build Artifact from command line I used Ant.
These are the steps:
Install Idea Ant Generator Plugin
https://plugins.jetbrains.com/plugin/14169-ant-build-generation
and use "generate ant build ..." to create an ant xml file of your project (and modules).
Open Ant tool window and add the file generated.
Click build.all.artifact to test the build
Now download Ant from Apache repository https://downloads.apache.org/ant/binaries/
Unzip and add the folder to your SYSTEM PATH.
Now from command line:
ant -buildfile myfileant.xml build.all.artifacts
I have a eclipse workspace which constitutes of 15 different java projects . To configure the eclipse workspace , every time I need to add the java projects manually and add the dependency and refrences in the java build path.
Adding all the projects and resolving dependency every time becomes a manual and redundant task. I explored on the .classpath inside the every projects which stores the dependency and refrences information.
I would like to automate this redundant process.
Have any one tried doing that , any inputs will be helpful.
I don't need to add same project more than once , but often need to create a new eclipse workspace with new code changes and delivery (I can't take some of the changes in the current work space).In simple terms for e.g if some one need to create eclipse workspace again and again , or multiple people need to create the same workspace for their work . How can we reduce that manual effort?
I am still a little unsure about your motivations but I am going to assume that by new code changes and delivery you mean a different revision/branch of the same code base. For this purpose and for many other reasons, if you are not using source control like SVN or Git, look into it. These tools are priceless and also free.
Eclipse
I don't think this is technically part of your question but I wanted to add it for completeness. If you're implementing the techniques below, it is also handy to have a 'fully loaded eclipse'. I keep a 'fully loaded eclipse' on a network drive somewhere with some plugins pre-loaded so that new additions to the team don't have to download/install the plugins. It's not hard to do since eclipse doesn't need to be 'installed'. You can just copy the eclipse folder to where you want it and run it. Personally I like to include plugins for source control, code style, code coverage and metrics but you should include anything that you use consistently in your project.
The Workspace
To copy an existing workspace (not including any projects, I'll get to that later) all you have to do is copy the .metadata folder from an existing workspace folder to an empty folder that will be your new workspace folder. When you start up eclipse simply choose the new workspace folder and you will have all the same preferences as you had in the other workspace.
I have used this technique before so that when people join a project they can take a copy of a 'clean workspace' I keep on a network drive somewhere that helps them get up and running quickly. Preferably, this 'clean workspace' should not have any preferences that are only personal preferences like having the perspectives setup just the way you like it but should only have preferences like Ant global properties, compiler compliance level, pre-made commonly-used external tool and run configurations etc.
Projects
For the projects themselves, I would recommend checking them into source control including the eclipse .project and .classpath files. The SVN plugin (subclipse) makes it very easy to do this. Then when someone joins your project, all they have to do is check them out as projects in their new 'clean workspace' which is also very easy to do. Since the project you're checking-out already has the .project and .classpath files, all of the dependencies are already setup! Just make sure that all the jars and any other dependencies are checked-in with the projects.
Workspace Setup Procedure
Take a copy of the 'fully loaded eclipse'.
Take a copy of the 'clean workspace'.
Check out the projects into that workspace.
That's it! Your new recruit should be ready to go!
Multiple Code Branches
Now, if I was right to assume that by new code changes and delivery you mean a different branch of the same code base, creating a workspace for a different branch as easy as following the same steps but checking out the required revision or branch instead of the latest version from the trunk. If you don't quite understand what I mean by that, read up on source control.
Cudos
Good on you for taking the time to do this, I have been in projects where it can literally take a day to get setup...
Maybe little late, but stuck into the same problem and found a tool in eclipse marketplace that helps to manage setting up and launching eclipse all time for different branches, new developers or other reasons.
The tool is called yatta.
With this, one can create profiles which can be based on their current running eclipse with all the tools, plugins, workspace, CSM repos and what not.
This profiles can be exported to yatta profile hub which can be public or private and later shared with different developers and can be imported and launched.
You don't say whether you're using a build tool other than Eclipse, but if not you should.
Eclipse is able to parse Ant files to discover the source directories and libraries. And Maven and Gradle can both generate Eclipse project files for you to import.
As a longer-term benefit, using a build tool means that you can easily build and deploy your projects without any need for Eclipse. And it will be easier for new team members to work on the projects, as they won't need to figure out all the dependencies.
If you don't already have people with expertise, I would recommend Maven. It's easy to set up a basic Java build script, and its dependency management features are IMO better than the alternatives. It will, however, force you into its way of doing things, particularly wrt source tree layout.
You should really look into build tools like Maven, Ant, .... Those can generate needed classpath variables for you automatically and can do many more things as well
If you're checking out the projects from CVS / SVN in Eclipse, then it's possible to create a Team Project Set. This is essentially an XML file that will contain a list of projects and their source repository path
It can be exported via File | Export | Team | Team Project Set, and imported into another workspace via File | Import | Team | Team Project Set
There's more information on this feature at this link on Javalobby
Using vagrant it is quite easy to automate setting up an entire desktop development environment.
See the answer I provided to a similar question here, which has links to scripts that automate checking out maven projects, creating an eclipse workspace and importing the projects.
I would like to generate Eclipse Java Project with my Java program. When I click a button: it will generate an eclipse project with the parameters I specified (source path, library, ...)
My questions are:
is there a way to do that ? and how ? (api).
it is possible to generate Net-beans project too ?
Best regards,
Florent
Maven enables this and many more things around creating, bulding, testing and developing Java projects.
Create a Java project from command line. Then, using Maven create NetBeans, Eclipse or IntelliJ IDEA specific project files. Or even easier, just import already created Maven project directly from these IDEs.
Create Java Project in Eclipse first. Then look into directory created. You should find there two files: .project and .classpath. These are the files you should create in your app to get what you want.
Also for eclipse available M2Eclipse plugin to provide some Maven feature from Eclipse IDE.
http://m2eclipse.sonatype.org/
While Maven is the way to go in the long term, the best way to start a project in Eclipse is:
Hit Ctrl+N and choose Java project
Fill in the project name fields
Copy your files from wherever they are to the newly created project (ensuring to preserve package hierarchy)
Refresh project from File menu
Create a Run / Debug profile to run your app.
It should be fairly simple to get up and running this way.
The reason people recommend Maven is because Eclipse is an IDE. It's great for development but its no good for resolving external dependencies or for command line / automated builds. Maven is an IDE neutral way of building and becomes essential the more dependencies a project pulls in.
Unfortunately Eclipse integration with Maven is pretty clumsy and can be summarized with these very broad steps:
Install Eclipse Helios
Install m2eclipse from the Help | Eclipse Marketplace
Mess around with eclipse.ini to make Eclipse start from a JDK.
Configure m2eclipse to use any existing Maven local repository
Hit Ctrl+N and create a new Maven project and skip archetype selection
Copy all the source files from the old project into the new ensuring to use Maven's conventions for file locations. (e.g. source goes in src/main/java)
Create a Run / Debug maven target to clean / install the app
I say broad steps because there are a lot of gotchas. For example if the source is Java 5+ you might have to tweak the pom to set the compiler level. Best to get Eclipse working and then worry about Maven.
Netbeans has vastly better out of the box support for Maven although IMO Eclipse is still the better IDE for other reasons.
I have been working solo on a project for some time, and now, new developers are likely to join the project for various reasons.
I, of course, use a version control software but I am afraid importing my project into Eclipse and making it run might prove a little difficult for new comers, and I want to make it as clean as possible.
When I first took over the project, it took me almost two days to have the project built and run it, I documented every step and fixed the most obvious errors, but not all, and I want the project to run as it is when imported.
The project is a mix of java projects for the backend, a j2ee project for the server and a flex project for the client.
The IDE is going to be Eclipse
The version control software is Perforce
Here are some of the specific problems I have right now, should I fix them, and how ?
Eclipse environment variables are used for libs, all the libs are in a folder in the j2ee project but are used by all the java projects (they have to be set in each IDE the project is imported into)
Runtime JRE is specified in .classpath for each project, so each projects property must be edited when trying to build the project in another environment
Apache server is specified in j2ee project property
To avoid exporting the jars of all the java projects into the j2ee project each time I modify the code, there are linked folders in the j2ee projects, linked to each java project bin folders
For (4) I will probably have to use maven, but is it possible to fix problem (1) (2) and (3) without using maven ?
The alternative is to have a one page set up instruction document
Also do you have any other general or specific advices as to how organize this whole mess.
Thank you
Dependency management is a must - use Maven. If you can't use maven, because you are already using ant, go with Ivy.
Make the project buildable with one click - be int ant build all or mvn package. Maven provides integration with the IDE (via the plugin).
Don't reply on IDE metadata. like .project and .classpath. You can still commit them to ease Eclipse users though, but don't restrict the IDE.
Provide build-on-save. Either using Eclipse WTP, or using the FilSync plugin (it sounds like a hack, but is pretty cool)
Use build profiles (maven provides them automatically) - to create different builds for different environments
It's not always possible to configure everything in your maven (or ant/ivy) scripts. For any additional actions, like installing app server - document then in a single file in the root of your project, describing step by step what should be installed, with what config options, etc. Thus the developers have only one place to look at and follow. The document can (and better) be plain .txt
A sidenote: use Continous Integration - download Hudson or TeamCity and configure it to build a project
From my very recent experience - we had a project we've been working on for 6 months. A colleague of mine had to re-import the project on a new machine. It took him 20 minutes. The project is configured with Maven.