28 Aug
2012
28 Aug
'12
1:15 p.m.
Hi guys,
I would like to modify a bit the Maven XAR plugin to add in the
package.xml some extension related informations like the extension id
and version at the very least.
The idea is to be able to know what a XAR is exactly like we have the
pom.xml packaged with the jar file for example.
Among other things it will cover the following use cases:
* when someone import a XAR with the standard UI, automatically
register it in the extension index if it happen to be an extension
(i.e. if we find extension informations in its package.xml)
* wiki manager and workspaces can properly register actual extension
when creating their default template from a XAR the first time (this
is for example required to be able to upgrade a farm with EM where
pretty much all the wiki as been created from this default template)
In both cases the idea is to support as much current behaviours as we
can and still be able to use the full power of Extension Manager.
There should not be any backward compatibility issue here since it
does not really change anything in the XAR structure.
WDYT ?
Here is my +1
Thanks,
--
Thomas Mortagne
28 Aug
28 Aug
1:22 p.m.
On Tue, Aug 28, 2012 at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi guys,
I would like to modify a bit the Maven XAR plugin to add in the
package.xml some extension related informations like the extension id
and version at the very least.
(Note that the version is actually already provided)
The idea is to be able to know what a XAR is exactly like we have the
pom.xml packaged with the jar file for example.
Among other things it will cover the following use cases:
* when someone import a XAR with the standard UI, automatically
register it in the extension index if it happen to be an extension
(i.e. if we find extension informations in its package.xml)
* wiki manager and workspaces can properly register actual extension
when creating their default template from a XAR the first time (this
is for example required to be able to upgrade a farm with EM where
pretty much all the wiki as been created from this default template)
In both cases the idea is to support as much current behaviours as we
can and still be able to use the full power of Extension Manager.
There should not be any backward compatibility issue here since it
does not really change anything in the XAR structure.
WDYT ?
Here is my +1
Thanks,
--
Thomas Mortagne
--
Thomas Mortagne
1:37 p.m.
On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Hi guys,
I would like to modify a bit the Maven XAR plugin to add in the
package.xml some extension related informations like the extension id
and version at the very least.
Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven JAR
plugin?
It would be more generic and similar to how JARs are handled.
Thanks
-Vincent
The idea is to be able to know what a XAR is exactly
like we have the
pom.xml packaged with the jar file for example.
Among other things it will cover the following use cases:
* when someone import a XAR with the standard UI, automatically
register it in the extension index if it happen to be an extension
(i.e. if we find extension informations in its package.xml)
* wiki manager and workspaces can properly register actual extension
when creating their default template from a XAR the first time (this
is for example required to be able to upgrade a farm with EM where
pretty much all the wiki as been created from this default template)
In both cases the idea is to support as much current behaviours as we
can and still be able to use the full power of Extension Manager.
There should not be any backward compatibility issue here since it
does not really change anything in the XAR structure.
WDYT ?
Here is my +1
2:50 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Because it's not supposed as part of XAR format by existing XAR
parser, you will get an error because it will fail to parse it as a
document. The proposal here is to use something that already exists,
does not break anything and is very easy to do.
Hi guys,
I would like to modify a bit the Maven XAR plugin to add in the
package.xml some extension related informations like the extension id
and version at the very least.
Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven JAR
plugin?
It would be more generic and similar to how JARs are handled.
Thanks
-Vincent
--
Thomas Mortagne
The idea is to be able to know what a XAR is
exactly like we have the
pom.xml packaged with the jar file for example.
Among other things it will cover the following use cases:
* when someone import a XAR with the standard UI, automatically
register it in the extension index if it happen to be an extension
(i.e. if we find extension informations in its package.xml)
* wiki manager and workspaces can properly register actual extension
when creating their default template from a XAR the first time (this
is for example required to be able to upgrade a farm with EM where
pretty much all the wiki as been created from this default template)
In both cases the idea is to support as much current behaviours as we
can and still be able to use the full power of Extension Manager.
There should not be any backward compatibility issue here since it
does not really change anything in the XAR structure.
WDYT ?
Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:18 p.m.
On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions.
It doesn't look complex to add either, it's a matter of excluding META-INF files
from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
Thanks
-Vincent
On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Because it's not supposed as part of XAR format by existing XAR
parser, you will get an error because it will fail to parse it as a
document. The proposal here is to use something that already exists,
does not break anything and is very easy to do. Hi guys,
I would like to modify a bit the Maven XAR plugin to add in the
package.xml some extension related informations like the extension id
and version at the very least.
Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven JAR
plugin? > It would be more generic and similar to how JARs
are handled.
>
> Thanks
> -Vincent
>
>> The idea is to be able to know what a XAR is exactly like we have the
>> pom.xml packaged with the jar file for example.
>>
>> Among other things it will cover the following use cases:
>> * when someone import a XAR with the standard UI, automatically
>> register it in the extension index if it happen to be an extension
>> (i.e. if we find extension informations in its package.xml)
>> * wiki manager and workspaces can properly register actual extension
>> when creating their default template from a XAR the first time (this
>> is for example required to be able to upgrade a farm with EM where
>> pretty much all the wiki as been created from this default template)
>>
>> In both cases the idea is to support as much current behaviours as we
>> can and still be able to use the full power of Extension Manager.
>>
>> There should not be any backward compatibility issue here since it
>> does not really change anything in the XAR structure.
>>
>> WDYT ?
>>
>> Here is my +1
3:23 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
I think you don't understand what I mean here. The issue is not that
it's complex to support it, adding support in 4.2 for META-INF will
not change the fact that you will get an error in older version with
your XAR.
On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions.
On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Because it's not supposed as part of XAR format by existing XAR
parser, you will get an error because it will fail to parse it as a
document. The proposal here is to use something that already exists,
does not break anything and is very easy to do. Hi guys,
I would like to modify a bit the Maven XAR plugin to add in the
package.xml some extension related informations like the extension id
and version at the very least.
Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven JAR
plugin?
It doesn't look complex to add either, it's a matter of excluding META-INF files
from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
Thanks
-Vincent
--
Thomas Mortagne
> It would be more generic and similar to how
JARs are handled.
>
> Thanks
> -Vincent
>
>> The idea is to be able to know what a XAR is exactly like we have the
>> pom.xml packaged with the jar file for example.
>>
>> Among other things it will cover the following use cases:
>> * when someone import a XAR with the standard UI, automatically
>> register it in the extension index if it happen to be an extension
>> (i.e. if we find extension informations in its package.xml)
>> * wiki manager and workspaces can properly register actual extension
>> when creating their default template from a XAR the first time (this
>> is for example required to be able to upgrade a farm with EM where
>> pretty much all the wiki as been created from this default template)
>>
>> In both cases the idea is to support as much current behaviours as we
>> can and still be able to use the full power of Extension Manager.
>>
>> There should not be any backward compatibility issue here since it
>> does not really change anything in the XAR structure.
>>
>> WDYT ?
>>
>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:29 p.m.
On Aug 28, 2012, at 3:23 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
That's ok because the new version of the XARs will have a Compatibility field that
says works only with version N+. Same strategy as with extensions; you can't install
new extensions in an old core.
Thanks
-Vincent
On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
I think you don't understand what I mean here. The issue is not that
it's complex to support it, adding support in 4.2 for META-INF will
not change the fact that you will get an error in older version with
your XAR. On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions.
On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
> Hi guys,
>
> I would like to modify a bit the Maven XAR plugin to add in the
> package.xml some extension related informations like the extension id
> and version at the very least.
Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven JAR
plugin?
Because it's not supposed as part of XAR format by existing XAR
parser, you will get an error because it will fail to parse it as a
document. The proposal here is to use something that already exists,
does not break anything and is very easy to do. > It doesn't look complex to add either,
it's a matter of excluding META-INF files from the parser and to use the Maven
Archiver (see http://maven.apache.org/shared/maven-archiver/).
>
> Thanks
> -Vincent
>
>>> It would be more generic and similar to how JARs are handled.
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> The idea is to be able to know what a XAR is exactly like we have the
>>>> pom.xml packaged with the jar file for example.
>>>>
>>>> Among other things it will cover the following use cases:
>>>> * when someone import a XAR with the standard UI, automatically
>>>> register it in the extension index if it happen to be an extension
>>>> (i.e. if we find extension informations in its package.xml)
>>>> * wiki manager and workspaces can properly register actual extension
>>>> when creating their default template from a XAR the first time (this
>>>> is for example required to be able to upgrade a farm with EM where
>>>> pretty much all the wiki as been created from this default template)
>>>>
>>>> In both cases the idea is to support as much current behaviours as we
>>>> can and still be able to use the full power of Extension Manager.
>>>>
>>>> There should not be any backward compatibility issue here since it
>>>> does not really change anything in the XAR structure.
>>>>
>>>> WDYT ?
>>>>
>>>> Here is my +1
3:32 p.m.
On Aug 28, 2012, at 3:29 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 3:23 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
<related>
BTW to handle changes to the XAR format better in the future, we should probably add a XAR
format version to the package.xml file.
</related>
Thanks
-Vincent
On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
That's ok because the new version of the XARs will have a Compatibility field that
says works only with version N+. Same strategy as with extensions; you can't install
new extensions in an old core.
On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
I think you don't understand what I mean here. The issue is not that
it's complex to support it, adding support in 4.2 for META-INF will
not change the fact that you will get an error in older version with
your XAR. On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> Hi guys,
>>
>> I would like to modify a bit the Maven XAR plugin to add in the
>> package.xml some extension related informations like the extension id
>> and version at the very least.
>
> Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven
JAR plugin?
Because it's not supposed as part of XAR format by existing XAR
parser, you will get an error because it will fail to parse it as a
document. The proposal here is to use something that already exists,
does not break anything and is very easy to do.
I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions. Thanks
-Vincent
> It doesn't look complex to add either,
it's a matter of excluding META-INF files from the parser and to use the Maven
Archiver (see http://maven.apache.org/shared/maven-archiver/).
>
> Thanks
> -Vincent
>
>>> It would be more generic and similar to how JARs are handled.
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> The idea is to be able to know what a XAR is exactly like we have the
>>>> pom.xml packaged with the jar file for example.
>>>>
>>>> Among other things it will cover the following use cases:
>>>> * when someone import a XAR with the standard UI, automatically
>>>> register it in the extension index if it happen to be an extension
>>>> (i.e. if we find extension informations in its package.xml)
>>>> * wiki manager and workspaces can properly register actual extension
>>>> when creating their default template from a XAR the first time (this
>>>> is for example required to be able to upgrade a farm with EM where
>>>> pretty much all the wiki as been created from this default template)
>>>>
>>>> In both cases the idea is to support as much current behaviours as we
>>>> can and still be able to use the full power of Extension Manager.
>>>>
>>>> There should not be any backward compatibility issue here since it
>>>> does not really change anything in the XAR structure.
>>>>
>>>> WDYT ?
>>>>
>>>> Here is my +1
3:32 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 3:29 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 3:23 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
That does not make any sense, it means that if you want you XAR to be
recognise properly as extension in 4.2+ it can't work with previous
version even if it does not depends in any way on 4.2. That's very bad
for an extension.
On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
That's ok because the new version of the XARs will have a Compatibility field that
says works only with version N+. Same strategy as with extensions; you can't install
new extensions in an old core.
On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
I think you don't understand what I mean here. The issue is not that
it's complex to support it, adding support in 4.2 for META-INF will
not change the fact that you will get an error in older version with
your XAR. On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> Hi guys,
>>
>> I would like to modify a bit the Maven XAR plugin to add in the
>> package.xml some extension related informations like the extension id
>> and version at the very least.
>
> Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven
JAR plugin?
Because it's not supposed as part of XAR format by existing XAR
parser, you will get an error because it will fail to parse it as a
document. The proposal here is to use something that already exists,
does not break anything and is very easy to do.
I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions.
Thanks
-Vincent
--
Thomas Mortagne
> It doesn't look complex to add either,
it's a matter of excluding META-INF files from the parser and to use the Maven
Archiver (see http://maven.apache.org/shared/maven-archiver/).
>
> Thanks
> -Vincent
>
>>> It would be more generic and similar to how JARs are handled.
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> The idea is to be able to know what a XAR is exactly like we have the
>>>> pom.xml packaged with the jar file for example.
>>>>
>>>> Among other things it will cover the following use cases:
>>>> * when someone import a XAR with the standard UI, automatically
>>>> register it in the extension index if it happen to be an extension
>>>> (i.e. if we find extension informations in its package.xml)
>>>> * wiki manager and workspaces can properly register actual extension
>>>> when creating their default template from a XAR the first time (this
>>>> is for example required to be able to upgrade a farm with EM where
>>>> pretty much all the wiki as been created from this default template)
>>>>
>>>> In both cases the idea is to support as much current behaviours as we
>>>> can and still be able to use the full power of Extension Manager.
>>>>
>>>> There should not be any backward compatibility issue here since it
>>>> does not really change anything in the XAR structure.
>>>>
>>>> WDYT ?
>>>>
>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:31 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Making the XAR format depends on Maven is not exactly something
generic or even very nice. Core extension scanner is looking at the
pom located in jar file among other things in order to find as much as
it can but lets not forget that this is a hack and nothing else.
On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
I think you don't understand what I mean here. The issue is not that
it's complex to support it, adding support in 4.2 for META-INF will
not change the fact that you will get an error in older version with
your XAR.
>
> It doesn't look complex to add either, it's a matter of excluding META-INF
files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/). On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions.
On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
> Hi guys,
>
> I would like to modify a bit the Maven XAR plugin to add in the
> package.xml some extension related informations like the extension id
> and version at the very least.
Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven JAR
plugin?
Because it's not supposed as part of XAR format by existing XAR
parser, you will get an error because it will fail to parse it as a
document. The proposal here is to use something that already exists,
does not break anything and is very easy to do.
Thanks
-Vincent
--
Thomas Mortagne > It would be more generic and similar to how
JARs are handled.
>
> Thanks
> -Vincent
>
>> The idea is to be able to know what a XAR is exactly like we have the
>> pom.xml packaged with the jar file for example.
>>
>> Among other things it will cover the following use cases:
>> * when someone import a XAR with the standard UI, automatically
>> register it in the extension index if it happen to be an extension
>> (i.e. if we find extension informations in its package.xml)
>> * wiki manager and workspaces can properly register actual extension
>> when creating their default template from a XAR the first time (this
>> is for example required to be able to upgrade a farm with EM where
>> pretty much all the wiki as been created from this default template)
>>
>> In both cases the idea is to support as much current behaviours as we
>> can and still be able to use the full power of Extension Manager.
>>
>> There should not be any backward compatibility issue here since it
>> does not really change anything in the XAR structure.
>>
>> WDYT ?
>>
>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:35 p.m.
On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
Thanks
-Vincent
On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Making the XAR format depends on Maven is not exactly something
generic or even very nice. Core extension scanner is looking at the
pom located in jar file among other things in order to find as much as
it can but lets not forget that this is a hack and nothing else.
On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
I think you don't understand what I mean here. The issue is not that
it's complex to support it, adding support in 4.2 for META-INF will
not change the fact that you will get an error in older version with
your XAR.
>
> It doesn't look complex to add either, it's a matter of excluding META-INF
files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/). On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> Hi guys,
>>
>> I would like to modify a bit the Maven XAR plugin to add in the
>> package.xml some extension related informations like the extension id
>> and version at the very least.
>
> Why not package the pom.xml instead in META-INF/maven/* as it's done by the Maven
JAR plugin?
Because it's not supposed as part of XAR format by existing XAR
parser, you will get an error because it will fail to parse it as a
document. The proposal here is to use something that already exists,
does not break anything and is very easy to do.
I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions. >> Thanks
>> -Vincent
>>
>>>> It would be more generic and similar to how JARs are handled.
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>> The idea is to be able to know what a XAR is exactly like we have
the
>>>>> pom.xml packaged with the jar file for example.
>>>>>
>>>>> Among other things it will cover the following use cases:
>>>>> * when someone import a XAR with the standard UI, automatically
>>>>> register it in the extension index if it happen to be an extension
>>>>> (i.e. if we find extension informations in its package.xml)
>>>>> * wiki manager and workspaces can properly register actual extension
>>>>> when creating their default template from a XAR the first time (this
>>>>> is for example required to be able to upgrade a farm with EM where
>>>>> pretty much all the wiki as been created from this default template)
>>>>>
>>>>> In both cases the idea is to support as much current behaviours as
we
>>>>> can and still be able to use the full power of Extension Manager.
>>>>>
>>>>> There should not be any backward compatibility issue here since it
>>>>> does not really change anything in the XAR structure.
>>>>>
>>>>> WDYT ?
>>>>>
>>>>> Here is my +1
3:44 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
It's exactly the same thing. The package.xml file is the XAR way to
provide informations about the file and is generated from the pom.xml.
It already provide the a subset of extension informations (name,
version, license, etc.) so the proposal here is about adding more
things.
On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information. On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Making the XAR format depends on Maven is not exactly something
generic or even very nice. Core extension scanner is looking at the
pom located in jar file among other things in order to find as much as
it can but lets not forget that this is a hack and nothing else.
On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
>>
>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>>
>>> Hi guys,
>>>
>>> I would like to modify a bit the Maven XAR plugin to add in the
>>> package.xml some extension related informations like the extension id
>>> and version at the very least.
>>
>> Why not package the pom.xml instead in META-INF/maven/* as it's done by the
Maven JAR plugin?
>
> Because it's not supposed as part of XAR format by existing XAR
> parser, you will get an error because it will fail to parse it as a
> document. The proposal here is to use something that already exists,
> does not break anything and is very easy to do.
I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions.
I think you don't understand what I mean here. The issue is not that
it's complex to support it, adding support in 4.2 for META-INF will
not change the fact that you will get an error in older version with
your XAR.
>
> It doesn't look complex to add either, it's a matter of excluding META-INF
files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
Thanks
-Vincent
--
Thomas Mortagne
>> Thanks
>> -Vincent
>>
>>>> It would be more generic and similar to how JARs are handled.
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>> The idea is to be able to know what a XAR is exactly like we have
the
>>>>> pom.xml packaged with the jar file for example.
>>>>>
>>>>> Among other things it will cover the following use cases:
>>>>> * when someone import a XAR with the standard UI, automatically
>>>>> register it in the extension index if it happen to be an extension
>>>>> (i.e. if we find extension informations in its package.xml)
>>>>> * wiki manager and workspaces can properly register actual extension
>>>>> when creating their default template from a XAR the first time (this
>>>>> is for example required to be able to upgrade a farm with EM where
>>>>> pretty much all the wiki as been created from this default template)
>>>>>
>>>>> In both cases the idea is to support as much current behaviours as
we
>>>>> can and still be able to use the full power of Extension Manager.
>>>>>
>>>>> There should not be any backward compatibility issue here since it
>>>>> does not really change anything in the XAR structure.
>>>>>
>>>>> WDYT ?
>>>>>
>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:20 p.m.
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go.
Thanks
-Vincent
On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
It's exactly the same thing. The package.xml file is the XAR way to
provide informations about the file and is generated from the pom.xml.
It already provide the a subset of extension informations (name,
version, license, etc.) so the proposal here is about adding more
things. On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information. On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>
>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I would like to modify a bit the Maven XAR plugin to add in the
>>>> package.xml some extension related informations like the extension id
>>>> and version at the very least.
>>>
>>> Why not package the pom.xml instead in META-INF/maven/* as it's done by
the Maven JAR plugin?
>>
>> Because it's not supposed as part of XAR format by existing XAR
>> parser, you will get an error because it will fail to parse it as a
>> document. The proposal here is to use something that already exists,
>> does not break anything and is very easy to do.
>
> I personally much prefer to add META-INF support over changing the package.xml format
because it's much better aligned with all other formats like JAR, EAR, WAR, etc and
with the way we handle JAR extensions.
I think you don't understand what I mean here. The issue is not that
it's complex to support it, adding support in 4.2 for META-INF will
not change the fact that you will get an error in older version with
your XAR.
>
> It doesn't look complex to add either, it's a matter of excluding META-INF
files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
Making the XAR format depends on Maven is not exactly something
generic or even very nice. Core extension scanner is looking at the
pom located in jar file among other things in order to find as much as
it can but lets not forget that this is a hack and nothing else. > Thanks
> -Vincent
>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>>> It would be more generic and similar to how JARs are handled.
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>> The idea is to be able to know what a XAR is exactly like we
have the
>>>>>>> pom.xml packaged with the jar file for example.
>>>>>>>
>>>>>>> Among other things it will cover the following use cases:
>>>>>>> * when someone import a XAR with the standard UI,
automatically
>>>>>>> register it in the extension index if it happen to be an
extension
>>>>>>> (i.e. if we find extension informations in its package.xml)
>>>>>>> * wiki manager and workspaces can properly register actual
extension
>>>>>>> when creating their default template from a XAR the first
time (this
>>>>>>> is for example required to be able to upgrade a farm with EM
where
>>>>>>> pretty much all the wiki as been created from this default
template)
>>>>>>>
>>>>>>> In both cases the idea is to support as much current
behaviours as we
>>>>>>> can and still be able to use the full power of Extension
Manager.
>>>>>>>
>>>>>>> There should not be any backward compatibility issue here
since it
>>>>>>> does not really change anything in the XAR structure.
>>>>>>>
>>>>>>> WDYT ?
>>>>>>>
>>>>>>> Here is my +1
4:26 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages. I need something for 4.2 and
adding the id in package.xml along with the other existing extension
informations is quick, easy, fully retro compatible and does not
really introduce anything new.
On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go.
On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
It's exactly the same thing. The package.xml file is the XAR way to
provide informations about the file and is generated from the pom.xml.
It already provide the a subset of extension informations (name,
version, license, etc.) so the proposal here is about adding more
things. On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <vincent(a)massol.net> wrote:
>>
>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>>
>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>>
>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I would like to modify a bit the Maven XAR plugin to add in the
>>>>> package.xml some extension related informations like the extension
id
>>>>> and version at the very least.
>>>>
>>>> Why not package the pom.xml instead in META-INF/maven/* as it's done
by the Maven JAR plugin?
>>>
>>> Because it's not supposed as part of XAR format by existing XAR
>>> parser, you will get an error because it will fail to parse it as a
>>> document. The proposal here is to use something that already exists,
>>> does not break anything and is very easy to do.
>>
>> I personally much prefer to add META-INF support over changing the package.xml
format because it's much better aligned with all other formats like JAR, EAR, WAR, etc
and with the way we handle JAR extensions.
>
> I think you don't understand what I mean here. The issue is not that
> it's complex to support it, adding support in 4.2 for META-INF will
> not change the fact that you will get an error in older version with
> your XAR.
>
>>
>> It doesn't look complex to add either, it's a matter of excluding
META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
Making the XAR format depends on Maven is not exactly something
generic or even very nice. Core extension scanner is looking at the
pom located in jar file among other things in order to find as much as
it can but lets not forget that this is a hack and nothing else.
Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
Thanks
-Vincent
--
Thomas Mortagne
> Thanks
> -Vincent
>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>>> It would be more generic and similar to how JARs are handled.
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>> The idea is to be able to know what a XAR is exactly like we
have the
>>>>>>> pom.xml packaged with the jar file for example.
>>>>>>>
>>>>>>> Among other things it will cover the following use cases:
>>>>>>> * when someone import a XAR with the standard UI,
automatically
>>>>>>> register it in the extension index if it happen to be an
extension
>>>>>>> (i.e. if we find extension informations in its package.xml)
>>>>>>> * wiki manager and workspaces can properly register actual
extension
>>>>>>> when creating their default template from a XAR the first
time (this
>>>>>>> is for example required to be able to upgrade a farm with EM
where
>>>>>>> pretty much all the wiki as been created from this default
template)
>>>>>>>
>>>>>>> In both cases the idea is to support as much current
behaviours as we
>>>>>>> can and still be able to use the full power of Extension
Manager.
>>>>>>>
>>>>>>> There should not be any backward compatibility issue here
since it
>>>>>>> does not really change anything in the XAR structure.
>>>>>>>
>>>>>>> WDYT ?
>>>>>>>
>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:37 p.m.
On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
There are 2 topics:
* Create a generic format for all xwiki extensions (the META-INF/xwiki/extension.xml),
nothing to do with wiki pages
* Modify the existing XAR format descriptor (package.xml) to remove stuff that are 1) not
needed (like the list of files and 2) can be found in the extension information (i.e. in
META-INF/xwiki/extension.xml)
So far you/we have decided that the xwiki extension format will be the pom.xml format
which is why we are using it in our JAR file to discover extensions. Based on that
it's not logical to invent a new way to add extension information even if the existing
package.xml contains already some information that happens (by pure coincidence) to be the
same as the one needed by the extension manager (for ex the version in package.xml could
be a completely different version than the extension version).
Based on this the logic is to add the pom.xml file to the XAR.
Now you said that you didn't think using the Maven format is good. Fine. This is a
change from what we had decided so far and I'm ready to accept that we may want to
dissociate from Maven; hence my proposal about the META-INF/xwiki/extension.xml file.
So we have 2 choices for me:
* continue with the current rule of using pom.xml files as containing extension
information
* decide to bite the bullet and invent a new format for holding extension information
Those are the 2 *good* choices for me. Ofc we need to handle backward compat as best as we
can but that's doable.
You'd like to do the 3rd choice which IMO is a quick and dirty solution. I'd
accept it but only as a quick hack for 4.2 and that we would need to correct ASAP.
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages. On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go.
On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com> wrote:
>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>
>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>
>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>
>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I would like to modify a bit the Maven XAR plugin to add in the
>>>>>> package.xml some extension related informations like the
extension id
>>>>>> and version at the very least.
>>>>>
>>>>> Why not package the pom.xml instead in META-INF/maven/* as it's
done by the Maven JAR plugin?
>>>>
>>>> Because it's not supposed as part of XAR format by existing XAR
>>>> parser, you will get an error because it will fail to parse it as a
>>>> document. The proposal here is to use something that already exists,
>>>> does not break anything and is very easy to do.
>>>
>>> I personally much prefer to add META-INF support over changing the
package.xml format because it's much better aligned with all other formats like JAR,
EAR, WAR, etc and with the way we handle JAR extensions.
>>
>> I think you don't understand what I mean here. The issue is not that
>> it's complex to support it, adding support in 4.2 for META-INF will
>> not change the fact that you will get an error in older version with
>> your XAR.
>>
>>>
>>> It doesn't look complex to add either, it's a matter of excluding
META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
>
> Making the XAR format depends on Maven is not exactly something
> generic or even very nice. Core extension scanner is looking at the
> pom located in jar file among other things in order to find as much as
> it can but lets not forget that this is a hack and nothing else.
Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
It's exactly the same thing. The package.xml file is the XAR way to
provide informations about the file and is generated from the pom.xml.
It already provide the a subset of extension informations (name,
version, license, etc.) so the proposal here is about adding more
things. I need something for 4.2 and
adding the id in package.xml along with the other existing extension
informations is quick, easy, fully retro compatible and does not
really introduce anything new.
Sure but it does introduce something new: the new information you add to package.xml. And
this is exactly like a public API; once it's there we have to support it and be retro
compatible. So we have to be careful because it's a pain to change after.
I'm curious to know what others think about this.
Thanks
-Vincent
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>> It would be more generic and similar to how JARs are
handled.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>> The idea is to be able to know what a XAR is exactly
like we have the
>>>>>>>>> pom.xml packaged with the jar file for example.
>>>>>>>>>
>>>>>>>>> Among other things it will cover the following use
cases:
>>>>>>>>> * when someone import a XAR with the standard UI,
automatically
>>>>>>>>> register it in the extension index if it happen to be
an extension
>>>>>>>>> (i.e. if we find extension informations in its
package.xml)
>>>>>>>>> * wiki manager and workspaces can properly register
actual extension
>>>>>>>>> when creating their default template from a XAR the
first time (this
>>>>>>>>> is for example required to be able to upgrade a farm
with EM where
>>>>>>>>> pretty much all the wiki as been created from this
default template)
>>>>>>>>>
>>>>>>>>> In both cases the idea is to support as much current
behaviours as we
>>>>>>>>> can and still be able to use the full power of
Extension Manager.
>>>>>>>>>
>>>>>>>>> There should not be any backward compatibility issue
here since it
>>>>>>>>> does not really change anything in the XAR
structure.
>>>>>>>>>
>>>>>>>>> WDYT ?
>>>>>>>>>
>>>>>>>>> Here is my +1
4:55 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 4:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
We never decided such thing. Again the core extension scanner try to
find all it can from the jar located and among other things it check
if there is pom.xml because that's a format in which it can find
extension informations usually but there is others and for some JAR it
does not exists. The only other thing that look at pom.xml is the
Maven Reposirory handler (and I actually plan to move the core scanner
part which looks at pom descriptor to the Maven handler when I get
some time). Extension Manager in general does not officially depends
in any way on Maven, you don't have to build you extension with Maven
for it to be supported by Extension Manager and I hope you will never
have to.
So if you want to start designing a new packaging format no problem
and it's actually listed in
http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManageXWikiPackage
but it's a totally different subject and in no way a priority. The way
standard to provide informations about the package in a XAR is
package.xml so I'm just proposing to add one more informations. You
are talking about packing format that does not have anything to do
with XAR, the fact that you change everything and still call it XAR is
only you point of view.
On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
There are 2 topics:
* Create a generic format for all xwiki extensions (the META-INF/xwiki/extension.xml),
nothing to do with wiki pages
* Modify the existing XAR format descriptor (package.xml) to remove stuff that are 1) not
needed (like the list of files and 2) can be found in the extension information (i.e. in
META-INF/xwiki/extension.xml)
So far you/we have decided that the xwiki extension format will be the pom.xml format
which is why we are using it in our JAR file to discover extensions.
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages. On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>> <thomas.mortagne(a)xwiki.com> wrote:
>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>>
>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>
>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>>
>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I would like to modify a bit the Maven XAR plugin to add in
the
>>>>>>> package.xml some extension related informations like the
extension id
>>>>>>> and version at the very least.
>>>>>>
>>>>>> Why not package the pom.xml instead in META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>
>>>>> Because it's not supposed as part of XAR format by existing XAR
>>>>> parser, you will get an error because it will fail to parse it as a
>>>>> document. The proposal here is to use something that already exists,
>>>>> does not break anything and is very easy to do.
>>>>
>>>> I personally much prefer to add META-INF support over changing the
package.xml format because it's much better aligned with all other formats like JAR,
EAR, WAR, etc and with the way we handle JAR extensions.
>>>
>>> I think you don't understand what I mean here. The issue is not that
>>> it's complex to support it, adding support in 4.2 for META-INF will
>>> not change the fact that you will get an error in older version with
>>> your XAR.
>>>
>>>>
>>>> It doesn't look complex to add either, it's a matter of excluding
META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
>>
>> Making the XAR format depends on Maven is not exactly something
>> generic or even very nice. Core extension scanner is looking at the
>> pom located in jar file among other things in order to find as much as
>> it can but lets not forget that this is a hack and nothing else.
>
> Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
>
> I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
It's exactly the same thing. The package.xml file is the XAR way to
provide informations about the file and is generated from the pom.xml.
It already provide the a subset of extension informations (name,
version, license, etc.) so the proposal here is about adding more
things.
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go. Based on that it's not logical to invent a new way
to add extension information even if the existing package.xml contains already some
information that happens (by pure coincidence) to be the same as the one needed by the
extension manager (for ex the version in package.xml could be a completely different
version than the extension version).
Based on this the logic is to add the pom.xml file to the XAR.
Now you said that you didn't think using the Maven format is good. Fine. This is a
change from what we had decided so far and I'm ready to accept that we may want to
dissociate from Maven; hence my proposal about the META-INF/xwiki/extension.xml file.
So we have 2 choices for me:
* continue with the current rule of using pom.xml files as containing extension
information
* decide to bite the bullet and invent a new format for holding extension information
Those are the 2 *good* choices for me. Ofc we need to handle backward compat as best as
we can but that's doable.
You'd like to do the 3rd choice which IMO is a quick and dirty solution. I'd
accept it but only as a quick hack for 4.2 and that we would need to correct ASAP.
--
Thomas Mortagne
I need something for 4.2 and
adding the id in package.xml along with the other existing extension
informations is quick, easy, fully retro compatible and does not
really introduce anything new.
Sure but it does introduce something new: the new information you add to package.xml. And
this is exactly like a public API; once it's there we have to support it and be retro
compatible. So we have to be careful because it's a pain to change after.
I'm curious to know what others think about this.
Thanks
-Vincent
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>> It would be more generic and similar to how JARs are
handled.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>> The idea is to be able to know what a XAR is exactly
like we have the
>>>>>>>>> pom.xml packaged with the jar file for example.
>>>>>>>>>
>>>>>>>>> Among other things it will cover the following use
cases:
>>>>>>>>> * when someone import a XAR with the standard UI,
automatically
>>>>>>>>> register it in the extension index if it happen to be
an extension
>>>>>>>>> (i.e. if we find extension informations in its
package.xml)
>>>>>>>>> * wiki manager and workspaces can properly register
actual extension
>>>>>>>>> when creating their default template from a XAR the
first time (this
>>>>>>>>> is for example required to be able to upgrade a farm
with EM where
>>>>>>>>> pretty much all the wiki as been created from this
default template)
>>>>>>>>>
>>>>>>>>> In both cases the idea is to support as much current
behaviours as we
>>>>>>>>> can and still be able to use the full power of
Extension Manager.
>>>>>>>>>
>>>>>>>>> There should not be any backward compatibility issue
here since it
>>>>>>>>> does not really change anything in the XAR
structure.
>>>>>>>>>
>>>>>>>>> WDYT ?
>>>>>>>>>
>>>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:02 p.m.
On Aug 28, 2012, at 4:55 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 4:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
It's a de facto choice since this is currently how our artifacts provide extension
information for the Extension Manager (we even have custom pom properties for that).
On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
We never decided such thing. On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
There are 2 topics:
* Create a generic format for all xwiki extensions (the META-INF/xwiki/extension.xml),
nothing to do with wiki pages
* Modify the existing XAR format descriptor (package.xml) to remove stuff that are 1) not
needed (like the list of files and 2) can be found in the extension information (i.e. in
META-INF/xwiki/extension.xml)
So far you/we have decided that the xwiki extension format will be the pom.xml format
which is why we are using it in our JAR file to discover extensions.
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
> On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol <vincent(a)massol.net> wrote:
>>
>> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>>
>>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>
>>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>
>>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>>>
>>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I would like to modify a bit the Maven XAR plugin to add
in the
>>>>>>>> package.xml some extension related informations like the
extension id
>>>>>>>> and version at the very least.
>>>>>>>
>>>>>>> Why not package the pom.xml instead in META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>>
>>>>>> Because it's not supposed as part of XAR format by existing
XAR
>>>>>> parser, you will get an error because it will fail to parse it as
a
>>>>>> document. The proposal here is to use something that already
exists,
>>>>>> does not break anything and is very easy to do.
>>>>>
>>>>> I personally much prefer to add META-INF support over changing the
package.xml format because it's much better aligned with all other formats like JAR,
EAR, WAR, etc and with the way we handle JAR extensions.
>>>>
>>>> I think you don't understand what I mean here. The issue is not that
>>>> it's complex to support it, adding support in 4.2 for META-INF will
>>>> not change the fact that you will get an error in older version with
>>>> your XAR.
>>>>
>>>>>
>>>>> It doesn't look complex to add either, it's a matter of
excluding META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
>>>
>>> Making the XAR format depends on Maven is not exactly something
>>> generic or even very nice. Core extension scanner is looking at the
>>> pom located in jar file among other things in order to find as much as
>>> it can but lets not forget that this is a hack and nothing else.
>>
>> Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
>>
>> I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
>
> It's exactly the same thing. The package.xml file is the XAR way to
> provide informations about the file and is generated from the pom.xml.
> It already provide the a subset of extension informations (name,
> version, license, etc.) so the proposal here is about adding more
> things.
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go.
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages. Again the core extension scanner try to
find all it can from the jar located and among other things it check
if there is pom.xml because that's a format in which it can find
extension informations usually but there is others and for some JAR it
does not exists. The only other thing that look at pom.xml is the
Maven Reposirory handler (and I actually plan to move the core scanner
part which looks at pom descriptor to the Maven handler when I get
some time). Extension Manager in general does not officially depends
in any way on Maven, you don't have to build you extension with Maven
for it to be supported by Extension Manager and I hope you will never
have to.
So if you want to start designing a new packaging format no problem
and it's actually listed in
http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManageXWikiPackage
but it's a totally different subject and in no way a priority. The way
standard to provide informations about the package in a XAR is
package.xml so I'm just proposing to add one more informations. You
are talking about packing format that does not have anything to do
with XAR, the fact that you change everything and still call it XAR is
only you point of view.
I know you're on a tight schedule for 4.2 and I don't want to block you so I'm
going to vote +0 for now but I'm still of the view that it isn't the right place
for the future. Let's hope it doesn't cause us more harm (but it should be ok
because removing one or several properties in the future is going to be roughly the same
cost).
Thanks
-Vincent
Based on that
it's not logical to invent a new way to add extension information even if the existing
package.xml contains already some information that happens (by pure coincidence) to be the
same as the one needed by the extension manager (for ex the version in package.xml could
be a completely different version than the extension version).
Based on this the logic is to add the pom.xml file to the XAR.
Now you said that you didn't think using the Maven format is good. Fine. This is a
change from what we had decided so far and I'm ready to accept that we may want to
dissociate from Maven; hence my proposal about the META-INF/xwiki/extension.xml file.
So we have 2 choices for me:
* continue with the current rule of using pom.xml files as containing extension
information
* decide to bite the bullet and invent a new format for holding extension information
Those are the 2 *good* choices for me. Ofc we need to handle backward compat as best as
we can but that's doable.
You'd like to do the 3rd choice which IMO is a quick and dirty solution. I'd
accept it but only as a quick hack for 4.2 and that we would need to correct ASAP.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs I need something for 4.2 and
adding the id in package.xml along with the other existing extension
informations is quick, easy, fully retro compatible and does not
really introduce anything new.
Sure but it does introduce something new: the new information you add to package.xml. And
this is exactly like a public API; once it's there we have to support it and be retro
compatible. So we have to be careful because it's a pain to change after.
I'm curious to know what others think about this.
Thanks
-Vincent
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>> It would be more generic and similar to how JARs are
handled.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>> The idea is to be able to know what a XAR is exactly
like we have the
>>>>>>>>> pom.xml packaged with the jar file for example.
>>>>>>>>>
>>>>>>>>> Among other things it will cover the following use
cases:
>>>>>>>>> * when someone import a XAR with the standard UI,
automatically
>>>>>>>>> register it in the extension index if it happen to be
an extension
>>>>>>>>> (i.e. if we find extension informations in its
package.xml)
>>>>>>>>> * wiki manager and workspaces can properly register
actual extension
>>>>>>>>> when creating their default template from a XAR the
first time (this
>>>>>>>>> is for example required to be able to upgrade a farm
with EM where
>>>>>>>>> pretty much all the wiki as been created from this
default template)
>>>>>>>>>
>>>>>>>>> In both cases the idea is to support as much current
behaviours as we
>>>>>>>>> can and still be able to use the full power of
Extension Manager.
>>>>>>>>>
>>>>>>>>> There should not be any backward compatibility issue
here since it
>>>>>>>>> does not really change anything in the XAR
structure.
>>>>>>>>>
>>>>>>>>> WDYT ?
>>>>>>>>>
>>>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:07 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 5:02 PM, Vincent Massol <vincent(a)massol.net> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
On Aug 28, 2012, at 4:55 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
No it's not, it's how Maven Repository provide extension information
for Extension Manager. When you install an extension from XWiki
Repository there is not a single line of code reading at any pom.xml.
On Tue, Aug 28, 2012 at 4:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
It's a de facto choice since this is currently how our artifacts provide extension
information for the Extension Manager (we even have custom pom properties for that).
On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
We never decided such thing. On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>
>>> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>
>>>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>>
>>>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>>
>>>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>>>>
>>>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>>
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> I would like to modify a bit the Maven XAR plugin to
add in the
>>>>>>>>> package.xml some extension related informations like
the extension id
>>>>>>>>> and version at the very least.
>>>>>>>>
>>>>>>>> Why not package the pom.xml instead in META-INF/maven/*
as it's done by the Maven JAR plugin?
>>>>>>>
>>>>>>> Because it's not supposed as part of XAR format by
existing XAR
>>>>>>> parser, you will get an error because it will fail to parse
it as a
>>>>>>> document. The proposal here is to use something that already
exists,
>>>>>>> does not break anything and is very easy to do.
>>>>>>
>>>>>> I personally much prefer to add META-INF support over changing
the package.xml format because it's much better aligned with all other formats like
JAR, EAR, WAR, etc and with the way we handle JAR extensions.
>>>>>
>>>>> I think you don't understand what I mean here. The issue is not
that
>>>>> it's complex to support it, adding support in 4.2 for META-INF
will
>>>>> not change the fact that you will get an error in older version with
>>>>> your XAR.
>>>>>
>>>>>>
>>>>>> It doesn't look complex to add either, it's a matter of
excluding META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
>>>>
>>>> Making the XAR format depends on Maven is not exactly something
>>>> generic or even very nice. Core extension scanner is looking at the
>>>> pom located in jar file among other things in order to find as much as
>>>> it can but lets not forget that this is a hack and nothing else.
>>>
>>> Whatever the solution we need consistency IMO. If your proposal is to create
an extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
>>>
>>> I don't like mixing extension information with packaging information. For
me package.xml shouldn't contain extension information.
>>
>> It's exactly the same thing. The package.xml file is the XAR way to
>> provide informations about the file and is generated from the pom.xml.
>> It already provide the a subset of extension informations (name,
>> version, license, etc.) so the proposal here is about adding more
>> things.
>
> For me the package.xml should probably even be removed or at least a lot of
information should be removed. There's no point in listing the files explicitly for
example. Same for whether it's a backup pack or not.
>
> And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
>
> So I'm definitely with you about creating a XWiki-specific descriptor (not tied
to maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
>
> At the very least I'd like that we agree about where we'd like to go
(I've made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get
there and what it takes. If it means going through intermediary steps, then fine, the
important part for me being to agree on where we want to go.
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages.
There are 2 topics:
* Create a generic format for all xwiki extensions (the META-INF/xwiki/extension.xml),
nothing to do with wiki pages
* Modify the existing XAR format descriptor (package.xml) to remove stuff that are 1) not
needed (like the list of files and 2) can be found in the extension information (i.e. in
META-INF/xwiki/extension.xml)
So far you/we have decided that the xwiki extension format will be the pom.xml format
which is why we are using it in our JAR file to discover extensions. Again the core extension scanner try to
find all it can from the jar located and among other things it check
if there is pom.xml because that's a format in which it can find
extension informations usually but there is others and for some JAR it
does not exists. The only other thing that look at pom.xml is the
Maven Reposirory handler (and I actually plan to move the core scanner
part which looks at pom descriptor to the Maven handler when I get
some time). Extension Manager in general does not officially depends
in any way on Maven, you don't have to build you extension with Maven
for it to be supported by Extension Manager and I hope you will never
have to.
So if you want to start designing a new packaging format no problem
and it's actually listed in
http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManageXWikiPackage
but it's a totally different subject and in no way a priority. The way
standard to provide informations about the package in a XAR is
package.xml so I'm just proposing to add one more informations. You
are talking about packing format that does not have anything to do
with XAR, the fact that you change everything and still call it XAR is
only you point of view.
I know you're on a tight schedule for 4.2 and I don't want to block you so
I'm going to vote +0 for now but I'm still of the view that it isn't the right
place for the future. Let's hope it doesn't cause us more harm (but it should be
ok because removing one or several properties in the future is going to be roughly the
same cost).
Thanks
-Vincent
Based on
that it's not logical to invent a new way to add extension information even if the
existing package.xml contains already some information that happens (by pure coincidence)
to be the same as the one needed by the extension manager (for ex the version in
package.xml could be a completely different version than the extension version).
Based on this the logic is to add the pom.xml file to the XAR.
Now you said that you didn't think using the Maven format is good. Fine. This is a
change from what we had decided so far and I'm ready to accept that we may want to
dissociate from Maven; hence my proposal about the META-INF/xwiki/extension.xml file.
So we have 2 choices for me:
* continue with the current rule of using pom.xml files as containing extension
information
* decide to bite the bullet and invent a new format for holding extension information
Those are the 2 *good* choices for me. Ofc we need to handle backward compat as best as
we can but that's doable.
You'd like to do the 3rd choice which IMO is a quick and dirty solution. I'd
accept it but only as a quick hack for 4.2 and that we would need to correct ASAP.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs I need something for 4.2 and
adding the id in package.xml along with the other existing extension
informations is quick, easy, fully retro compatible and does not
really introduce anything new.
Sure but it does introduce something new: the new information you add to package.xml. And
this is exactly like a public API; once it's there we have to support it and be retro
compatible. So we have to be careful because it's a pain to change after.
I'm curious to know what others think about this.
Thanks
-Vincent
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>> It would be more generic and similar to how JARs are
handled.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>> The idea is to be able to know what a XAR is exactly
like we have the
>>>>>>>>> pom.xml packaged with the jar file for example.
>>>>>>>>>
>>>>>>>>> Among other things it will cover the following use
cases:
>>>>>>>>> * when someone import a XAR with the standard UI,
automatically
>>>>>>>>> register it in the extension index if it happen to be
an extension
>>>>>>>>> (i.e. if we find extension informations in its
package.xml)
>>>>>>>>> * wiki manager and workspaces can properly register
actual extension
>>>>>>>>> when creating their default template from a XAR the
first time (this
>>>>>>>>> is for example required to be able to upgrade a farm
with EM where
>>>>>>>>> pretty much all the wiki as been created from this
default template)
>>>>>>>>>
>>>>>>>>> In both cases the idea is to support as much current
behaviours as we
>>>>>>>>> can and still be able to use the full power of
Extension Manager.
>>>>>>>>>
>>>>>>>>> There should not be any backward compatibility issue
here since it
>>>>>>>>> does not really change anything in the XAR
structure.
>>>>>>>>>
>>>>>>>>> WDYT ?
>>>>>>>>>
>>>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
5:38 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
Short answer is +1, provide a solution fast, and stay backward compatible.
Longer answer: I do not see how this could really cause an issue when we
need to completely review xar packaging. Maybe we would even change them
fully, and this would be no more a xar, but this could not be discussed
during 4.2, and it could maybe even wait 5.x . In the meantime, we need a
solution, and Thomas propose a smooth and cheap solution, even if I agree
with Vincent that it is not so nice... but the xar format is not so nice,
and we all agree that it need to be refactored.
About the more general debate: How the Maven Repository use pom information
is perfect IMO and should not be changed, since this is the maven way. Each
kind of a repository may have their own way to provide information about
their packages. All Vincent said is valid to be discussed in that context,
and may be different supported way to convey the needed informations, these
are not necessarily mutually exclusives.
On Tue, Aug 28, 2012 at 5:07 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Tue, Aug 28, 2012 at 5:02 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
extension information for the Extension Manager (we even have custom pom
properties for that).
No it's not, it's how Maven Repository provide extension information
for Extension Manager. When you install an extension from XWiki
Repository there is not a single line of code reading at any pom.xml.
so
I'm going to vote +0 for now but I'm still of the view that it isn't the
right place for the future. Let's hope it doesn't cause us more harm (but
it should be ok because removing one or several properties in the future is
going to be roughly the same cost).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On Aug 28, 2012, at 4:55 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
> On Tue, Aug 28, 2012 at 4:37 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>
>> On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>
>>> On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>>
>>>> On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>
>>>>> On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>>>>>>
>>>>>> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>>
>>>>>>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>>>>>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <
vincent(a)massol.net> wrote:
>>>>>>>>>
>>>>>>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<
vincent(a)massol.net> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<
thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi guys,
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to modify a bit the Maven
XAR plugin to add in
the
>>>>>>>>>>>>
package.xml some extension related informations like the
extension id
>>>>>>>>>>>>
and version at the very least.
>>>>>>>>>>>
>>>>>>>>>>> Why not package the pom.xml instead in
META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>>>>>>
>>>>>>>>>> Because it's not supposed as part of XAR
format by existing XAR
>>>>>>>>>> parser, you will get an error because it will
fail to parse it
as a
>>>>>>>>>> document.
The proposal here is to use something that already
exists,
>>>>>>>>>> does not
break anything and is very easy to do.
>>>>>>>>>
>>>>>>>>> I personally much prefer to add META-INF support over
changing
the package.xml format because it's much better aligned with all
other
formats like JAR, EAR, WAR, etc and with the way we handle JAR extensions.
>>>>>>>>
>>>>>>>> I think you don't understand what I mean here. The
issue is not
that
>>>>>>>> it's complex
to support it, adding support in 4.2 for META-INF
will
>>>>>>>> not change the
fact that you will get an error in older version
with
>>>>>>>> your XAR.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> It doesn't look complex to add either, it's a
matter of
excluding META-INF files from the parser and to use the Maven Archiver
(see
http://maven.apache.org/shared/maven-archiver/).
>>>>>>>
>>>>>>> Making the XAR format depends on Maven is not exactly
something
>>>>>>> generic or even very nice. Core extension scanner is looking
at
the
>>>>>>> pom located in jar
file among other things in order to find as
much as
>>>>>>> it can but lets not
forget that this is a hack and nothing else.
>>>>>>
>>>>>> Whatever the solution we need consistency IMO. If your proposal
is
to create an extension.xml file located in META-INF/xwiki and that we would
put in all our extension types then I'm all for it too.
>>>>>>
>>>>>> I don't like mixing extension information with packaging
information. For me package.xml shouldn't contain extension information.
>>>>>
>>>>> It's exactly the same thing. The package.xml file is the XAR way
to
>>>>> provide informations about the file and is generated from the
pom.xml.
>>>>> It already provide the a
subset of extension informations (name,
>>>>> version, license, etc.) so the proposal here is about adding more
>>>>> things.
>>>>
>>>> For me the package.xml should probably even be removed or at least a
lot of information should be removed. There's no point in listing the files
explicitly for example. Same for whether it's a backup pack or not.
>>>>
>>>> And a lot of the information currently in package.xml should be
moved to META-INF/xwiki/extension.xml such as author, license, version,
name, description.
>>>>
>>>> So I'm definitely with you about creating a XWiki-specific
descriptor (not tied to maven) located in META-INF/xwiki/extension.xml for
all our extensions, but beefing up package.xml goes in the wrong direction
IMO.
>>>>
>>>> At the very least I'd like that we agree about where we'd like to
go
(I've made a proposal with META-INF/xwiki/extension.xml) and then discuss
how to get there and what it takes. If it means going through intermediary
steps, then fine, the important part for me being to agree on where we want
to go.
>>>
>>> Maybe but that's a different subject and IMO it sounds like creating a
>>> new packaging format for wiki pages.
>>
>> There are 2 topics:
>> * Create a generic format for all xwiki extensions (the
META-INF/xwiki/extension.xml), nothing to do with wiki pages
>> * Modify the existing XAR format
descriptor (package.xml) to remove
stuff that are 1) not needed (like the list of
files and 2) can be found in
the extension information (i.e. in META-INF/xwiki/extension.xml)
>>
>> So far you/we have decided that the xwiki extension format will be the
pom.xml format which is why we are using it in our JAR file to discover
extensions.
We never decided such thing.
It's a de facto choice since this is currently how our artifacts provide Again the core extension scanner try to
find all it can from the jar located and among other things it check
if there is pom.xml because that's a format in which it can find
extension informations usually but there is others and for some JAR it
does not exists. The only other thing that look at pom.xml is the
Maven Reposirory handler (and I actually plan to move the core scanner
part which looks at pom descriptor to the Maven handler when I get
some time). Extension Manager in general does not officially depends
in any way on Maven, you don't have to build you extension with Maven
for it to be supported by Extension Manager and I hope you will never
have to.
So if you want to start designing a new packaging format no problem
and it's actually listed in
http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManageXWikiPackage
but it's a totally different subject and in no way a priority. The way
standard to provide informations about the package in a XAR is
package.xml so I'm just proposing to add one more informations. You
are talking about packing format that does not have anything to do
with XAR, the fact that you change everything and still call it XAR is
only you point of view.
I know you're on a tight schedule for 4.2 and I don't want to block you
Thanks
-Vincent
>> Based on that it's not logical to invent a new way to add extension
information even if the existing package.xml contains already some
information that happens (by pure coincidence) to be the same as the one
needed by the extension manager (for ex the version in package.xml could be
a completely different version than the extension version).
>>
>> Based on this the logic is to add the pom.xml file to the XAR.
>>
>> Now you said that you didn't think using the Maven format is good.
Fine. This is a change from what we had decided so far and I'm ready to
accept that we may want to dissociate from Maven; hence my proposal about
the META-INF/xwiki/extension.xml file.
>>
>> So we have 2 choices for me:
>> * continue with the current rule of using pom.xml files as containing
extension information
>> * decide to bite the bullet and invent a
new format for holding
extension information
>>
>> Those are the 2 *good* choices for me. Ofc we need to handle backward
compat as best as we can but that's doable.
>>
>> You'd like to do the 3rd choice which IMO is a quick and dirty
solution. I'd accept it but only as a quick hack for 4.2 and that we would
need to correct ASAP.
>>
>>> I need something for 4.2 and
>>> adding the id in package.xml along with the other existing extension
>>> informations is quick, easy, fully retro compatible and does not
>>> really introduce anything new.
>>
>> Sure but it does introduce something new: the new information you add
to
package.xml. And this is exactly like a public API; once it's there we
have to support it and be retro compatible. So we have to be careful
because it's a pain to change after.
>>
>> I'm curious to know what others think about this.
>>
>> Thanks
>> -Vincent
>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> -Vincent
>>>>>>>>>
>>>>>>>>>>> It would be more generic and similar to how
JARs are handled.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> -Vincent
>>>>>>>>>>>
>>>>>>>>>>>> The idea is to be able to know what a XAR
is exactly like we
have the
>>>>>>>>>>>>
pom.xml packaged with the jar file for example.
>>>>>>>>>>>>
>>>>>>>>>>>> Among other things it will cover the
following use cases:
>>>>>>>>>>>> * when someone import a XAR with the
standard UI,
automatically
>>>>>>>>>>>>
register it in the extension index if it happen to be an
extension
>>>>>>>>>>>>
(i.e. if we find extension informations in its package.xml)
>>>>>>>>>>>> * wiki manager and workspaces can
properly register actual
extension
>>>>>>>>>>>>
when creating their default template from a XAR the first
time (this
>>>>>>>>>>>>
is for example required to be able to upgrade a farm with EM
where
>>>>>>>>>>>>
pretty much all the wiki as been created from this default
template)
>>>>>>>>>>>>
>>>>>>>>>>>> In both cases the idea is to support as
much current
behaviours as we
>>>>>>>>>>>>
can and still be able to use the full power of Extension
Manager.
>>>>>>>>>>>>
>>>>>>>>>>>> There should not be any backward
compatibility issue here
since it
>>>>>>>>>> does not
really change anything in the XAR structure.
>>>>>>>>>>
>>>>>>>>>> WDYT ?
>>>>>>>>>>
>>>>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:59 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 4:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
--
Thomas Mortagne
On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
No it's not doable, if you remove the package.xml then it does not
work with older parsers, there is nothing you can do about it.
On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
There are 2 topics:
* Create a generic format for all xwiki extensions (the META-INF/xwiki/extension.xml),
nothing to do with wiki pages
* Modify the existing XAR format descriptor (package.xml) to remove stuff that are 1) not
needed (like the list of files and 2) can be found in the extension information (i.e. in
META-INF/xwiki/extension.xml)
So far you/we have decided that the xwiki extension format will be the pom.xml format
which is why we are using it in our JAR file to discover extensions. Based on that
it's not logical to invent a new way to add extension information even if the existing
package.xml contains already some information that happens (by pure coincidence) to be the
same as the one needed by the extension manager (for ex the version in package.xml could
be a completely different version than the extension version).
Based on this the logic is to add the pom.xml file to the XAR.
Now you said that you didn't think using the Maven format is good. Fine. This is a
change from what we had decided so far and I'm ready to accept that we may want to
dissociate from Maven; hence my proposal about the META-INF/xwiki/extension.xml file.
So we have 2 choices for me:
* continue with the current rule of using pom.xml files as containing extension
information
* decide to bite the bullet and invent a new format for holding extension information
Those are the 2 *good* choices for me. Ofc we need to handle backward compat as best as
we can but that's doable.
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages. On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>> <thomas.mortagne(a)xwiki.com> wrote:
>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>>
>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>
>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>>
>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I would like to modify a bit the Maven XAR plugin to add in
the
>>>>>>> package.xml some extension related informations like the
extension id
>>>>>>> and version at the very least.
>>>>>>
>>>>>> Why not package the pom.xml instead in META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>
>>>>> Because it's not supposed as part of XAR format by existing XAR
>>>>> parser, you will get an error because it will fail to parse it as a
>>>>> document. The proposal here is to use something that already exists,
>>>>> does not break anything and is very easy to do.
>>>>
>>>> I personally much prefer to add META-INF support over changing the
package.xml format because it's much better aligned with all other formats like JAR,
EAR, WAR, etc and with the way we handle JAR extensions.
>>>
>>> I think you don't understand what I mean here. The issue is not that
>>> it's complex to support it, adding support in 4.2 for META-INF will
>>> not change the fact that you will get an error in older version with
>>> your XAR.
>>>
>>>>
>>>> It doesn't look complex to add either, it's a matter of excluding
META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
>>
>> Making the XAR format depends on Maven is not exactly something
>> generic or even very nice. Core extension scanner is looking at the
>> pom located in jar file among other things in order to find as much as
>> it can but lets not forget that this is a hack and nothing else.
>
> Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
>
> I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
It's exactly the same thing. The package.xml file is the XAR way to
provide informations about the file and is generated from the pom.xml.
It already provide the a subset of extension informations (name,
version, license, etc.) so the proposal here is about adding more
things.
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go.
You'd like to do the 3rd choice which IMO is a quick and dirty solution. I'd
accept it but only as a quick hack for 4.2 and that we would need to correct ASAP.
I propose to follow the existing XAR standard.
I need something for 4.2 and
adding the id in package.xml along with the other existing extension
informations is quick, easy, fully retro compatible and does not
really introduce anything new.
Sure but it does introduce something new: the new information you add to package.xml. And
this is exactly like a public API; once it's there we have to support it and be retro
compatible. So we have to be careful because it's a pain to change after.
I'm curious to know what others think about this.
Thanks
-Vincent
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>> It would be more generic and similar to how JARs are
handled.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>> The idea is to be able to know what a XAR is exactly
like we have the
>>>>>>>>> pom.xml packaged with the jar file for example.
>>>>>>>>>
>>>>>>>>> Among other things it will cover the following use
cases:
>>>>>>>>> * when someone import a XAR with the standard UI,
automatically
>>>>>>>>> register it in the extension index if it happen to be
an extension
>>>>>>>>> (i.e. if we find extension informations in its
package.xml)
>>>>>>>>> * wiki manager and workspaces can properly register
actual extension
>>>>>>>>> when creating their default template from a XAR the
first time (this
>>>>>>>>> is for example required to be able to upgrade a farm
with EM where
>>>>>>>>> pretty much all the wiki as been created from this
default template)
>>>>>>>>>
>>>>>>>>> In both cases the idea is to support as much current
behaviours as we
>>>>>>>>> can and still be able to use the full power of
Extension Manager.
>>>>>>>>>
>>>>>>>>> There should not be any backward compatibility issue
here since it
>>>>>>>>> does not really change anything in the XAR
structure.
>>>>>>>>>
>>>>>>>>> WDYT ?
>>>>>>>>>
>>>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:07 p.m.
On Aug 28, 2012, at 4:59 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 4:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I've proposed a solution (granted, I didn't have much time to think about it)
which would work from my pov:
* You package version N of such UI module with XAR plugin version N and you put in the
release notes that starting from version N XAR files must be open with XE N+, which is
logical and the default rule for extensions too. In addition the modified XAR plugin can
handle older formats by checking for existence or non existence of some fields (or for
existence of the extension.xml file).
Thanks
-Vincent
On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
No it's not doable, if you remove the package.xml then it does not
work with older parsers, there is nothing you can do about it. On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
There are 2 topics:
* Create a generic format for all xwiki extensions (the META-INF/xwiki/extension.xml),
nothing to do with wiki pages
* Modify the existing XAR format descriptor (package.xml) to remove stuff that are 1) not
needed (like the list of files and 2) can be found in the extension information (i.e. in
META-INF/xwiki/extension.xml)
So far you/we have decided that the xwiki extension format will be the pom.xml format
which is why we are using it in our JAR file to discover extensions. Based on that
it's not logical to invent a new way to add extension information even if the existing
package.xml contains already some information that happens (by pure coincidence) to be the
same as the one needed by the extension manager (for ex the version in package.xml could
be a completely different version than the extension version).
Based on this the logic is to add the pom.xml file to the XAR.
Now you said that you didn't think using the Maven format is good. Fine. This is a
change from what we had decided so far and I'm ready to accept that we may want to
dissociate from Maven; hence my proposal about the META-INF/xwiki/extension.xml file.
So we have 2 choices for me:
* continue with the current rule of using pom.xml files as containing extension
information
* decide to bite the bullet and invent a new format for holding extension information
Those are the 2 *good* choices for me. Ofc we need to handle backward compat as best as
we can but that's doable.
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
> On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol <vincent(a)massol.net> wrote:
>>
>> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>>
>>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>
>>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>
>>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>>>
>>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I would like to modify a bit the Maven XAR plugin to add
in the
>>>>>>>> package.xml some extension related informations like the
extension id
>>>>>>>> and version at the very least.
>>>>>>>
>>>>>>> Why not package the pom.xml instead in META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>>
>>>>>> Because it's not supposed as part of XAR format by existing
XAR
>>>>>> parser, you will get an error because it will fail to parse it as
a
>>>>>> document. The proposal here is to use something that already
exists,
>>>>>> does not break anything and is very easy to do.
>>>>>
>>>>> I personally much prefer to add META-INF support over changing the
package.xml format because it's much better aligned with all other formats like JAR,
EAR, WAR, etc and with the way we handle JAR extensions.
>>>>
>>>> I think you don't understand what I mean here. The issue is not that
>>>> it's complex to support it, adding support in 4.2 for META-INF will
>>>> not change the fact that you will get an error in older version with
>>>> your XAR.
>>>>
>>>>>
>>>>> It doesn't look complex to add either, it's a matter of
excluding META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
>>>
>>> Making the XAR format depends on Maven is not exactly something
>>> generic or even very nice. Core extension scanner is looking at the
>>> pom located in jar file among other things in order to find as much as
>>> it can but lets not forget that this is a hack and nothing else.
>>
>> Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
>>
>> I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
>
> It's exactly the same thing. The package.xml file is the XAR way to
> provide informations about the file and is generated from the pom.xml.
> It already provide the a subset of extension informations (name,
> version, license, etc.) so the proposal here is about adding more
> things.
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go.
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages. You'd like
to do the 3rd choice which IMO is a quick and dirty solution. I'd accept it but only
as a quick hack for 4.2 and that we would need to correct ASAP.
I propose to follow the existing XAR standard.
>
>> I need something for 4.2 and
>> adding the id in package.xml along with the other existing extension
>> informations is quick, easy, fully retro compatible and does not
>> really introduce anything new.
>
> Sure but it does introduce something new: the new information you add to package.xml.
And this is exactly like a public API; once it's there we have to support it and be
retro compatible. So we have to be careful because it's a pain to change after.
>
> I'm curious to know what others think about this.
>
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>>> It would be more generic and similar to how JARs
are handled.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Vincent
>>>>>>>>>>
>>>>>>>>>>> The idea is to be able to know what a XAR is
exactly like we have the
>>>>>>>>>>> pom.xml packaged with the jar file for
example.
>>>>>>>>>>>
>>>>>>>>>>> Among other things it will cover the
following use cases:
>>>>>>>>>>> * when someone import a XAR with the standard
UI, automatically
>>>>>>>>>>> register it in the extension index if it
happen to be an extension
>>>>>>>>>>> (i.e. if we find extension informations in
its package.xml)
>>>>>>>>>>> * wiki manager and workspaces can properly
register actual extension
>>>>>>>>>>> when creating their default template from a
XAR the first time (this
>>>>>>>>>>> is for example required to be able to upgrade
a farm with EM where
>>>>>>>>>>> pretty much all the wiki as been created from
this default template)
>>>>>>>>>>>
>>>>>>>>>>> In both cases the idea is to support as much
current behaviours as we
>>>>>>>>>>> can and still be able to use the full power
of Extension Manager.
>>>>>>>>>>>
>>>>>>>>>>> There should not be any backward
compatibility issue here since it
>>>>>>>>>>> does not really change anything in the XAR
structure.
>>>>>>>>>>>
>>>>>>>>>>> WDYT ?
>>>>>>>>>>>
>>>>>>>>>>> Here is my +1 
6:04 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 5:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
There are 2 topics:
* Create a generic format for all xwiki extensions (the META-INF/xwiki/extension.xml),
nothing to do with wiki pages
* Modify the existing XAR format descriptor (package.xml) to remove stuff that are 1) not
needed (like the list of files and 2) can be found in the extension information (i.e. in
META-INF/xwiki/extension.xml)
So far you/we have decided that the xwiki extension format will be the pom.xml format
which is why we are using it in our JAR file to discover extensions. Based on that
it's not logical to invent a new way to add extension information even if the existing
package.xml contains already some information that happens (by pure coincidence) to be the
same as the one needed by the extension manager (for ex the version in package.xml could
be a completely different version than the extension version).
Based on this the logic is to add the pom.xml file to the XAR.
Now you said that you didn't think using the Maven format is good. Fine. This is a
change from what we had decided so far and I'm ready to accept that we may want to
dissociate from Maven; hence my proposal about the META-INF/xwiki/extension.xml file.
So we have 2 choices for me:
* continue with the current rule of using pom.xml files as containing extension
information
* decide to bite the bullet and invent a new format for holding extension information
Those are the 2 *good* choices for me. Ofc we need to handle backward compat as best as
we can but that's doable.
You'd like to do the 3rd choice which IMO is a quick and dirty solution. I'd
accept it but only as a quick hack for 4.2 and that we would need to correct ASAP.
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages. On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>> <thomas.mortagne(a)xwiki.com> wrote:
>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>>
>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>
>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>>
>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I would like to modify a bit the Maven XAR plugin to add in
the
>>>>>>> package.xml some extension related informations like the
extension id
>>>>>>> and version at the very least.
>>>>>>
>>>>>> Why not package the pom.xml instead in META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>
>>>>> Because it's not supposed as part of XAR format by existing XAR
>>>>> parser, you will get an error because it will fail to parse it as a
>>>>> document. The proposal here is to use something that already exists,
>>>>> does not break anything and is very easy to do.
>>>>
>>>> I personally much prefer to add META-INF support over changing the
package.xml format because it's much better aligned with all other formats like JAR,
EAR, WAR, etc and with the way we handle JAR extensions.
>>>
>>> I think you don't understand what I mean here. The issue is not that
>>> it's complex to support it, adding support in 4.2 for META-INF will
>>> not change the fact that you will get an error in older version with
>>> your XAR.
>>>
>>>>
>>>> It doesn't look complex to add either, it's a matter of excluding
META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
>>
>> Making the XAR format depends on Maven is not exactly something
>> generic or even very nice. Core extension scanner is looking at the
>> pom located in jar file among other things in order to find as much as
>> it can but lets not forget that this is a hack and nothing else.
>
> Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
>
> I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
It's exactly the same thing. The package.xml file is the XAR way to
provide informations about the file and is generated from the pom.xml.
It already provide the a subset of extension informations (name,
version, license, etc.) so the proposal here is about adding more
things.
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go. I need something for 4.2 and
adding the id in package.xml along with the other existing extension
informations is quick, easy, fully retro compatible and does not
really introduce anything new.
Sure but it does introduce something new: the new information you add to package.xml. And
this is exactly like a public API; once it's there we have to support it and be retro
compatible. So we have to be careful because it's a pain to change after.
I'm curious to know what others think about this.
Thomas is proposing to add some new _optional_ information to the XAR
_descriptor_. If I understood correctly, you don't think the XAR
descriptor is the right place and you propose instead to use a
separate file. More over, you'd like that all supported extension
types use this file. In other words, you don't want the extension
manager to extract information from the descriptor specific to the
extension type but from a different file within that extension. I
think this has two problems in general:
* we need to add support for this separate file for each type of
extension (we control the code of XAR packager but this might not be
the case with other types of extension that we'd want to support in
the future)
* the dedicated file will most probably duplicate information from the
native descriptor (pom.xml, package.xml, etc.)
I'm still +1 for what Thomas proposed.
Thanks,
Marius
Thanks
-Vincent
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>> It would be more generic and similar to how JARs are
handled.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>> The idea is to be able to know what a XAR is exactly
like we have the
>>>>>>>>> pom.xml packaged with the jar file for example.
>>>>>>>>>
>>>>>>>>> Among other things it will cover the following use
cases:
>>>>>>>>> * when someone import a XAR with the standard UI,
automatically
>>>>>>>>> register it in the extension index if it happen to be
an extension
>>>>>>>>> (i.e. if we find extension informations in its
package.xml)
>>>>>>>>> * wiki manager and workspaces can properly register
actual extension
>>>>>>>>> when creating their default template from a XAR the
first time (this
>>>>>>>>> is for example required to be able to upgrade a farm
with EM where
>>>>>>>>> pretty much all the wiki as been created from this
default template)
>>>>>>>>>
>>>>>>>>> In both cases the idea is to support as much current
behaviours as we
>>>>>>>>> can and still be able to use the full power of
Extension Manager.
>>>>>>>>>
>>>>>>>>> There should not be any backward compatibility issue
here since it
>>>>>>>>> does not really change anything in the XAR
structure.
>>>>>>>>>
>>>>>>>>> WDYT ?
>>>>>>>>>
>>>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:29 p.m.
On Aug 28, 2012, at 6:04 PM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
wrote:
On Tue, Aug 28, 2012 at 5:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
It's quite the opposite. Right now, for JAR extensions stored in a Maven Repository we
extract information from the META-INF/maven/.../pom.xml file. We don't control that at
all since it's put there by Maven and in a Maven-controlled format (which we extend by
adding Maven pom properties).
As I've said a few times in this thread, I'm fine to standardize on the Maven POM
format. I'm also fine to have our own format (I called it
META-INF/xwiki/extension.xml). If we have our own format then we do control it.
Also if we use the same strategy for all extensions (be them JAR or XAR) the it's the
opposite to what you say: we need only to implement to logic to read
META-INF/xwiki/extension.xml once whereas now we need a different logic for each type:
* for JAR we read from the META-INF/maven/.../pom.xm
* for XAR we read from package.xml
On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
There are 2 topics:
* Create a generic format for all xwiki extensions (the META-INF/xwiki/extension.xml),
nothing to do with wiki pages
* Modify the existing XAR format descriptor (package.xml) to remove stuff that are 1) not
needed (like the list of files and 2) can be found in the extension information (i.e. in
META-INF/xwiki/extension.xml)
So far you/we have decided that the xwiki extension format will be the pom.xml format
which is why we are using it in our JAR file to discover extensions. Based on that
it's not logical to invent a new way to add extension information even if the existing
package.xml contains already some information that happens (by pure coincidence) to be the
same as the one needed by the extension manager (for ex the version in package.xml could
be a completely different version than the extension version).
Based on this the logic is to add the pom.xml file to the XAR.
Now you said that you didn't think using the Maven format is good. Fine. This is a
change from what we had decided so far and I'm ready to accept that we may want to
dissociate from Maven; hence my proposal about the META-INF/xwiki/extension.xml file.
So we have 2 choices for me:
* continue with the current rule of using pom.xml files as containing extension
information
* decide to bite the bullet and invent a new format for holding extension information
Those are the 2 *good* choices for me. Ofc we need to handle backward compat as best as
we can but that's doable.
You'd like to do the 3rd choice which IMO is a quick and dirty solution. I'd
accept it but only as a quick hack for 4.2 and that we would need to correct ASAP.
On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
> On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol <vincent(a)massol.net> wrote:
>>
>> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>>
>>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>
>>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>
>>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol
<vincent(a)massol.net> wrote:
>>>>>>>
>>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I would like to modify a bit the Maven XAR plugin to add
in the
>>>>>>>> package.xml some extension related informations like the
extension id
>>>>>>>> and version at the very least.
>>>>>>>
>>>>>>> Why not package the pom.xml instead in META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>>
>>>>>> Because it's not supposed as part of XAR format by existing
XAR
>>>>>> parser, you will get an error because it will fail to parse it as
a
>>>>>> document. The proposal here is to use something that already
exists,
>>>>>> does not break anything and is very easy to do.
>>>>>
>>>>> I personally much prefer to add META-INF support over changing the
package.xml format because it's much better aligned with all other formats like JAR,
EAR, WAR, etc and with the way we handle JAR extensions.
>>>>
>>>> I think you don't understand what I mean here. The issue is not that
>>>> it's complex to support it, adding support in 4.2 for META-INF will
>>>> not change the fact that you will get an error in older version with
>>>> your XAR.
>>>>
>>>>>
>>>>> It doesn't look complex to add either, it's a matter of
excluding META-INF files from the parser and to use the Maven Archiver (see
http://maven.apache.org/shared/maven-archiver/).
>>>
>>> Making the XAR format depends on Maven is not exactly something
>>> generic or even very nice. Core extension scanner is looking at the
>>> pom located in jar file among other things in order to find as much as
>>> it can but lets not forget that this is a hack and nothing else.
>>
>> Whatever the solution we need consistency IMO. If your proposal is to create an
extension.xml file located in META-INF/xwiki and that we would put in all our extension
types then I'm all for it too.
>>
>> I don't like mixing extension information with packaging information. For me
package.xml shouldn't contain extension information.
>
> It's exactly the same thing. The package.xml file is the XAR way to
> provide informations about the file and is generated from the pom.xml.
> It already provide the a subset of extension informations (name,
> version, license, etc.) so the proposal here is about adding more
> things.
For me the package.xml should probably even be removed or at least a lot of information
should be removed. There's no point in listing the files explicitly for example. Same
for whether it's a backup pack or not.
And a lot of the information currently in package.xml should be moved to
META-INF/xwiki/extension.xml such as author, license, version, name, description.
So I'm definitely with you about creating a XWiki-specific descriptor (not tied to
maven) located in META-INF/xwiki/extension.xml for all our extensions, but beefing up
package.xml goes in the wrong direction IMO.
At the very least I'd like that we agree about where we'd like to go (I've
made a proposal with META-INF/xwiki/extension.xml) and then discuss how to get there and
what it takes. If it means going through intermediary steps, then fine, the important part
for me being to agree on where we want to go.
Maybe but that's a different subject and IMO it sounds like creating a
new packaging format for wiki pages. I need something for 4.2 and
adding the id in package.xml along with the other existing extension
informations is quick, easy, fully retro compatible and does not
really introduce anything new.
Sure but it does introduce something new: the new information you add to package.xml. And
this is exactly like a public API; once it's there we have to support it and be retro
compatible. So we have to be careful because it's a pain to change after.
I'm curious to know what others think about
this.
Thomas is proposing to add some new _optional_ information to the XAR
_descriptor_. If I understood correctly, you don't think the XAR
descriptor is the right place and you propose instead to use a
separate file. More over, you'd like that all supported extension
types use this file. In other words, you don't want the extension
manager to extract information from the descriptor specific to the
extension type but from a different file within that extension. I
think this has two problems in general:
* we need to add support for this separate file for each type of
extension (we control the code of XAR packager but this might not be
the case with other types of extension that we'd want to support in
the future) * the dedicated file will most probably duplicate
information from the
native descriptor (pom.xml, package.xml, etc.)
Yes that's true for pom.xml but it doesn't really matter. We have 2 choices:
- standardize on the pom.xml format
- use our own format
For package.xml it wouldn't be true because we wouldn't keep the same information
in 2 places. We would have it in extension.xml and not in package.xml which would either
disappear (not needed) or contain some XAR-specific config options, or (third option) we
would allow to provide generic properties in our extension.xml format and the XAR
extension type would have whatever it needs in there.
I'm still +1 for what Thomas proposed.
What I've discussed in this thread is how I view this ideally. Thomas' proposal is
ok for the short term (4.2) without breaking anything existing.
When you say you're +1 do you mean you're +1 for now for 4.2 or even more
generally in the future as the right solution?
Thanks
-Vincent
Thanks,
Marius
>
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>>> It would be more generic and similar to how JARs
are handled.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Vincent
>>>>>>>>>>
>>>>>>>>>>> The idea is to be able to know what a XAR is
exactly like we have the
>>>>>>>>>>> pom.xml packaged with the jar file for
example.
>>>>>>>>>>>
>>>>>>>>>>> Among other things it will cover the
following use cases:
>>>>>>>>>>> * when someone import a XAR with the standard
UI, automatically
>>>>>>>>>>> register it in the extension index if it
happen to be an extension
>>>>>>>>>>> (i.e. if we find extension informations in
its package.xml)
>>>>>>>>>>> * wiki manager and workspaces can properly
register actual extension
>>>>>>>>>>> when creating their default template from a
XAR the first time (this
>>>>>>>>>>> is for example required to be able to upgrade
a farm with EM where
>>>>>>>>>>> pretty much all the wiki as been created from
this default template)
>>>>>>>>>>>
>>>>>>>>>>> In both cases the idea is to support as much
current behaviours as we
>>>>>>>>>>> can and still be able to use the full power
of Extension Manager.
>>>>>>>>>>>
>>>>>>>>>>> There should not be any backward
compatibility issue here since it
>>>>>>>>>>> does not really change anything in the XAR
structure.
>>>>>>>>>>>
>>>>>>>>>>> WDYT ?
>>>>>>>>>>>
>>>>>>>>>>> Here is my +1
11:35 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 6:29 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 28, 2012, at 6:04 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
It's quite the opposite. Right now, for JAR extensions stored in a Maven
Repository we extract information from the META-INF/maven/.../pom.xml file.
We don't control that at all since it's put there by Maven and in a
Maven-controlled format (which we extend by adding Maven pom properties).
As I've said a few times in this thread, I'm fine to standardize on the
Maven POM format. I'm also fine to have our own format (I called it
META-INF/xwiki/extension.xml). If we have our own format then we do control
it.
Also if we use the same strategy for all extensions (be them JAR or XAR)
the it's the opposite to what you say: we need only to implement to logic
to read META-INF/xwiki/extension.xml once whereas now we need a different
logic for each type:
* for JAR we read from the META-INF/maven/.../pom.xm
* for XAR we read from package.xml
Vincent, either I have missed something, or you have, but I do not
understand how you expect to manage all the maven dependencies that we
currently importing as dependencies of our extensions, if you choose to
have our own metadata format only ?
For package.xml it wouldn't be true because we wouldn't keep the same
On Tue, Aug 28, 2012 at 5:37 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>
>>> On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>
>>>> On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>>>>>
>>>>> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>
>>>>>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>>>>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>>>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <
vincent(a)massol.net> wrote:
>>>>>>>>
>>>>>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>>
>>>>>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol <
vincent(a)massol.net> wrote:
>>>>>>>>>>
>>>>>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> I would like to modify a bit the Maven XAR
plugin to add in
the
>>>>>>>>>>>
package.xml some extension related informations like the
extension id
>>>>>>>>>>> and
version at the very least.
>>>>>>>>>>
>>>>>>>>>> Why not package the pom.xml instead in
META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>>>>>
>>>>>>>>> Because it's not supposed as part of XAR format
by existing XAR
>>>>>>>>> parser, you will get an error because it will fail to
parse it
as a
>>>>>>>>> document. The
proposal here is to use something that already
exists,
>>>>>>>>> does not
break anything and is very easy to do.
>>>>>>>>
>>>>>>>> I personally much prefer to add META-INF support over
changing
the package.xml format because it's much better aligned with all
other
formats like JAR, EAR, WAR, etc and with the way we handle JAR extensions.
>>>>>>>
>>>>>>> I think you don't understand what I mean here. The issue
is not
that
>>>>>>> it's complex to
support it, adding support in 4.2 for META-INF
will
>>>>>>> not change the fact
that you will get an error in older version
with
>>>>>>> your XAR.
>>>>>>>
>>>>>>>>
>>>>>>>> It doesn't look complex to add either, it's a
matter of
excluding META-INF files from the parser and to use the Maven Archiver
(see
http://maven.apache.org/shared/maven-archiver/).
>>>>>>
>>>>>> Making the XAR format depends on Maven is not exactly something
>>>>>> generic or even very nice. Core extension scanner is looking at
the
>>>>>> pom located in jar file among other things in order to find as
much as
>>>>>> it can but lets not
forget that this is a hack and nothing else.
>>>>>
>>>>> Whatever the solution we need consistency IMO. If your proposal is
to create an extension.xml file located in META-INF/xwiki and that we would
put in all our extension types then I'm all for it too.
>>>>>
>>>>> I don't like mixing extension information with packaging
information. For me package.xml shouldn't contain extension information.
>>>>
>>>> It's exactly the same thing. The package.xml file is the XAR way to
>>>> provide informations about the file and is generated from the
pom.xml.
>>>> It already provide the a subset
of extension informations (name,
>>>> version, license, etc.) so the proposal here is about adding more
>>>> things.
>>>
>>> For me the package.xml should probably even be removed or at least a
lot of information should be removed. There's no point in listing the files
explicitly for example. Same for whether it's a backup pack or not.
>>>
>>> And a lot of the information currently in package.xml should be moved
to META-INF/xwiki/extension.xml such as author, license, version, name,
description.
>>>
>>> So I'm definitely with you about creating a XWiki-specific descriptor
(not tied to maven) located in META-INF/xwiki/extension.xml for all our
extensions, but beefing up package.xml goes in the wrong direction IMO.
>>>
>>> At the very least I'd like that we agree about where we'd like to go
(I've made a proposal with META-INF/xwiki/extension.xml) and then discuss
how to get there and what it takes. If it means going through intermediary
steps, then fine, the important part for me being to agree on where we want
to go.
>>
>> Maybe but that's a different subject and IMO it sounds like creating a
>> new packaging format for wiki pages.
>
> There are 2 topics:
> * Create a generic format for all xwiki extensions (the
META-INF/xwiki/extension.xml), nothing to do with wiki pages
> * Modify the existing XAR format descriptor
(package.xml) to remove
stuff that are 1) not needed (like the list of files and 2)
can be found in
the extension information (i.e. in META-INF/xwiki/extension.xml)
>
> So far you/we have decided that the xwiki extension format will be the
pom.xml
format which is why we are using it in our JAR file to discover
extensions. Based on that it's not logical to invent a new way to add
extension information even if the existing package.xml contains already
some information that happens (by pure coincidence) to be the same as the
one needed by the extension manager (for ex the version in package.xml
could be a completely different version than the extension version).
>
> Based on this the logic is to add the pom.xml file to the XAR.
>
> Now you said that you didn't think using the Maven format is good.
Fine.
This is a change from what we had decided so far and I'm ready to
accept that we may want to dissociate from Maven; hence my proposal about
the META-INF/xwiki/extension.xml file.
>
> So we have 2 choices for me:
> * continue with the current rule of using pom.xml files as containing
extension information
> * decide to bite the bullet and invent a new
format for holding
extension information
>
> Those are the 2 *good* choices for me. Ofc we need to handle backward
compat
as best as we can but that's doable.
>
> You'd like to do the 3rd choice which IMO is a quick and dirty
solution.
I'd accept it but only as a quick hack for 4.2 and that we would
need to correct ASAP.
>
>> I need something for 4.2 and
>> adding the id in package.xml along with the other existing extension
>> informations is quick, easy, fully retro compatible and does not
>> really introduce anything new.
>
> Sure but it does introduce something new: the new information you add
to
package.xml. And this is exactly like a public API; once it's there we
have to support it and be retro compatible. So we have to be careful
because it's a pain to change after.
I'm curious to know what others think about
this.
Thomas is proposing to add some new _optional_ information to the XAR
_descriptor_. If I understood correctly, you don't think the XAR
descriptor is the right place and you propose instead to use a
separate file. More over, you'd like that all supported extension
types use this file. In other words, you don't want the extension
manager to extract information from the descriptor specific to the
extension type but from a different file within that extension. I
think this has two problems in general:
* we need to add support for this separate file for each type of
extension (we control the code of XAR packager but this might not be
the case with other types of extension that we'd want to support in
the future) * the dedicated file will most probably duplicate
information from the
native descriptor (pom.xml, package.xml, etc.)
Yes that's true for pom.xml but it doesn't really matter. We have 2
choices:
- standardize on the pom.xml format
- use our own format
information in 2 places. We would have it in
extension.xml and not in
package.xml which would either disappear (not needed) or contain some
XAR-specific config options, or (third option) we would allow to provide
generic properties in our extension.xml format and the XAR extension type
would have whatever it needs in there.
Once again, IMO, the way extension are stored, and the way the information
about these extensions are provided to the EM, only depends on the
repository they came from. Extension stored in a maven repository will have
to use the maven way, and therefore store their extension related
information in their pom.xml. Extension coming from other repository may
have other method to provide the same information or not. It is up to the
repository.
The problem of Thomas relate to how standalone XAR could be seen as
extension and registered in the EM when these XAR are imported from outside
EM, and therefore being not installed from a repository. I have seen this
as an edge case, similar to how we register built-in extension installed in
the lib folder.
What you to talk about, is to have a more generic way to support these
standalone extensions, but you seems to apply it globally to all extensions.
IMO, you could not expect or impose that all extension coming from a Maven
repository conform to a unique way of containing meta information, since
these extensions may have been extracted from different repositories. This
would require all built-in jar and all dependencies to be repackaged
properly with the needed metadata, which would simply be counter
productive. This would also reduce the flexibility of the current system.
So, if you really want that, using pom.xml is your only choice.
That said, having a standardized, standalone packaging of extension,
independent of a repository, is something that we should think about, and
in that context, your proposal and remarks make sense to me.
I'm still +1 for what Thomas proposed.
What I've discussed in this thread is how I view this ideally. Thomas'
proposal is ok for the short term (4.2) without breaking anything existing.
When you say you're +1 do you mean you're +1
for now for 4.2 or even more
generally in the future as the right solution?
I am +1 for now and later, that extension package stored as a standalone
XAR, use the package.xml to store additional information denoting this XAR
to be a special extension XAR. It will helps current issues quickly without
breaking anything and it does not prevent to develop later a standalone
packaging for any kind of extension, that provide extension information in
a more common way.
WDYT ? Have I misunderstood the situation ?
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Thanks,
Marius
>
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>>> It would be more generic and similar to how JARs
are handled.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Vincent
>>>>>>>>>>
>>>>>>>>>>> The idea is to be able to know what a XAR is
exactly like we
have the
>>>>>>>>>>>
pom.xml packaged with the jar file for example.
>>>>>>>>>>>
>>>>>>>>>>> Among other things it will cover the
following use cases:
>>>>>>>>>>> * when someone import a XAR with the standard
UI,
automatically
>>>>>>>>>>>
register it in the extension index if it happen to be an
extension
>>>>>>>>>>> (i.e.
if we find extension informations in its package.xml)
>>>>>>>>>>> * wiki manager and workspaces can properly
register actual
extension
>>>>>>>>>>> when
creating their default template from a XAR the first
time (this
>>>>>>>>>>> is
for example required to be able to upgrade a farm with EM
where
>>>>>>>>>>>
pretty much all the wiki as been created from this default
template)
>>>>>>>>>>>
>>>>>>>>>>> In both cases the idea is to support as much
current
behaviours as we
>>>>>>>>>>> can
and still be able to use the full power of Extension
Manager.
>>>>>>>>>>>
>>>>>>>>>>> There should not be any backward
compatibility issue here
since it
>>>>>>>>>>> does
not really change anything in the XAR structure.
>>>>>>>>>>>
>>>>>>>>>>> WDYT ?
>>>>>>>>>>>
>>>>>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
29 Aug
29 Aug
9:29 a.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
On Tue, Aug 28, 2012 at 11:35 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
--
Thomas Mortagne
On Tue, Aug 28, 2012 at 6:29 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Yes we don't care a bit what the hell is stored in the file when the
extension comes from a repository. Providing metadata is the
repository job and it does that in its own format (pom.xml for Maven
Repository, custom REST protocoal for XWiki Repository and many others
for other kind of reposirories) and that's the only standard for real
extensions you install from Extension Manager UI.
On Aug 28, 2012, at 6:04 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
It's quite the opposite. Right now, for JAR extensions stored in a Maven
Repository we extract information from the META-INF/maven/.../pom.xml file.
We don't control that at all since it's put there by Maven and in a
Maven-controlled format (which we extend by adding Maven pom properties).
As I've said a few times in this thread, I'm fine to standardize on the
Maven POM format. I'm also fine to have our own format (I called it
META-INF/xwiki/extension.xml). If we have our own format then we do control
it.
Also if we use the same strategy for all extensions (be them JAR or XAR)
the it's the opposite to what you say: we need only to implement to logic
to read META-INF/xwiki/extension.xml once whereas now we need a different
logic for each type:
* for JAR we read from the META-INF/maven/.../pom.xm
* for XAR we read from package.xml
Vincent, either I have missed something, or you have, but I do not
understand how you expect to manage all the maven dependencies that we
currently importing as dependencies of our extensions, if you choose to
have our own metadata format only ?
For package.xml it wouldn't be true because we wouldn't keep the same
On Tue, Aug 28, 2012 at 5:37 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
>> On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>
>>> On Aug 28, 2012, at 3:44 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>
>>>> On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>>>>>
>>>>> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>
>>>>>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne
>>>>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>>>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol <
vincent(a)massol.net> wrote:
>>>>>>>>
>>>>>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>>
>>>>>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol <
vincent(a)massol.net> wrote:
>>>>>>>>>>
>>>>>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> I would like to modify a bit the Maven XAR
plugin to add in
the
>>>>>>>>>>>
package.xml some extension related informations like the
extension id
>>>>>>>>>>> and
version at the very least.
>>>>>>>>>>
>>>>>>>>>> Why not package the pom.xml instead in
META-INF/maven/* as
it's done by the Maven JAR plugin?
>>>>>>>>>
>>>>>>>>> Because it's not supposed as part of XAR format
by existing XAR
>>>>>>>>> parser, you will get an error because it will fail to
parse it
as a
>>>>>>>>> document. The
proposal here is to use something that already
exists,
>>>>>>>>> does not
break anything and is very easy to do.
>>>>>>>>
>>>>>>>> I personally much prefer to add META-INF support over
changing
the package.xml format because it's much better aligned with all
other
formats like JAR, EAR, WAR, etc and with the way we handle JAR extensions.
>>>>>>>
>>>>>>> I think you don't understand what I mean here. The issue
is not
that
>>>>>>> it's complex to
support it, adding support in 4.2 for META-INF
will
>>>>>>> not change the fact
that you will get an error in older version
with
>>>>>>> your XAR.
>>>>>>>
>>>>>>>>
>>>>>>>> It doesn't look complex to add either, it's a
matter of
excluding META-INF files from the parser and to use the Maven Archiver
(see
http://maven.apache.org/shared/maven-archiver/).
>>>>>>
>>>>>> Making the XAR format depends on Maven is not exactly something
>>>>>> generic or even very nice. Core extension scanner is looking at
the
>>>>>> pom located in jar file among other things in order to find as
much as
>>>>>> it can but lets not
forget that this is a hack and nothing else.
>>>>>
>>>>> Whatever the solution we need consistency IMO. If your proposal is
to create an extension.xml file located in META-INF/xwiki and that we would
put in all our extension types then I'm all for it too.
>>>>>
>>>>> I don't like mixing extension information with packaging
information. For me package.xml shouldn't contain extension information.
>>>>
>>>> It's exactly the same thing. The package.xml file is the XAR way to
>>>> provide informations about the file and is generated from the
pom.xml.
>>>> It already provide the a subset
of extension informations (name,
>>>> version, license, etc.) so the proposal here is about adding more
>>>> things.
>>>
>>> For me the package.xml should probably even be removed or at least a
lot of information should be removed. There's no point in listing the files
explicitly for example. Same for whether it's a backup pack or not.
>>>
>>> And a lot of the information currently in package.xml should be moved
to META-INF/xwiki/extension.xml such as author, license, version, name,
description.
>>>
>>> So I'm definitely with you about creating a XWiki-specific descriptor
(not tied to maven) located in META-INF/xwiki/extension.xml for all our
extensions, but beefing up package.xml goes in the wrong direction IMO.
>>>
>>> At the very least I'd like that we agree about where we'd like to go
(I've made a proposal with META-INF/xwiki/extension.xml) and then discuss
how to get there and what it takes. If it means going through intermediary
steps, then fine, the important part for me being to agree on where we want
to go.
>>
>> Maybe but that's a different subject and IMO it sounds like creating a
>> new packaging format for wiki pages.
>
> There are 2 topics:
> * Create a generic format for all xwiki extensions (the
META-INF/xwiki/extension.xml), nothing to do with wiki pages
> * Modify the existing XAR format descriptor
(package.xml) to remove
stuff that are 1) not needed (like the list of files and 2)
can be found in
the extension information (i.e. in META-INF/xwiki/extension.xml)
>
> So far you/we have decided that the xwiki extension format will be the
pom.xml
format which is why we are using it in our JAR file to discover
extensions. Based on that it's not logical to invent a new way to add
extension information even if the existing package.xml contains already
some information that happens (by pure coincidence) to be the same as the
one needed by the extension manager (for ex the version in package.xml
could be a completely different version than the extension version).
>
> Based on this the logic is to add the pom.xml file to the XAR.
>
> Now you said that you didn't think using the Maven format is good.
Fine.
This is a change from what we had decided so far and I'm ready to
accept that we may want to dissociate from Maven; hence my proposal about
the META-INF/xwiki/extension.xml file.
>
> So we have 2 choices for me:
> * continue with the current rule of using pom.xml files as containing
extension information
> * decide to bite the bullet and invent a new
format for holding
extension information
>
> Those are the 2 *good* choices for me. Ofc we need to handle backward
compat
as best as we can but that's doable.
>
> You'd like to do the 3rd choice which IMO is a quick and dirty
solution.
I'd accept it but only as a quick hack for 4.2 and that we would
need to correct ASAP.
>
>> I need something for 4.2 and
>> adding the id in package.xml along with the other existing extension
>> informations is quick, easy, fully retro compatible and does not
>> really introduce anything new.
>
> Sure but it does introduce something new: the new information you add
to
package.xml. And this is exactly like a public API; once it's there we
have to support it and be retro compatible. So we have to be careful
because it's a pain to change after.
I'm curious to know what others think about
this.
Thomas is proposing to add some new _optional_ information to the XAR
_descriptor_. If I understood correctly, you don't think the XAR
descriptor is the right place and you propose instead to use a
separate file. More over, you'd like that all supported extension
types use this file. In other words, you don't want the extension
manager to extract information from the descriptor specific to the
extension type but from a different file within that extension. I
think this has two problems in general:
* we need to add support for this separate file for each type of
extension (we control the code of XAR packager but this might not be
the case with other types of extension that we'd want to support in
the future) * the dedicated file will most probably duplicate
information from the
native descriptor (pom.xml, package.xml, etc.)
Yes that's true for pom.xml but it doesn't really matter. We have 2
choices:
- standardize on the pom.xml format
- use our own format
information in 2 places. We would have it in
extension.xml and not in
package.xml which would either disappear (not needed) or contain some
XAR-specific config options, or (third option) we would allow to provide
generic properties in our extension.xml format and the XAR extension type
would have whatever it needs in there.
Once again, IMO, the way extension are stored, and the way the information
about these extensions are provided to the EM, only depends on the
repository they came from. Extension stored in a maven repository will have
to use the maven way, and therefore store their extension related
information in their pom.xml. Extension coming from other repository may
have other method to provide the same information or not. It is up to the
repository.
The problem of Thomas relate to how standalone XAR could be seen as
extension and registered in the EM when these XAR are imported from outside
EM, and therefore being not installed from a repository. I have seen this
as an edge case, similar to how we register built-in extension installed in
the lib folder.
What you to talk about, is to have a more generic way to support these
standalone extensions, but you seems to apply it globally to all extensions.
IMO, you could not expect or impose that all extension coming from a Maven
repository conform to a unique way of containing meta information, since
these extensions may have been extracted from different repositories. This
would require all built-in jar and all dependencies to be repackaged
properly with the needed metadata, which would simply be counter
productive. This would also reduce the flexibility of the current system.
So, if you really want that, using pom.xml is your only choice. I'm still +1 for what Thomas proposed.
What I've discussed in this thread is how I view this ideally. Thomas'
proposal is ok for the short term (4.2) without breaking anything existing.
That said, having a standardized, standalone packaging of extension,
independent of a repository, is something that we should think about, and
in that context, your proposal and remarks make sense to me.
You perfectly understood the situation.
When you say you're +1 do you mean you're
+1 for now for 4.2 or even more
generally in the future as the right solution?
I am +1 for now and later, that extension package stored as a standalone
XAR, use the package.xml to store additional information denoting this XAR
to be a special extension XAR. It will helps current issues quickly without
breaking anything and it does not prevent to develop later a standalone
packaging for any kind of extension, that provide extension information in
a more common way.
WDYT ? Have I misunderstood the situation ?
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Thanks,
Marius
>
> Thanks
> -Vincent
>
>>> Thanks
>>> -Vincent
>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>>>> It would be more generic and similar to how JARs
are handled.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Vincent
>>>>>>>>>>
>>>>>>>>>>> The idea is to be able to know what a XAR is
exactly like we
have the
>>>>>>>>>>>
pom.xml packaged with the jar file for example.
>>>>>>>>>>>
>>>>>>>>>>> Among other things it will cover the
following use cases:
>>>>>>>>>>> * when someone import a XAR with the standard
UI,
automatically
>>>>>>>>>>>
register it in the extension index if it happen to be an
extension
>>>>>>>>>>> (i.e.
if we find extension informations in its package.xml)
>>>>>>>>>>> * wiki manager and workspaces can properly
register actual
extension
>>>>>>>>>>> when
creating their default template from a XAR the first
time (this
>>>>>>>>>>> is
for example required to be able to upgrade a farm with EM
where
>>>>>>>>>>>
pretty much all the wiki as been created from this default
template)
>>>>>>>>>>>
>>>>>>>>>>> In both cases the idea is to support as much
current
behaviours as we
>>>>>>>>>>> can
and still be able to use the full power of Extension
Manager.
>>>>>>>>>>>
>>>>>>>>>>> There should not be any backward
compatibility issue here
since it
>>>>>>>>>>> does
not really change anything in the XAR structure.
>>>>>>>>>>>
>>>>>>>>>>> WDYT ?
>>>>>>>>>>>
>>>>>>>>>>> Here is my +1
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
28 Aug
28 Aug
3:03 p.m.
New subject: [xwiki-devs] [VOTE] Add extension related information to XAR package.xml file
+1
Thanks,
Marius
On Tue, Aug 28, 2012 at 2:15 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi guys,
I would like to modify a bit the Maven XAR plugin to add in the
package.xml some extension related informations like the extension id
and version at the very least.
The idea is to be able to know what a XAR is exactly like we have the
pom.xml packaged with the jar file for example.
Among other things it will cover the following use cases:
* when someone import a XAR with the standard UI, automatically
register it in the extension index if it happen to be an extension
(i.e. if we find extension informations in its package.xml)
* wiki manager and workspaces can properly register actual extension
when creating their default template from a XAR the first time (this
is for example required to be able to upgrade a farm with EM where
pretty much all the wiki as been created from this default template)
In both cases the idea is to support as much current behaviours as we
can and still be able to use the full power of Extension Manager.
There should not be any backward compatibility issue here since it
does not really change anything in the XAR structure.
WDYT ?
Here is my +1
Thanks,
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4454
days inactive
4455
days old
25 comments
4 participants
participants (4)
-
Denis Gervalle -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol