Menu
▾
▴
gwt-openlayers-devl — Developer list. Fairly active.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
(3) |
Mar
(51) |
Apr
(8) |
May
(8) |
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(1) |
Feb
(21) |
Mar
(13) |
Apr
(8) |
May
(4) |
Jun
(3) |
Jul
(2) |
Aug
(11) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew H. <ahh...@gm...> - 2011-08-15 23:44:17
|
Hi All, Unless I have overlooked something, 100% of votes are 'YES'. So I will move to de-commission the SourceForge repository. Thanks for all your votes :) --AH On Thu, Aug 4, 2011 at 2:21 PM, Simon Borysiewicz < sim...@gm...> wrote: > YES vote. I have been working in a team that has been making additions > to the gwt-openlayers source and would like an easy way to put forward a > patch for review > > regards, > > Simon Borysiewicz > > ------------------------------ > * > * > *From:* Andrew Hughes [mailto:ahh...@gm...] > *Sent:* Monday, 1 August 2011 9:55 PM > *To:* gwt...@li...; > gwt...@li... > *Subject:* [Gwt-openlayers-users] GWT-OpenLayers : Vote on an SCM move to > BitBucket > > Hi All, > > This is for both the devel and users list. Currently the number of emails > we receive regarding contributing to the project indicates that the process > is not straight forward, not easy and not intuitive. This would no doubt > preclude a lot of "would be" contributors from contributing and something I > believe we must address. > > Goal: Make it as easy as possible for everyone to contribute > without compromising the stability and quality of the codebase. > > At this point you can read on or jump the the conclusion and vote at the > end.... > > *How Distributed Version Control Should be Used (IMHO):* > > Distributed version control should pass through a hierarchy of repositories > as it makes its way onto the stable baseline that releases are cut from > (Linus would probably call this a 'network of trust'). Believe it or not, > this is more about opening up access to source control than it is > restricting it. Why, because this way everyone has a sandbox repository to > fool around in, try things out, send them to others... do some RnD e.t.c. > This means that rather than sending an email to the mailing list about "how > can I contribute this" or "what is the process" or "here are some patches" > or "can I have access to the repository" everybody can just work with their > own repository... nice! It also means that since this is in a repository, it > can be easily promoted/pulled into the GWT-OpenLayers baseline ready for the > next release! via 'pull requests'. > > *What's the problem with GWT-OpenLayer's and Folllowing this:* > > The fundamental problem is that its *NOT EASY* for us to adhere to such a > process with SourceForge's source repository administration. It's possible, > but certainly not easy. > -Creating a new repository for a developer involves too much manual input. > A new member needs to send a request (email), the request needs to be > granted, the repository needs be be manually created by an administrator via > shell. > -Controlling access to each repository involves too much manual input, > SourceForge's administration web ui doesn't control who can push to each > repository. Administrators have to ssh in and then edit the > gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository > permissions. Again, this takes too much manual effort. > -Promoting code is also too manually intensive, the reason is that if an > individual actually gets their own repository, then then push up some work > to it. The only want that it will be push up into the baseline repository > that we release from is by sending emails, or patches via email e.t.c and > this is often not an intuitive or inviting process. This process is not > intrinsic in SourceForge's source control hosting. > > *Addressing these Issues:* > > Rather than documenting, emailing and publishing a DIY process of making a > contribution and how to work with source control, *we should target a > hosting service where the process is intrinsic in the service it's self * :) The > sooner we can switch the better. > > *CONCLUSION* > > Some of the developers are already using bitbucket ( > https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. > This can work concurrently with SF's mercurial. However, we should really > focus on bitbucket's additional features (such as forking, pull requests > e.t.c). These features provide us with a suitable service and an easy, > intrinsic process for contribution. Using SF and bitbucket concurrently is > something I would not recommend either, it doesn't solve our problem. > > *Please vote on a move to BitBucket and decommission SF's mercurial > repository YES/NO?* > > Cheers :) > > |
|
From: Edwin C. <com...@gm...> - 2011-08-08 19:17:04
|
This should be pretty easy to do once the move to Bitbucket, for which everybody seems in favour, is final: http://confluence.atlassian.com/display/BITBUCKET/Setting+Up+the+Bitbucket+Email+Service Greetings, Edwin On 7 August 2011 13:11, Francesco Izzi <fra...@gm...> wrote: > +1 this is a useful feature. > > Il giorno 07/ago/2011, alle ore 09:41, Giuseppe La Scaleia < > gla...@gm...> ha scritto: > > > Hi all,there is a way to notify via email commits done? would be useful to > have this. How about ?? > + 1 here > Regards Giuseppe. > > -- > Giuseppe La Scaleia > CNR - IMAA > geoSDI > Sviluppo Software > > C.da S. Loja > 85050 Tito Scalo - POTENZA (PZ) > Italia > > phone: +39 0971427305 > fax: +39 0971 427271 > mob: +39 3804697436 > mail: <giu...@ge...>giu...@ge... > skype: glascaleia > > web: <http://www.geosdi.org>http://www.geosdi.org > > > > > > > > -- > Giuseppe La Scaleia > CNR - IMAA > geoSDI - NSDI > Sviluppo Software > > C.da S. Loja > 85050 Tito Scalo - POTENZA (PZ) > Italia > > phone: +39 0971427305 > fax: +39 0971 427271 > mob: +39 3804697436 > mail: <giu...@ge...>giu...@ge... > skype: glascaleia > > web: <http://www.geosdi.org>http://www.geosdi.org > > > |
|
From: Edwin C. <com...@gm...> - 2011-08-01 13:04:09
|
Hi Dave, To vote just reply to the email with a YES or NO in the body. The nature of the repository will not change. The source code will still be in a Mercurial repository. What changes will be the address of the main repository. Currently the main repository (representing the main line of work) is hosted at SourceForge. We would like to move this repository to Bitbucket. Moving to Bitbucket makes things easier for committers as well as administrators. For committers it means: - Committers will have to sign up for Bitbucket (free). - Committers can fork the project at Bitbucket to create their own sandbox - If you are already have commit rights on SourceForge you can get commit rights on the main repo at BitBucket (just send an email to me) and pull changes from your fork into the main repo - If you do not have commit rights then you can send pull requests, so the admins can decide if they want to pull changes from your sandbox (probably via a sandbox of the admin). Greetings, Edwin On 1 August 2011 14:11, Dave Potts <dav...@pi...> wrote: > Hi > > 1. How does one vote? do you have some type of link that can be used? > 2. What happens to existing projects? > > I have an entire series of useful(?) changes (console,http,handler > stratgy,projection etc) They are part of my personnel codebase how could > I integrate these changes if you change the nature of the Mercurial > repository? > > > Dave. >> Hi All, >> >> This is for both the devel and users list. Currently the number of emails >> we >> receive regarding contributing to the project indicates that the process >> is >> not straight forward, not easy and not intuitive. This would no doubt >> preclude a lot of "would be" contributors from contributing and something >> I >> believe we must address. >> >> Goal: Make it as easy as possible for everyone to contribute >> without compromising the stability and quality of the codebase. >> >> At this point you can read on or jump the the conclusion and vote at the >> end.... >> >> *How Distributed Version Control Should be Used (IMHO):* >> >> Distributed version control should pass through a hierarchy of >> repositories >> as it makes its way onto the stable baseline that releases are cut from >> (Linus would probably call this a 'network of trust'). Believe it or not, >> this is more about opening up access to source control than it is >> restricting it. Why, because this way everyone has a sandbox repository to >> fool around in, try things out, send them to others... do some RnD e.t.c. >> This means that rather than sending an email to the mailing list about >> "how >> can I contribute this" or "what is the process" or "here are some patches" >> or "can I have access to the repository" everybody can just work with >> their >> own repository... nice! It also means that since this is in a repository, >> it >> can be easily promoted/pulled into the GWT-OpenLayers baseline ready for >> the >> next release! via 'pull requests'. >> >> *What's the problem with GWT-OpenLayer's and Folllowing this:* >> >> The fundamental problem is that its *NOT EASY* for us to adhere to such a >> process with SourceForge's source repository administration. It's >> possible, >> but certainly not easy. >> -Creating a new repository for a developer involves too much manual input. >> A >> new member needs to send a request (email), the request needs to be >> granted, >> the repository needs be be manually created by an administrator via shell. >> -Controlling access to each repository involves too much manual input, >> SourceForge's administration web ui doesn't control who can push to each >> repository. Administrators have to ssh in and then edit the >> gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository >> permissions. Again, this takes too much manual effort. >> -Promoting code is also too manually intensive, the reason is that if an >> individual actually gets their own repository, then then push up some work >> to it. The only want that it will be push up into the baseline repository >> that we release from is by sending emails, or patches via email e.t.c and >> this is often not an intuitive or inviting process. This process is not >> intrinsic in SourceForge's source control hosting. >> >> *Addressing these Issues:* >> >> Rather than documenting, emailing and publishing a DIY process of making a >> contribution and how to work with source control, *we should target a >> hosting service where the process is intrinsic in the service it's >> self * :) The >> sooner we can switch the better. >> >> *CONCLUSION* >> >> Some of the developers are already using bitbucket ( >> https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. >> This >> can work concurrently with SF's mercurial. However, we should really focus >> on bitbucket's additional features (such as forking, pull requests e.t.c). >> These features provide us with a suitable service and an easy, intrinsic >> process for contribution. Using SF and bitbucket concurrently is something >> I >> would not recommend either, it doesn't solve our problem. >> >> *Please vote on a move to BitBucket and decommission SF's mercurial >> repository YES/NO?* >> >> Cheers :) >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help often. >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Gwt-openlayers-users mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > |
|
From: Andrew H. <ahh...@gm...> - 2011-08-01 11:55:00
|
Hi All, This is for both the devel and users list. Currently the number of emails we receive regarding contributing to the project indicates that the process is not straight forward, not easy and not intuitive. This would no doubt preclude a lot of "would be" contributors from contributing and something I believe we must address. Goal: Make it as easy as possible for everyone to contribute without compromising the stability and quality of the codebase. At this point you can read on or jump the the conclusion and vote at the end.... *How Distributed Version Control Should be Used (IMHO):* Distributed version control should pass through a hierarchy of repositories as it makes its way onto the stable baseline that releases are cut from (Linus would probably call this a 'network of trust'). Believe it or not, this is more about opening up access to source control than it is restricting it. Why, because this way everyone has a sandbox repository to fool around in, try things out, send them to others... do some RnD e.t.c. This means that rather than sending an email to the mailing list about "how can I contribute this" or "what is the process" or "here are some patches" or "can I have access to the repository" everybody can just work with their own repository... nice! It also means that since this is in a repository, it can be easily promoted/pulled into the GWT-OpenLayers baseline ready for the next release! via 'pull requests'. *What's the problem with GWT-OpenLayer's and Folllowing this:* The fundamental problem is that its *NOT EASY* for us to adhere to such a process with SourceForge's source repository administration. It's possible, but certainly not easy. -Creating a new repository for a developer involves too much manual input. A new member needs to send a request (email), the request needs to be granted, the repository needs be be manually created by an administrator via shell. -Controlling access to each repository involves too much manual input, SourceForge's administration web ui doesn't control who can push to each repository. Administrators have to ssh in and then edit the gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository permissions. Again, this takes too much manual effort. -Promoting code is also too manually intensive, the reason is that if an individual actually gets their own repository, then then push up some work to it. The only want that it will be push up into the baseline repository that we release from is by sending emails, or patches via email e.t.c and this is often not an intuitive or inviting process. This process is not intrinsic in SourceForge's source control hosting. *Addressing these Issues:* Rather than documenting, emailing and publishing a DIY process of making a contribution and how to work with source control, *we should target a hosting service where the process is intrinsic in the service it's self * :) The sooner we can switch the better. *CONCLUSION* Some of the developers are already using bitbucket ( https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. This can work concurrently with SF's mercurial. However, we should really focus on bitbucket's additional features (such as forking, pull requests e.t.c). These features provide us with a suitable service and an easy, intrinsic process for contribution. Using SF and bitbucket concurrently is something I would not recommend either, it doesn't solve our problem. *Please vote on a move to BitBucket and decommission SF's mercurial repository YES/NO?* Cheers :) |
|
From: Edwin C. <com...@gm...> - 2011-02-14 23:45:30
|
Thanks for all the quick responses to the BitBucket idea. Andrew, thanks for correcting me on the fact that Google Code does host Mercurial (and Git). Hadn't caught up with that. That does open up Google Code as an option. However, it does appeal to me that Bitbucket is more Mercurial focused (though it also offers SVN) and is a bit like the popular Github site in it's social aspects. Google Code has a good write up why you would want to create a server-side clone: http://code.google.com/p/support/wiki/MercurialFAQ#Why_should_I_create_a_server-side_clone? At BitBucket they call a server-side clone a fork, and from your fork you can issue pull requests to the repo you forked. The term fork seems a bit heavy, but is nothing big in BitBucket. BitBucket has some support for static pages: http://hgtip.com/tips/beginner/2009-10-13-free-hosting-at-bitbucket/ With this workaround it should be possible to host the Maven generated website. I can have a go at that. Furthermore Farrukh is -1 on Google Code. So far I gauge you would be open to moving at least the code to BitBucket. Greetings, Edwin P.S. Open to any arguments why should stick at SF (can't see why actually) or why we should move to another Hg provider than Bitbucket. On 15 February 2011 00:15, Andrew Hughes <ahh...@gm...> wrote: > FYI: Google code offer both mercurial and subversion - the choice is yours. > Examples: > http://code.google.com/p/gwt-presenter/source/checkout > http://code.google.com/p/gwt-platform/source/checkout > Since I would support staying with mercurial I'll build on this. The ability > to create new "per developer" or "per issue" clones on sf is a very human > intensive exercise. The result is that we end up with a lot of people from > the general public submitting work (as patches as best) via email (because > they don't have access to a clone/sandbox). If bit bucket can overcome this > I see it as a big step forward. Likewise, google code has web interface to > create a "per developer", "per issue" or "per whatever" clones... > Example, here is a list of clones currently on the gwt-platform project: > http://code.google.com/p/gwt-platform/source/clones > Also, notice the button at the bottom "create a clone". I would like to know > if you can limit who can push to what clone (via .hg/hgrc) - I would hope > so. > The only thing I don't like about google code, is that you can't upload > (scp, ftp e.t.c.) your own static web content anywhere (that I know of). > This means all of the javadocs and documentation we currently deploy to sf > would remain there (but thats a different issue). > Anyway.. like Edwin I don't have much spare time, this would be really > helpful to keep the project moving forward. > Cheers > --AH > > On Tue, Feb 15, 2011 at 9:29 AM, Edwin Commandeur > <com...@gm...> wrote: >> >> That's a fast response :) >> >> Google Code would be a no-go, because it is Subversion based and the >> GWT-OpenLayers code is now in a Mercurial repository. Since Bitbucket >> focuses on services around Mercurial, it seems like a natural choice. >> Also, Mercurial is far easier to use than SF for developers, and it is >> more social and easier for people to get involved. >> >> Greetings, >> Edwin Commandeur >> >> On 14 February 2011 23:50, Dave Koberstein <da...@da...> wrote: >> > Sounds like a good plan. I've been developing a lot of TODOs that I >> > need to >> > implement one of these days. So I can stay with std gwt-openlayers I've >> > taken to poking JSObject from my code with //TODO markers to clean up >> > later. These are almost all just pulling up existing openlayers >> > parameters >> > to gwt-openlayers. So shouldn't be any surprises or controversy. :) >> > >> > We might consider google code since there are many gwt projects there >> > already. But if you prefer bitbucket, it will be nice to try out >> > something >> > new. >> > >> > Dave >> > >> > On 2/14/2011 2:45 PM, Edwin Commandeur wrote: >> > >> > Dear GWT OpenLayers developers, >> > >> > In order to make better use of the distributed version control system >> > we are using I would like to propose to move the code over to >> > Bitbucket. I would see the following advantages: >> > >> > - Easy workflow for code contributions: Any Bitbucket user can fork, >> > submit code to their fork, and issue a pull request (versus the mails >> > with patches we get now) >> > - Hg repo works over https (which is easier to get going than SSH and >> > uses a port that is unlikely to be blocked by enterprise firewalls) >> > - Nicer online code browsing interface (whole Bitbucket interface is >> > clean and simple) >> > - Nice features like follow commits via RSS, of follow on Bitbucket >> > - Might attract even more developers, as Bitbucket is a social coding >> > site. >> > >> > The static web pages, issue tracker, and downloadable artifacts can >> > all remain at SourceForge. Downloads could be offered both at SF and >> > Bitbucket. >> > >> > I have already made a fork that is on BitBucket to try stuff out: >> > https://bitbucket.org/ecommandeur/gwt-openlayers >> > >> > We might want to make a user gwtopenmaps on bitbucket and place >> > gwt-openlayers under that user. If everybody (at least al admins) >> > agree, then I will do that. >> > >> > Greetings, >> > Edwin Commandeur >> > >> > >> > ------------------------------------------------------------------------------ >> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio >> > XE: >> > Pinpoint memory and threading errors before they happen. >> > Find and fix more than 250 security defects in the development cycle. >> > Locate bottlenecks in serial and parallel code that limit performance. >> > http://p.sf.net/sfu/intel-dev2devfeb >> > _______________________________________________ >> > Gwt-openlayers-devl mailing list >> > Gwt...@li... >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl >> > >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> Gwt-openlayers-devl mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Andrew H. <ahh...@gm...> - 2011-02-14 23:15:10
|
FYI: Google code offer both mercurial and subversion - the choice is yours. Examples: http://code.google.com/p/gwt-presenter/source/checkout <http://code.google.com/p/gwt-presenter/source/checkout> http://code.google.com/p/gwt-platform/source/checkout <http://code.google.com/p/gwt-platform/source/checkout>Since I would support staying with mercurial I'll build on this. The ability to create new "per developer" or "per issue" clones on sf is a very human intensive exercise. The result is that we end up with a lot of people from the general public submitting work (as patches as best) via email (because they don't have access to a clone/sandbox). If bit bucket can overcome this I see it as a big step forward. Likewise, google code has web interface to create a "per developer", "per issue" or "per whatever" clones... Example, here is a list of clones currently on the gwt-platform project: http://code.google.com/p/gwt-platform/source/clones Also, notice the button at the bottom "create a clone". I would like to know if you can limit who can push to what clone (via .hg/hgrc) - I would hope so. The only thing I don't like about google code, is that you can't upload (scp, ftp e.t.c.) your own static web content anywhere (that I know of). This means all of the javadocs and documentation we currently deploy to sf would remain there (but thats a different issue). Anyway.. like Edwin I don't have much spare time, this would be really helpful to keep the project moving forward. Cheers --AH On Tue, Feb 15, 2011 at 9:29 AM, Edwin Commandeur < com...@gm...> wrote: > That's a fast response :) > > Google Code would be a no-go, because it is Subversion based and the > GWT-OpenLayers code is now in a Mercurial repository. Since Bitbucket > focuses on services around Mercurial, it seems like a natural choice. > Also, Mercurial is far easier to use than SF for developers, and it is > more social and easier for people to get involved. > > Greetings, > Edwin Commandeur > > On 14 February 2011 23:50, Dave Koberstein <da...@da...> wrote: > > Sounds like a good plan. I've been developing a lot of TODOs that I need > to > > implement one of these days. So I can stay with std gwt-openlayers I've > > taken to poking JSObject from my code with //TODO markers to clean up > > later. These are almost all just pulling up existing openlayers > parameters > > to gwt-openlayers. So shouldn't be any surprises or controversy. :) > > > > We might consider google code since there are many gwt projects there > > already. But if you prefer bitbucket, it will be nice to try out > something > > new. > > > > Dave > > > > On 2/14/2011 2:45 PM, Edwin Commandeur wrote: > > > > Dear GWT OpenLayers developers, > > > > In order to make better use of the distributed version control system > > we are using I would like to propose to move the code over to > > Bitbucket. I would see the following advantages: > > > > - Easy workflow for code contributions: Any Bitbucket user can fork, > > submit code to their fork, and issue a pull request (versus the mails > > with patches we get now) > > - Hg repo works over https (which is easier to get going than SSH and > > uses a port that is unlikely to be blocked by enterprise firewalls) > > - Nicer online code browsing interface (whole Bitbucket interface is > > clean and simple) > > - Nice features like follow commits via RSS, of follow on Bitbucket > > - Might attract even more developers, as Bitbucket is a social coding > site. > > > > The static web pages, issue tracker, and downloadable artifacts can > > all remain at SourceForge. Downloads could be offered both at SF and > > Bitbucket. > > > > I have already made a fork that is on BitBucket to try stuff out: > > https://bitbucket.org/ecommandeur/gwt-openlayers > > > > We might want to make a user gwtopenmaps on bitbucket and place > > gwt-openlayers under that user. If everybody (at least al admins) > > agree, then I will do that. > > > > Greetings, > > Edwin Commandeur > > > > > ------------------------------------------------------------------------------ > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > > Pinpoint memory and threading errors before they happen. > > Find and fix more than 250 security defects in the development cycle. > > Locate bottlenecks in serial and parallel code that limit performance. > > http://p.sf.net/sfu/intel-dev2devfeb > > _______________________________________________ > > Gwt-openlayers-devl mailing list > > Gwt...@li... > > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > |
|
From: Farrukh N. <fa...@we...> - 2011-02-14 23:08:58
|
First thanks Edwin for the valuable leadership you have provided to this project. Sorry that I have been unable to contribute more to the project in a long time. I never quite liked googlecode for my OS projects. So -1 on googlecode. No direct experience with BitBucket but your arguments make sense. On 02/14/2011 05:59 PM, Edwin Commandeur wrote: > That's a fast response :) > > Google Code would be a no-go, because it is Subversion based and the > GWT-OpenLayers code is now in a Mercurial repository. Since Bitbucket > focuses on services around Mercurial, it seems like a natural choice. > Also, Mercurial is far easier to use than SF for developers, and it is > more social and easier for people to get involved. > > Greetings, > Edwin Commandeur > > On 14 February 2011 23:50, Dave Koberstein<da...@da...> wrote: >> Sounds like a good plan. I've been developing a lot of TODOs that I need to >> implement one of these days. So I can stay with std gwt-openlayers I've >> taken to poking JSObject from my code with //TODO markers to clean up >> later. These are almost all just pulling up existing openlayers parameters >> to gwt-openlayers. So shouldn't be any surprises or controversy. :) >> >> We might consider google code since there are many gwt projects there >> already. But if you prefer bitbucket, it will be nice to try out something >> new. >> >> Dave >> >> On 2/14/2011 2:45 PM, Edwin Commandeur wrote: >> >> Dear GWT OpenLayers developers, >> >> In order to make better use of the distributed version control system >> we are using I would like to propose to move the code over to >> Bitbucket. I would see the following advantages: >> >> - Easy workflow for code contributions: Any Bitbucket user can fork, >> submit code to their fork, and issue a pull request (versus the mails >> with patches we get now) >> - Hg repo works over https (which is easier to get going than SSH and >> uses a port that is unlikely to be blocked by enterprise firewalls) >> - Nicer online code browsing interface (whole Bitbucket interface is >> clean and simple) >> - Nice features like follow commits via RSS, of follow on Bitbucket >> - Might attract even more developers, as Bitbucket is a social coding site. >> >> The static web pages, issue tracker, and downloadable artifacts can >> all remain at SourceForge. Downloads could be offered both at SF and >> Bitbucket. >> >> I have already made a fork that is on BitBucket to try stuff out: >> https://bitbucket.org/ecommandeur/gwt-openlayers >> >> We might want to make a user gwtopenmaps on bitbucket and place >> gwt-openlayers under that user. If everybody (at least al admins) >> agree, then I will do that. >> -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2011-02-14 22:59:29
|
That's a fast response :) Google Code would be a no-go, because it is Subversion based and the GWT-OpenLayers code is now in a Mercurial repository. Since Bitbucket focuses on services around Mercurial, it seems like a natural choice. Also, Mercurial is far easier to use than SF for developers, and it is more social and easier for people to get involved. Greetings, Edwin Commandeur On 14 February 2011 23:50, Dave Koberstein <da...@da...> wrote: > Sounds like a good plan. I've been developing a lot of TODOs that I need to > implement one of these days. So I can stay with std gwt-openlayers I've > taken to poking JSObject from my code with //TODO markers to clean up > later. These are almost all just pulling up existing openlayers parameters > to gwt-openlayers. So shouldn't be any surprises or controversy. :) > > We might consider google code since there are many gwt projects there > already. But if you prefer bitbucket, it will be nice to try out something > new. > > Dave > > On 2/14/2011 2:45 PM, Edwin Commandeur wrote: > > Dear GWT OpenLayers developers, > > In order to make better use of the distributed version control system > we are using I would like to propose to move the code over to > Bitbucket. I would see the following advantages: > > - Easy workflow for code contributions: Any Bitbucket user can fork, > submit code to their fork, and issue a pull request (versus the mails > with patches we get now) > - Hg repo works over https (which is easier to get going than SSH and > uses a port that is unlikely to be blocked by enterprise firewalls) > - Nicer online code browsing interface (whole Bitbucket interface is > clean and simple) > - Nice features like follow commits via RSS, of follow on Bitbucket > - Might attract even more developers, as Bitbucket is a social coding site. > > The static web pages, issue tracker, and downloadable artifacts can > all remain at SourceForge. Downloads could be offered both at SF and > Bitbucket. > > I have already made a fork that is on BitBucket to try stuff out: > https://bitbucket.org/ecommandeur/gwt-openlayers > > We might want to make a user gwtopenmaps on bitbucket and place > gwt-openlayers under that user. If everybody (at least al admins) > agree, then I will do that. > > Greetings, > Edwin Commandeur > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > |
|
From: Edwin C. <com...@gm...> - 2011-02-14 22:48:58
|
Dear all, As you may have noticed I have not been very active on GWT-OpenLayers and will not be able to make time to really advance the project. Andrew Hughes did a fantastic job on the GWT-OL 0.5 release and made it all play nice with Maven, which eases development a lot. Thanks again Andrew! If someone wants to step up and take the lead for a next release than that would be great! Greetings, Edwin Commandeur |
|
From: Edwin C. <com...@gm...> - 2011-02-14 22:45:45
|
Dear GWT OpenLayers developers, In order to make better use of the distributed version control system we are using I would like to propose to move the code over to Bitbucket. I would see the following advantages: - Easy workflow for code contributions: Any Bitbucket user can fork, submit code to their fork, and issue a pull request (versus the mails with patches we get now) - Hg repo works over https (which is easier to get going than SSH and uses a port that is unlikely to be blocked by enterprise firewalls) - Nicer online code browsing interface (whole Bitbucket interface is clean and simple) - Nice features like follow commits via RSS, of follow on Bitbucket - Might attract even more developers, as Bitbucket is a social coding site. The static web pages, issue tracker, and downloadable artifacts can all remain at SourceForge. Downloads could be offered both at SF and Bitbucket. I have already made a fork that is on BitBucket to try stuff out: https://bitbucket.org/ecommandeur/gwt-openlayers We might want to make a user gwtopenmaps on bitbucket and place gwt-openlayers under that user. If everybody (at least al admins) agree, then I will do that. Greetings, Edwin Commandeur |
|
From: Edwin C. <com...@gm...> - 2010-10-11 22:26:02
|
Hi Mårten, Your contributions just hit the trunk :) I also deprecate the addCloseListener method as it was fiddling with a private method in OL. Greetings and thanks, Edwin On 6 October 2010 16:16, Mårten Karlberg <mar...@di...> wrote: > Hi Edwin! > > Here are the files I changed. I've tested the code in Firefox. It seems to > work fine except for the Framed-class which does not produce a popup at all. > No matter if I use the old constructor or the new constructor with the > CloseListener callback. We don't use the Framed-class so I won't spend any > more time on debugging it. I'm not sure if it worked before my changes > either. > > Regards > Mårten Karlberg, Digpro Solutions AB > > 2010/10/6 Edwin Commandeur <com...@gm...> >> >> Hi Marten, >> >> Good to hear you solved the popup problem. I would definitely be >> interested in that code :). I have never really used the popups that >> come with OpenLayers (used Ext GWT windows instead), so I never looked >> at closely how GWT-OL wraps them. >> >> Greetings, >> Edwin >> >> On 6 October 2010 12:07, Mårten Karlberg <mar...@di...> >> wrote: >> > I solved this. All Popup-classes are implemented in a strange way, not >> > following the JavaScript-constructors of OpenLayers. What is the reason >> > for >> > doing it like this? Anyway, I added constructors that take the >> > CloseListener >> > and binds it to the closeBox at creation of the popups. That's the way >> > OpenLayers does it and that's the way I think openlayers-gwt should do >> > it >> > too. I didn't remove the original openlayers-gwt constructors or the >> > addCloseListener-function in Popup for back compatibility issues. >> > >> > Are you interested in this code? >> > >> > Regards >> > Mårten Karlberg, Digpro Solutions AB >> > >> > >> > ------------------------------------------------------------------------------ >> > Beautiful is writing same markup. Internet Explorer 9 supports >> > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. >> > Spend less time writing and rewriting code and more time creating great >> > experiences on the web. Be a part of the beta today. >> > http://p.sf.net/sfu/beautyoftheweb >> > _______________________________________________ >> > Gwt-openlayers-users mailing list >> > Gwt...@li... >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> > >> > > > |
|
From: Andrew H. <ahh...@gm...> - 2010-09-30 15:25:43
|
Hi Everyone, Would anyone know how to wrap up one of these hover handlers... http://dev.openlayers.org/releases/OpenLayers-2.10/doc/apidocs/files/OpenLayers/Handler/Hover-js.html http://openlayers.org/dev/examples/hover-handler.html The native source seems to have a few things going on that I can't understand. I'm lost, help would be grand! :) --AH |
|
From: Couzic M. <mik...@gm...> - 2010-09-27 13:45:28
|
Guys, this is just awesome ! I'd just like to add : A Big Thank You *Andrew *for putting so much effort into this release and full maven support ! A Big Thank You *Edwin *for... well... everyting ! 2010/9/27 Andrew Hughes <ahh...@gm...> > Greetings, > > Around Twelve months in the making and GWT-OpenLayers 0.5 has been > released, a BIG THANK YOU to everyone who contributed. I've posted this > across a few mailing lists that might find this interesting blend of > technologies applicable to their needs, these are primarily the GeoServer, > GWT, GWT-Maven and OpenLayers. > > Summary: > > - Substantial increase in the number of OpenLayers features exposed. > - Many bug fixes and improvements. > - Maven support, 0.5 has been released to maven's central repo ( > http://repo1.maven.org/maven2/org/gwtopenmaps/openlayers/gwt-openlayers/ > ) > - Increased documentation (http://gwt-openlayers.sourceforge.net/ including > javadocs > http://gwt-openlayers.sourceforge.net/maven-site-latest/gwt-openlayers-client/apidocs/index.html > ) > - The project configuration is now entirely driven from maven > (gwt-maven). > > Some Big Thank You's for the people behind... > > ...Sonatype (http://www.sonatype.com/) for their support and fantastic > services/infrastructure. I can't recommend these guys enough - talk about > bringing large scale disciplined engineering to small scale projects :) Well > done. > > ...OpenLayers (http://openlayers.org/) for creating such a fantastic > library that we were able to wrap in GWT. > > ...GWT-Maven (http://mojo.codehaus.org/gwt-maven-plugin/), great plugin. > > ...and of course those behind GWT development! > > For more information, please take a look at the latest documentation > http://gwt-openlayers.sourceforge.net/ > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Andrew H. <ahh...@gm...> - 2010-09-27 13:38:19
|
Greetings, Around Twelve months in the making and GWT-OpenLayers 0.5 has been released, a BIG THANK YOU to everyone who contributed. I've posted this across a few mailing lists that might find this interesting blend of technologies applicable to their needs, these are primarily the GeoServer, GWT, GWT-Maven and OpenLayers. Summary: - Substantial increase in the number of OpenLayers features exposed. - Many bug fixes and improvements. - Maven support, 0.5 has been released to maven's central repo ( http://repo1.maven.org/maven2/org/gwtopenmaps/openlayers/gwt-openlayers/) - Increased documentation (http://gwt-openlayers.sourceforge.net/ including javadocs http://gwt-openlayers.sourceforge.net/maven-site-latest/gwt-openlayers-client/apidocs/index.html ) - The project configuration is now entirely driven from maven (gwt-maven). Some Big Thank You's for the people behind... ...Sonatype (http://www.sonatype.com/) for their support and fantastic services/infrastructure. I can't recommend these guys enough - talk about bringing large scale disciplined engineering to small scale projects :) Well done. ...OpenLayers (http://openlayers.org/) for creating such a fantastic library that we were able to wrap in GWT. ...GWT-Maven (http://mojo.codehaus.org/gwt-maven-plugin/), great plugin. ...and of course those behind GWT development! For more information, please take a look at the latest documentation http://gwt-openlayers.sourceforge.net/ |
|
From: Farrukh N. <fa...@we...> - 2010-09-24 20:24:24
|
Congrats to the team! On 09/24/2010 03:56 PM, Edwin Commandeur wrote: > Hi Andrew, > > I just uploaded the jars that people need to SF: > > gwt-openlayers-client.jar > gwt-openlayers-server.jar > > In addition I have zipped the complete sources of all modules in a single zip: > gwt-openlayers-sources.zip > > Because of the single sources zip I figure that people don't need the > sources jars on SF (or they can get that from the Maven repos). > > I guess now we have to spread the word as soon as the jars hit Maven > Central and prepare for 0.6. > > Just to be sure, you did take step 9 in this guide?: > https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide > > I also found out that index.html was messed up a little bit (not that > Firefox cared at all), because it contained some of the old html. I > cleaned it up, so it only has the please wait you will be redirected > statement :). > > Greetings, > Edwin > > > On 23 September 2010 09:09, Andrew Hughes<ahh...@gm...> wrote: > >> Rock'n'roll... :) >> http://repo1.maven.org/maven2/org/gwtopenmaps/openlayers/ >> >> On Thu, Sep 23, 2010 at 7:39 AM, Edwin Commandeur >> <com...@gm...> wrote: >> >>> You rock!!! >>> >>> On 22 September 2010 19:31, Andrew Hughes<ahh...@gm...> wrote: >>> >>>> It's released, not sure when it will appear in central but it's 3am and >>>> I >>>> have hit the wall..... >>>> The site is up too... >>>> http://gwt-openlayers.sourceforge.net/ >>>> Too tired... good night :) >>>> >> >> > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2010-09-24 19:56:18
|
Hi Andrew, I just uploaded the jars that people need to SF: gwt-openlayers-client.jar gwt-openlayers-server.jar In addition I have zipped the complete sources of all modules in a single zip: gwt-openlayers-sources.zip Because of the single sources zip I figure that people don't need the sources jars on SF (or they can get that from the Maven repos). I guess now we have to spread the word as soon as the jars hit Maven Central and prepare for 0.6. Just to be sure, you did take step 9 in this guide?: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide I also found out that index.html was messed up a little bit (not that Firefox cared at all), because it contained some of the old html. I cleaned it up, so it only has the please wait you will be redirected statement :). Greetings, Edwin On 23 September 2010 09:09, Andrew Hughes <ahh...@gm...> wrote: > Rock'n'roll... :) > http://repo1.maven.org/maven2/org/gwtopenmaps/openlayers/ > > On Thu, Sep 23, 2010 at 7:39 AM, Edwin Commandeur > <com...@gm...> wrote: >> >> You rock!!! >> >> On 22 September 2010 19:31, Andrew Hughes <ahh...@gm...> wrote: >> > It's released, not sure when it will appear in central but it's 3am and >> > I >> > have hit the wall..... >> > The site is up too... >> > http://gwt-openlayers.sourceforge.net/ >> > Too tired... good night :) > > |
|
From: Edwin C. <com...@gm...> - 2010-09-21 08:49:23
|
Hi Andrew, I worked a bit on the doco, and got some developer doco in. Sorry I wasn't able to push something earlier. Sunday afternoon was lost on setting up my netbook for doing development stuff (that works, because I have a netbook with 4Gb ram, 320Gb hd, and Intel su4100 chip), but at least I can now develop on all my machines :)... There is also a link to the old Trac wiki page in the dev doco, because I added information to Trac on how to setup Putty for connecting to SSH on windows (wiki is like a notebook for me). Using Putty for SSH is nicer than OpenSSH, because OpenSSH uses CygWin stuff and will not install together with CygWin (Cygwin is a pain anyway, but that aside...). With respect to the getting started guide. I deliberately removed the line about two popular modes of development. Let's first steer people in one direction, namely Maven GWT plugin and later (in Developer Guide) explain how to work on the project using different environments. I think the site content should suffice for now and I will continue to work on doco for the next point release (completely porting it to apt, and try make a pdf version). What should we do to wrap up the release? Can you get a 0.5 build into the Maven repo? Will that take up time for some form of approval? Do you want me to make a zip of the files and upload that? Do you agree that we should get rid of the branches in Hg and go to one default branch? MercurialEclipse makes it easy to work with branches, but I think we should not keep branches around that are not a real separate line of development. Your Mercurial knowledge is superior to mine, so I hoped you would be able to help out. By the way, I found a tutorial site called HgInit which is just awesome: http://hginit.com/top/. I have also been looking briefly at Bitbucket. Just to be clear, As I understand it, Moving to Bitbucket doesn't look appealing to me at this point, but I was interested in how it works there. Bitbucket seems to make it easy to create an online accessible clone of the central repo for individual developers. Their clone will be managed by Bitbucket and changesets can be pulled from it. On SF this seems more painful, because, the way I understand it, we as project admins are responsible for creating hg repos for each developer that wants one. Am I missing something or do you have an idea how we could easily have people that are not on the project team clone the repo and then pull back changes. Right now I suggest we use hg export/import. Greetings, Edwin |
|
From: Edwin C. <com...@gm...> - 2010-09-15 15:56:15
|
Hi Andrew, Given a small window for doco, and if no-one has objections then I would propose to set the date on monday 20th of september. A nice even number :) and it gives us the weekend. Andrew, since you have put the hard work in making the 0.5 release happen, please let me know if you think the date should be set earlier (e.g. coming friday) or later. Greetings, Edwin P.S. I recently started looking at Blogger (http://ecommandeur.blogspot.com/), so a GWT-OL 0.5 release woul be a nice topic for a first blog. On 15 September 2010 17:22, Andrew Hughes <ahh...@gm...> wrote: > UPDATE: > The remaining known bug blocking the 0.5 release has been fixed (changeset > 322) (NOTE: this is NOT v1.0.0, one day we will get there :D) > The plan... speak up if you don't like this.... But I will merge > trac_ticket_48 prior to the release and I will close out the trac_ticket_48 > branch. Speak up if this is not ok. Also, micouz's recent (default) > changesets have been merged onto the trac_ticket_48 branch (so they too will > be in the 0.5 release). > All seems good to go, there's a small window for doco if anyone's keen. > Edwin, would you like to propose a date? > Cheers > > On Tue, Sep 14, 2010 at 12:48 AM, Couzic Mikael <mik...@gm...> > wrote: >> >> Well, it is true there has been many new features since 0.4, but I agree >> with Lukas, version 1.0 carries a meaning of "Mission Accomplished" and >> GWT-OpenLayers doesn't cover completely the API of OpenLayers yet. It's not >> a big deal for us contributors, we have the development environment all set >> and it's fast and easy (well, most of the time ^^) for us to just implement >> what's missing when we need it, but a new user would expect a 1.0 version to >> have all the functionnality he would get by coding directly to the JS API. >> All in all, I don't think a 0.x version is problematic, I believe users >> will look at the dynamism of the community more than the version numbers, >> which are pretty much arbitrary after all. And the project doesn't look so >> bad on ohloh.net : >> http://www.ohloh.net/p/gwt-openlayers >> >> 2010/9/13 Lukas Johansson <luk...@de...> >>> >>> I agree with all that you say, but I also think that a 1.0 release would >>> signal/give a promise that it’s a complete wrap of OpenLayers, which at >>> least wasn’t true the last time I checked out the code (ended in me sending >>> a path to the list with new features). Don’t get me wrong you all done a >>> great job but a 1.0 release promises a lot, are gwt-ol really up for it yet? >>> >>> /Lukas >>> >>> >>> >>> >>> >>> Från: Andrew Hughes [mailto:ahh...@gm...] >>> Skickat: den 13 september 2010 15:57 >>> Till: gwt...@li... >>> Kopia: gwt...@li... >>> Ämne: Re: [Gwt-openlayers-users] [Gwt-openlayers-devl] >>> GWT-OpenLayersv0.5, let's please do a release... >>> >>> >>> >>> Release is fast approaching, 1 minor issue remains but.... >>> >>> >>> >>> Would it seem feasible to have this released as v1.0.0 and not 0.5? >>> GWT-OpenLayers is quite a mature and feature rich codebase now and I think >>> the... >>> >>> >>> >>> MAJOR.FEATURE.BUG >>> >>> >>> >>> ....convention is far more suitable. >>> >>> >>> >>> I also think that the initial impression of a 0.x version indicates that >>> the codebase is juvenile and lacks features - I don't believe that to be the >>> case here :) >>> >>> >>> >>> Cheers >>> >>> >>> >>> On Fri, Aug 20, 2010 at 3:51 AM, Edwin Commandeur >>> <com...@gm...> wrote: >>> >>> Hi Andrew, >>> >>> All for the better if you have progressed on #48. >>> >>> 12 months between releases is way too long indeed :( >>> >>> Greetings, >>> Edwin >>> >>> On 18 August 2010 12:35, Andrew Hughes <ahh...@gm...> wrote: >>> > Thanks Edwin, >>> > I must confess I did more work on the #trac_ticket_48 branch - naughty >>> > me. >>> > This was two things... >>> > 1. I merged the default tip onto the branch (i.e. they are in sync) >>> > 2. I added a heap of maven configuration for maven based releases, this >>> > is >>> > something I would really like to do for 0.5.... get a proper release >>> > out the >>> > door and into central. It will also make releasing much easier in the >>> > future >>> > - hence we should look foward to major, minor AND bug fix releases :) >>> > 12 >>> > months between releases with soooooo many new features, fixes e.t.c. is >>> > too >>> > long :) >>> > I'll push ahead and try and get this working asap. >>> > Cheers :) >>> > >>> > On Tue, Aug 17, 2010 at 10:57 PM, Edwin Commandeur >>> > <com...@gm...> wrote: >>> >> >>> >> Hi Andrew, >>> >> >>> >> You are absolutely right, that we should get out a 0.5 release. You >>> >> should have the rights to do a release (or alpha release if you like), >>> >> but I don't know if you would be okay to arrange the release. >>> >> >>> >> - panel control => +1 for move to 0.6 (all widget toolkits have >>> >> toolbars that are far nicer than the Panel) >>> >> - #48 => if you can merge this, I would be all for that! >>> >> - other enhancements => +1 for move to 0.6 >>> >> >>> >> Thanks for all the hard work you have already put into 0.5! >>> >> >>> >> Sorry for the low activity on my side lately. I hope to get things >>> >> rolling again soon... >>> >> >>> >> Greetings, >>> >> Edwin >>> >> >>> >> On 17 August 2010 08:35, Andrew Hughes <ahh...@gm...> wrote: >>> >> > Hi All, >>> >> > I'd like to propose that we try and get a new release of >>> >> > gwt-openlayers. Unless I am mistaken the 0.4 tag was created 12 >>> >> > Months >>> >> > ago >>> >> > :O >>> >> > According to trac 0.5 now has... 30 closed issues, 7 of which are >>> >> > defects. >>> >> > Remaining in 0.5.... >>> >> > There are currently 6 Active tickets.... 5 enhancements, and one >>> >> > defect. >>> >> > Ticket #41 "Panel Control Not Working" >>> >> > - https://sourceforge.net/apps/trac/gwt-openlayers/ticket/41 >>> >> > >>> >> > I notice that Edwin changed the milestone from 0.5 to 0.6 and then >>> >> > back >>> >> > to >>> >> > 0.5... can this be moved onto 0.6? >>> >> > >>> >> > Ticket #48 "Project Identifies and Multi Module Maven >>> >> > setup" https://sourceforge.net/apps/trac/gwt-openlayers/ticket/48 >>> >> > >>> >> > This work's been completed on the >>> >> > >>> >> > >>> >> > branch... http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/file/46f69b5f9bd5 it >>> >> > has not been merged with the default/tip yet. I can merge this NOW >>> >> > if >>> >> > people >>> >> > want (it will help with the release too)? But if people don't want >>> >> > this >>> >> > in >>> >> > 0.5 I can also merge later (onto 0.6). I don't care either way 0.5 >>> >> > or >>> >> > 0.6 >>> >> > but I don't want 0.5 to get held up any longer. >>> >> > >>> >> > Ticket's #20, #51, #1, #13 are all enhancements and I don't believe >>> >> > they >>> >> > should hold up a 0.5 release. Can we please move this into 0.6. >>> >> > In summary.... Questions: >>> >> > Should I merge down #48 to help with the (maven) release? >>> >> > Can ticket #41, #48, #20, #51, #1, #13 be moved into 0.6 so that the >>> >> > 0.5 >>> >> > release can go ahead? >>> >> > If the answer is NO, then can I please do an alpha release... >>> >> > 0.5-alpha1? >>> >> > CHEERS :) >>> >> > >>> >> > >>> >> > >>> >> > ------------------------------------------------------------------------------ >>> >> > This SF.net email is sponsored by >>> >> > >>> >> > Make an app they can't live without >>> >> > Enter the BlackBerry Developer Challenge >>> >> > http://p.sf.net/sfu/RIM-dev2dev >>> >> > _______________________________________________ >>> >> > Gwt-openlayers-devl mailing list >>> >> > Gwt...@li... >>> >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl >>> >> > >>> >> > >>> > >>> > >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Start uncovering the many advantages of virtual appliances >>> and start using them to simplify application deployment and >>> accelerate your shift to cloud computing >>> http://p.sf.net/sfu/novell-sfdev2dev >>> >>> _______________________________________________ >>> Gwt-openlayers-users mailing list >>> Gwt...@li... >>> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >>> >> > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Andrew H. <ahh...@gm...> - 2010-09-15 15:22:34
|
UPDATE: The remaining known bug blocking the 0.5 release has been fixed (changeset 322<http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/rev/99c067afecb8>) (NOTE: this is NOT v1.0.0, one day we will get there :D) The plan... speak up if you don't like this.... But I will merge trac_ticket_48 prior to the release and I will close out the trac_ticket_48 branch. Speak up if this is not ok. Also, micouz's recent (default) changesets have been merged onto the trac_ticket_48 branch (so they too will be in the 0.5 release). All seems good to go, there's a small window for doco if anyone's keen. Edwin, would you like to propose a date? Cheers On Tue, Sep 14, 2010 at 12:48 AM, Couzic Mikael <mik...@gm...>wrote: > Well, it is true there has been many new features since 0.4, but I agree > with Lukas, version 1.0 carries a meaning of "Mission Accomplished" and > GWT-OpenLayers doesn't cover completely the API of OpenLayers yet. It's not > a big deal for us contributors, we have the development environment all set > and it's fast and easy (well, most of the time ^^) for us to just implement > what's missing when we need it, but a new user would expect a 1.0 version to > have all the functionnality he would get by coding directly to the JS API. > All in all, I don't think a 0.x version is problematic, I believe users > will look at the dynamism of the community more than the version numbers, > which are pretty much arbitrary after all. And the project doesn't look so > bad on ohloh.net : > http://www.ohloh.net/p/gwt-openlayers > > > 2010/9/13 Lukas Johansson <luk...@de...> > >> I agree with all that you say, but I also think that a 1.0 release would >> signal/give a promise that it’s a complete wrap of OpenLayers, which at >> least wasn’t true the last time I checked out the code (ended in me sending >> a path to the list with new features). Don’t get me wrong you all done a >> great job but a 1.0 release promises a lot, are gwt-ol really up for it yet? >> >> /Lukas >> >> >> >> >> >> *Från:* Andrew Hughes [mailto:ahh...@gm...] >> *Skickat:* den 13 september 2010 15:57 >> *Till:* gwt...@li... >> *Kopia:* gwt...@li... >> *Ämne:* Re: [Gwt-openlayers-users] [Gwt-openlayers-devl] >> GWT-OpenLayersv0.5, let's please do a release... >> >> >> >> Release is fast approaching, 1 minor issue remains but.... >> >> >> >> Would it seem feasible to have this released as v1.0.0 and not 0.5? >> GWT-OpenLayers is quite a mature and feature rich codebase now and I think >> the... >> >> >> >> MAJOR.FEATURE.BUG >> >> >> >> ....convention is far more suitable. >> >> >> >> I also think that the initial impression of a 0.x version indicates that >> the codebase is juvenile and lacks features - I don't believe that to be the >> case here :) >> >> >> >> Cheers >> >> >> >> On Fri, Aug 20, 2010 at 3:51 AM, Edwin Commandeur < >> com...@gm...> wrote: >> >> Hi Andrew, >> >> All for the better if you have progressed on #48. >> >> 12 months between releases is way too long indeed :( >> >> Greetings, >> Edwin >> >> >> On 18 August 2010 12:35, Andrew Hughes <ahh...@gm...> wrote: >> > Thanks Edwin, >> > I must confess I did more work on the #trac_ticket_48 branch - naughty >> me. >> > This was two things... >> > 1. I merged the default tip onto the branch (i.e. they are in sync) >> > 2. I added a heap of maven configuration for maven based releases, this >> is >> > something I would really like to do for 0.5.... get a proper release out >> the >> > door and into central. It will also make releasing much easier in the >> future >> > - hence we should look foward to major, minor AND bug fix releases :) >> 12 >> > months between releases with soooooo many new features, fixes e.t.c. is >> too >> > long :) >> > I'll push ahead and try and get this working asap. >> > Cheers :) >> > >> > On Tue, Aug 17, 2010 at 10:57 PM, Edwin Commandeur >> > <com...@gm...> wrote: >> >> >> >> Hi Andrew, >> >> >> >> You are absolutely right, that we should get out a 0.5 release. You >> >> should have the rights to do a release (or alpha release if you like), >> >> but I don't know if you would be okay to arrange the release. >> >> >> >> - panel control => +1 for move to 0.6 (all widget toolkits have >> >> toolbars that are far nicer than the Panel) >> >> - #48 => if you can merge this, I would be all for that! >> >> - other enhancements => +1 for move to 0.6 >> >> >> >> Thanks for all the hard work you have already put into 0.5! >> >> >> >> Sorry for the low activity on my side lately. I hope to get things >> >> rolling again soon... >> >> >> >> Greetings, >> >> Edwin >> >> >> >> On 17 August 2010 08:35, Andrew Hughes <ahh...@gm...> wrote: >> >> > Hi All, >> >> > I'd like to propose that we try and get a new release of >> >> > gwt-openlayers. Unless I am mistaken the 0.4 tag was created 12 >> Months >> >> > ago >> >> > :O >> >> > According to trac 0.5 now has... 30 closed issues, 7 of which are >> >> > defects. >> >> > Remaining in 0.5.... >> >> > There are currently 6 Active tickets.... 5 enhancements, and one >> defect. >> >> > Ticket #41 "Panel Control Not Working" >> >> > - https://sourceforge.net/apps/trac/gwt-openlayers/ticket/41 >> >> > >> >> > I notice that Edwin changed the milestone from 0.5 to 0.6 and then >> back >> >> > to >> >> > 0.5... can this be moved onto 0.6? >> >> > >> >> > Ticket #48 "Project Identifies and Multi Module Maven >> >> > setup" https://sourceforge.net/apps/trac/gwt-openlayers/ticket/48 >> >> > >> >> > This work's been completed on the >> >> > >> >> > branch... >> http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/file/46f69b5f9bd5 >> it >> >> > has not been merged with the default/tip yet. I can merge this NOW if >> >> > people >> >> > want (it will help with the release too)? But if people don't want >> this >> >> > in >> >> > 0.5 I can also merge later (onto 0.6). I don't care either way 0.5 or >> >> > 0.6 >> >> > but I don't want 0.5 to get held up any longer. >> >> > >> >> > Ticket's #20, #51, #1, #13 are all enhancements and I don't believe >> they >> >> > should hold up a 0.5 release. Can we please move this into 0.6. >> >> > In summary.... Questions: >> >> > Should I merge down #48 to help with the (maven) release? >> >> > Can ticket #41, #48, #20, #51, #1, #13 be moved into 0.6 so that the >> 0.5 >> >> > release can go ahead? >> >> > If the answer is NO, then can I please do an alpha release... >> >> > 0.5-alpha1? >> >> > CHEERS :) >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------------ >> >> > This SF.net email is sponsored by >> >> > >> >> > Make an app they can't live without >> >> > Enter the BlackBerry Developer Challenge >> >> > http://p.sf.net/sfu/RIM-dev2dev >> >> > _______________________________________________ >> >> > Gwt-openlayers-devl mailing list >> >> > Gwt...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl >> >> > >> >> > >> > >> > >> >> >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing >> http://p.sf.net/sfu/novell-sfdev2dev >> >> _______________________________________________ >> Gwt-openlayers-users mailing list >> >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users >> >> > |
|
From: Couzic M. <mik...@gm...> - 2010-09-13 15:18:09
|
Well, it is true there has been many new features since 0.4, but I agree with Lukas, version 1.0 carries a meaning of "Mission Accomplished" and GWT-OpenLayers doesn't cover completely the API of OpenLayers yet. It's not a big deal for us contributors, we have the development environment all set and it's fast and easy (well, most of the time ^^) for us to just implement what's missing when we need it, but a new user would expect a 1.0 version to have all the functionnality he would get by coding directly to the JS API. All in all, I don't think a 0.x version is problematic, I believe users will look at the dynamism of the community more than the version numbers, which are pretty much arbitrary after all. And the project doesn't look so bad on ohloh.net : http://www.ohloh.net/p/gwt-openlayers 2010/9/13 Lukas Johansson <luk...@de...> > I agree with all that you say, but I also think that a 1.0 release would > signal/give a promise that it’s a complete wrap of OpenLayers, which at > least wasn’t true the last time I checked out the code (ended in me sending > a path to the list with new features). Don’t get me wrong you all done a > great job but a 1.0 release promises a lot, are gwt-ol really up for it yet? > > /Lukas > > > > > > *Från:* Andrew Hughes [mailto:ahh...@gm...] > *Skickat:* den 13 september 2010 15:57 > *Till:* gwt...@li... > *Kopia:* gwt...@li... > *Ämne:* Re: [Gwt-openlayers-users] [Gwt-openlayers-devl] > GWT-OpenLayersv0.5, let's please do a release... > > > > Release is fast approaching, 1 minor issue remains but.... > > > > Would it seem feasible to have this released as v1.0.0 and not 0.5? > GWT-OpenLayers is quite a mature and feature rich codebase now and I think > the... > > > > MAJOR.FEATURE.BUG > > > > ....convention is far more suitable. > > > > I also think that the initial impression of a 0.x version indicates that > the codebase is juvenile and lacks features - I don't believe that to be the > case here :) > > > > Cheers > > > > On Fri, Aug 20, 2010 at 3:51 AM, Edwin Commandeur < > com...@gm...> wrote: > > Hi Andrew, > > All for the better if you have progressed on #48. > > 12 months between releases is way too long indeed :( > > Greetings, > Edwin > > > On 18 August 2010 12:35, Andrew Hughes <ahh...@gm...> wrote: > > Thanks Edwin, > > I must confess I did more work on the #trac_ticket_48 branch - naughty > me. > > This was two things... > > 1. I merged the default tip onto the branch (i.e. they are in sync) > > 2. I added a heap of maven configuration for maven based releases, this > is > > something I would really like to do for 0.5.... get a proper release out > the > > door and into central. It will also make releasing much easier in the > future > > - hence we should look foward to major, minor AND bug fix releases :) 12 > > months between releases with soooooo many new features, fixes e.t.c. is > too > > long :) > > I'll push ahead and try and get this working asap. > > Cheers :) > > > > On Tue, Aug 17, 2010 at 10:57 PM, Edwin Commandeur > > <com...@gm...> wrote: > >> > >> Hi Andrew, > >> > >> You are absolutely right, that we should get out a 0.5 release. You > >> should have the rights to do a release (or alpha release if you like), > >> but I don't know if you would be okay to arrange the release. > >> > >> - panel control => +1 for move to 0.6 (all widget toolkits have > >> toolbars that are far nicer than the Panel) > >> - #48 => if you can merge this, I would be all for that! > >> - other enhancements => +1 for move to 0.6 > >> > >> Thanks for all the hard work you have already put into 0.5! > >> > >> Sorry for the low activity on my side lately. I hope to get things > >> rolling again soon... > >> > >> Greetings, > >> Edwin > >> > >> On 17 August 2010 08:35, Andrew Hughes <ahh...@gm...> wrote: > >> > Hi All, > >> > I'd like to propose that we try and get a new release of > >> > gwt-openlayers. Unless I am mistaken the 0.4 tag was created 12 Months > >> > ago > >> > :O > >> > According to trac 0.5 now has... 30 closed issues, 7 of which are > >> > defects. > >> > Remaining in 0.5.... > >> > There are currently 6 Active tickets.... 5 enhancements, and one > defect. > >> > Ticket #41 "Panel Control Not Working" > >> > - https://sourceforge.net/apps/trac/gwt-openlayers/ticket/41 > >> > > >> > I notice that Edwin changed the milestone from 0.5 to 0.6 and then > back > >> > to > >> > 0.5... can this be moved onto 0.6? > >> > > >> > Ticket #48 "Project Identifies and Multi Module Maven > >> > setup" https://sourceforge.net/apps/trac/gwt-openlayers/ticket/48 > >> > > >> > This work's been completed on the > >> > > >> > branch... > http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/file/46f69b5f9bd5 > it > >> > has not been merged with the default/tip yet. I can merge this NOW if > >> > people > >> > want (it will help with the release too)? But if people don't want > this > >> > in > >> > 0.5 I can also merge later (onto 0.6). I don't care either way 0.5 or > >> > 0.6 > >> > but I don't want 0.5 to get held up any longer. > >> > > >> > Ticket's #20, #51, #1, #13 are all enhancements and I don't believe > they > >> > should hold up a 0.5 release. Can we please move this into 0.6. > >> > In summary.... Questions: > >> > Should I merge down #48 to help with the (maven) release? > >> > Can ticket #41, #48, #20, #51, #1, #13 be moved into 0.6 so that the > 0.5 > >> > release can go ahead? > >> > If the answer is NO, then can I please do an alpha release... > >> > 0.5-alpha1? > >> > CHEERS :) > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > This SF.net email is sponsored by > >> > > >> > Make an app they can't live without > >> > Enter the BlackBerry Developer Challenge > >> > http://p.sf.net/sfu/RIM-dev2dev > >> > _______________________________________________ > >> > Gwt-openlayers-devl mailing list > >> > Gwt...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > >> > > >> > > > > > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing > http://p.sf.net/sfu/novell-sfdev2dev > > _______________________________________________ > Gwt-openlayers-users mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users > > |
|
From: Andrew H. <ahh...@gm...> - 2010-09-13 13:56:54
|
Release is fast approaching, 1 minor issue remains but.... Would it seem feasible to have this released as v1.0.0 and not 0.5? GWT-OpenLayers is quite a mature and feature rich codebase now and I think the... MAJOR.FEATURE.BUG ....convention is far more suitable. I also think that the initial impression of a 0.x version indicates that the codebase is juvenile and lacks features - I don't believe that to be the case here :) Cheers On Fri, Aug 20, 2010 at 3:51 AM, Edwin Commandeur < com...@gm...> wrote: > Hi Andrew, > > All for the better if you have progressed on #48. > > 12 months between releases is way too long indeed :( > > Greetings, > Edwin > > On 18 August 2010 12:35, Andrew Hughes <ahh...@gm...> wrote: > > Thanks Edwin, > > I must confess I did more work on the #trac_ticket_48 branch - naughty > me. > > This was two things... > > 1. I merged the default tip onto the branch (i.e. they are in sync) > > 2. I added a heap of maven configuration for maven based releases, this > is > > something I would really like to do for 0.5.... get a proper release out > the > > door and into central. It will also make releasing much easier in the > future > > - hence we should look foward to major, minor AND bug fix releases :) 12 > > months between releases with soooooo many new features, fixes e.t.c. is > too > > long :) > > I'll push ahead and try and get this working asap. > > Cheers :) > > > > On Tue, Aug 17, 2010 at 10:57 PM, Edwin Commandeur > > <com...@gm...> wrote: > >> > >> Hi Andrew, > >> > >> You are absolutely right, that we should get out a 0.5 release. You > >> should have the rights to do a release (or alpha release if you like), > >> but I don't know if you would be okay to arrange the release. > >> > >> - panel control => +1 for move to 0.6 (all widget toolkits have > >> toolbars that are far nicer than the Panel) > >> - #48 => if you can merge this, I would be all for that! > >> - other enhancements => +1 for move to 0.6 > >> > >> Thanks for all the hard work you have already put into 0.5! > >> > >> Sorry for the low activity on my side lately. I hope to get things > >> rolling again soon... > >> > >> Greetings, > >> Edwin > >> > >> On 17 August 2010 08:35, Andrew Hughes <ahh...@gm...> wrote: > >> > Hi All, > >> > I'd like to propose that we try and get a new release of > >> > gwt-openlayers. Unless I am mistaken the 0.4 tag was created 12 Months > >> > ago > >> > :O > >> > According to trac 0.5 now has... 30 closed issues, 7 of which are > >> > defects. > >> > Remaining in 0.5.... > >> > There are currently 6 Active tickets.... 5 enhancements, and one > defect. > >> > Ticket #41 "Panel Control Not Working" > >> > - https://sourceforge.net/apps/trac/gwt-openlayers/ticket/41 > >> > > >> > I notice that Edwin changed the milestone from 0.5 to 0.6 and then > back > >> > to > >> > 0.5... can this be moved onto 0.6? > >> > > >> > Ticket #48 "Project Identifies and Multi Module Maven > >> > setup" https://sourceforge.net/apps/trac/gwt-openlayers/ticket/48 > >> > > >> > This work's been completed on the > >> > > >> > branch... > http://gwt-openlayers.hg.sourceforge.net/hgweb/gwt-openlayers/gwt-openlayers/file/46f69b5f9bd5 > it > >> > has not been merged with the default/tip yet. I can merge this NOW if > >> > people > >> > want (it will help with the release too)? But if people don't want > this > >> > in > >> > 0.5 I can also merge later (onto 0.6). I don't care either way 0.5 or > >> > 0.6 > >> > but I don't want 0.5 to get held up any longer. > >> > > >> > Ticket's #20, #51, #1, #13 are all enhancements and I don't believe > they > >> > should hold up a 0.5 release. Can we please move this into 0.6. > >> > In summary.... Questions: > >> > Should I merge down #48 to help with the (maven) release? > >> > Can ticket #41, #48, #20, #51, #1, #13 be moved into 0.6 so that the > 0.5 > >> > release can go ahead? > >> > If the answer is NO, then can I please do an alpha release... > >> > 0.5-alpha1? > >> > CHEERS :) > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > This SF.net email is sponsored by > >> > > >> > Make an app they can't live without > >> > Enter the BlackBerry Developer Challenge > >> > http://p.sf.net/sfu/RIM-dev2dev > >> > _______________________________________________ > >> > Gwt-openlayers-devl mailing list > >> > Gwt...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > >> > > >> > > > > > > |
|
From: Andrew H. <ahh...@gm...> - 2010-08-30 14:36:17
|
Hi All, Tonight I was able to do some testing on the maven release via a TEMP repository I setup. Several bugs/issues were resolved.... but it would appear that we are good to perform an official release. The only outstanding piece of work in documentation. Please feel free to contribute (see 2 emails prior to this on on the thread or ask me how if you would like to help out). Looks like we'll be ready to go in a few days! Cheers!!! On Wed, Aug 25, 2010 at 10:21 AM, Farrukh Najmi < fa...@we...> wrote: > Hi Andrew, > > The initial site docs look very nice. Thanks again for this valuable > contribution. > > > On 08/24/2010 07:47 PM, Andrew Hughes wrote: > > Hi Farrukh, > > +1 for Jira :) > > *The maven site (documentation)...* > > It's early days, but I have deployed the tip/snapshot to sourceforge's > htdoc's (using mvn site site:deploy) so please take a look.. > http://gwt-openlayers.sourceforge.net/maven-site/ > http://gwt-openlayers.sourceforge.net/maven-site/apidocs/index.html (javadocs > too) > > If you have something add/fix/append/remove, please do so... you will > find the src under ./src/site of each module. > > - Site's are configured in ./src/site/site.xml. Including pages, menu's > layout e.t.c. > - Content can come from a few formats, and so far I've used APT (almost > plain text). You can see the pages in ./src/site/apt/some-page.apt I > recommend the apt qucik start guide here > http://www.scottnesbitt.net/docs/apt_quick_ref.pdf (I'd also recommend > xdoc in some cases too, it's your call). > > Maven has really good doco about sites here: > http://maven.apache.org/plugins/maven-site-plugin/ > > I don't believe the site will or should hold up a 0.5 release, as we can > release much more frequently in the future - but it would be nice to see > this documentation site evolve quickly. The community needs good > documentation :) > > > On Tue, Aug 24, 2010 at 10:47 PM, Farrukh Najmi < > fa...@we...> wrote: > >> >> +1 on the proposed resolution of issue 48: >> >> https://sourceforge.net/apps/trac/gwt-openlayers/ticket/48 >> >> Kudos to Andrew for the terrific work to implement the proposed >> resolution. >> Kudos to Edwin and other dev team members for a lot of good work leading >> up to 0.5 release. >> >> BTW, we should consider getting a free hosted JIRA license for the >> project. >> It would be so much better than TRAC. Lots of SF projects are doing that >> these days that SF should just get a blanket deal with Atlassian. >> >> >> On 08/24/2010 07:43 AM, Edwin Commandeur wrote: >> > Hi all, >> > >> > Andrew Hughes has been working hard to get things ready for a 0.5 >> > release. One open issue is merging Andrew's fantastic work to make >> > proper use of Maven onto the default branch. You can check out the >> > improvements and see the new project dir layout by cloning the >> > 'trac_ticket_48' branch. >> > >> > PLEASE MAIL IT TO THE DEV LIST WITHIN 2 or 3 DAYS IF YOU WANT TO GIVE >> > FEEDBACK ON THE MERGE!!! If you are not okay with the merge then >> > please provide arguments about the how and why. >> > >> > All in all we think is a huge win, so we hope you'll feel the same way. >> > >> > There will be three modules in the new project structure: >> > gwt-openlayers (parent) >> > gwt-openlayers-client (what is now gwt-ol) >> > gwt-openlayers-showcase >> > >> > After checking out the project you can simply import the modules for >> > project into Eclipse as an existing Maven project (requires the >> > m2eclipse plugin). The documentation will be updated to describe how >> > to debug it all without the Google Eclipse Plugin and how to get the >> > showcase to work with the Google Eclipse Plugin (should work with new >> > versions of GEP). >> > >> > Building the jar: >> > >> >> cd gwt-openlayers-client >> >> mvn package (or mvn install) >> >> >> > Running the showcase: >> > >> >> cd gwt-openlayers-showcase >> >> mvn gwt:run >> >> >> > Building the new website >> > >> >> cd gwt-openlayers >> >> mvn site (requires mvn install of gwt-openlayers-client, to also build >> JavaDoc and link it in site). >> >> >> > Eventually the proxy in gwt-openlayers-client will be moved to >> > gwt-openlayers-server. This is in line with gwt-maven conventions. >> > >> > Building the project with Ant is no longer supported, as we want to >> > focus on getting everyting right with Maven. Also, the project website >> > will be generated from Maven. >> > > -- > Regards, > Farrukh Najmi > > Web: http://www.wellfleetsoftware.com > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Edwin C. <com...@gm...> - 2010-08-25 09:20:50
|
Hi Andrew, The new site is a huge improvement. I love the special message. I even saw you create a nice graphic combining the GWT and OL graphics :). I can make a start with the user documentation (well push it tomorrow) and write some developer documentation on how to get things working in Eclipse (will mail you about that). Greetings, Edwin On 25 August 2010 02:51, Farrukh Najmi <fa...@we...> wrote: > Hi Andrew, > > The initial site docs look very nice. Thanks again for this valuable > contribution. > > On 08/24/2010 07:47 PM, Andrew Hughes wrote: > > Hi Farrukh, > +1 for Jira :) > The maven site (documentation)... > It's early days, but I have deployed the tip/snapshot to sourceforge's > htdoc's (using mvn site site:deploy) so please take a look.. > http://gwt-openlayers.sourceforge.net/maven-site/ > http://gwt-openlayers.sourceforge.net/maven-site/apidocs/index.html (javadocs > too) > If you have something add/fix/append/remove, please do so... you will find > the src under ./src/site of each module. > > Site's are configured in ./src/site/site.xml. Including pages, menu's layout > e.t.c. > Content can come from a few formats, and so far I've used APT (almost plain > text). You can see the pages in ./src/site/apt/some-page.apt I recommend the > apt qucik start guide > here http://www.scottnesbitt.net/docs/apt_quick_ref.pdf (I'd also recommend > xdoc in some cases too, it's your call). > > Maven has really good doco about sites > here: http://maven.apache.org/plugins/maven-site-plugin/ > I don't believe the site will or should hold up a 0.5 release, as we can > release much more frequently in the future - but it would be nice to see > this documentation site evolve quickly. The community needs good > documentation :) > > On Tue, Aug 24, 2010 at 10:47 PM, Farrukh Najmi > <fa...@we...> wrote: >> >> +1 on the proposed resolution of issue 48: >> >> https://sourceforge.net/apps/trac/gwt-openlayers/ticket/48 >> >> Kudos to Andrew for the terrific work to implement the proposed >> resolution. >> Kudos to Edwin and other dev team members for a lot of good work leading >> up to 0.5 release. >> >> BTW, we should consider getting a free hosted JIRA license for the >> project. >> It would be so much better than TRAC. Lots of SF projects are doing that >> these days that SF should just get a blanket deal with Atlassian. >> >> >> On 08/24/2010 07:43 AM, Edwin Commandeur wrote: >> > Hi all, >> > >> > Andrew Hughes has been working hard to get things ready for a 0.5 >> > release. One open issue is merging Andrew's fantastic work to make >> > proper use of Maven onto the default branch. You can check out the >> > improvements and see the new project dir layout by cloning the >> > 'trac_ticket_48' branch. >> > >> > PLEASE MAIL IT TO THE DEV LIST WITHIN 2 or 3 DAYS IF YOU WANT TO GIVE >> > FEEDBACK ON THE MERGE!!! If you are not okay with the merge then >> > please provide arguments about the how and why. >> > >> > All in all we think is a huge win, so we hope you'll feel the same way. >> > >> > There will be three modules in the new project structure: >> > gwt-openlayers (parent) >> > gwt-openlayers-client (what is now gwt-ol) >> > gwt-openlayers-showcase >> > >> > After checking out the project you can simply import the modules for >> > project into Eclipse as an existing Maven project (requires the >> > m2eclipse plugin). The documentation will be updated to describe how >> > to debug it all without the Google Eclipse Plugin and how to get the >> > showcase to work with the Google Eclipse Plugin (should work with new >> > versions of GEP). >> > >> > Building the jar: >> > >> >> cd gwt-openlayers-client >> >> mvn package (or mvn install) >> >> >> > Running the showcase: >> > >> >> cd gwt-openlayers-showcase >> >> mvn gwt:run >> >> >> > Building the new website >> > >> >> cd gwt-openlayers >> >> mvn site (requires mvn install of gwt-openlayers-client, to also build >> >> JavaDoc and link it in site). >> >> >> > Eventually the proxy in gwt-openlayers-client will be moved to >> > gwt-openlayers-server. This is in line with gwt-maven conventions. >> > >> > Building the project with Ant is no longer supported, as we want to >> > focus on getting everyting right with Maven. Also, the project website >> > will be generated from Maven. > > -- > Regards, > Farrukh Najmi > > Web: http://www.wellfleetsoftware.com > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Farrukh N. <fa...@we...> - 2010-08-25 00:52:04
|
Hi Andrew, The initial site docs look very nice. Thanks again for this valuable contribution. On 08/24/2010 07:47 PM, Andrew Hughes wrote: > Hi Farrukh, > > +1 for Jira :) > > *The maven site (documentation)...* > > It's early days, but I have deployed the tip/snapshot to sourceforge's > htdoc's (using mvn site site:deploy) so please take a look.. > http://gwt-openlayers.sourceforge.net/maven-site/ > http://gwt-openlayers.sourceforge.net/maven-site/apidocs/index.html (javadocs > too) > > If you have something add/fix/append/remove, please do so... you will > find the src under ./src/site of each module. > > * Site's are configured in ./src/site/site.xml. Including pages, > menu's layout e.t.c. > * Content can come from a few formats, and so far I've used APT > (almost plain text). You can see the pages in > ./src/site/apt/some-page.apt I recommend the apt qucik start > guide here > http://www.scottnesbitt.net/docs/apt_quick_ref.pdf (I'd also > recommend xdoc in some cases too, it's your call). > > Maven has really good doco about sites here: > http://maven.apache.org/plugins/maven-site-plugin/ > > I don't believe the site will or should hold up a 0.5 release, as we > can release much more frequently in the future - but it would be nice > to see this documentation site evolve quickly. The community needs > good documentation :) > > > On Tue, Aug 24, 2010 at 10:47 PM, Farrukh Najmi > <fa...@we... <mailto:fa...@we...>> > wrote: > > > +1 on the proposed resolution of issue 48: > > https://sourceforge.net/apps/trac/gwt-openlayers/ticket/48 > > Kudos to Andrew for the terrific work to implement the proposed > resolution. > Kudos to Edwin and other dev team members for a lot of good work > leading > up to 0.5 release. > > BTW, we should consider getting a free hosted JIRA license for the > project. > It would be so much better than TRAC. Lots of SF projects are > doing that > these days that SF should just get a blanket deal with Atlassian. > > > On 08/24/2010 07:43 AM, Edwin Commandeur wrote: > > Hi all, > > > > Andrew Hughes has been working hard to get things ready for a 0.5 > > release. One open issue is merging Andrew's fantastic work to make > > proper use of Maven onto the default branch. You can check out the > > improvements and see the new project dir layout by cloning the > > 'trac_ticket_48' branch. > > > > PLEASE MAIL IT TO THE DEV LIST WITHIN 2 or 3 DAYS IF YOU WANT TO > GIVE > > FEEDBACK ON THE MERGE!!! If you are not okay with the merge then > > please provide arguments about the how and why. > > > > All in all we think is a huge win, so we hope you'll feel the > same way. > > > > There will be three modules in the new project structure: > > gwt-openlayers (parent) > > gwt-openlayers-client (what is now gwt-ol) > > gwt-openlayers-showcase > > > > After checking out the project you can simply import the modules for > > project into Eclipse as an existing Maven project (requires the > > m2eclipse plugin). The documentation will be updated to describe how > > to debug it all without the Google Eclipse Plugin and how to get the > > showcase to work with the Google Eclipse Plugin (should work > with new > > versions of GEP). > > > > Building the jar: > > > >> cd gwt-openlayers-client > >> mvn package (or mvn install) > >> > > Running the showcase: > > > >> cd gwt-openlayers-showcase > >> mvn gwt:run > >> > > Building the new website > > > >> cd gwt-openlayers > >> mvn site (requires mvn install of gwt-openlayers-client, to > also build JavaDoc and link it in site). > >> > > Eventually the proxy in gwt-openlayers-client will be moved to > > gwt-openlayers-server. This is in line with gwt-maven conventions. > > > > Building the project with Ant is no longer supported, as we want to > > focus on getting everyting right with Maven. Also, the project > website > > will be generated from Maven. > -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com |
|
From: Andrew H. <ahh...@gm...> - 2010-08-24 23:47:39
|
Hi Farrukh, +1 for Jira :) *The maven site (documentation)...* It's early days, but I have deployed the tip/snapshot to sourceforge's htdoc's (using mvn site site:deploy) so please take a look.. http://gwt-openlayers.sourceforge.net/maven-site/ http://gwt-openlayers.sourceforge.net/maven-site/apidocs/index.html (javadocs too) If you have something add/fix/append/remove, please do so... you will find the src under ./src/site of each module. - Site's are configured in ./src/site/site.xml. Including pages, menu's layout e.t.c. - Content can come from a few formats, and so far I've used APT (almost plain text). You can see the pages in ./src/site/apt/some-page.apt I recommend the apt qucik start guide here http://www.scottnesbitt.net/docs/apt_quick_ref.pdf (I'd also recommend xdoc in some cases too, it's your call). Maven has really good doco about sites here: http://maven.apache.org/plugins/maven-site-plugin/ I don't believe the site will or should hold up a 0.5 release, as we can release much more frequently in the future - but it would be nice to see this documentation site evolve quickly. The community needs good documentation :) On Tue, Aug 24, 2010 at 10:47 PM, Farrukh Najmi < fa...@we...> wrote: > > +1 on the proposed resolution of issue 48: > > https://sourceforge.net/apps/trac/gwt-openlayers/ticket/48 > > Kudos to Andrew for the terrific work to implement the proposed resolution. > Kudos to Edwin and other dev team members for a lot of good work leading > up to 0.5 release. > > BTW, we should consider getting a free hosted JIRA license for the project. > It would be so much better than TRAC. Lots of SF projects are doing that > these days that SF should just get a blanket deal with Atlassian. > > > On 08/24/2010 07:43 AM, Edwin Commandeur wrote: > > Hi all, > > > > Andrew Hughes has been working hard to get things ready for a 0.5 > > release. One open issue is merging Andrew's fantastic work to make > > proper use of Maven onto the default branch. You can check out the > > improvements and see the new project dir layout by cloning the > > 'trac_ticket_48' branch. > > > > PLEASE MAIL IT TO THE DEV LIST WITHIN 2 or 3 DAYS IF YOU WANT TO GIVE > > FEEDBACK ON THE MERGE!!! If you are not okay with the merge then > > please provide arguments about the how and why. > > > > All in all we think is a huge win, so we hope you'll feel the same way. > > > > There will be three modules in the new project structure: > > gwt-openlayers (parent) > > gwt-openlayers-client (what is now gwt-ol) > > gwt-openlayers-showcase > > > > After checking out the project you can simply import the modules for > > project into Eclipse as an existing Maven project (requires the > > m2eclipse plugin). The documentation will be updated to describe how > > to debug it all without the Google Eclipse Plugin and how to get the > > showcase to work with the Google Eclipse Plugin (should work with new > > versions of GEP). > > > > Building the jar: > > > >> cd gwt-openlayers-client > >> mvn package (or mvn install) > >> > > Running the showcase: > > > >> cd gwt-openlayers-showcase > >> mvn gwt:run > >> > > Building the new website > > > >> cd gwt-openlayers > >> mvn site (requires mvn install of gwt-openlayers-client, to also build > JavaDoc and link it in site). > >> > > Eventually the proxy in gwt-openlayers-client will be moved to > > gwt-openlayers-server. This is in line with gwt-maven conventions. > > > > Building the project with Ant is no longer supported, as we want to > > focus on getting everyting right with Maven. Also, the project website > > will be generated from Maven. > > > > -- > Regards, > Farrukh Najmi > > Web: http://www.wellfleetsoftware.com > > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > |
8 messages has been excluded from this view by a project administrator.
