Re: [dash-dev] Git repo for m4e tools
Hello, To get things started, I've created a repo on github: https://github.com/digulla/org.eclipse.dash.m4e.tools Please have a look, especially to make sure the IP stuff is OK (license, copyright notice, etc). Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.pdark.de/ http://blog.pdark.de/ ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
[dash-dev] Project Dash m4e Tools
Hi, I've posted an explanation of the tools and an overview in my blog: http://blog.pdark.de/2011/03/18/project-dash-m4e-tools-create-maven-artifacts-from-eclipse-plug-ins/ Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.pdark.de/ http://blog.pdark.de/ ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Project Dash m4e Tools
Zitat von Aaron Digulla : I've posted an explanation of the tools and an overview in my blog: http://blog.pdark.de/2011/03/18/project-dash-m4e-tools-create-maven-artifacts-from-eclipse-plug-ins/ Forgot to mention: Please comment on https://bugs.eclipse.org/bugs/show_bug.cgi?id=340416 Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.pdark.de/ http://blog.pdark.de/ ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Git repo for m4e tools
Honestly, I think you're doing a better job than most Eclipse projects :-) Bear in mind that--owing to the fact that you're not a committer yet--we're going to have to run this as a contribution through the IP process. That shouldn't be a big deal, except that the IP team is running pretty hard with Indigo stuff right now. The fact that you've got the right headers, and all the right files in the right places should make this a lot easier/faster. The second you get your committer status, I'll snapshot the current version and use it to create the necessary "contribution" CQ. Any commits that you make after that point will be as a committer and subject to different rules (i.e. we won't have to take your ongoing work though the CQ process). Once we get check on the CQ, we can move the code into an Eclipse-based Git repo and we're off to the races. FWIW, others can contribute to the GitHub Repo, we just need to keep track of who they are (which Git does quite nicely for us). Hopefully, this doesn't sound scary. We just need to cover our intellectual property ownership backsides... Wayne On 03/18/2011 06:20 AM, Aaron Digulla wrote: > Hello, > > To get things started, I've created a repo on github: > > https://github.com/digulla/org.eclipse.dash.m4e.tools > > Please have a look, especially to make sure the IP stuff is OK > (license, copyright notice, etc). > > Regards, > ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Git repo for m4e tools
Zitat von Wayne Beaton : Honestly, I think you're doing a better job than most Eclipse projects :-) Thanks. I've started the AROS project (www.aros.org) which is a clean room implementation of the Amiga OS. That started in 1993 and I learned a lot about international copyright law, IP laws, etc. So I've been there, done that. Bear in mind that--owing to the fact that you're not a committer yet--we're going to have to run this as a contribution through the IP process. That shouldn't be a big deal, except that the IP team is running pretty hard with Indigo stuff right now. The fact that you've got the right headers, and all the right files in the right places should make this a lot easier/faster. I forgot the headers in the first commits; I hope that's not a problem. [...] Hopefully, this doesn't sound scary. We just need to cover our intellectual property ownership backsides... Looking at Sony vs. Hotz, or on groklaw, it does sound scary. But I have no intention to ever visit the US - so you can sue me as much as you like. Switzerland doesn't deport for copyright crimes. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.pdark.de/ http://blog.pdark.de/ ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Git repo for m4e tools
There was a header in the first file I looked at. I didn't notice the missing headers in the rest. Nice catch. FWIW, I include you in "our" when I say "our intellectual property backsides". It's not only you that we're trying to protect; potential adopters of the software need protections as well. :-) Wayne On 03/18/2011 12:07 PM, Aaron Digulla wrote: > Zitat von Wayne Beaton : > >> Honestly, I think you're doing a better job than most Eclipse >> projects :-) > > Thanks. I've started the AROS project (www.aros.org) which is a clean > room implementation of the Amiga OS. That started in 1993 and I > learned a lot about international copyright law, IP laws, etc. So I've > been there, done that. > >> Bear in mind that--owing to the fact that you're not a committer >> yet--we're going to have to run this as a contribution through the IP >> process. That shouldn't be a big deal, except that the IP team is >> running pretty hard with Indigo stuff right now. The fact that you've >> got the right headers, and all the right files in the right places >> should make this a lot easier/faster. > > I forgot the headers in the first commits; I hope that's not a problem. > >> [...] >> Hopefully, this doesn't sound scary. We just need to cover our >> intellectual property ownership backsides... > > Looking at Sony vs. Hotz, or on groklaw, it does sound scary. But I > have no intention to ever visit the US - so you can sue me as much as > you like. Switzerland doesn't deport for copyright crimes. > > Regards, > ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
[dash-dev] Naming the Maven effort
I am concerned that naming your efforts "m4e" is potentially confusing for the community as it seems awfully close to "m2e" [1]. "m2e" comes from "Maven 2 Plug-in for Eclipse" and, apparently, some folks from the Maven community are already asking about "m3e" for Maven 3. Thoughts? Wayne [1] http://www.eclipse.org/m2e ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Project Dash m4e Tools
Can we make sure that this sort of information eventually finds a home in the wiki? Wayne On 03/18/2011 07:52 AM, Aaron Digulla wrote: > Hi, > > I've posted an explanation of the tools and an overview in my blog: > > http://blog.pdark.de/2011/03/18/project-dash-m4e-tools-create-maven-artifacts-from-eclipse-plug-ins/ > > > Regards, > ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Project Dash m4e Tools
Am 18.03.2011 17:45, schrieb Wayne Beaton: > Can we make sure that this sort of information eventually finds a home > in the wiki? Can I already access the wiki? I thought I need to wait for my committer accolade. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Project Dash m4e Tools
Nah. You just need a Bugzilla ID. Wayne On 03/18/2011 03:31 PM, Aaron Digulla wrote: > Am 18.03.2011 17:45, schrieb Wayne Beaton: >> Can we make sure that this sort of information eventually finds a home >> in the wiki? > Can I already access the wiki? I thought I need to wait for my committer > accolade. > > Regards, > ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Naming the Maven effort
Am 18.03.2011 17:45, schrieb Wayne Beaton: > I am concerned that naming your efforts "m4e" is potentially confusing > for the community as it seems awfully close to "m2e" [1]. "m2e" comes > from "Maven 2 Plug-in for Eclipse" and, apparently, some folks from the > Maven community are already asking about "m3e" for Maven 3. > > Thoughts? I agree but naming is hard. Some suggestions: Eclipse Maven Tools - too long. Is that tools for Maven or Eclipse? Since we translate Eclipse bundles into Maven artifacts: "translate" in various languages: Catalan: traduir Croatian: prevesti Dutch: vertalen Filipino: isalin French: traduire Galician: traducir Or we use "m2e tools" because I'm building tools to use make Eclipse bundles usable in projects that use m2e to build. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Naming the Maven effort
The use of the repository produced by this effort is not limited to m2e, so I think "m2e tools" will be misleading. And, yes, naming is hard. ;-) -- Regards, Igor On 11-03-18 03:50 PM, Aaron Digulla wrote: Am 18.03.2011 17:45, schrieb Wayne Beaton: I am concerned that naming your efforts "m4e" is potentially confusing for the community as it seems awfully close to "m2e" [1]. "m2e" comes from "Maven 2 Plug-in for Eclipse" and, apparently, some folks from the Maven community are already asking about "m3e" for Maven 3. Thoughts? I agree but naming is hard. Some suggestions: Eclipse Maven Tools - too long. Is that tools for Maven or Eclipse? Since we translate Eclipse bundles into Maven artifacts: "translate" in various languages: Catalan: traduir Croatian: prevesti Dutch: vertalen Filipino: isalin French: traduire Galician: traducir Or we use "m2e tools" because I'm building tools to use make Eclipse bundles usable in projects that use m2e to build. Regards, ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
[dash-dev] Unknown Host on Hudson Slave 1 for maven.eclipse.org
The hudson build machines don't seem to know about maven.eclipse.org. I get the following issue. Error transferring file: Unknown host maven.eclipse.org -> [Help 2] ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Naming the Maven effort
On Fri, Mar 18, 2011 at 3:04 PM, Igor Fedorenko wrote: > The use of the repository produced by this effort is not limited to m2e, > so I think "m2e tools" will be misleading. You can consider using "Minerva" I'm going to donate a maven archetype for eclipse.org projects so maybe we can make things a bit more generic... http://wiki.eclipse.org/Minerva -- Cheers, Chris Aniszczyk http://aniszczyk.org +1 860 839 2465 ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
[dash-dev] First conversion of 3.6.2 projects
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/ Due to a bug, the repo is still polluted with non-Eclipse artifacts. 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? Background: To make sure everything is ok, I check that all files are identical when I merge repositories. Only, they aren't... Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
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: org.eclipse.jface org.eclipse.jface [3.2.0,4.0.0) false We can probably optimise out the false 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
[dash-dev] Maven wiki page and suggested repository layout
I've started a Maven wiki page: http://wiki.eclipse.org/Maven I've put some suggested repositories as per my previous mail on how we should organise nexus. It'd be great to get feedback on it. I also think we should probably drop most of the caches that exist on the maven.eclipse.org repository, like the 'google' and 'apache' forwards. http://maven.eclipse.org/nexus/index.html#view-repositories I propose to delete: * 3rd party * Apache snapshots * Codehaus snapshots * Google code * Java.net - maven 2 * java.net - m1 * java.net - m1 M2 shadow * Snapshots * Sonatype repositories This would leave: * Releases * Maven central * Central m1 shadow We might want to temporarily have a 'testing' repository so we can publish e.g. the trial work that Aaron has been doing. I'm happy to set up the repositories as proposed if people are OK with this approach. Alex ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Maven wiki page and suggested repository layout
I added Sonatype repositories for a reason, as not everything for Tycho is currently at Maven Central (most things are). The Codehaus snapshots is also needed to get the FindBugs version that is compatible with running with Maven 3 and Tycho. Snapshots we should keep. The reason is that Snapshots repository are for development deployments. So those eclipse projects that need to deploy items to be used by other eclipse projects, can do so with snapshots. This is important for projects like jgit and egit that might depend on snapshots. You can exclude the Snapshots repository from showing up in a Public URL so people would need and will need to add it specifically to their settings.xml. I for one plan to use Snapshots to deploy some development versions of the PsychoPath Processor as it doesn't need P2 or Eclipse to even run, it works though in both environments. Dave On 03/18/2011 07:00 PM, Alex Blewitt wrote: I've started a Maven wiki page: http://wiki.eclipse.org/Maven I've put some suggested repositories as per my previous mail on how we should organise nexus. It'd be great to get feedback on it. I also think we should probably drop most of the caches that exist on the maven.eclipse.org repository, like the 'google' and 'apache' forwards. http://maven.eclipse.org/nexus/index.html#view-repositories I propose to delete: * 3rd party * Apache snapshots * Codehaus snapshots * Google code * Java.net - maven 2 * java.net - m1 * java.net - m1 M2 shadow * Snapshots * Sonatype repositories This would leave: * Releases * Maven central * Central m1 shadow We might want to temporarily have a 'testing' repository so we can publish e.g. the trial work that Aaron has been doing. I'm happy to set up the repositories as proposed if people are OK with this approach. Alex ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
Re: [dash-dev] Maven wiki page and suggested repository layout
Rather than having a general "snapshots" bucket, can't we have a better name that is more appropriate to the Eclipse workflow? We should hide all the other repositories behind a virtual repository though so we can amend the list without leaking the set. Not convinced we should depend on external snapshots though - if there's a findbugs/tycho incompatibility it would be better to wait for a released version than risk having the snapshots get away from us. It's all to easy for people to start depending on more and more once you add a repository in. Alex Sent from my iPhone 4 On 18 Mar 2011, at 23:13, David Carver wrote: > I added Sonatype repositories for a reason, as not everything for Tycho is > currently at Maven Central (most things are). > > The Codehaus snapshots is also needed to get the FindBugs version that is > compatible with running with Maven 3 and Tycho. > > Snapshots we should keep. The reason is that Snapshots repository are for > development deployments. So those eclipse projects that need to deploy items > to be used by other eclipse projects, can do so with snapshots. This is > important for projects like jgit and egit that might depend on snapshots. > > You can exclude the Snapshots repository from showing up in a Public URL so > people would need and will need to add it specifically to their settings.xml. > > I for one plan to use Snapshots to deploy some development versions of the > PsychoPath Processor as it doesn't need P2 or Eclipse to even run, it works > though in both environments. > > Dave > > > On 03/18/2011 07:00 PM, Alex Blewitt wrote: >> I've started a Maven wiki page: >> >> http://wiki.eclipse.org/Maven >> >> I've put some suggested repositories as per my previous mail on how we >> should organise nexus. It'd be great to get feedback on it. I also think we >> should probably drop most of the caches that exist on the maven.eclipse.org >> repository, like the 'google' and 'apache' forwards. >> >> http://maven.eclipse.org/nexus/index.html#view-repositories >> >> I propose to delete: >> >> * 3rd party >> * Apache snapshots >> * Codehaus snapshots >> * Google code >> * Java.net - maven 2 >> * java.net - m1 >> * java.net - m1 M2 shadow >> * Snapshots >> * Sonatype repositories >> >> This would leave: >> >> * Releases >> * Maven central >> * Central m1 shadow >> >> We might want to temporarily have a 'testing' repository so we can publish >> e.g. the trial work that Aaron has been doing. >> >> I'm happy to set up the repositories as proposed if people are OK with this >> approach. >> >> Alex >> ___ >> dash-dev mailing list >> dash-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/dash-dev >> > > ___ > dash-dev mailing list > dash-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/dash-dev ___ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
