On 18 Mar 2011, at 21:28, Aaron Digulla wrote: > Hello, > > I've converted the first batch of 3.6.2 archives from > http://www.eclipse.org/downloads/, namely: > > eclipse-3.6.2-delta-pack.zip > eclipse-modeling-helios-SR2-incubation-linux-gtk.tar.gz > eclipse-rcp-helios-SR2-linux-gtk.tar.gz > eclipse-reporting-helios-SR2-linux-gtk.tar.gz > eclipse-SDK-3.6.2-win32.zip > org.eclipse.rcp-3.6.2.zip > org.eclipse.rcp.source-3.6.2.zip > > That's 1074 artifacts, 283 with sources. > > You can find the result in > /home/nexus/workspace/org.eclipse.dash.m4e.tools/tmp/m2repo/
Looks good from what I've seen briefly. A couple of thoughts: <dependency> <groupId>org.eclipse.jface</groupId> <artifactId>org.eclipse.jface</artifactId> <version>[3.2.0,4.0.0)</version> <optional>false</optional> </dependency> We can probably optimise out the <optional>false</optional> if it's optional. Secondly, how does Maven handle the version range dependency? I know technically it should support it, but I am concerned it might not. We *should* be able to find out what the release version is based on what we know is in the repository. For example, org/eclipse/jface/org.eclipse.jface/3.6.2 exists, so we could replace [3.2.0,4.0.0) with 3.6.2. This might make it easier for direct resolutions, as well as recording what was actually compiled against. > Due to a bug, the repo is still polluted with non-Eclipse artifacts. No problem - we can probably just miss out anything that isn't in the org/eclipse tree. > During the conversion, I had warnings like this one: > > WARNING ../tmp/m2repo/org/junit/org.junit/3.8.2/org.junit-3.8.2.jar > differs from > ../tmp/eclipse-SDK-3.6.2-win32_home/m2repo/org/junit/org.junit/3.8.2/org.junit-3.8.2.jar > > A quick search found four archives which contain this file: > > ./eclipse-reporting-helios-SR2-linux-gtk_home/m2repo/org/junit/org.junit/3.8.2/org.junit-3.8.2.jar > ./eclipse-modeling-helios-SR2-incubation-linux-gtk_home/m2repo/org/junit/org.junit/3.8.2/org.junit-3.8.2.jar > ./eclipse-rcp-helios-SR2-linux-gtk_home/m2repo/org/junit/org.junit/3.8.2/org.junit-3.8.2.jar > ./eclipse-SDK-3.6.2-win32_home/m2repo/org/junit/org.junit/3.8.2/org.junit-3.8.2.jar > > Comparing the first two shows that JUnit 3.8.2 from > eclipse-reporting-helios-SR2-linux-gtk.tar.gz and > eclipse-modeling-helios-SR2-incubation-linux-gtk.tar.gz have differences > near the beginning. > > In the file, it looks like this: > > 948 Defl:N 517 46% 03-18-11 17:09 7ce61aa8 > META-INF/MANIFEST.MF > 948 Defl:N 517 46% 03-18-11 17:15 7ce61aa8 > META-INF/MANIFEST.MF > > So you can see the file date is different. How can that happen? I > understand that Eclipse recreates the MANIFEST.MF when the JAR is signed > but why are many plug-ins signed several times? There may be a bug in which a signed jar is already re-signed; this wouldn't change the bits but would update the time processed. > Background: To make sure everything is ok, I check that all files are > identical when I merge repositories. Only, they aren't... Is the junit a special case? If so, we can probably ignore it. Alex _______________________________________________ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev