As a Eclipse's release repository, like https://download.eclipse.org/releases/2022-06 or https://download.eclipse.org/releases/2022-03, what are its characteristics?
As far as I know:
Once released, its content will never change;
The dependencies in this repository can fully satisfy each other, in other words, when the Eclipse IDE only connects to this site and uses p2 to install and uninstall any features on this site, there are no dependency problems or other problems that cannot be installed or uninstalled
Am I right? Or are there any other characteristics of this repository that are very important?
Related
I have one single external installation of Maven 3.0.4 and two Eclipses (Juno and Indigo) referring it in their m2e settings.
Also I have one single user setting file which describes one single local repository. Both Eclipses refer it.
I have a problems with Maven which can be suspected as conflict between Eclipses.
For example, one of Eclipses (say Indigo) can be blind concerning some global repository (say central). This means that it's subnodes in "Maven Repositories" view of eclipse are empty
Updating/Rebuilding index does not help and probably does nothing since ends very fast.
Reloading settings also does not help.
The question is: is it possible to use one single maven with several Eclipses? Is it possible that principal multiuser system does not support multiusing?
Where the data can be corrupted?
You would be better of ignoring the Eclipse specific installs of Maven.
I have found that relying on pre-installed software on Eclipse, leads to problems for the following reasons.
You will never know exactly what version of maven they have installed and why (finding out is harder than installing yourself)
If it won't run in the IDE, what chance will your build server have (and you will meet those problems in Jenkins or your CI server when it comes to release time)
It is very easy to install Maven yourself and run it from the commandline and less problematic.
http://maven.apache.org/download.cgi
If there is a team of developers using maven think about hosting it yourself on a nexus server.
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.
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).
How do you manage your Eclipse installation, i.e. the basic installation, plug-ins and workspace settings with regard to consistent updates (including major ones, 3.5 => 3.6) and usage on two or more computers (desktop + notebook).
My current setup is to basically managing the installation on several installations in parallel, i.e. manually add new plug-ins I installed on one to the other, and when I haven't used one in a long time to copy the whole directory from one location to the other.
For updates I usually run it about once a month to get the latest versions, major updates I do manually by downloading the basic distribution and re-installing all the plug-ins in the matching version for the new major Eclipse version.
However, this approach has some drawbacks:
time intensive
update inconsistencies (Update sites change location, update doesn't work because of some version inconsistency between plug-ins that requires a lot of manual fixing, etc) (this has gotten better with 3.5 but still bugs me)
no "global" update site, I manually have to manage several locations
I tried alternatives like Yoxos for configuration management but there plug-ins were missing and / or not that well tested together as I expected.
I took a look at Idea as an IDE, the one thing I really loved was the update management: centralized and 90% of the functionality I'd be using are provided as a core that is tested and updated as one.
Thus the question: How do you manage your Eclipse installations and deal with updates?
From my experience with other Eclipse users they have at least the same problem with updates, but I haven't heard of a solution yet.
I've heard good things from other developers about Google's Workspace Mechanic.
That's what they use inside Google to manage Eclipse environments across teams.
It was open sourced in May 2010, and you may find more information in the blog post.
Note that the Workspace Mechanic does not yet manage plug-in installations (see discussion thread): it remembers "plugin preferences", but installing the plug-in themselves is not yet supported.
I also met such inconvenience. I always need install similar development tools(such as Mylyn, SVN, CDT, Clearcase) in different eclipse instances on different hosts(Windows, Linux).
Update:
Eclipse has officially offered a feature to help migrating what you have installed since Eclipse Indigo.
And it also supports install existing plug-ins from another instance.
My strategy is as follows:
When a new Eclipse version comes out, I install it fresh and set up a fresh workspace. Then, I install all the minimal plugins I need manually, such as Subversion and M2Eclipse. Also, I export the preferences (e.g. code formatting) to an external file and reimport it in the new Eclipse installation.
I always import existing projects into the workspace. I can use my workspaces (or better, my SVN working copy) from multiple Eclipse versions if necessary.
I only occassionally install additional Eclipse plugins and try to move all other toolchain parts into the build environment (e.g. Hudson with several slaves, automated builds and release scripts, Sonar for code-quality reports etc.)
I try to minimize the complexity of the development setup on my local developer machine.
I only have one installations but I have multiple workspaces.
I synchronize the workspace setting by copying the content of <workspace_dir>/.metadata/.plugins/org.eclipse.core.runtime/.settings directory.
I also use the bookmarks to centralized to save the update-sites relevant for my work. This can act as a global update site. To import/export some bookmarks, go in Preferences -> Install/Update -> Available software sites. When a new Eclipse version comes out (once a year), I only have to install the plugins using the bookmarks.
I've just set up my machine from scratch and was wondering if there are any open available ready to use Eclipse versions (3.5 preferred) which have already installed famous (most used) plugins like subversion support, maven, pmd, checkstyle, findbugs etc. This would save me time setting it up myself.
thx,
kuku
Never really tried it myself, but this may ease it up for you: yoxos
And then there's myeclipseide but I think you pay for it.
For making sure everyone on our team works with the same set of plugins, we are using the notion of "group of plugins" in a Nexus Pro (so non-free) repository
Nexus Professional has support for Eclipse P2 repositories, and it can serve Eclipse plugin artifacts to tools that know how to interact with the Eclipse P2 repository format including Eclipse 3.4 Ganymede.
If you use the Eclipse IDE, you probably have a set of plugins which every single developer needs to install to get productive.
Using Nexus Professional, you can combine multiple Eclipse update sites into a single URL which your developers can use when they are configuring a development environment.
Using Nexus Professional as a single point-of-access between your developers and the Eclipse update sites they depend on allows you to manage and define a set of common Eclipse plugins in your organization's Eclipse development environment.