[PROPOSAL] New extensions package

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] New extensions package

Thomas Mortagne
Administrator
Hi devs,

I'm currently working on a new package format to package a bunch of
extensions into a single file.

The first use case is to make offline install easier. We can't count on all
in one XAR anymore (plus all in one XAR prduces very crappy extensions) so
I was thinking about providing a generic package containing all the
extensions you need in it. It will simply be a zip containing extensions in
the same format than Extension Manager local repository so that you can
unzip it it there (or later use some UI to "import" it).

So now I need a name for this new package. Since extension descriptor file
extension is "xed" (for "XWiki Extension Descriptor") I was thinking about
naming it XEP (for "XWiki Extension Package"). Any better idea ?

For now my plan is to provide the following:
* a new Maven handler for <packaging>xep</packaging>
* a new Maven mojo "xep" in the existing extension Maven plugin
* start using it with the new platform flavor which is supposed to replace
XE so that people can have something to use for offline installs

WDYT ?

--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New extensions package

vmassol
Administrator
Hi,

> On 2 May 2017, at 16:05, Thomas Mortagne <[hidden email]> wrote:
>
> Hi devs,
>
> I'm currently working on a new package format to package a bunch of
> extensions into a single file.
>
> The first use case is to make offline install easier. We can't count on all
> in one XAR anymore (plus all in one XAR prduces very crappy extensions) so
> I was thinking about providing a generic package containing all the
> extensions you need in it. It will simply be a zip containing extensions in
> the same format than Extension Manager local repository so that you can
> unzip it it there (or later use some UI to "import" it).
>
> So now I need a name for this new package. Since extension descriptor file
> extension is "xed" (for "XWiki Extension Descriptor") I was thinking about
> naming it XEP (for "XWiki Extension Package"). Any better idea ?
>
> For now my plan is to provide the following:
> * a new Maven handler for <packaging>xep</packaging>
> * a new Maven mojo "xep" in the existing extension Maven plugin
> * start using it with the new platform flavor which is supposed to replace
> XE so that people can have something to use for offline installs
>
> WDYT ?

Sounds good.

Regarding the naming, assuming we need a file extension other than ZIP, "XWiki Extension Package” seems like a package for a single XWiki Extension.

Some ideas. Why not something in the name that suggest it’s a repository.

For example: XWiki Extension Repository Archive or XWiki Repository Archive for short, which, using a 3LA, would translate into XRA.

XAR = XWiki Archive = a single extension
XRA = XWiki Repository Archive = a repository of extensions = several extensions

We could also have XWiki Extension Repository, i.e. “XER”, which would also be one letter change from XAR:

XAR = XWiki Archive = a single extension
XER = XWiki Extension Repository = a repository of extensions = several extensions

Now since the users will need to unzip this binary and they won’t import it (as they do for XAR), it would be better for it to be ZIP as otherwise it’ll harder to unzip (no double-clicking on it for ex).

Thanks
-Vincent

>
> --
> Thomas Mortagne

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New extensions package

Thomas Mortagne
Administrator
On Tue, May 2, 2017 at 4:28 PM, Vincent Massol <[hidden email]> wrote:

> Hi,
>
> > On 2 May 2017, at 16:05, Thomas Mortagne <[hidden email]>
> wrote:
> >
> > Hi devs,
> >
> > I'm currently working on a new package format to package a bunch of
> > extensions into a single file.
> >
> > The first use case is to make offline install easier. We can't count on
> all
> > in one XAR anymore (plus all in one XAR prduces very crappy extensions)
> so
> > I was thinking about providing a generic package containing all the
> > extensions you need in it. It will simply be a zip containing extensions
> in
> > the same format than Extension Manager local repository so that you can
> > unzip it it there (or later use some UI to "import" it).
> >
> > So now I need a name for this new package. Since extension descriptor
> file
> > extension is "xed" (for "XWiki Extension Descriptor") I was thinking
> about
> > naming it XEP (for "XWiki Extension Package"). Any better idea ?
> >
> > For now my plan is to provide the following:
> > * a new Maven handler for <packaging>xep</packaging>
> > * a new Maven mojo "xep" in the existing extension Maven plugin
> > * start using it with the new platform flavor which is supposed to
> replace
> > XE so that people can have something to use for offline installs
> >
> > WDYT ?
>
> Sounds good.
>
> Regarding the naming, assuming we need a file extension other than ZIP,
> "XWiki Extension Package” seems like a package for a single XWiki Extension.
>
> Some ideas. Why not something in the name that suggest it’s a repository.
>
> For example: XWiki Extension Repository Archive or XWiki Repository
> Archive for short, which, using a 3LA, would translate into XRA.
>
> XAR = XWiki Archive = a single extension
> XRA = XWiki Repository Archive = a repository of extensions = several
> extensions
>
> We could also have XWiki Extension Repository, i.e. “XER”, which would
> also be one letter change from XAR:
>
> XAR = XWiki Archive = a single extension
> XER = XWiki Extension Repository = a repository of extensions = several
> extensions
>

I'm fine with XER.


> Now since the users will need to unzip this binary and they won’t import
> it (as they do for XAR), it would be better for it to be ZIP as otherwise
> it’ll harder to unzip (no double-clicking on it for ex).
>

As I said I think we'll have a UI for it at some point. I just don't think
I will have time to work on that in the new platform flavor scope (or maybe
just a quick tool in
http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak).


> Thanks
> -Vincent
>
> >
> > --
> > Thomas Mortagne
>
>


--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New extensions package

vmassol
Administrator

> On 2 May 2017, at 16:36, Thomas Mortagne <[hidden email]> wrote:
>
> On Tue, May 2, 2017 at 4:28 PM, Vincent Massol <[hidden email]> wrote:
>
>> Hi,
>>
>>> On 2 May 2017, at 16:05, Thomas Mortagne <[hidden email]>
>> wrote:
>>>
>>> Hi devs,
>>>
>>> I'm currently working on a new package format to package a bunch of
>>> extensions into a single file.
>>>
>>> The first use case is to make offline install easier. We can't count on
>> all
>>> in one XAR anymore (plus all in one XAR prduces very crappy extensions)
>> so
>>> I was thinking about providing a generic package containing all the
>>> extensions you need in it. It will simply be a zip containing extensions
>> in
>>> the same format than Extension Manager local repository so that you can
>>> unzip it it there (or later use some UI to "import" it).
>>>
>>> So now I need a name for this new package. Since extension descriptor
>> file
>>> extension is "xed" (for "XWiki Extension Descriptor") I was thinking
>> about
>>> naming it XEP (for "XWiki Extension Package"). Any better idea ?
>>>
>>> For now my plan is to provide the following:
>>> * a new Maven handler for <packaging>xep</packaging>
>>> * a new Maven mojo "xep" in the existing extension Maven plugin
>>> * start using it with the new platform flavor which is supposed to
>> replace
>>> XE so that people can have something to use for offline installs
>>>
>>> WDYT ?
>>
>> Sounds good.
>>
>> Regarding the naming, assuming we need a file extension other than ZIP,
>> "XWiki Extension Package” seems like a package for a single XWiki Extension.
>>
>> Some ideas. Why not something in the name that suggest it’s a repository.
>>
>> For example: XWiki Extension Repository Archive or XWiki Repository
>> Archive for short, which, using a 3LA, would translate into XRA.
>>
>> XAR = XWiki Archive = a single extension
>> XRA = XWiki Repository Archive = a repository of extensions = several
>> extensions
>>
>> We could also have XWiki Extension Repository, i.e. “XER”, which would
>> also be one letter change from XAR:
>>
>> XAR = XWiki Archive = a single extension
>> XER = XWiki Extension Repository = a repository of extensions = several
>> extensions
>>
>
> I'm fine with XER.
>
>
>> Now since the users will need to unzip this binary and they won’t import
>> it (as they do for XAR), it would be better for it to be ZIP as otherwise
>> it’ll harder to unzip (no double-clicking on it for ex).
>>
>
> As I said I think we'll have a UI for it at some point. I just don't think
> I will have time to work on that in the new platform flavor scope (or maybe
> just a quick tool in
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak).

