Skip to main content
[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

Back to the top