When you develop OSGi bundles using eclipse, there are many denpendent bundles to be imported and opened. When there're many bundles, setting up projects is time-comsuming and difficult, especially to newbies .
I've tried the Tycho plugin and m2e; it seems that they are not for this goal.
You can use Eclipse Target Platform concept.
Moreover, with some luck and persistence, you can use remote P2 site as a Target Platform definition in Eclipse. Since you can export Target Platform definition as a file, that means the whole setup for developers will be importing project with that file and selecting this target platform in Eclipse preferences. The Eclipse will download the whole bunch of dependencies itself. For more details see the blog post here.
Also, since you can use that P2 site as a repository for Tycho builds, that allows you to make Tycho use the same set of dependencies as you use in Eclipse making the build more stable. You can host P2 site as a static web content or use repository, like Nexus (however, only commercial version supports P2 repositories, so I have not tried that myself).
Related
I'm using Eclipse Luna 4.4.2 and installed the Ivy plugin and Vaadin plugin from the market place as instructed by their book, but I'm unable to create a project since every time I try to I get the message:
Failed to list downloaded Vaadin versions
From what I'm reading around, Vaadin uses Ivy for managing the download of their packages but it seems to be blocked by my company's firewall.
Since the available versions cannot be downloaded, the combobox for selecting the version comes empty, stopping the process to create the project.
Is there a way to download the Vaadin version I need separately? Are there any options for me in my situation?
You can go to the Vaadin download page and select the Download as .zip option on the left of the page as in the image below. Please note that only the visual editor plugin is IDE dependent, while Vaadin as a framework can be used regardless of the IDE (you could write your code in notepad and compile it with the jars in the classpath), so there's no such thing as Vaadin versions for Eclipse.
On a sidenote you can also use maven to manage your dependencies and build process besides ivy. If you plan on using other frameworks or other Vaadin addons it may prove difficult to manage all these dependencies manually, so depending on your company's policies and configuration I'd ask whether they can grant access to the repositories or if at least there is an internal repository where one can add/find the necessary dependencies.
I'm kinda newbie to Maven and Continuous Integration, so excuse my trivial questions below
In our project we intend to introduce the Continuous Integration through performing automated daily builds on our development integration server using Maven and hudson
on our projects we used to check-in the all the jars (internal, commercial & 3rd party) to SCM under one separate project and force the web project to depend on that project so that the project can compile in eclipse then exporting an EAR
my question is, how will each developer locally on his machine compile the project now ?, should we remove the jars project at all from scm ?
If yes : does this mean that each developer must refer to the enterprise's maven repository from within eclipse so that the project can compile ? and in that case there will be extreme NW overhead ??
If No : there might be a conflict between jars on scm and those in maven repository
another question that is related to the above one, will each developer have his own maven local repository on his machine ?
final question, shall each developer compile the code using maven (through M2Eclipse) or using eclipse compiler as normal ?
thanks :)
The way we do, and I believe is quite common, is
We have our own installation of a repository manager, for example Nexus, installed at some machine in the intranet, available for all developers to use
Jars would not be in the SCM, but stored in the Nexus or equivalent. Common arrangement is to have there one repo for external dependencies, one for internal snapshot builds and one for internal release builds (per project). We have defined maven central repository as well as the internal repositories in Maven configuration, storing the artifacts in the relevant internal repositories (external, internal-release or internal-snapshot) and picking them up from there, but having central repo as a backup for standard plugins.
Repository references (definitions, urls) are either in Maven settings file or then in the pom.xml. Individual developer should not need to do anything, he/she just uses these files. pom.xml would be in the SCM, settings file could be there or not.
Maven uses also local cache when it downloads the files, so they are downloaded only once per version/machine, which should keep the NW overhead tolerable. Intranet repo is there also partly to reduce external network overhead.
Maven release plugin is often used to handle internal-snapshot and internal-release repository updates
Each developer has a local repository cache in his machine. This is a standard Maven feature. Eclipse can refer to these same files.
Code can be compiled with the help of eclipse-maven plugin (of which M2E is the most common), using Maven on the command line or then using Maven to generate regular Eclipse project files and then normally with Eclipse. We use command line and M2E+Eclipse both for this.
SCM would be for source code, repositories for binaries (including .jars)
You configure all dependencies in the pom.xml for each project. Maven then downloads all needed jars from your enterprise repository. You don't need your SCM project any more and i would remove it.
I don't think there is much network overhead, because Maven only downloads the jars the first time they are needed. After that, they are in the local repository (which every developer has on his machine), and only updates will be downloaded after the first time.
If you use M2Eclipse, then the standard Eclipse compiler will be extended with Maven builders, so you can use all Eclipse compile features.
I just created a Web App project from a repository through Eclipse's SVN support. What I would be doing is have an ANT build going and then finally deploy through Tomcat.
I am using Eclipse IDE for Java EE developers on an Ubuntu system.
There are a number of jar files needed
to support my project - like Struts,
Hibernate, etc. etc.
Do I need to
manually download each of them
and put them in the lib folder?
OR
Does Eclipse have a solution to
automatically UPDATE these from the internet? Any plugins to automatically take care of this?
You should consider using Maven for your project. It's VERY well supported in Eclipse, and handles all dependencies (as well as other things, such as releases).
The problem is there's a bit of a learning curve, but if you intend your project to get to a considerable size, I'd say it's very important.
Maven has support for ant builds and most libraries are in the central Maven repository. You just say your project has a dependency on the external project and it will automatically download the dependencies.
http://maven.apache.org/
I am new to maven. The main feature I benefit from, yet, is the automatic dependency management. The standardized directory structure seems also to be nice, but Eclipse has a standard directory structure, too. The directory structure is now independent from Eclipse, but now it is dependent from maven. OK, I see, both programs seem to be quite flexible at this point.
I am not quite sure, if maven is more dedicated to servers or to client systems, e.g. there is a feature / plugin to generate a project website. Doesn't this make most sense on a server system?
How to integrate maven with a version control system (VCS), e.g. SVN? I think of a system where there is a repository and always up-to-date website with download section for development artifacts.
How to integrate maven with Eclipse? I'm now using m2eclipse with WTP integration. Its ok, but it has some behaviors that I don't like, e.g.:
When I generate new Java projects the JRE version is set to 1.4 . I have to reset it to 1.6 / workspace default manually.
Facets configuration is not stable. Some configurations have to be done manually and in a specific order.
Maybe I can fix them if I read more about it. And I have a more or less serious problem with its WTP extension. I think its important to say, that the WTP extension is not officially supported and may not have production quality.
I know there is another plugin which integrates maven into Eclipse. I did not try it, yet. Is it better?
Also I think, that maven may be useful for much more areas. For example the directory structure could be extended to hold e.g. requirements, specification and modeling artifacts. I think that would only work, if it would be standardized. Revision control for all documents would be nice, too.
So many thing, that could be integrated to support the complete software development prosess. Maybe its unrealistic, to get all of these features. For now the Eclipse integration with WTP and VCS integration have the highest priority for me.
Any suggestions? Thanks in advance.
The directory structure is now independent from Eclipse, but now it is dependent from maven. OK, I see, both programs seem to be quite flexible at this point.
Yes, they are both flexible so we could bend one or the other. But if I had to choose a layout, I would pick the IDE agnostic one i.e. the Maven layout and I would stick to the defaults to minimize the efforts and because they are well known (so anybody familiar with Maven knows where to find things). And if someone wants to use IntelliJ IDEA or NetBeans because he feels more productive with it, he can do it. In other words, I don't see any benefit to use the Eclipse layout.
I am not quite sure, if maven is more dedicated to servers or to client systems, e.g. there is a feature / plugin to generate a project website. Doesn't this make most sense on a server system?
Maven can be used for local builds on developer machines, for central builds on a continuous integration machine. And things like generating a website, deploying artifacts are usually done on the central server.
How to integrate maven with a version control system (VCS), e.g. SVN? I think of a system where there is a repository and always up-to-date website with download section for development artifacts.
I didn't really understand the first part of the question. How do you want to integrate Maven with SVN exactly (there is the maven-release-plugin but I'm not sure that's what the question is about)? For the second part, the traditional approach is to use a continuous integration server to trigger a build after a change in the VCS and to deploy (in the maven sense) the created artifacts to a "corporate repository". Many people use Hudson as CI server.
When I generate new Java projects the JRE version is set to 1.4 . I have to reset it to 1.6 / workspace default manually.
That's because the maven project itself is not configured to use 1.6 level (the Eclipse configuration is derived from the POM, which makes sense). You have to configure the maven compiler plugin for 1.6. Here is one way to do it (there are plenty of previous questions on this topic):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
And then update your project configuration under Eclipse via right-click then Maven > Update Project Configuration.
Facets configuration is not stable. Some configurations has to be done manuel and in a specific order.
They are for me and again, they are derived from your POM (e.g. from the version of your web.xml).
And I have a more or less serious problem with its WTP extention. I think its important to say, that the WTP extension is not officially supported and may not have production quality.
Huh? Where did you read this? Works fine for webapps for me.
I know there is another plugin which integrates maven into Eclipse. I did not try it,yet. Is it better?
I don't have experience with Eclipse IAM. But what is your problem with m2eclipse?
Also I think, that maven may be useful for much more areas. For example the directory structure could be extended to hold e.g. requirements, specification and modeling artifacts. I think that would only work, if it would be standardized. Revision control for all documents would be nice, too.
You're free to put whatever you want in your project tree. Many people are doing this and referring to docs from the site. Possibilities are endless.
Some random points to push you in the right direction:
The standardized directory structure seems also to be nice, but Eclipse has a standard directory structure, too
Eclipse does not have a "standard" directory structure. For example, some people put their unit tests in src next to their code, and others put it in a separate dir like tests or test. You can configure either up as much as you want, but Maven follows has defaults that almost everyone follows:
source in src/main/java
tests in src/test/java
resources necessary for running in src/main/resources
language files
Spring config files
resources necessary for running tests
golden results
config files in src/main/config
Eclipse is an IDE, and Maven is a built build management tool
case in point: if you ask Eclipse to build a JAR/WAR, you have to manually tell it what to include and where. Because you placed your files in Maven's defaults, you get things like:
JARs/WARs contain the compiled Java classes from src/main/java, but not the ones from src/test/java
config files from src/main/config don't go into the JAR/WAR (kinda defeats the purpose of a config file if it did)
test resources from src/test/resources don't go into the JAR/WAR
if you decide to build an assembly (Maven speak for a distribution of your code you can put on your website that includes documentation, source, binaries, etc.), it can make a JAR, the config files, and javadocs into a ZIP file.
I am not quite sure, if maven is more dedicated to servers or to client systems, e.g. there is a feature / plugin to generate a project website.
Yeah, the Maven site plugin.
Doesn't this make most sense on a server system?
Not really. Documentation is critical for any project, especially for client systems.
Maybe I can fix them if I read more about it. And I have a more or less serious problem with its WTP extention. I think its important to say, that the WTP extension is not officially supported and may not have production quality.
Because Maven integration with Eclipse via the m2eclipse plugin isn't perfect, I actually won't use it for WTP projects. I use the Maven Eclipse plugin to generate Eclipse project files and then import the project as a regular Eclipse project. The downside is that the Eclipse project files have to be re-run after any significant changes to the project.
Revision controll for all documents would be nice, too.
That's not Maven, or any build management tool. That's your SCM, Subversion or whatever.
When I generate new Java projects the JRE version is set to 1.4 . I have to reset it to 1.6 / workspace default manually.
You can set that through Maven.
Maybe its unrealistic, to get all of these features. For now the Eclipse integration with WTP and VCS integration have the highest priority for me.
The m2eclipse plugin and friends work best for simple Java Maven projects. Personally, I use the Maven eclipse plugin to generate an Eclipse project for any web, EJB, etc. projects.
There's downsides to that as mentioned earlier, but the upsides, including dependency management as you mentioned, outweigh them, IMHO.
Of course, a poorly configured Maven project is still a poorly configured project. It's not magic. :)
We have an Eclipse RCP product, which means it depends on a number of Eclipse plugins (for the UI etc). We have set up a reference Eclipse ("target") to supply the latter.
Our product also depends on a number of third party plugins. Is there a standard location for these to be put?
We have a few of our third-party plugins in the /plugins of the target Eclipse, but this seems wrong to me. The third party plugins change more frequently than, or at least in a different timeframe to, our reference Eclipse.
I tried putting some third party plugins in a separate project in the workspace (under version control), but the PDE headless build did not seem to find them - even though I used the pluginPath property in the headless build.properties.
This is Eclipse 3.4.2. I am aware than the handling of target platforms has changed somewhat in 3.5.
Most of the comments I've seen see on the web about this seem to assume that you're writing a plugin to be added to a standard Eclipse installation. We're not, it's a completely separate product.
For my RCP applications I created a customized target platform directory for it to use (e.g. rcpapptarget). Under that directory I unzip the following packages:
eclipse-RCP-SDK-3.4.2-win32.zip
eclipse-3.4.2-delta-pack.zip
Then I add what ever other eclipse or third party plug-ins that my application will need. For example:
the latest GEF all .zip file
jay libs EclipseCallBasic_1.1.0 plug-in
derby distributed plug-in
additional eclipse plug-ins needed for help support, cheatsheets, updates etc.
I then setup a workspace for developing that RCP application and point the workspace's "Target Platform" to use that customized target platform directory. I do all my development using that target platform and my headless builds use it too.
To set the target platform choose the Window | Preferences command and then select Plug-in Development | Target Platform from the preference tree. Set the "Location" to point to the directory you created.
There isn't a standard that I know of for where 3rd part plugins should go. You can define an external extension location and store your party plugins/features there. This also allows you to reuse the plugins in multiple Eclipse installs if you wish.
You add an Extension location by going to
Ganymede onwards: Help->Software Updates->Available Software->Add Site->Local
Older versions: Help->Software Updates->Manage Configuration->Add Extension Location
For Ganymede onwards, the extension locations work a bit differently (IIRC the plugins are copied to the standard Eclipse install, which kind of defeats the point),there is however a new concept called dropins that you might find useful.