I know you said that but IMO the primary usage is for users to unzip into a given directory and the easiest is to provide a ZIP to them. Even if we have an import UI, we can still offer the ZIP to that UI…

So at this point, I don’t fully understand why we’d need something other than zip.

Sounds like we might be overcomplicated things. On the maven side, we could use the maven assembly plugin to generate the zip.

Am I missing something?

Thanks
-Vincent

> Thanks
>> -Vincent
>>
>>>
>>> --
>>> Thomas Mortagne
>>
>>
>
>
> --
> Thomas Mortagne

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New extensions package

Thomas Mortagne
Administrator
On Tue, May 2, 2017 at 4:43 PM, Vincent Massol <[hidden email]> wrote:

>
> > On 2 May 2017, at 16:36, Thomas Mortagne <[hidden email]>
> wrote:
> >
> > On Tue, May 2, 2017 at 4:28 PM, Vincent Massol <[hidden email]>
> wrote:
> >
> >> Hi,
> >>
> >>> On 2 May 2017, at 16:05, Thomas Mortagne <[hidden email]>
> >> wrote:
> >>>
> >>> Hi devs,
> >>>
> >>> I'm currently working on a new package format to package a bunch of
> >>> extensions into a single file.
> >>>
> >>> The first use case is to make offline install easier. We can't count on
> >> all
> >>> in one XAR anymore (plus all in one XAR prduces very crappy extensions)
> >> so
> >>> I was thinking about providing a generic package containing all the
> >>> extensions you need in it. It will simply be a zip containing
> extensions
> >> in
> >>> the same format than Extension Manager local repository so that you can
> >>> unzip it it there (or later use some UI to "import" it).
> >>>
> >>> So now I need a name for this new package. Since extension descriptor
> >> file
> >>> extension is "xed" (for "XWiki Extension Descriptor") I was thinking
> >> about
> >>> naming it XEP (for "XWiki Extension Package"). Any better idea ?
> >>>
> >>> For now my plan is to provide the following:
> >>> * a new Maven handler for <packaging>xep</packaging>
> >>> * a new Maven mojo "xep" in the existing extension Maven plugin
> >>> * start using it with the new platform flavor which is supposed to
> >> replace
> >>> XE so that people can have something to use for offline installs
> >>>
> >>> WDYT ?
> >>
> >> Sounds good.
> >>
> >> Regarding the naming, assuming we need a file extension other than ZIP,
> >> "XWiki Extension Package” seems like a package for a single XWiki
> Extension.
> >>
> >> Some ideas. Why not something in the name that suggest it’s a
> repository.
> >>
> >> For example: XWiki Extension Repository Archive or XWiki Repository
> >> Archive for short, which, using a 3LA, would translate into XRA.
> >>
> >> XAR = XWiki Archive = a single extension
> >> XRA = XWiki Repository Archive = a repository of extensions = several
> >> extensions
> >>
> >> We could also have XWiki Extension Repository, i.e. “XER”, which would
> >> also be one letter change from XAR:
> >>
> >> XAR = XWiki Archive = a single extension
> >> XER = XWiki Extension Repository = a repository of extensions = several
> >> extensions
> >>
> >
> > I'm fine with XER.
> >
> >
> >> Now since the users will need to unzip this binary and they won’t import
> >> it (as they do for XAR), it would be better for it to be ZIP as
> otherwise
> >> it’ll harder to unzip (no double-clicking on it for ex).
> >>
> >
> > As I said I think we'll have a UI for it at some point. I just don't
> think
> > I will have time to work on that in the new platform flavor scope (or
> maybe
> > just a quick tool in
> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak).
>
> I know you said that but IMO the primary usage is for users to unzip into
> a given directory and the easiest is to provide a ZIP to them. Even if we
> have an import UI, we can still offer the ZIP to that UI…
>
> So at this point, I don’t fully understand why we’d need something other
> than zip.
>
> Sounds like we might be overcomplicated things. On the maven side, we
> could use the maven assembly plugin to generate the zip.
>
> Am I missing something?
>

Just using assembly plugin is not enough because you also need get the
dependencies, put them in the right sub-folders, generate the extensions
descriptors and exclude dependencies that are already part of the WAR (in
flavor package use case) so you need a special mojo to take care of all
that. also it's still a specific package with a specific format that happen
to be based on zip, I find it more clear to give it a specific file
extension (it "certify" that you won't get surprise when unzipping it).

Double clicking on the file is really not a major use case for me since
this is going to be used mostly on servers. When you do "unzip myfile" the
file extension does not really matter much.


> Thanks
> -Vincent
>
> > Thanks
> >> -Vincent
> >>
> >>>
> >>> --
> >>> Thomas Mortagne
> >>
> >>
> >
> >
> > --
> > Thomas Mortagne
>
>


--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New extensions package

Ecaterina Moraru (Valica)
XIP = XWiki Importable Package :)
sounds like ZIP, so I think is funny :)

Thanks,
Caty

On Tue, May 2, 2017 at 6:02 PM, Thomas Mortagne <[hidden email]>
wrote:

> On Tue, May 2, 2017 at 4:43 PM, Vincent Massol <[hidden email]> wrote:
>
> >
> > > On 2 May 2017, at 16:36, Thomas Mortagne <[hidden email]>
> > wrote:
> > >
> > > On Tue, May 2, 2017 at 4:28 PM, Vincent Massol <[hidden email]>
> > wrote:
> > >
> > >> Hi,
> > >>
> > >>> On 2 May 2017, at 16:05, Thomas Mortagne <[hidden email]>
> > >> wrote:
> > >>>
> > >>> Hi devs,
> > >>>
> > >>> I'm currently working on a new package format to package a bunch of
> > >>> extensions into a single file.
> > >>>
> > >>> The first use case is to make offline install easier. We can't count
> on
> > >> all
> > >>> in one XAR anymore (plus all in one XAR prduces very crappy
> extensions)
> > >> so
> > >>> I was thinking about providing a generic package containing all the
> > >>> extensions you need in it. It will simply be a zip containing
> > extensions
> > >> in
> > >>> the same format than Extension Manager local repository so that you
> can
> > >>> unzip it it there (or later use some UI to "import" it).
> > >>>
> > >>> So now I need a name for this new package. Since extension descriptor
> > >> file
> > >>> extension is "xed" (for "XWiki Extension Descriptor") I was thinking
> > >> about
> > >>> naming it XEP (for "XWiki Extension Package"). Any better idea ?
> > >>>
> > >>> For now my plan is to provide the following:
> > >>> * a new Maven handler for <packaging>xep</packaging>
> > >>> * a new Maven mojo "xep" in the existing extension Maven plugin
> > >>> * start using it with the new platform flavor which is supposed to
> > >> replace
> > >>> XE so that people can have something to use for offline installs
> > >>>
> > >>> WDYT ?
> > >>
> > >> Sounds good.
> > >>
> > >> Regarding the naming, assuming we need a file extension other than
> ZIP,
> > >> "XWiki Extension Package” seems like a package for a single XWiki
> > Extension.
> > >>
> > >> Some ideas. Why not something in the name that suggest it’s a
> > repository.
> > >>
> > >> For example: XWiki Extension Repository Archive or XWiki Repository
> > >> Archive for short, which, using a 3LA, would translate into XRA.
> > >>
> > >> XAR = XWiki Archive = a single extension
> > >> XRA = XWiki Repository Archive = a repository of extensions = several
> > >> extensions
> > >>
> > >> We could also have XWiki Extension Repository, i.e. “XER”, which would
> > >> also be one letter change from XAR:
> > >>
> > >> XAR = XWiki Archive = a single extension
> > >> XER = XWiki Extension Repository = a repository of extensions =
> several
> > >> extensions
> > >>
> > >
> > > I'm fine with XER.
> > >
> > >
> > >> Now since the users will need to unzip this binary and they won’t
> import
> > >> it (as they do for XAR), it would be better for it to be ZIP as
> > otherwise
> > >> it’ll harder to unzip (no double-clicking on it for ex).
> > >>
> > >
> > > As I said I think we'll have a UI for it at some point. I just don't
> > think
> > > I will have time to work on that in the new platform flavor scope (or
> > maybe
> > > just a quick tool in
> > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak).
> >
> > I know you said that but IMO the primary usage is for users to unzip into
> > a given directory and the easiest is to provide a ZIP to them. Even if we
> > have an import UI, we can still offer the ZIP to that UI…
> >
> > So at this point, I don’t fully understand why we’d need something other
> > than zip.
> >
> > Sounds like we might be overcomplicated things. On the maven side, we
> > could use the maven assembly plugin to generate the zip.
> >
> > Am I missing something?
> >
>
> Just using assembly plugin is not enough because you also need get the
> dependencies, put them in the right sub-folders, generate the extensions
> descriptors and exclude dependencies that are already part of the WAR (in
> flavor package use case) so you need a special mojo to take care of all
> that. also it's still a specific package with a specific format that happen
> to be based on zip, I find it more clear to give it a specific file
> extension (it "certify" that you won't get surprise when unzipping it).
>
> Double clicking on the file is really not a major use case for me since
> this is going to be used mostly on servers. When you do "unzip myfile" the
> file extension does not really matter much.
>
>
> > Thanks
> > -Vincent
> >
> > > Thanks
> > >> -Vincent
> > >>
> > >>>
> > >>> --
> > >>> Thomas Mortagne
> > >>
> > >>
> > >
> > >
> > > --
> > > Thomas Mortagne
> >
> >
>
>
> --
> Thomas Mortagne
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New extensions package

Krzysiek Płachno
+1 for XIP
:)

Best,
Krzysiek

2017-05-02 17:32 GMT+02:00 Ecaterina Moraru (Valica) <[hidden email]>:

> XIP = XWiki Importable Package :)
> sounds like ZIP, so I think is funny :)
>
> Thanks,
> Caty
>
> On Tue, May 2, 2017 at 6:02 PM, Thomas Mortagne <[hidden email]
> >
> wrote:
>
> > On Tue, May 2, 2017 at 4:43 PM, Vincent Massol <[hidden email]>
> wrote:
> >
> > >
> > > > On 2 May 2017, at 16:36, Thomas Mortagne <[hidden email]>
> > > wrote:
> > > >
> > > > On Tue, May 2, 2017 at 4:28 PM, Vincent Massol <[hidden email]>
> > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >>> On 2 May 2017, at 16:05, Thomas Mortagne <
> [hidden email]>
> > > >> wrote:
> > > >>>
> > > >>> Hi devs,
> > > >>>
> > > >>> I'm currently working on a new package format to package a bunch of
> > > >>> extensions into a single file.
> > > >>>
> > > >>> The first use case is to make offline install easier. We can't
> count
> > on
> > > >> all
> > > >>> in one XAR anymore (plus all in one XAR prduces very crappy
> > extensions)
> > > >> so
> > > >>> I was thinking about providing a generic package containing all the
> > > >>> extensions you need in it. It will simply be a zip containing
> > > extensions
> > > >> in
> > > >>> the same format than Extension Manager local repository so that you
> > can
> > > >>> unzip it it there (or later use some UI to "import" it).
> > > >>>
> > > >>> So now I need a name for this new package. Since extension
> descriptor
> > > >> file
> > > >>> extension is "xed" (for "XWiki Extension Descriptor") I was
> thinking
> > > >> about
> > > >>> naming it XEP (for "XWiki Extension Package"). Any better idea ?
> > > >>>
> > > >>> For now my plan is to provide the following:
> > > >>> * a new Maven handler for <packaging>xep</packaging>
> > > >>> * a new Maven mojo "xep" in the existing extension Maven plugin
> > > >>> * start using it with the new platform flavor which is supposed to
> > > >> replace
> > > >>> XE so that people can have something to use for offline installs
> > > >>>
> > > >>> WDYT ?
> > > >>
> > > >> Sounds good.
> > > >>
> > > >> Regarding the naming, assuming we need a file extension other than
> > ZIP,
> > > >> "XWiki Extension Package” seems like a package for a single XWiki
> > > Extension.
> > > >>
> > > >> Some ideas. Why not something in the name that suggest it’s a
> > > repository.
> > > >>
> > > >> For example: XWiki Extension Repository Archive or XWiki Repository
> > > >> Archive for short, which, using a 3LA, would translate into XRA.
> > > >>
> > > >> XAR = XWiki Archive = a single extension
> > > >> XRA = XWiki Repository Archive = a repository of extensions =
> several
> > > >> extensions
> > > >>
> > > >> We could also have XWiki Extension Repository, i.e. “XER”, which
> would
> > > >> also be one letter change from XAR:
> > > >>
> > > >> XAR = XWiki Archive = a single extension
> > > >> XER = XWiki Extension Repository = a repository of extensions =
> > several
> > > >> extensions
> > > >>
> > > >
> > > > I'm fine with XER.
> > > >
> > > >
> > > >> Now since the users will need to unzip this binary and they won’t
> > import
> > > >> it (as they do for XAR), it would be better for it to be ZIP as
> > > otherwise
> > > >> it’ll harder to unzip (no double-clicking on it for ex).
> > > >>
> > > >
> > > > As I said I think we'll have a UI for it at some point. I just don't
> > > think
> > > > I will have time to work on that in the new platform flavor scope (or
> > > maybe
> > > > just a quick tool in
> > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak
> ).
> > >
> > > I know you said that but IMO the primary usage is for users to unzip
> into
> > > a given directory and the easiest is to provide a ZIP to them. Even if
> we
> > > have an import UI, we can still offer the ZIP to that UI…
> > >
> > > So at this point, I don’t fully understand why we’d need something
> other
> > > than zip.
> > >
> > > Sounds like we might be overcomplicated things. On the maven side, we
> > > could use the maven assembly plugin to generate the zip.
> > >
> > > Am I missing something?
> > >
> >
> > Just using assembly plugin is not enough because you also need get the
> > dependencies, put them in the right sub-folders, generate the extensions
> > descriptors and exclude dependencies that are already part of the WAR (in
> > flavor package use case) so you need a special mojo to take care of all
> > that. also it's still a specific package with a specific format that
> happen
> > to be based on zip, I find it more clear to give it a specific file
> > extension (it "certify" that you won't get surprise when unzipping it).
> >
> > Double clicking on the file is really not a major use case for me since
> > this is going to be used mostly on servers. When you do "unzip myfile"
> the
> > file extension does not really matter much.
> >
> >
> > > Thanks
> > > -Vincent
> > >
> > > > Thanks
> > > >> -Vincent
> > > >>
> > > >>>
> > > >>> --
> > > >>> Thomas Mortagne
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Thomas Mortagne
> > >
> > >
> >
> >
> > --
> > Thomas Mortagne
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New extensions package

Sergiu Dumitriu-3
In reply to this post by vmassol
Users are very bad at reading or following instructions. It's likely
that they will download the file, double click it, and expect it to be
installed automatically.

If the extension is .zip, then the OS will silently unpack it, and the
user won't know what to do next. But since at least something happened,
they might actually think that the file installed itself, then wonder
why it still doesn't work.

If the extension is something special, then the OS won't know what to do
with it, and present a dialog warning that the file can't be opened, and
the user is more likely to search for information about how that file
can be installed.

The downside of it not being a .zip file is that when the user should
unzip it, it's a bit more difficult to do it.

+1 for .xip, it seems that nobody else is using it.

https://fileinfo.com/extension/xip

On 05/02/2017 10:43 AM, Vincent Massol wrote:

>
>> On 2 May 2017, at 16:36, Thomas Mortagne <[hidden email]> wrote:
>>
>> On Tue, May 2, 2017 at 4:28 PM, Vincent Massol <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>>> On 2 May 2017, at 16:05, Thomas Mortagne <[hidden email]>
>>> wrote:
>>>>
>>>> Hi devs,
>>>>
>>>> I'm currently working on a new package format to package a bunch of
>>>> extensions into a single file.
>>>>
>>>> The first use case is to make offline install easier. We can't count on
>>> all
>>>> in one XAR anymore (plus all in one XAR prduces very crappy extensions)
>>> so
>>>> I was thinking about providing a generic package containing all the
>>>> extensions you need in it. It will simply be a zip containing extensions
>>> in
>>>> the same format than Extension Manager local repository so that you can
>>>> unzip it it there (or later use some UI to "import" it).
>>>>
>>>> So now I need a name for this new package. Since extension descriptor
>>> file
>>>> extension is "xed" (for "XWiki Extension Descriptor") I was thinking
>>> about
>>>> naming it XEP (for "XWiki Extension Package"). Any better idea ?
>>>>
>>>> For now my plan is to provide the following:
>>>> * a new Maven handler for <packaging>xep</packaging>
>>>> * a new Maven mojo "xep" in the existing extension Maven plugin
>>>> * start using it with the new platform flavor which is supposed to
>>> replace
>>>> XE so that people can have something to use for offline installs
>>>>
>>>> WDYT ?
>>>
>>> Sounds good.
>>>
>>> Regarding the naming, assuming we need a file extension other than ZIP,
>>> "XWiki Extension Package” seems like a package for a single XWiki Extension.
>>>
>>> Some ideas. Why not something in the name that suggest it’s a repository.
>>>
>>> For example: XWiki Extension Repository Archive or XWiki Repository
>>> Archive for short, which, using a 3LA, would translate into XRA.
>>>
>>> XAR = XWiki Archive = a single extension
>>> XRA = XWiki Repository Archive = a repository of extensions = several
>>> extensions
>>>
>>> We could also have XWiki Extension Repository, i.e. “XER”, which would
>>> also be one letter change from XAR:
>>>
>>> XAR = XWiki Archive = a single extension
>>> XER = XWiki Extension Repository = a repository of extensions = several
>>> extensions
>>>
>>
>> I'm fine with XER.
>>
>>
>>> Now since the users will need to unzip this binary and they won’t import
>>> it (as they do for XAR), it would be better for it to be ZIP as otherwise
>>> it’ll harder to unzip (no double-clicking on it for ex).
>>>
>>
>> As I said I think we'll have a UI for it at some point. I just don't think
>> I will have time to work on that in the new platform flavor scope (or maybe
>> just a quick tool in
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak).
>
> I know you said that but IMO the primary usage is for users to unzip into a given directory and the easiest is to provide a ZIP to them. Even if we have an import UI, we can still offer the ZIP to that UI…
>
> So at this point, I don’t fully understand why we’d need something other than zip.
>
> Sounds like we might be overcomplicated things. On the maven side, we could use the maven assembly plugin to generate the zip.
>
> Am I missing something?
>
> Thanks
> -Vincent
>
>> Thanks
>>> -Vincent
>>>
>>>>
>>>> --
>>>> Thomas Mortagne
>>>
>>>
>>
>>
>> --
>> Thomas Mortagne
>


--
Sergiu Dumitriu
http://purl.org/net/sergiu
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New extensions package

Thomas Mortagne
Administrator
On Thu, May 4, 2017 at 6:47 PM, Sergiu Dumitriu <[hidden email]> wrote:

> Users are very bad at reading or following instructions. It's likely
> that they will download the file, double click it, and expect it to be
> installed automatically.
>
> If the extension is .zip, then the OS will silently unpack it, and the
> user won't know what to do next. But since at least something happened,
> they might actually think that the file installed itself, then wonder
> why it still doesn't work.
>
> If the extension is something special, then the OS won't know what to do
> with it, and present a dialog warning that the file can't be opened, and
> the user is more likely to search for information about how that file
> can be installed.
>
> The downside of it not being a .zip file is that when the user should
> unzip it, it's a bit more difficult to do it.
>
>

> +1 for .xip, it seems that nobody else is using it.
>

Indeed I was not sure where to look for this. I checked quickly on
https://en.wikipedia.org/wiki/List_of_filename_extensions_(S%E2%80%93Z)#X
but it did not felt like the right reference :)

So +1 for xip too.


>
> https://fileinfo.com/extension/xip
>
> On 05/02/2017 10:43 AM, Vincent Massol wrote:
> >
> >> On 2 May 2017, at 16:36, Thomas Mortagne <[hidden email]>
> wrote:
> >>
> >> On Tue, May 2, 2017 at 4:28 PM, Vincent Massol <[hidden email]>
> wrote:
> >>
> >>> Hi,
> >>>
> >>>> On 2 May 2017, at 16:05, Thomas Mortagne <[hidden email]>
> >>> wrote:
> >>>>
> >>>> Hi devs,
> >>>>
> >>>> I'm currently working on a new package format to package a bunch of
> >>>> extensions into a single file.
> >>>>
> >>>> The first use case is to make offline install easier. We can't count
> on
> >>> all
> >>>> in one XAR anymore (plus all in one XAR prduces very crappy
> extensions)
> >>> so
> >>>> I was thinking about providing a generic package containing all the
> >>>> extensions you need in it. It will simply be a zip containing
> extensions
> >>> in
> >>>> the same format than Extension Manager local repository so that you
> can
> >>>> unzip it it there (or later use some UI to "import" it).
> >>>>
> >>>> So now I need a name for this new package. Since extension descriptor
> >>> file
> >>>> extension is "xed" (for "XWiki Extension Descriptor") I was thinking
> >>> about
> >>>> naming it XEP (for "XWiki Extension Package"). Any better idea ?
> >>>>
> >>>> For now my plan is to provide the following:
> >>>> * a new Maven handler for <packaging>xep</packaging>
> >>>> * a new Maven mojo "xep" in the existing extension Maven plugin
> >>>> * start using it with the new platform flavor which is supposed to
> >>> replace
> >>>> XE so that people can have something to use for offline installs
> >>>>
> >>>> WDYT ?
> >>>
> >>> Sounds good.
> >>>
> >>> Regarding the naming, assuming we need a file extension other than ZIP,
> >>> "XWiki Extension Package” seems like a package for a single XWiki
> Extension.
> >>>
> >>> Some ideas. Why not something in the name that suggest it’s a
> repository.
> >>>
> >>> For example: XWiki Extension Repository Archive or XWiki Repository
> >>> Archive for short, which, using a 3LA, would translate into XRA.
> >>>
> >>> XAR = XWiki Archive = a single extension
> >>> XRA = XWiki Repository Archive = a repository of extensions = several
> >>> extensions
> >>>
> >>> We could also have XWiki Extension Repository, i.e. “XER”, which would
> >>> also be one letter change from XAR:
> >>>
> >>> XAR = XWiki Archive = a single extension
> >>> XER = XWiki Extension Repository = a repository of extensions = several
> >>> extensions
> >>>
> >>
> >> I'm fine with XER.
> >>
> >>
> >>> Now since the users will need to unzip this binary and they won’t
> import
> >>> it (as they do for XAR), it would be better for it to be ZIP as
> otherwise
> >>> it’ll harder to unzip (no double-clicking on it for ex).
> >>>
> >>
> >> As I said I think we'll have a UI for it at some point. I just don't
> think
> >> I will have time to work on that in the new platform flavor scope (or
> maybe
> >> just a quick tool in
> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak).
> >
> > I know you said that but IMO the primary usage is for users to unzip
> into a given directory and the easiest is to provide a ZIP to them. Even if
> we have an import UI, we can still offer the ZIP to that UI…
> >
> > So at this point, I don’t fully understand why we’d need something other
> than zip.
> >
> > Sounds like we might be overcomplicated things. On the maven side, we
> could use the maven assembly plugin to generate the zip.
> >
> > Am I missing something?
> >
> > Thanks
> > -Vincent
> >
> >> Thanks
> >>> -Vincent
> >>>
> >>>>
> >>>> --
> >>>> Thomas Mortagne
> >>>
> >>>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu
>



--
Thomas Mortagne