I used to package my various Eclipse RCP products with PDE, for years.
With my latest upgrade attempt to Eclipse Oxygen, I got some new strange resolution errors which I could not solve, and I decided it really was time to give Tycho a try. I followed the excellent article about Tycho by Lars Vogel, and after a bit of tweaking, it worked well (and I was not stucked by the same resolution errors as in PDE! Yay!).
But indeed it was a simple test: I created a folder for my bundles, another for my features, created my poms, and so on. Now I look at the degree of automating in my PDE and find quite a huge gap.
In PDE, there is a build.properties where you give your master feature file and a map file, and the process will, seemingly:
parse the master feature
parse the features in it (recursively)
parse the plugins in them
find in the map file the plugins to be packaged (the other dependencies are supposed to be in the target platform)
download the relevant git repos
move the relevant plugins/features to the working directories
launch compile, p2 and so on
(note : the git part needs you provide the egit fetchfactory)
Now in Tycho, I have to create poms, but it is not the problem. I have to create some master poms, and for the individual plugin poms, I have either the pomless option, or the pom generator. The pom generator also seems to have the advantage of creating the parent pom which contains all the plugins as modules. So far so good.
But I have to fill the features and plugins folders, and I'm stuck here.
I do not have PSFs for my products, because I never needed it: in PDE, map + product definition does the trick.
Does it mean I will have to maintain PSFs from now on or is there another tycho solution I did not find? (Tycho doc is quite scarce, in my opinion). Maintaining PSFs seems redundant to me because I have product and map, and also because I have many products, many plugins, and many of which are common to several products.
(Indeed, a basic solution would be to take the git repositories mentioned in the map file, dump them all and launch tycho. Tycho would compile all the plugins, and then the p2 part would package only the product-relevant ones. The problem is that I have plenty of different products that rely on plenty of different repositories. And even in a given git repo, I have plugins that may or may not be relevant for a given product. Thus, I would compile hundreds of useless plugins in the process.)
My need is to copy in the tycho folders only the plugins and features which are referenced in my product and which are not already in my target platform. Generating a PSF from my product and my map would be shifting the problem.
Indeed, I can code this, and I will if needed.
But given that all this is already automated in PDE, is there at least some parts of the process that could be automated with some tycho plugins I did not uncover?
After some time of digging, here is the solution I finally chose.
In order to fetch the relevant features and plugins, I used... PDE ! I digged in PDE and found the various steps in its process. The first one is to fetch (it is an ant task named eclipse.fetch). I externalized this part, and my script launches it, then generates the master poms by scanning the fetched features names and fecthed plugins names, then adds the other tycho confugurations and then launches tycho.
In the end, granted, it is not a full tycho solution, it is a hybrid one PDE + Tycho. But it works like a charm, and the build/package process is Tycho, only the initial fetch is delegated to PDE. (anyway, PDE build/package process does not work in my case, as stated initially)
Related
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.
I use Java/Eclipse for development and I've never really used any conventional build tools like ant or maven. I generally just rely on building projects through eclipse and I rarely use commandline. I don't really want to spend time getting to know ant/maven, but I'd like to know whether eclipse can really substitute all functionality of ant/maven through its .classpath file any other settings.
(Please don't suggest me some tutorial that makes it really easy to learn ant).
Eclipse knows how to build a project based on the .project and .classpath files.
build.xml is the default filename of build rules used by Ant, so that when you run ant without parameters, it will use this file to figure out what to do.
pom.xml is the default filename to describe a Maven project, so that when you run mvn compile, it will use this file to figure out how to build the project.
Eclipse can import a project based on an Ant build file or a POM file, and create the appropriate .project and .classpath files.
Eclipse, Ant, Maven are all different tools that cannot replace each other. They have some overlapping functions, but also some unique functions.
Being able to build a project using the command line is a very useful skill, and part of being a good programmer. In the Programmer Competency Matrix, being able to build your software using the command line is considered Level 1 (out of Level 0, 1, 2, 3), if you cannot do this, that's not so good.
http://www.indiangeek.net/programmer-competency-matrix/
I strongly recommend to learn Maven.
If your applications have little existence outside of Eclipse then maybe you should keep using Eclipse in that way. But Eclipse is a developer tool (developer as in the person who writes the code). Any other than the most trivial projects have to deal with roles other than developers. and applications go through an entire life cycle. In fact, different axes of life cycles exist, whether it being from a project management perspective, from the perspective of deliverables traversing a number of phases such as coding, compiling, assembling dependencies, packaging, deployment, or from other perspectives.
When you look at those deliverables traversing phases, a lot of these steps can be done (manually) from within Eclipse. So, again, if that works for you, praise. However, it misses automation and for some steps (phases) Eclipse just ain't the right tool. For example: Continuous Integration is not something Eclipse is built for. A CI server may want to checkout your sources and build stuff from scratch. It needs to find dependencies and such, may do so on basis of Eclipse's .classpath file, but that introduces a dependency on Eclipse. Now, I've seen large companies do it exactly that way, but it's a bit clunky because that's again not what Eclipse was meant for.
Instead there's tools that are great at dealing with the entire* life cycle.
*Note that "entire" is a very subjective matter. From a developer's perspective the life cycle may be nicely split up in phases, but other people in your larger organization may find that their duties are underrepresented in any given breakdown of life cycle phases.
Maven or Gradle are such tools. Look at them as an assembly line with a number of stations. The developer is at one of the stations, using Eclipse, but underneath the assembly line keeps rolling. CI is another station, using Bamboo, Hudson, Jenkins or similar, but underneath still the assembly line at work. Within Eclipse the m2e plugin is the connector between Eclipse and the assembly line Maven.
A different approach to the matter is to use scripts, either to replace the manual steps that you're doing in Eclipse, to hook them together, or to complement them. There is clearly many languages that can be used, but within the build tooling domain Ant is wildly popular because its functionality aligns well with exactly this purpose.
If you're a professional software factory (which might already be the case for a single developer project) you need an assembly line. Maven or Gradle give you one out of the box. If you want to swim upstream you build your own, using Ant or other stuff. And if you really have no requirements in this area to speak of, keep doing things manually in Eclipse.
Even though being defined in XML, Ant comes naturally to us as developers, since it has much of traditional sequential programming languages. Maven and Gradle have a different approach, and have thus a steeper learning curve. But it is definitely worth it. If you do it their way things become a breeze and you don't have to code every other thing you want to add to your assembly line. This hand-crafted scripts always start small, but they never stay that way, do they? :)
In addition to all this, I'd like to mention that Maven is also really good at resolving dependencies. That's what it's most known for, but that's not what this question was about, and it is in fact only such a small part of what it can do for you.
Here is the situation. A development team has a large number (hundreds) of Eclipse projects. The code is very much in churn - new projects are being created; projects are being renamed and project dependencies are constantly changing. The external build system is ant. It is proving extremely challenging to keep the dependencies defined in the ant build files in sync with the state of the world in Eclipse. The external ant build needs constant changes to keep up. For various reasons, using ant as the default builder in Eclipse is not an option. The developers want to continue using Eclipse as the build and edit environment for local use.
Question: Is there a tool which will allow a single set of dependencies to be maintained which can be used by Eclipse as well as an external build system like ant?
I have heard of Gradle but never used it before. Would it make sense in this context? I am pretty sure Maven wouldnt work for what is needed
The typical workflow should be:
1. Developers continue working as they currently do - creating and changing Eclipse project dependencies at will and using the default Eclipse builder to compile and test locally.
2. Some mechanism exists by which these dependencies can be carried into an external build system like ant and an external continuous build triggered on every checkin.
Appreciate your feedback - thanks!
We have been quite successful at using Gradle to tackle a similar problem. Here's the outline of the setup
Each project contains a build.gradle that defines project specific dependencies and tasks (may even be empty).
A special master project contains build.gradle that sets up common dependencies and tasks for child projects, and/or injects settings pertinent to a group of child projects.
Logically master project is the parent project, but it exists as a sibling folder so that Eclipse can be more comfortable with it.
Gradle contains a built-in Eclipse plugin which allows generation of Eclipse settings files for each of the projects from the dependencies information (including inter-project dependencies). It works nicely for simple projects, and as for more complicated ones Gradle allows you to tinker with the settings files, so you can do pretty much everything. From here you have two options:
Not to store Eclipse settings file in the repository and call the generation task every time you do a fresh check-out (I prefer this option).
Tell Gradle to use custom variables to make it generate generic settings files which can be checked-in to the repository. You'll then only need to run the generation task when dependencies or other configuration changes.
(Optional) It's a little tricky, but you can make Gradle parse existing project ivy.xml files and set up dependencies from there. I had some success with this, although I would recommend converting dependencies into Gradle format for more flexibility.
Continuous build system integrate with Gradle very well (same as ant). If you are using Jenkins (Hudson) there is a Gradle plugin.
The advantage of using Gradle is that it scales pretty well, and you can support other IDEs like IntelliJ or Netbeans at the same time without much effort (unless you have lots of crazy custom settings). An advantage and a disadvantage is that Gradle is a powerful build system which requires learning Groovy and Gradle DSL which may take some time to acquire. Also the documentation is awesome.
Gradle has a very active community with the sole purpose of tackling exactly this kind of problem.
Hope this helps, and best of luck!
How about parsing the .classpath files, generate a dependency tree and start building from the root. What you need is a convention on the layout of your projects or an generic (ant-) buildfile that could be changed in each project, if needed (e.g. different project layouts). I´m not sure if Eclipse Tycho could be used for that, since it´s a maven plugin(s) to build eclipse plugins or projects. But it´s able to resolve the bundle and project dependencies against maven repositories and eclipse update sites.
i am looking to make our deployments here not suck and i need some help, if you can help me with these few things i owe you beer
right now whenever i make a change thats not to the jsps i need to clean-including-tomcat otherwise my change doesnt take. this is really annoying.
any clues as to what i can change to make it work?
my current build is really simple, just the regular old, javac, war, deploy
one thing that isnt done is that there is no build dir, the project itself contains a web-inf and the javac is done in place, then the war excludes all the .java resources and wars the project.
edit:
I am looking to fix this problem with least amount of effort - so while switching to maven and learning how to use it might solve this problem, but it will create another problem ;)
You've already identified some of the weaknesses, in your current build.
The easiest way that I can suggest to clean it up would be to start with the directory structure.
I highly recommend using the maven directory structure, I would go further to suggest using maven as a build tool instead of ant, however for some folk that remains open for debate.
The maven directory structure has been well thought out, I really like working on projects that use the maven directory structure, because they follow a convention that allows me to save a lot of time, by knowing from previous experience where to find the application components
java source
unit test source
resources etc.
Also by following the convention, the maven plugins work with less configuration required.
Another useful advantage that I get from working on maven based projects is good code metrics, to measure the health of the application. There are various report available as maven plugins, which will give you new insight into your codebase, including:
checkstyle
pmd
findbugs
and more.
Created a build directory where everything got copied before build
Added some flags to not copy over things that rarely change, like images (also to not remove them on clean)
Started using ant-reload task after deploying code
Now i don't need to restart tomcat on every build, and build takes much less time.
example:
For logging, my code uses log4j. but other jars my code is dependent upon, uses slf4j instead. So both jars must be in the build path. Unfortunately, its possible for my code to directly use (depend on) slf4j now, either by context-assist, or some other developers changes. I would like any use of slf4j to show up as an error, but my application (and tests) will still need it in the classpath when running.
explanation:
I'd like to find out if this is possible in eclipse. This scenario happens often for me. I'll have a large project, that uses alot of 3rd party libraries. And of course those 3rd party jars have their own dependencies as well. So I have to include all dependencies in the classpath ("build path" in eclipse) for the application and its tests to compile and run (from within eclipse).
But I don't want my code to use all of those jars, just the few direct dependencies I've decided upon myself. So if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
I know I can manually configure the classpath when running outside of eclipse, and even within eclipse I can modify the classpath for a specific class I'm running (in the run configurations), but thats not manageable if you run alot of individual test cases, or have alot of main() classes.
It sounds like your project has enough dependency relationships that you might consider structuring it with OSGi bundles (plug-ins). Each bundle gets its own classloader and gets to specify what bundles (and optionally what version ranges, etc.) it depends on, what packages it exports, whether it re-exports stuff from its dependencies, etc.
Eclipse itself is structured out of Eclipse plug-ins and fragments, which are just OSGi bundles with an optional tiny bit of additional Eclipse wiring (plugin.xml, which is used to declare Eclipse "extension points" and "extensions") attached. Eclipse thus has fairly good tooling for creating and managing bundles built-in (via the Plug-in Development Environment). Much of what you find out there may lead you to conflate "OSGi bundle" with "plug-in that extends the Eclipse IDE", but the two concepts are quite separable.
The Eclipse tooling does distinguish rather clearly (and sometimes annoyingly, but in the "helpful medicine" way) between the bundles in your build environment vs. the bundles that a particular run configuration includes.
After a few years of living in OSGi land, the default Java "flat classpath" feels weird and even kind of broken to me, largely because (as you've experienced) it throws all JARs into one giant arena and hopes they can sort of work things out. The OSGi environment gives me a lot more control over dependency relationships, and as a "side effect" also naturally demands clarification of those relationships. Between these clear declarations and the tooling's enforcement of them, the project's structure is more obvious to everyone on the team.
if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
Put your code in one plug-in, your direct dependencies in other plug-ins, their dependencies in other plug-ins, etc. and declare each plug-in's dependencies. Eclipse will immediately do exactly what you want. You won't be offered dependencies' dependencies' contents in autocompletes; you'll get red squiggles and build errors; etc.
Why not use access rules to keep your code clean?
It looks like it would better be managed with maven, integrated in eclipse with m2eclipse.
That way, you can only execute part of the maven build lifecycle, and you can manage separate set of dependencies per build steps.
In my experience it helps to be more resrictive, I made the team filling out (paper) forms why this jar is needed and what license...
and they did rather type in a few lines of code instead of drag along 20 jars to open a file using only one line of code, or another fancy 'feature'.
Using maven could help for a while, but when you first spot jars having names like nightly-build or snapshot, you will know you're in jar-hell.
conclusion: Choose dependencies well
Would using the slf4j-over-log4j jar be useful? That allows using slf4j with actual logging going to log4j.