[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [dash-dev] First conversion of 3.6.2 projects
|
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