Please do. I think it would be advantageous to build the final IvyDE 2.1.0 with this fix as well.
Jon On Thu, Feb 4, 2010 at 10:24 AM, Matt Benson <gudnabr...@gmail.com> wrote: > Okay, all the silly questions notwithstanding, I was actually able to > muddle through this. ;) As it turns out, the Pulse-managed Eclipse > installations I've been using, even after adding Eclipse plugin development > plugins, are apparently not suitable as baseLocations for the updatesite's > buildfile. After downloading a plugin-development-target Eclipse > installation and using that I was able to to create the optimized artifacts, > and was able to use a filesystem-based updatesite from there to verify that > the Pulse tool is now able to recognize the packed features jars. So does > anyone oppose my committing my changes on trunk so that the Hudson builds > will also pack these jars? > > Thanks, > Matt > > > > On Feb 3, 2010, at 3:15 PM, Jon Schneider wrote: > > Matt, >> >> Just dump the contents of the dist directory into a folder (e.g. >> updatesite) >> in any http server of your choice. That's it. >> >> Jon >> >> On Wed, Feb 3, 2010 at 3:07 PM, Matt Benson <gudnabr...@gmail.com> wrote: >> >> Hi, Jon. I realize from the text below that the problem here is a bug >>> with >>> this other tool, and believe me, I have reported it. But rank hath its >>> privileges, and being in a position to affect the IvyDE updatesite Hudson >>> build I am inclined to selfishly do so. If it is that big a deal I could >>> use a locally staged updatesite to begin with, but this still brings to a >>> head the problem I have which actually prompted my original mail: I am >>> not >>> clear on how to set up my own local updatesite. ;) >>> >>> Thanks, >>> Matt >>> >>> >>> On Feb 3, 2010, at 2:58 PM, Jon Schneider wrote: >>> >>> From the Eclipse documentation concerning the pack200="true" attribute >>> we >>> >>>> have on our updatesite: >>>> >>>> "This lets the Update Manager know that the site contains packed jars, >>>> and >>>> it will look for a .jar.pack.gz file beside the .jar file that it would >>>> normally download. If the .jar.pack.gz file is found, it will be >>>> downloaded >>>> and unpacked, otherwise the .jar file is downloaded as normal." >>>> >>>> This indicates to me that a reasonable local test would be to delete all >>>> but >>>> the packed jars from a locally staged update site and verify that the >>>> Update >>>> Manager will pick up the feature jar correctly. >>>> >>>> Jon >>>> >>>> On Wed, Feb 3, 2010 at 2:25 PM, Matt Benson <gudnabr...@gmail.com> >>>> wrote: >>>> >>>> My original email seems to have been lost; please see below: >>>> >>>>> >>>>> >>>>> On Feb 3, 2010, at 1:16 PM, Matt Benson wrote: >>>>> >>>>> For fun I'll include the text of my patch file between --- and --- : >>>>> >>>>> >>>>>> >>>>>> [SNIP] >>>>> >>>>> >>>>> --- >>>>> >>>>> On Feb 3, 2010, at 12:55 PM, Matt Benson wrote: >>>>>> >>>>>> Apparently some tools (in particular I'm back to dealing with >>>>>> Genuitec >>>>>> >>>>>> Pulse) want not only plugins but features jars to be packed. I can >>>>>>> pretty >>>>>>> well see how to add this to the updatesite build, but I don't have a >>>>>>> whole >>>>>>> lot of idea what is required for me to test my changes locally. Can >>>>>>> either >>>>>>> of you guys, Nicolas/Jon, help me with that? I'm hoping to do it all >>>>>>> on Mac >>>>>>> OSX Tiger w/ Java 1.5.... >>>>>>> >>>>>>> Thanks, >>>>>>> Matt >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>>> For additional commands, e-mail: dev-h...@ant.apache.org >>>>> >>>>> >>>>> >>>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>> For additional commands, e-mail: dev-h...@ant.apache.org >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
