Comments for Eclipse hints, tips, and random musings http://dev.eclipse.org/blogs/wayne Wayne Beaton's blog about Eclipse. Sat, 07 Nov 2009 14:50:09 +0000 http://wordpress.org/?v=2.6.5 Comment on The Power to Make things Better by Denis Roy http://dev.eclipse.org/blogs/wayne/2009/11/05/the-power-to-make-things-better/#comment-1477 Denis Roy Fri, 06 Nov 2009 18:44:13 +0000 http://dev.eclipse.org/blogs/wayne/?p=892#comment-1477 Great post, Wayne. Great post, Wayne.

]]> Comment on The Power to Make things Better by Chris Aniszczyk http://dev.eclipse.org/blogs/wayne/2009/11/05/the-power-to-make-things-better/#comment-1476 Chris Aniszczyk Thu, 05 Nov 2009 23:31:50 +0000 http://dev.eclipse.org/blogs/wayne/?p=892#comment-1476 Thanks for your hard work Wayne and adapting the new role. The only thing that upsets me atm is the lack of a full-time evangelist at Eclipse. Thanks for your hard work Wayne and adapting the new role.

The only thing that upsets me atm is the lack of a full-time evangelist at Eclipse.

]]> Comment on The Power to Make things Better by Jeff McAffer http://dev.eclipse.org/blogs/wayne/2009/11/05/the-power-to-make-things-better/#comment-1475 Jeff McAffer Thu, 05 Nov 2009 22:58:30 +0000 http://dev.eclipse.org/blogs/wayne/?p=892#comment-1475 This is awesome. Kudos (and thanks) to all involved. On the repo front, would be great to also talk about / look at durability. What is the retention policy around the things in the repos etc. This has been the topic of some debate in the planning council and elsewhere as we currently merrily toss old content from repos every SR... This is awesome. Kudos (and thanks) to all involved.

On the repo front, would be great to also talk about / look at durability. What is the retention policy around the things in the repos etc. This has been the topic of some debate in the planning council and elsewhere as we currently merrily toss old content from repos every SR…

]]> Comment on +iplog by Wayne Beaton http://dev.eclipse.org/blogs/wayne/2009/10/23/iplog/#comment-1474 Wayne Beaton Thu, 05 Nov 2009 21:49:14 +0000 http://dev.eclipse.org/blogs/wayne/?p=889#comment-1474 Hi Eike. The Bugzilla interface certainly doesn't make it easy to query the flags. However, the Automated IP Log tool does just this. If there is a different sort of query you need, let me know, and we can work something out. Hi Eike. The Bugzilla interface certainly doesn’t make it easy to query the flags. However, the Automated IP Log tool does just this. If there is a different sort of query you need, let me know, and we can work something out.

]]> Comment on +iplog by Eike http://dev.eclipse.org/blogs/wayne/2009/10/23/iplog/#comment-1473 Eike Sat, 24 Oct 2009 05:11:31 +0000 http://dev.eclipse.org/blogs/wayne/?p=889#comment-1473 Hi Wayne, Where in the process is it written that the iplog+ flag on an entire bug means that *all* comments are subject to IP clearance? In my opinion this makes absolutely no sense. You already mentioned one technical reason: If comments could be subject to IP clearance at all then this should certainly apply to dedicated single comments. For me the main reason against this usage of the flag is that I can not query the flags of the attachments. Or can I? Not that it's particularly convenient or free of redundancy to set the bug to iplog+ if any attachment has iplog+, but how else could I get a list of those bugs? Hi Wayne,

