I have 2 separate projects in STS Eclipse, both using gradle to build. One is a web application. The other is a data access library that the web application uses. I have the buildship plugin for this.
Normally, I would simply change the project properties to include the data project in the web application's build path/project references/etc to make this work, but we're switching over to using Gradle for this.
I have a working build.gradle file in each project, but I don't know how to make the web app's build script build and include the data project.
I've looked for various tutorials and examples, and they talk about a root project that contains both projects inside. I have no idea how to create this.
How do I go about setting this up?
Furthermore, I'm concerned about SVN in a setup like this. I want to be able to commit each project separately since other applications will use the data access library, which is why it's a separate project. My understanding is that a nested project structure suggested by gradle would cause the entire root project to be committed as 1 entry, with both subprojects.
This would then mean that I would have to copy the data access project into all the other projects that need to use it, which would make maintaining the code a pain. At that point, I might as well not have a separate data access project and instead just include all that code in a package in the web app.
The solution to this issue was the "includeflat" command in the settings.gradle
Related
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.
Is there a way to split up a Dynamic Web Project in Eclipse into two libraries and link them up properly?
So, I'd like to have a library project and two other applications specific web projects. Both using the library project.
I looked into the "references" option in Eclipse to link projects up but didn't work as intended. I also looked into Web Fragment feature but that didn't let me define servlets which need to be defined in the lib project as well as the servlets will be the same for both projects.
Also, is there a way to overlay content from the lib project by content defined in each project? Example:
-Lib
-WEB-INF
-img.jpg
-AppProjectA (using Lib project)
-WEB-INF
-img.jpg
I'd like to be able to use the Lib project in AppProjectA and replace the img.jpg file imported from the lib project with the one defined in AppProjectA.
I looked into Maven overlay but that's a bit too crazy for what I need to do. I also prefer Ant script over Maven. Any ideas on how to accomplish what I need to do here?
I guess with sufficiently clever Ant you probably can achieve what you want, but I don't know of anything off the shelf. However do you really need to do this? Can you get the level of reuse by just referring to resources from the other web app?
Suppose you deploy them both, each with their own context root.
A page from appA can refer to appB
/appB/imgages/img.jpg
For common code, put it in a library JAR project, packaging the JAR in the root of the EAR, or in WEB-INF/lib of each app.
I've got a simple Dynamic Web project set up in Eclipse 3.6 Helios, but am having trouble getting it to make use of the code in another project that I've got.
I've added a reference to my other project to the build path of my web project, and I've got no problems in terms of compiling, only in terms of deploying and testing the result. The built web application doesn't have a jar in the WEB-INF/lib directory, so fair enough it can't find the code. The question is how I set this up. I've looked through the help that I can find and googled a bit but can't find anything obvious that helps out.
How do I set up my web project so that on deploying it it magically has the code from my dependent project inside it?
Thanks.
Note: Ideally I'd like a solution that doesn't involve setting up some kind of build tool. The web project deploys itself without recourse to any build tool (or at least none visible to end user), so was rather hoping that a references project could be integrated into that easily.
What goes in the deployment is determined not by the build path but by the Deployment Assembly entry in Preferences for the dynamic web project.
Use some build tool like ANT or Ivy or Maven that, on build, copies all the dependencies to WEB-INF/lib
Using a build tool is a good practice to automate build, test and deployment. You may also be interested in plug-ins like Maven Reactor.
I'm about to start working on a web-application and I'll be using Maven. I want the web-application to be an individual artifact. The web-application will end up depending on a couple of self written libraries (for example text-formatting), and each of these libraries should be an individual artifact.
What's the recommended way of achieving this separation while making it simple to code for both artifacts? I was thinking of creating one project for each artifact and import them one by one in Eclipse. However, if the pom for web-application has a dependency pointing at the self written library, I'll end up having to deploy a snapshot every time I want to see if the change I made stopped the web-application from crashing (in example).
I hope you understand what I am getting at. I'll be working with a couple more developers, and we're using Nexus to maintain our shared artifact repository.
I was thinking of creating one project for each artifact and import them one by one in Eclipse.
Yes, that's the recommended way.
However, if the pom for web-application has a dependency pointing at the self written library, I'll end up having to deploy a snapshot every time I want to see if the change I made stopped the web-application from crashing
During development, you can use "workspace resolution" i.e. configure Eclipse to resolve dependencies from the workspace. This way changes are immediately visible from the webapp. This is possible whether you are using m2eclipse or the maven eclipse plugin (and is actually the default behavior for both).
Below, an illustration for m2eclipse:
A good maven plugin for eclipse is capable of "workspace resolution", i.e. it will recognize if the dependency is also present in the workspace, and refer to the other project directly rather than adding a JAR to the build path.
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.