You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2023/08/07 15:35:48 UTC
[VOTE] Modularisation, Gradle and source code restructuring
Hello all
Following on the proposal posted as a discussion thread one week ago, a
pull request has been created with the specific changes:
https://github.com/apache/sis/pull/37
Given that this is a big change for Apache SIS developers (but not for
users of the binaries), I think that we need a vote. So this is a vote
for merging the above-cited pull request. I will keep the vote open for
one week, until Monday August 14th.
Martin
Re: [VOTE] Modularisation, Gradle and source code restructuring
Posted by Nicholas Knize <nk...@gmail.com>.
+1
Nicholas Knize, Ph.D., GISP
Principal Engineer - Search | Amazon
Apache Lucene PMC Member and Committer
nknize@apache.org
On Mon, Aug 14, 2023 at 4:08 AM Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
> Le 13/08/2023 à 20:07, Nicholas Knize a écrit :
>
> > +1 as well. Will it be a squash merge or will the merge retain the
> > separate commits for traceability?
> >
> Thanks. I propose to merge as-is with no squash. The current merge
> request is already the result of a lot of rebases and squashes in an
> attempt to separate the commits as logical units of work.
>
> Martin
>
>
>
Re: [VOTE] Modularisation, Gradle and source code restructuring
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 13/08/2023 à 20:07, Nicholas Knize a écrit :
> +1 as well. Will it be a squash merge or will the merge retain the
> separate commits for traceability?
>
Thanks. I propose to merge as-is with no squash. The current merge
request is already the result of a lot of rebases and squashes in an
attempt to separate the commits as logical units of work.
Martin
Re: [VOTE] Modularisation, Gradle and source code restructuring
Posted by Nicholas Knize <nk...@gmail.com>.
+1 as well. Will it be a squash merge or will the merge retain the separate
commits for traceability?
On Sun, Aug 13, 2023, 11:53 AM Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
> Thanks you Johann and Alexis.
>
> I'm +1 too. So if there is no negative vote tomorrow (Monday), I will
> merge Tuesday.
>
> Martin
>
>
> Le 11/08/2023 à 10:25, Alexis Manin a écrit :
>
> > Vote : +1
> >
> > The split between stable and incubator looks like a very good idea.
> >
> > JPMS also seems an important step.
>
>
Re: [VOTE] Modularisation, Gradle and source code restructuring
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Thanks you Johann and Alexis.
I'm +1 too. So if there is no negative vote tomorrow (Monday), I will
merge Tuesday.
Martin
Le 11/08/2023 à 10:25, Alexis Manin a écrit :
> Vote : +1
>
> The split between stable and incubator looks like a very good idea.
>
> JPMS also seems an important step.
Re: [VOTE] Modularisation, Gradle and source code restructuring
Posted by Alexis Manin <am...@apache.org>.
Vote : +1
The split between stable and incubator looks like a very good idea.
JPMS also seems an important step.
Regards,
Le mer. 9 août 2023, 11:55, Johann Sorel <jo...@geomatys.com> a
écrit :
> I'm fine with JPMS. +1
> It will be great with jlink and graalvm for standalone applications.
>
> I understand that gradle is necessary, until a better build tool comes
> up, so I'm okay with it being merged.
>
> Johann Sorel
>
>
>
> Le 09/08/2023 à 11:10, Martin Desruisseaux a écrit :
> > Hello Johann
> >
> > Thank for your vote. So in my understanding it can be split as below:
> >
> > * Source code restructuring: +1
> > * JPMS modularisation: not voted
> > * Migration to Gradle: -1
> >
> > Unfortunately those 3 topics cannot be separated. I would also have
> > liked a simpler solution than Gradle, but I'm not aware of any of
> > them. A constraint is that it must be a build tools supported by IDE,
> > and on Apache NetBeans side there is only three: Ant, Maven and Gradle.
> >
> > It would be nice if IDE makers could agree on a standard set of
> > interfaces for plugin an arbitrary build tools to an IDE, something
> > like the "Open Test Alliance for the JVM" created for unit tests [1].
> >
> > Martin
> >
> > [1]https://github.com/ota4j-team/opentest4j
> >
> >
> > Le 09/08/2023 à 10:02, Johann Sorel a écrit :
> >
> >> My vote is neither +1 or -1.
> >>
> >> +1 :
> >> Better module management and the side effect of future incubator
> >> modules.
> >>
> >> -1 :
> >> Gradle, I have a very limited experience with it and will surely have
> >> a hard time with it,
> >> My concerns are only related to a deep personal dislike of this build
> >> tool, both the script syntax and the way things are managed/unordered.
> >> I won't argument on it since this is not the place, maybe with time I
> >> will come to like it ... or not ...
> >>
> >> So my vote is 0.
> >
>
Re: [VOTE] Modularisation, Gradle and source code restructuring
Posted by Johann Sorel <jo...@geomatys.com>.
I'm fine with JPMS. +1
It will be great with jlink and graalvm for standalone applications.
I understand that gradle is necessary, until a better build tool comes
up, so I'm okay with it being merged.
Johann Sorel
Le 09/08/2023 à 11:10, Martin Desruisseaux a écrit :
> Hello Johann
>
> Thank for your vote. So in my understanding it can be split as below:
>
> * Source code restructuring: +1
> * JPMS modularisation: not voted
> * Migration to Gradle: -1
>
> Unfortunately those 3 topics cannot be separated. I would also have
> liked a simpler solution than Gradle, but I'm not aware of any of
> them. A constraint is that it must be a build tools supported by IDE,
> and on Apache NetBeans side there is only three: Ant, Maven and Gradle.
>
> It would be nice if IDE makers could agree on a standard set of
> interfaces for plugin an arbitrary build tools to an IDE, something
> like the "Open Test Alliance for the JVM" created for unit tests [1].
>
> Martin
>
> [1]https://github.com/ota4j-team/opentest4j
>
>
> Le 09/08/2023 à 10:02, Johann Sorel a écrit :
>
>> My vote is neither +1 or -1.
>>
>> +1 :
>> Better module management and the side effect of future incubator
>> modules.
>>
>> -1 :
>> Gradle, I have a very limited experience with it and will surely have
>> a hard time with it,
>> My concerns are only related to a deep personal dislike of this build
>> tool, both the script syntax and the way things are managed/unordered.
>> I won't argument on it since this is not the place, maybe with time I
>> will come to like it ... or not ...
>>
>> So my vote is 0.
>
Re: [VOTE] Modularisation, Gradle and source code restructuring
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Johann
Thank for your vote. So in my understanding it can be split as below:
* Source code restructuring: +1
* JPMS modularisation: not voted
* Migration to Gradle: -1
Unfortunately those 3 topics cannot be separated. I would also have
liked a simpler solution than Gradle, but I'm not aware of any of them.
A constraint is that it must be a build tools supported by IDE, and on
Apache NetBeans side there is only three: Ant, Maven and Gradle.
It would be nice if IDE makers could agree on a standard set of
interfaces for plugin an arbitrary build tools to an IDE, something like
the "Open Test Alliance for the JVM" created for unit tests [1].
Martin
[1]https://github.com/ota4j-team/opentest4j
Le 09/08/2023 à 10:02, Johann Sorel a écrit :
> My vote is neither +1 or -1.
>
> +1 :
> Better module management and the side effect of future incubator modules.
>
> -1 :
> Gradle, I have a very limited experience with it and will surely have
> a hard time with it,
> My concerns are only related to a deep personal dislike of this build
> tool, both the script syntax and the way things are managed/unordered.
> I won't argument on it since this is not the place, maybe with time I
> will come to like it ... or not ...
>
> So my vote is 0.
Re: [VOTE] Modularisation, Gradle and source code restructuring
Posted by Johann Sorel <jo...@geomatys.com>.
Hello,
My vote is neither +1 or -1.
+1 :
Better module management and the side effect of future incubator modules.
-1 :
Gradle, I have a very limited experience with it and will surely have a
hard time with it,
My concerns are only related to a deep personal dislike of this build
tool, both the script syntax and the way things are managed/unordered.
I won't argument on it since this is not the place, maybe with time I
will come to like it ... or not ...
So my vote is 0.
Johann Sorel
Le 07/08/2023 à 17:35, Martin Desruisseaux a écrit :
> Hello all
>
> Following on the proposal posted as a discussion thread one week ago,
> a pull request has been created with the specific changes:
>
> https://github.com/apache/sis/pull/37
>
> Given that this is a big change for Apache SIS developers (but not for
> users of the binaries), I think that we need a vote. So this is a vote
> for merging the above-cited pull request. I will keep the vote open
> for one week, until Monday August 14th.
>
> Martin
>
>