I think it's better to not put editable source code in .forge. With upgrades of API's etc. it's sometimes necessary to throw away the .forge dir. I like the idea though, so maybe we can ask the user: "where do you want to save the plugin project?" on plugin installation which by default saves in .forge/plugins so that we don't mess up the user's file system. Paul On Wed, May 11, 2011 at 10:27 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > As I've been demoing forge, I've been pitching that one of the most > elegant aspects of the git-plugin command is that it automatically sets you > up with source code to hack on. After experimenting with a plugin tonight, I > realized that while the final artifact gets put in ~/.forge/plugins, the > repository is hidden away in a cryptic directory in my temporary folder. I > think behavior should be changed to make it more welcoming for developers to > contribute back. > > I propose one of the following two locations, though feel free to choose a > more flexible option: > > ~/.forge/plugin-repos > ~/forge/plugins > > ...or read an option from .forge/config. Perhaps prompt the user where to > stick the source even. > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Agreed. A simple prompt asking if they would like to save the source for later would probably be sufficient to isolate this choice from the workflow usability standpoint. Defaulting to "No" but if "Yes" is chosen, they will get a second prompt for where they would like to save the project. Thoughts? ~Lincoln On Wed, May 11, 2011 at 4:51 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > I say we prompt. After all, if you are downloading source, I'm very likely > going to want to know where you are putting that source. We could remember > the parent folder the first time they save source (make the config variable) > and suggest that location the second time they do it. That would be a > stellar experience. > > (We could even remind them they are free to hack on it, then reload). > > -Dan > > > On Wed, May 11, 2011 at 01:45, Paul Bakker <paul.bakker.nl(a)gmail.com&gt;wrote: > >> I think it's better to not put editable source code in .forge. With >> upgrades of API's etc. it's sometimes necessary to throw away the .forge >> dir. I like the idea though, so maybe we can ask the user: "where do you >> want to save the plugin project?" on plugin installation which by default >> saves in .forge/plugins so that we don't mess up the user's file system. >> >> Paul >> >> On Wed, May 11, 2011 at 10:27 AM, Dan Allen <dan.j.allen(a)gmail.com&gt;wrote: >> >>> As I've been demoing forge, I've been pitching that one of the most >>> elegant aspects of the git-plugin command is that it automatically sets you >>> up with source code to hack on. After experimenting with a plugin tonight, I >>> realized that while the final artifact gets put in ~/.forge/plugins, the >>> repository is hidden away in a cryptic directory in my temporary folder. I >>> think behavior should be changed to make it more welcoming for developers to >>> contribute back. >>> >>> I propose one of the following two locations, though feel free to choose >>> a more flexible option: >>> >>> ~/.forge/plugin-repos >>> ~/forge/plugins >>> >>> ...or read an option from .forge/config. Perhaps prompt the user where >>> to stick the source even. >>> >>> -Dan >>> >>> -- >>> Dan Allen >>> Principal Software Engineer, Red Hat | Author of Seam in Action >>> Registered Linux User #231597 >>> >>> http://www.google.com/profiles/dan.j.allen#about >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> >>> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev