pde-dev http://dev.eclipse.org/mhonarc/lists/pde-dev/maillist.html pde-dev en-us Mon, 06 May 2013 17:30:12 GMT Mon, 06 May 2013 17:30:12 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) pde-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/pde-dev/maillist.html [pde-dev] 4.3 Endgame rules for PDE http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02192.html The 4.3 endgame plan has been posted: http://www.eclipse.org/eclipse/development/plans/freeze_plan_4_3.php Here are the expectations for contributing fixes to PDE during the end game Documentation changes: 1) Must not require code changes, including setti... The 4.3 endgame plan has been posted:
http://www.eclipse.org/eclipse/development/plans/freeze_plan_4_3.php

Here are the expectations for contributing fixes to PDE during the end game

Documentation changes:

1) Must not require code changes, including setting up context ids
2) Must be tagged with the documentation keyword in bugzilla
3) Changes to general PDE doc (not context help) should belong to PDE Documentation component
4) Should have updated copyright dates on each changed file

May 8-17 - contributions to RC1

To fix a bug:
1) Add RC1 target milestone
2) Push your fix to gerrit or attach a patch (check copyrights for each changed file)
3) Add another committer to the bugzilla review field, add them to the cc list, ask them to review your fix

To review a bug:
1) Check out the fix from Gerrit or apply the patch
2) Verify and approve (+2) on Gerrit or push the changes to master
3) Set the bugzilla review flag to +1
4) Copy the commit url from git.eclipse.org to the bug
5) Assign the bug to the fix creator
6) Mark the bug as RESOLVED FIXED

May 20-24 - contributions to RC2

To fix a bug:
1) Add RC2 target milestone
2) Push your fix to gerrit or attach a patch (check copyrights for each changed file)
3) Add 2 other committers to the bugzilla review field, add them to the cc list, ask them to review your fix

To review a bug:
1) Check out the fix from Gerrit or apply the patch
2a) If you are the first reviewer, verify (+1) on Gerrit
2b) If you are the second reviewer, approve (+2) on gerrit or push the changes to master
3) Set the bugzilla review flag to +1
4) Copy the commit url from git.eclipse.org to the bug
5) Assign the bug to the fix creator
6) Mark the bug as RESOLVED FIXED

May 28-31 - contributions to RC3

RC2 requirements + component lead approval + announcing change to platform-releng-dev@xxxxxxxxxxx + fix creating must verify

June 4-7 - contributions to RC4

RC2 requirements + 2 component leads + announcing change with risk assessment

Thanks,
Curtis


]]> Mon, 06 May 2013 17:28:43 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02192.html Curtis_Windatt@xxxxxxx (Curtis Windatt) [pde-dev] Gerrit Enabled http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02191.html Hello all PDE committers and contributors, Gerrit, the code review system, has been enabled for all PDE repositories (eclipse.pde, eclipse.pde.ui, eclipse.pde.build). This provides a streamlined process for reviewing and merging contributions into the ma... Hello all PDE committers and contributors,

Gerrit, the code review system, has been enabled for all PDE repositories (eclipse.pde, eclipse.pde.ui, eclipse.pde.build).  This provides a streamlined process for reviewing and merging contributions into the master branch.

Committers will still be able to push changes directly to the repository via the old ssh URLs (ex: ssh://git.eclipse.org/gitroot/pde/eclipse.pde.ui.git).

This wiki explains the steps to push a commit to Gerrit for review:
http://wiki.eclipse.org/Gerrit#Logon

Make sure to use the following configuration:
    remote.review.url=""> remote.review.push=HEAD:refs/for/master

Curtis]]> Thu, 11 Apr 2013 18:20:26 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02191.html Curtis_Windatt@xxxxxxx (Curtis Windatt) Re: [pde-dev] Single plug-in in Git. Project Layout http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02190.html Yes, the way things stand, this is what I'm forced to do. It's still a cumbersome to not be able to keep everything related to the plug-in in the project. JUnit tests are tightly tied to the code that they are testing. It strikes me ass odd that the most ...
On 2013-03-11 15:04, John Arthorne wrote:
FWIW I suggest option 1). You can always edit the readme.md and other root files like .gitignore using EGit's "Git Repositories" view under "Working Directory". Or if not using EGit, it can be edited with File > Open File. Keeping the plugin in a child folder also gives you a natural way to later add documentation, tests, or other files outside the plugin directory as needed over time. Having the plugin at the root of the repository feels very constraining and will likely limit your options as the code evolves.

Yes, the way things stand, this is what I'm forced to do. It's still a cumbersome to not be able to keep everything related to the plug-in in the project. JUnit tests are tightly tied to the code that they are testing. It strikes me ass odd that the most common IDE on the market doesn't support a layout where they reside in the same project.

- thomas

John




