You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(113) |
Aug
(56) |
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: Michelle S O. <ms...@ny...> - 2008-07-20 13:57:25
|
Does that mean that anytime the javagit jar's name changes, our build will break until we go in and fix the manifest file? If I understand that correctly then maybe we should change the jar's name to something static. I noticed something else when using (or at least trying to use) javagit. In order for one of our plugins to find javagit's classes, I have to add the javagit plugin as a dependency in our plugin's manifest file. When I do that though, the build breaks. I get the error 'Missing required plug-in edu.nyu.cs.javagit_0.0.0'. Is this something that you've already taken care of in your build script changes, or is it a different problem? Michelle ----- Original Message ----- From: Patrick Winters <pat...@ny...> Date: Sunday, July 20, 2008 0:57 am Subject: RE: [Gitclipse-devel] javagit plug-in To: 'Michelle S Osborne' <ms...@ny...> Cc: Gitclipse Devel <git...@li...> > This is made a little difficult because the javagit plug-in needs to > hardcode the jar filename in its manifest. What it does is include > the jar > in the packaged plug-in and add it to its own classpath. I don't think > there's any way for us to make the plug-in dymanic. We'll need to modify > the plug-in as versions and javagit filenames change. > > All we can do is point the build script to the filename to copy it > into the > plug-in project. Unless of course we rename the published javagit jar > file > to something static, devoid of version number. > -- > Patrick > > > -----Original Message----- > > From: Michelle S Osborne [mailto:ms...@ny...] > > Sent: Saturday, July 19, 2008 2:04 PM > > To: pat...@ny... > > Cc: git...@li... > > Subject: Re: [Gitclipse-devel] javagit plug-in > > > > Patrick, > > > > I like the idea of putting the location into a property file and then > > copying from that location into the plugin. Should we add it to > > build.local.properties? If we did that, we could have every successful > > javagit build publish the jar file to the location that the property > > file points to. This way we'd always have the most up-to-date working > > version. > > > > What do people think? If that sounds reasonable let me know and I can > > do it. > > > > Michelle > > > > ----- Original Message ----- > > From: Patrick Winters <pat...@ny...> > > Date: Saturday, July 19, 2008 3:18 am > > Subject: [Gitclipse-devel] javagit plug-in > > To: git...@li... > > > > > Hey All, > > > There is a plug-in project now for javagit that wraps the jar > > inside > > > a > > > plug-in. You can get the project from the gitclispe source. It only > > > requires that the "javagit-0.01-SNAPSHOT.jar" be in the project root. > > > We'll have to update the project as the versions change. I decided > > to > > > not check-in the jar file to the gitclipse repository, and require > > you > > > to build it yourself. > > > Michelle when you're ready I'll check-in modifications to the build > > > script and feature that include this javagit plug-in with the build. > > > Again, it will require the JAR to be inside the project directory. > > > Should we integrate this into our build process somehow, or just > > add > > > the location of the javagit jar in a property file so it can be > > copied > > > in? > > > -- > > > Patrick > > > > > > > > > --------------------------------------------------------------------- > > ---- > > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge > > > Build the coolest Linux based applications with Moblin SDK & win > > great > > > prizes > > > Grand prize is a trip for two to an Open Source event anywhere in > the > > > world > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > _______________________________________________ > > > Gitclipse-devel mailing list > > > Git...@li... > > > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel > |
From: Patrick W. <pat...@ny...> - 2008-07-20 04:57:10
|
This is made a little difficult because the javagit plug-in needs to hardcode the jar filename in its manifest. What it does is include the jar in the packaged plug-in and add it to its own classpath. I don't think there's any way for us to make the plug-in dymanic. We'll need to modify the plug-in as versions and javagit filenames change. All we can do is point the build script to the filename to copy it into the plug-in project. Unless of course we rename the published javagit jar file to something static, devoid of version number. -- Patrick > -----Original Message----- > From: Michelle S Osborne [mailto:ms...@ny...] > Sent: Saturday, July 19, 2008 2:04 PM > To: pat...@ny... > Cc: git...@li... > Subject: Re: [Gitclipse-devel] javagit plug-in > > Patrick, > > I like the idea of putting the location into a property file and then > copying from that location into the plugin. Should we add it to > build.local.properties? If we did that, we could have every successful > javagit build publish the jar file to the location that the property > file points to. This way we'd always have the most up-to-date working > version. > > What do people think? If that sounds reasonable let me know and I can > do it. > > Michelle > > ----- Original Message ----- > From: Patrick Winters <pat...@ny...> > Date: Saturday, July 19, 2008 3:18 am > Subject: [Gitclipse-devel] javagit plug-in > To: git...@li... > > > Hey All, > > There is a plug-in project now for javagit that wraps the jar > inside > > a > > plug-in. You can get the project from the gitclispe source. It only > > requires that the "javagit-0.01-SNAPSHOT.jar" be in the project root. > > We'll have to update the project as the versions change. I decided > to > > not check-in the jar file to the gitclipse repository, and require > you > > to build it yourself. > > Michelle when you're ready I'll check-in modifications to the build > > script and feature that include this javagit plug-in with the build. > > Again, it will require the JAR to be inside the project directory. > > Should we integrate this into our build process somehow, or just > add > > the location of the javagit jar in a property file so it can be > copied > > in? > > -- > > Patrick > > > > > > --------------------------------------------------------------------- > ---- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win > great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Gitclipse-devel mailing list > > Git...@li... > > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel |
From: Andrew C. <ac...@co...> - 2008-07-20 00:15:08
|
Please direct questions/answers to the git...@li... address. -- Drew ---------- Forwarded message ---------- Date: Sat, 19 Jul 2008 19:53:34 -0400 From: Michelle S Osborne <ms...@ny...> To: Chuanhan Qiu <cq...@ny...> Cc: osp <g22...@cs...> Subject: Re: [osp_2008] Need help for the JavaGit folks Han, What did you need to do to get javagit commands working? I've had git working on the shell for a while (so it's definitely on the system path) but I'm having what seems like the same problem running it through java. If I try to run any javagit commands I see the exception 'Unable to start sub-process'. If I try to run any git commands directly through a ProcessBuilder I get 'git:not found'. I'm also running os x 10.4. Thanks, Michelle ----- Original Message ----- From: Chuanhan Qiu <cq...@ny...> Date: Friday, July 11, 2008 0:08 am Subject: Re: [osp_2008] Need help for the JavaGit folks To: James Linder <jh...@ny...> Cc: "g22...@cs..." <g22...@cs...> > James, thanks for the pointers. I got it to work, though I think the > real problem is that I had to restart the machine, so that Java was > able to get the updated PATH from the environment. I am not sure if > there is a way for the $PATH to get picked up (by Java) without > restarting since I am new to Mac. If not, then the step of restarting > should be on our installation instructions. > Thanks and appreciate the help. > GitClipse, not sure if you guys already knew this, but the git init, > git commit, git add works nicely so I will actually try to get it > integrated into our plugin. > Han > > ----- Original Message ----- > From: James Linder <jh...@ny...> > Date: Thursday, July 10, 2008 9:13 pm > Subject: Re: [osp_2008] Need help for the JavaGit folks > To: Chuanhan Qiu <cq...@ny...> > Cc: "g22...@cs..." <g22...@cs...> > >> Hi Han, >> >> When you installed git, did you compile from source or install using > >> >> the prebuilt installation? Also, are you on OS X 10.5 or 10.4? >> >> If you are on 10.5 and installed from the prebuilt installation, did > >> >> you run the "2 - Setup Git Environment Variables" script? If not, > you >> >> should do so. >> >> If you are on 10.5 and built git from source, you should make sure > you >> >> have set up the environment variables in all the places the attached > >> >> script sets them up. Note: take care to set the correct path in the > >> >> script. >> >> If you are on 10.4 I imagine you built from source. If you set the > >> normal environment variables up in ~/.bashrc and/or ~/.bash_profile, > >> >> then I think there is a second place that they need to get set in. > I >> >> don't know where it is exactly because I run OS X 10.5. >> >> Hope that helps. >> >> Cheers, >> >> James >> >> >> On Jul 10, 2008, at 8:37 PM, Chuanhan Qiu wrote: >> >>> hi guys, I am trying to integrate the JavaGit APIs into our >>> GitClipse plugin. So I tried to run JavaGit unit tests for > git-add >> >>> and I am getting an IOException in UnixProcess.forkAndExec, the >>> detail message is "git-add" not found. I have git installed on my > >> >>> machine (/usr/local/git) and I am able to use git-add on my shell. > >> >>> I am using Mac OS X, can you guys shed some lights. Appreciate it. >>> Han >>> _______________________________________________ >>> G22_3033_003_su08 mailing list >>> G22...@cs... >>> http://www.cs.nyu.edu/mailman/listinfo/g22_3033_003_su08 >> >> > _______________________________________________ > G22_3033_003_su08 mailing list > G22...@cs... > http://www.cs.nyu.edu/mailman/listinfo/g22_3033_003_su08 _______________________________________________ G22_3033_003_su08 mailing list G22...@cs... http://www.cs.nyu.edu/mailman/listinfo/g22_3033_003_su08 |
From: Michelle S O. <ms...@ny...> - 2008-07-19 18:03:33
|
Patrick, I like the idea of putting the location into a property file and then copying from that location into the plugin. Should we add it to build.local.properties? If we did that, we could have every successful javagit build publish the jar file to the location that the property file points to. This way we'd always have the most up-to-date working version. What do people think? If that sounds reasonable let me know and I can do it. Michelle ----- Original Message ----- From: Patrick Winters <pat...@ny...> Date: Saturday, July 19, 2008 3:18 am Subject: [Gitclipse-devel] javagit plug-in To: git...@li... > Hey All, > There is a plug-in project now for javagit that wraps the jar inside > a > plug-in. You can get the project from the gitclispe source. It only > requires that the "javagit-0.01-SNAPSHOT.jar" be in the project root. > We'll have to update the project as the versions change. I decided to > not check-in the jar file to the gitclipse repository, and require you > to build it yourself. > Michelle when you're ready I'll check-in modifications to the build > script and feature that include this javagit plug-in with the build. > Again, it will require the JAR to be inside the project directory. > Should we integrate this into our build process somehow, or just add > the location of the javagit jar in a property file so it can be copied > in? > -- > Patrick > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gitclipse-devel mailing list > Git...@li... > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel |
From: <pm...@ny...> - 2008-07-19 18:02:29
|
Nice work. I should be using this tomorrow. -PB ------Original Message------ From: Patrick Winters Sender: git...@li... To: git...@li... ReplyTo: pat...@ny... Sent: Jul 18, 2008 11:32 PM Subject: [Gitclipse-devel] javagit plug-in Hey All, There is a plug-in project now for javagit that wraps the jar inside a plug-in. You can get the project from the gitclispe source. It only requires that the "javagit-0.01-SNAPSHOT.jar" be in the project root. We'll have to update the project as the versions change. I decided to not check-in the jar file to the gitclipse repository, and require you to build it yourself. Michelle when you're ready I'll check-in modifications to the build script and feature that include this javagit plug-in with the build. Again, it will require the JAR to be inside the project directory. Should we integrate this into our build process somehow, or just add the location of the javagit jar in a property file so it can be copied in? -- Patrick ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gitclipse-devel mailing list Git...@li... https://lists.sourceforge.net/lists/listinfo/gitclipse-devel Sent via BlackBerry |
From: Patrick W. <pat...@ny...> - 2008-07-19 06:32:52
|
Hey All, There is a plug-in project now for javagit that wraps the jar inside a plug-in. You can get the project from the gitclispe source. It only requires that the "javagit-0.01-SNAPSHOT.jar" be in the project root. We'll have to update the project as the versions change. I decided to not check-in the jar file to the gitclipse repository, and require you to build it yourself. Michelle when you're ready I'll check-in modifications to the build script and feature that include this javagit plug-in with the build. Again, it will require the JAR to be inside the project directory. Should we integrate this into our build process somehow, or just add the location of the javagit jar in a property file so it can be copied in? -- Patrick |
From: Andrew C. <ac...@co...> - 2008-07-18 02:05:14
|
Personally I think dialogs are simpler to implement and manage, but then in the long term if you decide you want multiple pages a wizard is definitely easier to maintain. If something is obviously a one page thing and will always be a one page, I don't see a problem with a dialog. If something could one day be seen to possibly have multiple pages lets use a wizard. -- Drew On Thu, 17 Jul 2008, Michelle S Osborne wrote: > I believe we're talking about two different things.. swapping out actions for commands vs swapping out dialogs for wizards. Switching the actions out for commands shouldn't take more than a few minutes. > > I'm not sure how the argument that we're voluntarily using page abstractions when we implement dialogs is compelling. I really don't see the benefit of using one over the other, and both IDEs that I regularly use have dialogs rather than wizards for most svn-related tasks. I hate to be the argumentative one, but this just feels like a waste of effort for questionable benefit. > > Michelle > > ----- Original Message ----- > From: pm...@ny... > Date: Thursday, July 17, 2008 7:26 pm > Subject: Re: [Gitclipse-devel] Commands vs ActionDelegates code review > To: Michelle S Osborne <ms...@ny...>, Patrick Winters <pat...@ny...> > Cc: Code Review <git...@li...>, Git...@sc..., Gitclipse Devel <git...@li...> > >> Hold on. Patrick's previous argument was compelling, so I am sold on >> wizards. >> >> But let's not rewrite something for the sake of rewriting it until >> this week's requirements for release are done. >> >> Remember this week's task list, they are all on the Milestones page. >> >> * do we have a plugin build of javagit yet? >> >> -P >> >> >> >> ------Original Message------ >> From: Michelle S Osborne >> Sender: >> To: Patrick Winters >> Cc: Code Review >> Cc: Git...@sc... >> Cc: Gitclipse Devel >> Sent: Jul 17, 2008 6:55 PM >> Subject: Re: [Gitclipse-devel] Commands vs ActionDelegates code review >> >> I'll take care of them. >> >> ----- Original Message ----- >> From: Patrick Winters <pat...@ny...> >> Date: Thursday, July 17, 2008 5:32 pm >> Subject: [Gitclipse-devel] Commands vs ActionDelegates code review >> To: Gitclipse Devel <git...@li...> >> Cc: Gitclipse Code Review <git...@li...> >> >> >>> In Gitclipse-5 I tried to convert some actions to the command >>> framework. We >>> have a lot of action delegates that need to be re-written as commands. >>> Anybody want to take a stab at it? >>> -- >>> Patrick >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win >> great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in >> the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Gitclipse-devel mailing list >>> Git...@li... >>> https://lists.sourceforge.net/lists/listinfo/gitclipse-devel >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Gitclipse-devel mailing list >> Git...@li... >> https://lists.sourceforge.net/lists/listinfo/gitclipse-devel >> >> >> Sent via BlackBerry > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gitclipse-codereview mailing list > Git...@li... > https://lists.sourceforge.net/lists/listinfo/gitclipse-codereview > |
From: Michelle S O. <ms...@ny...> - 2008-07-18 01:33:18
|
I believe we're talking about two different things.. swapping out actions for commands vs swapping out dialogs for wizards. Switching the actions out for commands shouldn't take more than a few minutes. I'm not sure how the argument that we're voluntarily using page abstractions when we implement dialogs is compelling. I really don't see the benefit of using one over the other, and both IDEs that I regularly use have dialogs rather than wizards for most svn-related tasks. I hate to be the argumentative one, but this just feels like a waste of effort for questionable benefit. Michelle ----- Original Message ----- From: pm...@ny... Date: Thursday, July 17, 2008 7:26 pm Subject: Re: [Gitclipse-devel] Commands vs ActionDelegates code review To: Michelle S Osborne <ms...@ny...>, Patrick Winters <pat...@ny...> Cc: Code Review <git...@li...>, Git...@sc..., Gitclipse Devel <git...@li...> > Hold on. Patrick's previous argument was compelling, so I am sold on > wizards. > > But let's not rewrite something for the sake of rewriting it until > this week's requirements for release are done. > > Remember this week's task list, they are all on the Milestones page. > > * do we have a plugin build of javagit yet? > > -P > > > > ------Original Message------ > From: Michelle S Osborne > Sender: > To: Patrick Winters > Cc: Code Review > Cc: Git...@sc... > Cc: Gitclipse Devel > Sent: Jul 17, 2008 6:55 PM > Subject: Re: [Gitclipse-devel] Commands vs ActionDelegates code review > > I'll take care of them. > > ----- Original Message ----- > From: Patrick Winters <pat...@ny...> > Date: Thursday, July 17, 2008 5:32 pm > Subject: [Gitclipse-devel] Commands vs ActionDelegates code review > To: Gitclipse Devel <git...@li...> > Cc: Gitclipse Code Review <git...@li...> > > > > In Gitclipse-5 I tried to convert some actions to the command > > framework. We > > have a lot of action delegates that need to be re-written as commands. > > Anybody want to take a stab at it? > > -- > > Patrick > > > > > > > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > > Build the coolest Linux based applications with Moblin SDK & win > great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in > the > > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Gitclipse-devel mailing list > > Git...@li... > > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gitclipse-devel mailing list > Git...@li... > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel > > > Sent via BlackBerry |
From: <pm...@ny...> - 2008-07-17 23:26:06
|
Hold on. Patrick's previous argument was compelling, so I am sold on wizards. But let's not rewrite something for the sake of rewriting it until this week's requirements for release are done. Remember this week's task list, they are all on the Milestones page. * do we have a plugin build of javagit yet? -P ------Original Message------ From: Michelle S Osborne Sender: To: Patrick Winters Cc: Code Review Cc: Git...@sc... Cc: Gitclipse Devel Sent: Jul 17, 2008 6:55 PM Subject: Re: [Gitclipse-devel] Commands vs ActionDelegates code review I'll take care of them. ----- Original Message ----- From: Patrick Winters <pat...@ny...> Date: Thursday, July 17, 2008 5:32 pm Subject: [Gitclipse-devel] Commands vs ActionDelegates code review To: Gitclipse Devel <git...@li...> Cc: Gitclipse Code Review <git...@li...> > In Gitclipse-5 I tried to convert some actions to the command > framework. We > have a lot of action delegates that need to be re-written as commands. > Anybody want to take a stab at it? > -- > Patrick > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gitclipse-devel mailing list > Git...@li... > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gitclipse-devel mailing list Git...@li... https://lists.sourceforge.net/lists/listinfo/gitclipse-devel Sent via BlackBerry |
From: Michelle S O. <ms...@ny...> - 2008-07-17 22:55:04
|
I'll take care of them. ----- Original Message ----- From: Patrick Winters <pat...@ny...> Date: Thursday, July 17, 2008 5:32 pm Subject: [Gitclipse-devel] Commands vs ActionDelegates code review To: Gitclipse Devel <git...@li...> Cc: Gitclipse Code Review <git...@li...> > In Gitclipse-5 I tried to convert some actions to the command > framework. We > have a lot of action delegates that need to be re-written as commands. > Anybody want to take a stab at it? > -- > Patrick > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gitclipse-devel mailing list > Git...@li... > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel |
From: Michelle S O. <ms...@ny...> - 2008-07-17 22:54:13
|
There's nothing requiring you to create a 'page'. You can put all of your code into the dialog class if you like. I think I did this first, and I did it because I was copying an example from the Clearcase plugin. It seemed nice to separate most of the widget-related code from the actions taken when OK or Cancel are pressed, but it's in no way mandatory. ----- Original Message ----- From: Patrick Winters <pat...@ny...> Date: Thursday, July 17, 2008 5:14 pm Subject: [Gitclipse-devel] Wizards vs Dialogs To: Gitclipse Devel <git...@li...> > Hey All, > I thought a bit about why we should be using Wizards instead of Dialogs. > Firstly, the claim was made that Dialogs are easier because we don't have > multiple pages to begin with. Looking at every dialog committed into > the > repository so far, each one has an associated page. Each page or part > is > not using any interface or base class and is being implemented in its > own > way everytime. > If we need to implement pages and parts to build a dialog, then we should > just use the Wizard interface and benefit from the Page base classes. > There > is no difference in code amount, and it simplifies things. > -- > Patrick > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gitclipse-devel mailing list > Git...@li... > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel |
From: Patrick W. <pat...@ny...> - 2008-07-17 22:31:34
|
In Gitclipse-5 I tried to convert some actions to the command framework. We have a lot of action delegates that need to be re-written as commands. Anybody want to take a stab at it? -- Patrick |
From: Patrick W. <pat...@ny...> - 2008-07-17 22:13:47
|
Hey All, I thought a bit about why we should be using Wizards instead of Dialogs. Firstly, the claim was made that Dialogs are easier because we don't have multiple pages to begin with. Looking at every dialog committed into the repository so far, each one has an associated page. Each page or part is not using any interface or base class and is being implemented in its own way everytime. If we need to implement pages and parts to build a dialog, then we should just use the Wizard interface and benefit from the Page base classes. There is no difference in code amount, and it simplifies things. -- Patrick |
From: Patrick W. <pat...@ny...> - 2008-07-17 17:58:21
|
FYI. I contacted a guy from the Eclipse developer team to see if we could do this correctly. The way we are using the menu extension (we have two examples) and adding into the team menu is a bit of a hack. I'm surprised it works really. I think we may need to hold off using them, or provide our own menu "Git" instead of "Team". The problem is they haven't translated the Team menu definition to the new way yet, and don't plan to until 3.5 he says. I think we have three options, and my vote is for the third. 1. We create a Git menu and forgoe the Team one. 2. We use our dirty little hack,. 3. We use mappings to make our UI Actions a "GenericCommandDelegate" to just call Commands when executed. http://wiki.eclipse.org/Platform_Command_Framework#Using_an_IActionDelegate_ to_execute_a_command With the third we can define our commands and handlers all independent of the ui and add key bindings and stuff. Then we just have a compatibility layer where we create the UI pieces with IActionDelegates which automatically map themselves to the command with a parameter. This way we don't have to double up on actions and commands, and in the future we can convert to the menu extension. Any thoughts? -- Patrick From: Paul Webster [mailto:Pau...@ca...] Sent: Thursday, July 17, 2008 10:27 AM To: Patrick Winters Subject: Re: Team MenuContributions I normally answer questions like this in the newsgroup, but I'll save you some time :-) You've hit on the only solution in 3.3. Menus are built with programmatic additions first (the ones the view itself provides), followed by menu contributions, followed by legacy action contributions (which is where the Team menu is coming from). Menu contributions cannot see legacy action contributions (which cannot see each other, a fundamental problem with action contributions). The problem in 3.3 is that if you provide the Team menu as a menu contribution, then you also need to provide a similar group structure or risk changing contribution order. In 3.5 we hope to convert the Team menu to a menu contribution, which would allow a locationURI="popup:team.main" to work (and then there should only be one menu contribution for Team). I swiped this definition from the org.eclipse.team.ui object contribution definition: <objectContribution objectClass="org.eclipse.core.resources.mapping.ResourceMapping" adaptable="true" id="org.eclipse.team.ui.ResourceContributions"> <menu label="%TeamGroupMenu.label" path="additions" id="team.main"> <separator name="group1"> </separator> <separator name="group2"> </separator> <separator name="group3"> </separator> <separator name="group4"> </separator> <separator name="group5"> </separator> <separator name="group6"> </separator> <separator name="group7"> </separator> <separator name="group8"> </separator> <separator name="group9"> </separator> <separator name="group10"> </separator> <separator name="targetGroup"> </separator> <separator name="projectGroup"> </separator> </menu> </objectContribution> If you have any other questions, please direct them to the eclipse.platform newsgroup - http://www.eclipse.org/newsgroups/ Paul Webster Eclipse Platform UI Committer IBM Rational Canada "Patrick Winters" <pat...@ny...> wrote on 07/17/2008 02:26:39 AM: > Paul, > I'm sorry to bother you but my hours of frustration have led me to the > source. I'm developing a plug-in to provide Git support in Eclipse 3.3, and > I'm trying to use the org.eclipse.ui.menu extension. I need to get my > commands into the Team context menu, but can't seem to figure out how to > formulate a locationURI. > I have something that hacks its way in, but I don't like it. > > <extension > point="org.eclipse.ui.menus"> > <menuContribution > locationURI="popup:org.eclipse.ui.popup.any?after=additions"> > <menu > id="team.main" > label="Team"> > <command > commandId="edu.nyu.cs.gitclipse.ui.commitCommand" > id="edu.nyu.cs.gitclipse.ui.menus.commitCommand"> > </command> > ... > > By setting my menu id like this, it will actually insert the commands into > the Team menupath; but this is incorrect and complicates things for me > greatly. Do you think you could help? |
From: Patrick W. <pat...@ny...> - 2008-07-17 17:33:13
|
FYI. I contacted a guy from the Eclipse developer team to see if we could do this correctly. The way we are using the menu extension (we have two examples) and adding into the team menu is a bit of a hack. I'm surprised it works really. I think we may need to hold off using them, or provide our own menu "Git" instead of "Team". The problem is they haven't translated the Team menu definition to the new way yet, and don't plan to until 3.5 he says. I think we have three options, and my vote is for the third. 1. We create a Git menu and forgoe the Team one. 2. We use our dirty little hack,. 3. We use mappings to make our UI Actions a "GenericCommandDelegate" to just call Commands when executed. http://wiki.eclipse.org/Platform_Command_Framework#Using_an_IActionDelegate_ to_execute_a_command With the third we can define our commands and handlers all independent of the ui and add key bindings and stuff. Then we just have a compatibility layer where we create the UI pieces with IActionDelegates which automatically map themselves to the command with a parameter. This way we don't have to double up on actions and commands, and in the future we can convert to the menu extension. Any thoughts? -- Patrick From: Paul Webster [mailto:Pau...@ca...] Sent: Thursday, July 17, 2008 10:27 AM To: Patrick Winters Subject: Re: Team MenuContributions I normally answer questions like this in the newsgroup, but I'll save you some time :-) You've hit on the only solution in 3.3. Menus are built with programmatic additions first (the ones the view itself provides), followed by menu contributions, followed by legacy action contributions (which is where the Team menu is coming from). Menu contributions cannot see legacy action contributions (which cannot see each other, a fundamental problem with action contributions). The problem in 3.3 is that if you provide the Team menu as a menu contribution, then you also need to provide a similar group structure or risk changing contribution order. In 3.5 we hope to convert the Team menu to a menu contribution, which would allow a locationURI="popup:team.main" to work (and then there should only be one menu contribution for Team). I swiped this definition from the org.eclipse.team.ui object contribution definition: <objectContribution objectClass="org.eclipse.core.resources.mapping.ResourceMapping" adaptable="true" id="org.eclipse.team.ui.ResourceContributions"> <menu label="%TeamGroupMenu.label" path="additions" id="team.main"> <separator name="group1"> </separator> <separator name="group2"> </separator> <separator name="group3"> </separator> <separator name="group4"> </separator> <separator name="group5"> </separator> <separator name="group6"> </separator> <separator name="group7"> </separator> <separator name="group8"> </separator> <separator name="group9"> </separator> <separator name="group10"> </separator> <separator name="targetGroup"> </separator> <separator name="projectGroup"> </separator> </menu> </objectContribution> If you have any other questions, please direct them to the eclipse.platform newsgroup - http://www.eclipse.org/newsgroups/ Paul Webster Eclipse Platform UI Committer IBM Rational Canada "Patrick Winters" <pat...@ny...> wrote on 07/17/2008 02:26:39 AM: > Paul, > I'm sorry to bother you but my hours of frustration have led me to the > source. I'm developing a plug-in to provide Git support in Eclipse 3.3, and > I'm trying to use the org.eclipse.ui.menu extension. I need to get my > commands into the Team context menu, but can't seem to figure out how to > formulate a locationURI. > I have something that hacks its way in, but I don't like it. > > <extension > point="org.eclipse.ui.menus"> > <menuContribution > locationURI="popup:org.eclipse.ui.popup.any?after=additions"> > <menu > id="team.main" > label="Team"> > <command > commandId="edu.nyu.cs.gitclipse.ui.commitCommand" > id="edu.nyu.cs.gitclipse.ui.menus.commitCommand"> > </command> > ... > > By setting my menu id like this, it will actually insert the commands into > the Team menupath; but this is incorrect and complicates things for me > greatly. Do you think you could help? |
From: Michelle S O. <ms...@ny...> - 2008-07-17 01:28:50
|
Han (and anyone else who is interested), The clearcase plugin is located at http://eclipse-ccase.cvs.sourceforge.net/eclipse-ccase/ In particular, when we were discussing caching we were looking at classes in the package http://eclipse-ccase.cvs.sourceforge.net/eclipse-ccase/net.sourceforge.eclipseccase/src/net/sourceforge/eclipseccase/ Michelle |
From: Michelle S O. <ms...@ny...> - 2008-07-16 15:48:36
|
Done. ----- Original Message ----- From: Andrew Case <ac...@co...> Date: Wednesday, July 16, 2008 1:25 am Subject: Re: [Gitclipse-devel] Welcome to the "Gitclipse-devel" mailing list To: Git...@li..., jav...@li... > Hey Gitclipsers/Javagiters, > > I went ahead and added us all to our respective gitclipse/javagit > mailing > lists (you should have gotten some emails about it). We should > probably > keep all our discussion to our own lists to minimize the cross traffic > > noise from the groups (stop using the class list unless it's class > specific). > > > Michelle, > > Can we have the [cc] mailings sent to gitclipse-build and > javagit-build > lists respectively? > > > I'm checking to make sure the archives are active too... > > Thanks! > -- > Drew > > > On Tue, 15 Jul 2008, git...@li... wrote: > > > Welcome to the Git...@li... mailing list! > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gitclipse-devel mailing list > Git...@li... > https://lists.sourceforge.net/lists/listinfo/gitclipse-devel |
From: Andrew C. <ac...@co...> - 2008-07-16 05:05:14
|
Hey Gitclipsers/Javagiters, I went ahead and added us all to our respective gitclipse/javagit mailing lists (you should have gotten some emails about it). We should probably keep all our discussion to our own lists to minimize the cross traffic noise from the groups (stop using the class list unless it's class specific). Michelle, Can we have the [cc] mailings sent to gitclipse-build and javagit-build lists respectively? I'm checking to make sure the archives are active too... Thanks! -- Drew On Tue, 15 Jul 2008, git...@li... wrote: > Welcome to the Git...@li... mailing list! > |
From: Patrick W. <pat...@ny...> - 2008-07-16 04:59:05
|
Paul, I figured some funky stuff out with how to manage menu properties and visibility. This would be much nicer if we targeted 3.4 but I think we can still make do. At the top of the plugin.xml you can see a couple of additions. I added a property tester that accepts an IResource and tests for some properties, our method of testing it is handled programmatically in the property tester class. I added an expression definition which says iterate over what you pass it, make sure they are IResource's and then call the property tester to see if it's a git resource. The team menu has a clause now that says with the current selection reference the definition I created above. Different definitions can be made, and this can be fine tuned later. For example, you may wish a team menu to be visible if this is a git project, but you might want the command handlers to be grayed out if the selected resource has a certain git status. http://linserv3.cims.nyu.edu:11000/changelog/OSP/?cs=430 -- Patrick |