is it possible to add multiple nature to a single project in eclipse ?
eg: i want to add Python and Ruby nature to a Java project.
the purpose.
I have solutions to projecteuler.net problems in Java,Ruby,Scala,Clojure and Python.
But the solutions are in different projects.
I need them in a single project.
The GUI does not have any option for creating such a multilanguage projects.
However, technically, project natures can be added independently from each other. So if you manage to programmatically create the required environment, it would work. If you want to do it manually, find the .project file in the project root, and add all natures and builders to one (you can look the required elements from other projects - do a copy-paste).
This would add the project natures and builders, but not any additional configuration required - e.g. in Java projects .classpath files are used to describe the source folders, in other languages different configurations are needed.
Alltogether, if you need to do this multiple times, create a plug-in that manages this configuration for you; if you need it for a single project, think about it whether it is worth the huge effort required.
Related
What is the best way to share project specific settings between multiple Eclipse projects?
I'm working with an application that is divided into several Eclipse projects. All of the Eclipse projects should use the same compiler settings. I could duplicate the settings in all the projects, but I'm looking for a way to avoid that.
The relevant settings are the ones that are saved in <PROJECT_LOC>/.settings, most importantly org.eclipse.jdt.core.prefs but also for example org.eclipse.jdt.ui.prefs. They are the ones that are set in Project Properties > Java Compiler, Java Code Style (and a few more places).
The solution must be version control friendly.
One possible solution use a linked resource, from org.eclipse.jdt.core.prefs or .settings of the projects to the same file, located in one of the projects. A similar solutions is to use soft file system links. I don't really like these solutions, it seems to me that they are hard to maintain, for example if the name of a project is changed.
I found this question which is different because it asks about sharing settings between developers, not between projects. (I must do both.)
How to share Eclipse project preferences between users?
I think it depends on how frequently you expect projects settings to change.
If not frequently, you shouldn't over-engineer your solution: just configure one project and copy settings to other projects, put everything under version control and you're done, except for having to perform this operation again every other year, or so.
If frequently, and if a lot of settings are involved, and if all (most) workspace projects should indeed use the same settings, then consider creating your own Oomph setup, that would include your settings as workspace settings. Then let all projects just use the workspace settings. (Of course a few projects could still deviate and use their own project settings, but once using project specific settings, changes to workspace settings will have no effect on that project).
BTW: Oomph includes capabilities to also specify once and for all: selection of plug-ins to install plus how to populate a workspace with projects from version control, and more. So I can only recommend this tool if you are really concerned about systematic configuration of working environments: create one setup - apply it automatically hundreds of times. And no, I'm not an author of Oomph, just a happy user.
Sharing your workspace setup using Project Sets
Your workspace setup may consist of several projects from one or more repositories. Once you have setup your workspace, you can share it with others by exporting a Team Project Set. A project set is a text file that contains a pointer to each of the projects contained in the project set.When a project set is imported, these pointers are used to fetch the projects from the repository.
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-cvs-project-set.htm
A long time afterwards I got an idea about how to solve this:
Set up a multi-module Maven project.
Configure the settings in the parent pom file.
Import the projects into Eclipse as Maven projects.
Disclaimer: I haven't actually tested this, so I don't know how well it's working...
Eclipse has projects, what's the purpose of the Workspace that appears to group projects? Projects could live in the directory tree isn't that a more natural way of organizing different projects?
When you first start up Eclipse not knowing much about it, it feels like an unnecessary layer of bloat that new users have to get accustomed to first. You're forced to set up some organizing structure that, although specific to Eclipse, wants to live in the rather general-sounding place ~/Workspace.
The workspace is a collection of projects and the metadata that cannot be included in a project because it's not portable (references paths and resources on a specific system) or because it pertains to Eclipse as a whole.
Without the workspace concept, opening a project in Eclipse would be followed by multiple steps of getting things configured. This information would be lost when Eclipse is closed or all projects you ever work on would have to share the same configuration.
Examples of metadata stored in workspace:
Locations of available JDK's and JRE's. The project references a JRE by name, the workspace metadata is needed to resolve that reference.
Locations of application servers.
Path variables.
Open perspectives, layout of views, etc. Consider one application where you need Git and app server vs another application where you need SVN and Android development tools. The views you'd want to keep open and how you'd arrange these views would be very different for two applications.
I am new to J2EE. I would like to create a Spring+Primefaces+Hibernate project.
I googled for it.
But I found all projects examples show in internet contains maven. My questions are
Is it possible to create a spring+primefaces+hibernate project in eclipse without Maven? If no, what is need of maven?
How to add the jar file of primefaces and spring and hibernate in eclipse?
Will the spring controller xml file (spring context or dispatcher servlet) be created automatically or manually?I mean Spring MVC.
Will the hibernate file (mapping file) also be created automatically or manually?
If possible, can anyone guide me to tutorial (preferably video) to implement the same?
I am using tomcat 7 and Eclipse - kepler.
Any help is appreciated.
If this is downvoted , do specify the reason also.
Although it's not a 'must' to use Maven or any other build tool, you should strongly consider using one.Eclipse Kepler has by default maven support but feel free to use other build tools(Gradle, Ant) or none(see 2.).Maven and the other build tools remove the headache of scaffolding, searching for dependencies(external jars like spring-mvc, hibernate, some db drivers), even deploying applications in a server.
If you chose not to use a build tool you have to manually get your project dependencies and enter them
into your project's buildpath(Right Click -> Build Path then enter their location).As you have noticed this step can be really really time consuming...
No, you have to manually create the configuration unless you use another project that already has what you need, again this might get easier with a build tool(maven archetypes for example)
The same as 3.
You won't have a hard time finding resources about these technologies, they are being used practically everywhere, and I think the Spring team has some videos in their YouTube channel.
Hope that helps a little!
1:* The fundamental difference between Maven and Ant is that Maven's design regards all projects as having a certain structure and a set of supported task work-flows (e.g., getting resources from source control, compiling the project, unit testing, etc.). While most software projects in effect support these operations and actually do have a well-defined structure, Maven requires that this structure and the operation implementation details be defined in the POM file. Thus, Maven relies on a convention on how to define projects and on the list of work-flows that are generally supported in all projects.
This design constraint resembles the way that an IDE handles a project, and it provides many benefits, such as a succinct project definition, and the possibility of automatic integration of a Maven project with other development tools such as IDEs, build servers, etc.
But one drawback to this approach is that Maven requires a user to first understand what a project is from the Maven point of view, and how Maven works with projects, because what happens when one executes a phase in Maven is not immediately obvious just from examining the Maven project file. In many cases, this required structure is also a significant hurdle in migrating a mature project to Maven, because it is usually hard to adapt from other approaches.
In Ant, projects do not really exist from the tool's technical perspective. Ant works with XML build scripts defined in one or more files. It processes targets from these files and each target executes tasks. Each task performs a technical operation such as running a compiler or copying files around. Targets are executed primarily in the order given by their defined dependency on other targets. Thus, Ant is a tool that chains together targets and executes them based on inter-dependencies and other Boolean conditions.
The benefits provided by Ant are also numerous. It has an XML language optimized for clearer definition of what each task does and on what it depends. Also, all the information about what will be executed by an Ant target can be found in the Ant script.
A developer not familiar with Ant would normally be able to determine what a simple Ant script does just by examining the script. This is not usually true for Maven.
However, even an experienced developer who is new to a project using Ant cannot infer what the higher level structure of an Ant script is and what it does without examining the script in detail. Depending on the script's complexity, this can quickly become a daunting challenge. With Maven, a developer who previously worked with other Maven projects can quickly examine the structure of a never-before-seen Maven project and execute the standard Maven work-flows against it while already knowing what to expect as an outcome.
It is possible to use Ant scripts that are defined and behave in a uniform manner for all projects in a working group or an organization. However, when the number and complexity of projects rises, it is also very easy to stray from the initially desired uniformity. With Maven this is less of a problem because the tool always imposes a certain way of doing thi
2:* You have to download all required jars file for hibernate/spring/primefaces from internet and place them in your project build path or in lib folder.
3:* Spring configuration files need to be created by you so that you can get the concept.
4:* Hibernate mapping files can be created by using reverse Engineering techniques for hibernate from where you can generates hbm files or you can use annotations if you dont want xml.
I suggest you to first create a sample java project in eclipse then download all required jars and place them in lib folder. Then configure hibernate in projects and spring integration.
When I commit a web appliction to source control should I also include the .project & .classpath files ? I don't think it should make any difference either way as other users who use the project should have the same project settings ?
This is the sort of question that gets people bent out of shape in a debate that never ends. You basically have two camps:
Only put source code into the source control system. Each developer chooses their own IDE and manages their own project configuration. Setting up your IDE after getting source code from the repository will be tricky. If one dev changes project dependencies, they have to explicitly communicate that so that all other devs update their project configurations. There are some tools that try to address this problem, like a Maven plugin that will attempt to generate Eclipse project metadata from pom.xml, but all have their limitations. Groups that go this way favor the purity of not restricting developer choice in IDE over the convenience of having Eclipse projects across the team that just work.
Standardize on Eclipse. Put all Eclipse project metadata into source control. This includes .project, .classpath and the entire contents of .settings. Basically, the only thing that you don't want in your source control repository is content marked as derived in Eclipse. You can check that in right-click->properties. Taking this approach ensures that developers can get started coding immediately after getting the project from source control. No additional configuration required. Also, when one dev changes project configuration, the rest of the team will see the same change on next sync.
Choose the approach that makes the most sense for your team.
For ClearCase, including the .project and .classpath can make a difference when you are using the IBM ClearCase plugin for Eclipse.
That plugin will work better if it can rely on those (versioned) files being there, right next to the sources (as opposed as being in the Eclipse workspace, which doesn't necessarily contains said sources).
In general, nothing generated should go into repository. Those files are generally generated by IDE or maven. However, sometimes you may need to click a button or execute a command to get those generated.
i would include them.
The .project file have plugin info (e.g. maven, ant, pdt, wst, aspectj, findbug..). It is essential if it is not a plain java project.
.classpath contain the classpath. it is needed if you use jar files.
I would say that all files - including .project and .classpath - should go to source control, to ensure that everyone in the team has the exact same setup.
I have a Helpdesk application that contains modules that can be downloaded and installed separately as required / preferred by the users. The structure is very similar to many software such as Drupal, which modules can be loaded/unloaded easily.
I'm using a single SVN repository for this Helpdesk application and create different tags for each module. And on my Eclipse I have everything as a single project.
My question is, can a single Subversion repository managed as multiple projects in Eclipse?
Can I create one Eclipse project for the whole application and at the same time for each module?
Another requirement is that by splitting each module as a different project would make Eclipse builds faster.
The reason is, I want to delegate programming work of each module to another person without the need to expose everything. The person would only see & work on the module only but commit to the main repository.
I know that Eclipse will have configuration files for every project, would there be any conflict.
I've had good look storing multiple Eclipse projects in one repository. Each of the projects is stored in a separate folder under the repository's root. Then, I use Subclipse to check out each of those folders as a separate Eclipse project.
I do not think that you should nest Eclipse projects (so that a master project contains many sub-projects).
Instead of the master project, you could group the individual projects into what Eclipse calls a Team Project Set (found in the Export/Import menus). This is an XML file that defines where all the projects are. You can put that file into Subversion as well.
So, you would have all the module's projects, and that XML file (which is not a project itself), all in Subversion (could be the same repository, could be spread over several).
I don't believe this is strictly possible. Personally, I would split the modules up into different projects entirely, and I would probably use Eclipse's plugin structure to resolve dependencies between them and the main project. If you ship the plugins as jars, they're still modular. Then, you can control each plugin as a separate project in Eclipse, and a separate folder in SVN.
That is no problem at all! Just create your trunk/tags/branches structure on your svn repo. Create your differen projects and then check thos projects into your trunc folder on your svn system. Finished!