From:        Thomas Hallgren <thomas@xxxxxxx>
To:        "Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>,
Date:        03/11/2013 08:54 AM
Subject:        [pde-dev] Single plug-in in Git. Project Layout
Sent by:        pde-dev-bounces@xxxxxxxxxxx



Hi,

I'm trying to figure out the best layout for a single plug-in project in
Git. The project has a readme.md file (to be visible on the GitHub
frontpage) and tests. I've tried two options:

1. A plug-in and a test fragment.

/here.is.my.plugin
  /src
  /META-INF
  ...
/here.is.my.plugin.testfragment
  /src
  /META-INF
 ...
/readme.md

The problem with this layout is that since the readme.md file is not
part of any project, it is not visible in Eclipse.

2. The root of the Git repository is the root of the plug-in. In this
case I cannot have a test fragment.

/src/main/
/src/test/
/META-INF
/readme.md

This layout seems natural to me. The tests are bundled with code and the
readme.md is at the root of it all, but I cannot get the JUnit plug-in
tests to work unless I actually include the test-classes on my
Bundle-Classpath. What seems to be lacking is that the generated
"dev.properties" file used by the PDE launcher does not contain the test
classes. Is there a known remedy for this problem?

Regards,
Thomas Hallgren

_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev

 


_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev

]]> Mon, 11 Mar 2013 15:59:26 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02190.html thomas@xxxxxxx (Thomas Hallgren) Re: [pde-dev] Single plug-in in Git. Project Layout http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02189.html FWIW I suggest option 1). You can always edit the readme.md and other root files like .gitignore using EGit's &quot;Git Repositories&quot; view under &quot;Working Directory&quot;. Or if not using EGit, it can be edited with File &gt; Open File. Keeping the plugin in a child fol... FWIW I suggest option 1). You can always edit the readme.md and other root files like .gitignore using EGit's "Git Repositories" view under "Working Directory". Or if not using EGit, it can be edited with File > Open File. Keeping the plugin in a child folder also gives you a natural way to later add documentation, tests, or other files outside the plugin directory as needed over time. Having the plugin at the root of the repository feels very constraining and will likely limit your options as the code evolves.

John




From:        Thomas Hallgren <thomas@xxxxxxx>
To:        "Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>,
Date:        03/11/2013 08:54 AM
Subject:        [pde-dev] Single plug-in in Git. Project Layout
Sent by:        pde-dev-bounces@xxxxxxxxxxx



Hi,

I'm trying to figure out the best layout for a single plug-in project in
Git. The project has a readme.md file (to be visible on the GitHub
frontpage) and tests. I've tried two options:

1. A plug-in and a test fragment.

/here.is.my.plugin
  /src
  /META-INF
  ...
/here.is.my.plugin.testfragment
  /src
  /META-INF
 ...
/readme.md

The problem with this layout is that since the readme.md file is not
part of any project, it is not visible in Eclipse.

2. The root of the Git repository is the root of the plug-in. In this
case I cannot have a test fragment.

/src/main/
/src/test/
/META-INF
/readme.md

This layout seems natural to me. The tests are bundled with code and the
readme.md is at the root of it all, but I cannot get the JUnit plug-in
tests to work unless I actually include the test-classes on my
Bundle-Classpath. What seems to be lacking is that the generated
"dev.properties" file used by the PDE launcher does not contain the test
classes. Is there a known remedy for this problem?

Regards,
Thomas Hallgren

_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
]]> Mon, 11 Mar 2013 14:04:59 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02189.html John_Arthorne@xxxxxxx (John Arthorne) [pde-dev] Single plug-in in Git. Project Layout http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02188.html Hi, I'm trying to figure out the best layout for a single plug-in project in Git. The project has a readme.md file (to be visible on the GitHub frontpage) and tests. I've tried two options: 1. A plug-in and a test fragment. /here.is.my.plugin /src /META-IN... Hi,
I'm trying to figure out the best layout for a single plug-in project in Git. The project has a readme.md file (to be visible on the GitHub frontpage) and tests. I've tried two options:

1. A plug-in and a test fragment.

/here.is.my.plugin
  /src
  /META-INF
  ...
/here.is.my.plugin.testfragment
  /src
  /META-INF
 ...
/readme.md

The problem with this layout is that since the readme.md file is not part of any project, it is not visible in Eclipse.

2. The root of the Git repository is the root of the plug-in. In this case I cannot have a test fragment.

/src/main/
/src/test/
/META-INF
/readme.md

This layout seems natural to me. The tests are bundled with code and the readme.md is at the root of it all, but I cannot get the JUnit plug-in tests to work unless I actually include the test-classes on my Bundle-Classpath. What seems to be lacking is that the generated "dev.properties" file used by the PDE launcher does not contain the test classes. Is there a known remedy for this problem?

