On 24 Sep 2010, at 12:12, Felix Meschberger wrote:
>>
>>
>> Use that, and fall back to Bundle.getLastModified() is missing?
>
> The correct thing is to use URLConnection.getLastModified(), which
> unfortunately gives you the Bundle.getLastModified() in Felix but may at
> the same time give you
Hi,
Am 24.09.2010 13:06, schrieb Ian Boston:
>
> On 24 Sep 2010, at 11:57, Felix Meschberger wrote:
>
>> Hi,
>>
>> Am 24.09.2010 12:39, schrieb Ian Boston:
>>>
>>> On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote:
>>>
Ian Boston wrote
>
> On 24 Sep 2010, at 11:06, Carsten Ziegeler
On 24 Sep 2010, at 11:57, Felix Meschberger wrote:
> Hi,
>
> Am 24.09.2010 12:39, schrieb Ian Boston:
>>
>> On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote:
>>
>>> Ian Boston wrote
On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote:
> So if you
> want to update this co
Hi,
Am 24.09.2010 12:39, schrieb Ian Boston:
>
> On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote:
>
>> Ian Boston wrote
>>>
>>> On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote:
>>>
So if you
want to update this content, you should update the corresponding bundle.
>>>
>>> Thats the b
On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote:
> Ian Boston wrote
>>
>> On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote:
>>
>>> So if you
>>> want to update this content, you should update the corresponding bundle.
>>
>> Thats the bit thats not really working (unless I say overwrite:=true
On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote:
> Ian Boston wrote
>>
>> On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote:
>>
>>> So if you
>>> want to update this content, you should update the corresponding bundle.
>>
>> Thats the bit thats not really working (unless I say overwrite:=true
Ian Boston wrote
>
> On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote:
>
>> So if you
>> want to update this content, you should update the corresponding bundle.
>
> Thats the bit thats not really working (unless I say overwrite:=true)
Yes, right - that's why you should have overwrite:=true :)
On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote:
> So if you
> want to update this content, you should update the corresponding bundle.
Thats the bit thats not really working (unless I say overwrite:=true)
as Felix said, perhaps the default should be the content gets updated if the
bundle get
Ian Boston wrote
> Ok,
> So you cant split content between bundles
> or
> Have a bundle update content.
>
>
> I think what I really want is something update:=true which looks at the
> lastModified on every file and only updates it if the bundled file is later.
> The overwrite functionality p
On 24 Sep 2010, at 10:54, Felix Meschberger wrote:
>
> Do we need such a flag ? Shouldn't this be default ?
>
> Not really sure and not having thought of all the
> backwards-compatibility consequences.
Well that would make sense, at the moment an updated bundle doesn't result in
updated conte
Hi,
Am 24.09.2010 11:50, schrieb Ian Boston:
>
> On 24 Sep 2010, at 10:47, Carsten Ziegeler wrote:
>
>> Ian Boston wrote
>>
>>> contentFolder1/contentInFolder2.txt is missing, indicating that subfolders
>>> are deleted when uninstall=false even if the content of the sub folder came
>>> from a
On 24 Sep 2010, at 10:47, Carsten Ziegeler wrote:
> Ian Boston wrote
>
>> contentFolder1/contentInFolder2.txt is missing, indicating that subfolders
>> are deleted when uninstall=false even if the content of the sub folder came
>> from another bundle.
>>
>> Bug or expected behaviour ?
> I th
Ian Boston wrote
> contentFolder1/contentInFolder2.txt is missing, indicating that subfolders
> are deleted when uninstall=false even if the content of the sub folder came
> from another bundle.
>
> Bug or expected behaviour ?
I think this is expected behaviour as you have "overwrite=true" - s
Hi,
install/update the bundles like this:
install test1
install test2
update test1
Right ?
In this case, due to overwrite:=true, when updating test1, the subtree
/content/contentFolder1 is replaced by what is provided by test1. Thus
/content/contentFolder1/contentInFolder2.txt is in fa
On 24 Sep 2010, at 10:35, Ian Boston wrote:
>
> On 24 Sep 2010, at 10:15, Ian Boston wrote:
>>
>> Bug or expected behaviour ?
>
>
> The registered bundle content contains no uninstall-paths so IIUC, nothing
> should have been uninstalled and yet the folders go awal
>
> x43543-2:contenttest
On 24 Sep 2010, at 10:15, Ian Boston wrote:
>
> Bug or expected behaviour ?
The registered bundle content contains no uninstall-paths so IIUC, nothing
should have been uninstalled and yet the folders go awal
x43543-2:contenttest ieb$ curl
http://localhost:8080/var/sling/bundle-content.tidy.3
16 matches
Mail list logo
