Well, yee-haw then. :P

On Feb 4, 2010, at 10:36 AM, Jon Schneider wrote:

> 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 <gudnabrsam@(protected)>
> 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
>>> <gudnabrsam@(protected):
>>>
>>> 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 <gudnabrsam@(protected)>
>>>>> 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-unsubscribe@(protected)
>>>>>> For additional commands, e-mail: dev-help@(protected)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@(protected)
>>>> For additional commands, e-mail: dev-help@(protected)
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@(protected)
>> For additional commands, e-mail: dev-help@(protected)
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@(protected)
For additional commands, e-mail: dev-help@(protected)