Regards,
Thomas Hallgren


]]> Mon, 11 Mar 2013 12:54:34 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02188.html thomas@xxxxxxx (Thomas Hallgren) [pde-dev] Fw: [cbi-dev] Tycho-friendly API Tools http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02187.html FYI. ----- Forwarded by John Arthorne/Ottawa/IBM on 02/27/2013 03:07 PM ----- From: Mickael Istria &lt;mistria@xxxxxxxxxx&gt; To: Common-build Developers discussion &lt;cbi-dev@xxxxxxxxxxx&gt;, Cc: p; Rob Stryker &lt;rstryker@xxxxxxxxxx&gt; Date: ; p; n... FYI.

----- Forwarded by John Arthorne/Ottawa/IBM on 02/27/2013 03:07 PM -----

From:        Mickael Istria <mistria@xxxxxxxxxx>
To:        Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>,
Cc:        Rob Stryker <rstryker@xxxxxxxxxx>
Date:        02/27/2013 01:38 PM
Subject:        [cbi-dev] Tycho-friendly API Tools
Sent by:        cbi-dev-bounces@xxxxxxxxxxx



Hi all,

Since we'd like to have some API Tools for JBoss Tools, but we're trying to avoid any eclipserun or antrunner plugin to do this job because they make the build more difficult to maintain, we've worked on Mojo that does what we need of API Tools. We've already described our efforts here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=399276
Here is the latest version of this mojo and dependencies: https://github.com/mickaelistria/apitooling

You'll see on the documentation how to give it a try without requiring to build anything (we have some experimental Nexus repo that contain everything necessary). There are currently 2 goals:
* one to generate .api_description file on eclipse-plugin
* one to generate api reports on an eclipse-plugin or an eclipse-repository that compares bundles with a baseline.

That is something we'd like to contribute to Tycho and CBI when it's good enough. But before that, we'd like to collect some feedback. So if you have time to give it a try, please do it, and give us feedback. This can be answers to this mail, GitHub issues or pull requests.
You'll notice that the Mojo has some Eclipse bundles as dependencies, that needs to be available in a Maven repositories. We just put them in one of our repo using a "mvn deploy-file". That also raise the question of whether the artifacts built by CBI should go into a Nexus repository for wider-consumption (by wider I mean out of Eclipse, in a Maven mojo, in a webapp, in an Android app...)

Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev
]]> Wed, 27 Feb 2013 20:11:38 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02187.html John_Arthorne@xxxxxxx (John Arthorne) [pde-dev] Commit rights for Darin Wright have been expired http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02186.html eclipse.pde.ui Committers, John Arthorne has expired the commit rights for Darin Wright (darin). The reason for this change is: eclipse.pde.ui merged into eclipse.pde eclipse.pde.ui Committers, John Arthorne has expired the commit rights for Darin Wright (darin). The reason for this change is: eclipse.pde.ui merged into eclipse.pde ]]> Tue, 11 Dec 2012 16:21:01 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02186.html emo@xxxxxxx (portal on behalf of emo) [pde-dev] Commit rights for Curtis Windatt have been expired http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02185.html eclipse.pde.ui Committers, John Arthorne has expired the commit rights for Curtis Windatt (cwindatt). The reason for this change is: eclipse.pde.ui merged into eclipse.pde eclipse.pde.ui Committers, John Arthorne has expired the commit rights for Curtis Windatt (cwindatt). The reason for this change is: eclipse.pde.ui merged into eclipse.pde ]]> Tue, 11 Dec 2012 16:20:03 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02185.html emo@xxxxxxx (portal on behalf of emo) [pde-dev] Commit rights for Olivier Thomann have been expired http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02184.html eclipse.pde.ui Committers, John Arthorne has expired the commit rights for Olivier Thomann (oliviert). The reason for this change is: eclipse.pde.ui merged into eclipse.pde eclipse.pde.ui Committers, John Arthorne has expired the commit rights for Olivier Thomann (oliviert). The reason for this change is: eclipse.pde.ui merged into eclipse.pde ]]> Tue, 11 Dec 2012 16:20:03 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02184.html emo@xxxxxxx (portal on behalf of emo) [pde-dev] Commit rights for Ankur Sharma have been expired http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02183.html eclipse.pde.ui Committers, John Arthorne has expired the commit rights for Ankur Sharma (asharma). The reason for this change is: eclipse.pde.ui merged into eclipse.pde eclipse.pde.ui Committers, John Arthorne has expired the commit rights for Ankur Sharma (asharma). The reason for this change is: eclipse.pde.ui merged into eclipse.pde ]]> Tue, 11 Dec 2012 16:20:02 GMT http://dev.eclipse.org/mhonarc/lists/pde-dev/msg02183.html emo@xxxxxxx (portal on behalf of emo)