Quick response: They would need to re-run an IP check on the geotools 9.0 jars. There is also less jars as geotools now uses java XML rather than xerces.
-- Jody Garnett On 10/04/2013, at 6:14 AM, Frank Gasdorf <fg...@users.sourceforge.net> wrote: > > 2013/4/9 Jody Garnett <jody.garn...@gmail.com> >> Cool, I will confirm that Frank is interested. > > This I admit is true ;) , actually I just created a branch : locationtech_ip > (based on the 1.4.0 release tag) > > We can start working to fix CQ issues and push these changes to this branch. > Whenever we feel comfortable with this changes we can create a tag for this > and provide an other zip file for IP Team. Let's tag these steps with a > prefix like locationtech_ip or something shorter.. > >> >> I will be in position to move on this from Friday onward - does that qualify >> as "quickly"? >> >> We can keep discussion no this email list, and we will have to take your >> guidance on how to communicate with the IP team. Should we advise them on >> this idea of issuing a second "cut down" archive with their initial issues >> resolved? > > 1+ Its kind of flip-flopping between IPZilla and different mailing lists. > Actually I thought about creating tickets in JIRA as tasks. Jody are you in > the position to create an other component in JIRA to organize these tasks? > Otherwise we can use the confluence wiki (e.g. > http://udig.refractions.net/confluence/display/UDIG/Eclipse+Foundation+LocationTech) > >> >> Frank if we are doing this then I want to focus on getting IP issues out of >> the way, not necessarily a functioning system. I think we could upgrade to >> GeoTools 9.0 release (I have a pull request doing the required API >> migration). > > Jody, I thing we should separate IP issues from feature updates. IMHO its > hazardous changing core functionality during infrastructure changes. Nobody > can track these afterwards and its will be a pain to get back a running > system/release although I thing your patch looks good. > > But what about changing geotools dependencies after IP Team reviewed codebase > and accepted the contribution? Do we need an other IP run afterwards? > > - Frank > >> >> (Aside - Wayne I think you can change your signature now that EclipseCon is >> over) >> >> -- >> Jody Garnett >> >> On Tuesday, 9 April 2013 at 2:02 AM, Wayne Beaton wrote: >> >>> If this can be quickly addressed, then I think you should move on it. >>> >>> If the IP team doesn't have to filter through the stuff you don't need, >>> they'll be able to move faster. >>> >>> Wayne >>> >>> On 04/07/2013 01:51 AM, Jody Garnett wrote: >>>> That is a *great* idea Wayne: >>>> >>>> Wayne do you need to check with the IP team to see if they are fine with >>>> this idea? My understanding was we had to submit *something* in order to >>>> start this conversation. >>>> >>>> If the IP team is going to stop dead, or be forced to restart when >>>> provided with a new link, then I would prefer to wait and do this once in >>>> a eclipse repository. >>>> >>>> Assuming the idea can go ahead, and Frank is keen, we can start the branch >>>> and "quickly" address the initial range of concerns that was raised. >>>> >>>> 1. Andrea's GPL file - we can remove the file and that plugin will just be >>>> broken for a bit >>>> 2. The Service tutorial - transition to whatever BIRT uses for parsing CSV >>>> files >>>> 3. JAI+ImageIO native fragments >>>> 4. Remove unused folders (Jesse's original release scripts etc…) >>>> >>>>>> OK, created a pull request for the origin repository to fix this issue: >>>>>> https://github.com/uDig/udig-platform/pull/167 >>>>>> Updated sphinx docs because otherwise the build would fail if the jar is >>>>>> not available. >>>>>> >>>>>> In General : What is the working copy we can collaborate, is the initial >>>>>> contribution already a repository (possible a temporary) at >>>>>> locationtech? If so, how can we access it >>>>> The initial contribution is just a CQ in our system. Jody included a >>>>> pointer to the zipped repository in the CQ since it wouldn't let him >>>>> attach such a large file. There is no repository from an IP team POV, >>>>> just attachments on that CQ. We can obsolete and replace those >>>>> attachments during the review process. Since it's very early in the >>>>> review, now is an excellent time to provide a more concise set of bits >>>>> for the IP team to review. >>>>> >>>>> Perhaps it makes sense for you to create a branch in the existing >>>>> repository to work out what really needs to be in the initial >>>>> contribution. When you've made your final decision, you can zip it up and >>>>> send it along to the IP team. >>>>> >>>>> I do like the idea of using a Git repository for the IP team, but that's >>>>> not how they work today. >>>>>>>> > ./plugins/net.refractions.udig.jai.macosx/src/net/refractions/udig/jai_core.jar >>>>>>>> > ./plugins/net.refractions.udig.jai.macosx/src/net/refractions/udig/jai_codec.jar >>>>>>>> > ./plugins/net.refractions.udig.jai.macosx/src/net/refractions/udig/clibwrapper_jiio.jar >>>>>>>> > ./plugins/net.refractions.udig.jai.macosx/src/net/refractions/udig/jai_imageio.jar >>>>>>>> > ./plugins/net.refractions.udig.jai.macosx/src/net/refractions/udig/mlibwrapper_jai.jar >>>>>>>> >>>>>>>> Third-party CQs needed (and it will be a pain). >>>>>> OK, maybe we can start with work I've already done to make JAI/Image IO >>>>>> available as a bundle with native fragments. Normally JAI/JAI Image IO >>>>>> is provided in the libs/ext folder of the Jave Runtime installation. >>>>>> Because its definitely required to run uDIG we set up a guide how to >>>>>> build a JRE and provide it e.g. with the installer. >>>>> This is going to take more brain power than I have available right now. >>>>> I'll get back to you. >>>> Frank/Wayne - if the native code is too stressful we *can* run just with >>>> jars for a bit - I don't even think moovida would care since he is running >>>> 64 bit these days (Where no native code is available). >>>> >>>> Wayne we have always expected that JAI/ImageIO will be the trouble part of >>>> this process, we did do some sanity checks prior to applying to >>>> LocationTech. >>>> >>>> -- >>>> Jody Garnett >>>> >>>> >>>> _______________________________________________ >>>> User-friendly Desktop Internet GIS (uDig) >>>> http://udig.refractions.net >>>> http://lists.refractions.net/mailman/listinfo/udig-devel >>> >>> -- >>> Wayne Beaton >>> Director of Open Source Projects, The Eclipse Foundation >>> Learn about Eclipse Projects >>> <480x60.png> >>> _______________________________________________ >>> User-friendly Desktop Internet GIS (uDig) >>> http://udig.refractions.net >>> http://lists.refractions.net/mailman/listinfo/udig-devel >> >> >> _______________________________________________ >> User-friendly Desktop Internet GIS (uDig) >> http://udig.refractions.net >> http://lists.refractions.net/mailman/listinfo/udig-devel >> > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