Where in the process is it written that the iplog+ flag on an entire bug means that *all* comments are subject to IP clearance? In my opinion this makes absolutely no sense. You already mentioned one technical reason: If comments could be subject to IP clearance at all then this should certainly apply to dedicated single comments. For me the main reason against this usage of the flag is that I can not query the flags of the attachments. Or can I? Not that it’s particularly convenient or free of redundancy to set the bug to iplog+ if any attachment has iplog+, but how else could I get a list of those bugs?

]]> Comment on Notification by email by Elias Volanakis http://dev.eclipse.org/blogs/wayne/2009/10/22/notification-by-email/#comment-1472 Elias Volanakis Thu, 22 Oct 2009 21:55:54 +0000 http://dev.eclipse.org/blogs/wayne/?p=887#comment-1472 Personally, I prefer receiving that information via email. While I welcome any additional channels (twitter, rss) I consider these optional (and frankly often more distracting than email). Subscription to the committer mailing list is mandatory, so at least you know we receive those mails ;-). Just my 2c, Elias. Personally, I prefer receiving that information via email. While I welcome any additional channels (twitter, rss) I consider these optional (and frankly often more distracting than email). Subscription to the committer mailing list is mandatory, so at least you know we receive those mails ;-). Just my 2c, Elias.

]]> Comment on Eclipse Maven Repository by Bob http://dev.eclipse.org/blogs/wayne/2009/08/13/eclipse-maven-repository/#comment-1471 Bob Thu, 15 Oct 2009 15:06:45 +0000 http://dev.eclipse.org/blogs/wayne/?p=825#comment-1471 I agree that an eclipse repository is needed, and that the current deployment to maven ibiblio is broken as far as version numbers and valid dependency ranges and actual dependencies. The fornax repository has it almost correct, as well as several others. Also needed in the repository are SOURCE artifacts, which can be deployed with the -sources qualifier the same way the current build artifacts are deployed. Right now I create these source artifacts myself, for every point release, and manually deploy to an internal repository (we do a lot of UML2 work internally, using maven as the build engine). IMHO, one of the main benefits of using Eclipse together with maven is the ability to automatically reference source artifacts in your development environment, using the eclipse-maven plugin takes care of this when the project is created or modified. Also, the dependency management mechanism of maven (the other great advantage of the product) and parent/child project -> project or artifact convention should be maintained, which requires a mapping of the standard flat project hierarchy seen in Eclipse. Comments left at Bug 283745 and 288644 (about the proposed groupId/artifactId convention, different than the convention used for all the other maven projects). I agree that an eclipse repository is needed, and that the current deployment to maven ibiblio is broken as far as version numbers and valid dependency ranges and actual dependencies. The fornax repository has it almost correct, as well as several others. Also needed in the repository are SOURCE artifacts, which can be deployed with the -sources qualifier the same way the current build artifacts are deployed. Right now I create these source artifacts myself, for every point release, and manually deploy to an internal repository (we do a lot of UML2 work internally, using maven as the build engine). IMHO, one of the main benefits of using Eclipse together with maven is the ability to automatically reference source artifacts in your development environment, using the eclipse-maven plugin takes care of this when the project is created or modified.

Also, the dependency management mechanism of maven (the other great advantage of the product) and parent/child project -> project or artifact convention should be maintained, which requires a mapping of the standard flat project hierarchy seen in Eclipse.

Comments left at Bug 283745 and 288644 (about the proposed groupId/artifactId convention, different than the convention used for all the other maven projects).

]]> Comment on How to Fix a Bug in Eclipse by Lars Vogel http://dev.eclipse.org/blogs/wayne/2009/09/28/how-to-fix-a-bug-in-eclipse/#comment-1470 Lars Vogel Tue, 29 Sep 2009 20:37:14 +0000 http://dev.eclipse.org/blogs/wayne/?p=883#comment-1470 Thanks Remy! Thanks Remy!

]]> Comment on How to Fix a Bug in Eclipse by Madhu http://dev.eclipse.org/blogs/wayne/2009/09/28/how-to-fix-a-bug-in-eclipse/#comment-1469 Madhu Tue, 29 Sep 2009 06:37:06 +0000 http://dev.eclipse.org/blogs/wayne/?p=883#comment-1469 Thanks Wayne for your efforts. This is helpful for budding contributors like me. Regards, Madhu http://eclipse-info.blogspot.com/ Thanks Wayne for your efforts. This is helpful for budding contributors like me.

Regards,
Madhu
http://eclipse-info.blogspot.com/

]]> Comment on How to Fix a Bug in Eclipse by Chris Aniszczyk http://dev.eclipse.org/blogs/wayne/2009/09/28/how-to-fix-a-bug-in-eclipse/#comment-1468 Chris Aniszczyk Tue, 29 Sep 2009 01:31:28 +0000 http://dev.eclipse.org/blogs/wayne/?p=883#comment-1468 On the <a href="http://wiki.eclipse.org/PDE/Plan/3.6" rel="nofollow">PDE Plan</a> for 3.6, we have an <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=243582" rel="nofollow">enhancement</a> to embed source related information into bundles. The idea was to add a header to the MANIFEST.MF that represents the source location of the bundle. The goal was to use a similar syntax to map files since that has been defined and we could potentially ride on the code that does that. Maybe this is something you can work so we don't duplicate work? On the PDE Plan for 3.6, we have an enhancement to embed source related information into bundles. The idea was to add a header to the MANIFEST.MF that represents the source location of the bundle. The goal was to use a similar syntax to map files since that has been defined and we could potentially ride on the code that does that.

Maybe this is something you can work so we don’t duplicate work?

]]>