You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Antonio <an...@vieiro.net> on 2017/10/29 09:48:19 UTC
Centralized external-binary versions?
Hi all,
Currently NetBeans modules define themselves the exact version of
third-party binaries, for instance:
netbinox depends on org.eclipse.osgi_3.9.1.v20140110-1610
and
o.eclipse.core.runtime depends on org.eclipse.core.runtime-3.7.0
Would it be a good idea to specify the exact versions of these in a
separate, centralized, release-specific version file?
I was thinking of defining some centralized properties files like [1]
that we could use to select appropriate, coherent versions of
third-party software for different modules at once. This will ensure
selected versions work well together.
Modules could refer then to binaries by a token (say
"org.eclipse.core.contenttype") and forget about specific versions
themselves.
The DownloadBinaries.java ant task could then use these properties files
to download proper versions.
Opnions? Should I give this a go?
Thanks,
Antonio
[1]
A sample properties file defining the exact versions of modules
o.eclipse.core.*, netbinox and o.eclipse.equinox.*
These versions are known to work properly together.
The properties file defines an alias ("org.eclipse.core.contenttype")
mapped to a SHA-1 hash and a Maven coordinate
("22CC2EBF3A23003F646323CDA38888F31CA6FD15
org.eclipse.platform:org.eclipse.core.contenttype:3.6.0"), just like in
external/binaries-list
org.eclipse.core.contenttype=22CC2EBF3A23003F646323CDA38888F31CA6FD15
org.eclipse.platform:org.eclipse.core.contenttype:3.6.0
org.eclipse.core.jobs=591A398580D6DFECDA2CA18EDA1A176C79875B7C
org.eclipse.platform:org.eclipse.core.jobs:3.9.0
org.eclipse.core.net=60A0B8927D017917546A76F091636DA4DA421DC9
org.eclipse.platform:org.eclipse.core.net:1.3.100
org.eclipse.core.runtime=5A1B57E5C1753858B3FF36876014A547EE608129
org.eclipse.platform:org.eclipse.core.runtime:3.13.0
org.eclipse.equinox.app=04C01F677E982499789FFA78B628EA67693DB949
org.eclipse.platform:org.eclipse.equinox.app:1.3.400
org.eclipse.equinox.common=A22125896FF8E25CE913371F54898AF733953ECB
org.eclipse.platform:org.eclipse.equinox.common:3.9.0
org.eclipse.equinox.preferences=78F9996FE3EAFA560A09EEE083C22154C689FFE1
org.eclipse.platform:org.eclipse.equinox.preferences:3.7.0
org.eclipse.equinox.registry=9874E42C373D8F90338DBB9A38DAB1DD81EFFFB5
org.eclipse.platform:org.eclipse.equinox.registry:3.7.0
org.eclipse.equinox.security=34FF7FB0878EE4297A6E99E5223D1F74D87D9C8D
org.eclipse.platform:org.eclipse.equinox.security:1.2.300
org.eclipse.osgi=D06B54D6947E5956694DEAE4AFEC4538711A7D08
org.eclipse.platform:org.eclipse.osgi:3.12.0
Re: Centralized external-binary versions?
Posted by Antonio <an...@vieiro.net>.
On 29/10/17 22:45, Antonio wrote:
> So I'm afraid we'll have to use repos at eclipse nexus. I'll concentrate
> on that in the coming days. Will keep you posted.
>
See PR#204 for an example: we could use an "eclipse//" prefix (or a set
of prefixes) in the external/binaries_list to download binaries from
other repos.
In this case the exact repository is "acceleo-releases" at [2], and the
netbinox binary is downloaded from there.
If you think the approach is good enough then I'll try to build a map of
repositories/binaries for the rest of binaries we need
(o.eclipse.equinox.* / o.eclipse.core.* / o.eclipse.mylyn.*).
Cheers,
Antonio
[1] https://github.com/apache/incubator-netbeans/pull/204
[2]
https://repo.eclipse.org/service/local/repositories/acceleo-releases/content/
Re: Centralized external-binary versions?
Posted by Antonio <an...@vieiro.net>.
Hi,
There's no need to modify any dependencies, all should be ok. Sorry for
the misunderstanding.
The main problem is that many libraries cannot be found in Maven
central. I thought we could use the latest binaries that are indeed in
Maven central, but after some experiments that's going to be a hard task
(*).
So I'm afraid we'll have to use repos at eclipse nexus. I'll concentrate
on that in the coming days. Will keep you posted.
Cheers,
Antonio
(*) netbinox, for instance, will have to be modified to adopt any higher
version of org.eclipse.osgi. APIs have changed a lot.
On 29/10/17 20:24, Matthias Bläsing wrote:
> Hey Antonio,
>
> Am Sonntag, den 29.10.2017, 10:48 +0100 schrieb Antonio:
>> Currently NetBeans modules define themselves the exact version of
>> third-party binaries, for instance:
>>
>> netbinox depends on org.eclipse.osgi_3.9.1.v20140110-1610
>> and
>> o.eclipse.core.runtime depends on org.eclipse.core.runtime-3.7.0
>>
>> Would it be a good idea to specify the exact versions of these in a
>> separate, centralized, release-specific version file?
>
> I would not try to reinvent the wheel right now. What I would try:
>
> - create a libs.eclipseruntime
> - let that hold the binaries
> - modify o.eclipse.core.runtime to depended on that
> - modify nebinox to depend on that
>
> or let netbinox depend on o.eclipse.core.runtime.
>
> Greetings
>
> Matthias
>
Re: Centralized external-binary versions?
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hey Antonio,
Am Sonntag, den 29.10.2017, 10:48 +0100 schrieb Antonio:
> Currently NetBeans modules define themselves the exact version of
> third-party binaries, for instance:
>
> netbinox depends on org.eclipse.osgi_3.9.1.v20140110-1610
> and
> o.eclipse.core.runtime depends on org.eclipse.core.runtime-3.7.0
>
> Would it be a good idea to specify the exact versions of these in a
> separate, centralized, release-specific version file?
I would not try to reinvent the wheel right now. What I would try:
- create a libs.eclipseruntime
- let that hold the binaries
- modify o.eclipse.core.runtime to depended on that
- modify nebinox to depend on that
or let netbinox depend on o.eclipse.core.runtime.
Greetings
Matthias
Re: Centralized external-binary versions?
Posted by Antonio Vieiro <an...@vieiro.net>.
Ok. Then let’s go ahead.
Expect a PR for netbinox/o.eclipse.equinox.*/o.eclipse.core.* in a few days. Probably upgraded to the latest Eclipse 4.7 binaries.
I imagine this is going to require some thorough testing.
Cheers,
Antonio
> El 29 oct 2017, a las 12:11, Geertjan Wielenga <ge...@googlemail.com> escribió:
>
> Thanks for thinking up this idea and to me it is a good one and makes sense.
>
> Gj
>
> On Sunday, October 29, 2017, Antonio <an...@vieiro.net> wrote:
>
>> Hi all,
>>
>> Currently NetBeans modules define themselves the exact version of
>> third-party binaries, for instance:
>>
>> netbinox depends on org.eclipse.osgi_3.9.1.v20140110-1610
>> and
>> o.eclipse.core.runtime depends on org.eclipse.core.runtime-3.7.0
>>
>> Would it be a good idea to specify the exact versions of these in a
>> separate, centralized, release-specific version file?
>>
>> I was thinking of defining some centralized properties files like [1] that
>> we could use to select appropriate, coherent versions of third-party
>> software for different modules at once. This will ensure selected versions
>> work well together.
>>
>> Modules could refer then to binaries by a token (say
>> "org.eclipse.core.contenttype") and forget about specific versions
>> themselves.
>>
>> The DownloadBinaries.java ant task could then use these properties files
>> to download proper versions.
>>
>> Opnions? Should I give this a go?
>>
>> Thanks,
>> Antonio
>>
>> [1]
>> A sample properties file defining the exact versions of modules
>> o.eclipse.core.*, netbinox and o.eclipse.equinox.*
>>
>> These versions are known to work properly together.
>>
>> The properties file defines an alias ("org.eclipse.core.contenttype")
>> mapped to a SHA-1 hash and a Maven coordinate ("22CC2EBF3A23003F646323CDA38888F31CA6FD15
>> org.eclipse.platform:org.eclipse.core.contenttype:3.6.0"), just like in
>> external/binaries-list
>>
>> org.eclipse.core.contenttype=22CC2EBF3A23003F646323CDA38888F31CA6FD15
>> org.eclipse.platform:org.eclipse.core.contenttype:3.6.0
>> org.eclipse.core.jobs=591A398580D6DFECDA2CA18EDA1A176C79875B7C
>> org.eclipse.platform:org.eclipse.core.jobs:3.9.0
>> org.eclipse.core.net=60A0B8927D017917546A76F091636DA4DA421DC9
>> org.eclipse.platform:org.eclipse.core.net:1.3.100
>> org.eclipse.core.runtime=5A1B57E5C1753858B3FF36876014A547EE608129
>> org.eclipse.platform:org.eclipse.core.runtime:3.13.0
>> org.eclipse.equinox.app=04C01F677E982499789FFA78B628EA67693DB949
>> org.eclipse.platform:org.eclipse.equinox.app:1.3.400
>> org.eclipse.equinox.common=A22125896FF8E25CE913371F54898AF733953ECB
>> org.eclipse.platform:org.eclipse.equinox.common:3.9.0
>> org.eclipse.equinox.preferences=78F9996FE3EAFA560A09EEE083C22154C689FFE1
>> org.eclipse.platform:org.eclipse.equinox.preferences:3.7.0
>> org.eclipse.equinox.registry=9874E42C373D8F90338DBB9A38DAB1DD81EFFFB5
>> org.eclipse.platform:org.eclipse.equinox.registry:3.7.0
>> org.eclipse.equinox.security=34FF7FB0878EE4297A6E99E5223D1F74D87D9C8D
>> org.eclipse.platform:org.eclipse.equinox.security:1.2.300
>> org.eclipse.osgi=D06B54D6947E5956694DEAE4AFEC4538711A7D08
>> org.eclipse.platform:org.eclipse.osgi:3.12.0
>>
>>
Re: Centralized external-binary versions?
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Thanks for thinking up this idea and to me it is a good one and makes sense.
Gj
On Sunday, October 29, 2017, Antonio <an...@vieiro.net> wrote:
> Hi all,
>
> Currently NetBeans modules define themselves the exact version of
> third-party binaries, for instance:
>
> netbinox depends on org.eclipse.osgi_3.9.1.v20140110-1610
> and
> o.eclipse.core.runtime depends on org.eclipse.core.runtime-3.7.0
>
> Would it be a good idea to specify the exact versions of these in a
> separate, centralized, release-specific version file?
>
> I was thinking of defining some centralized properties files like [1] that
> we could use to select appropriate, coherent versions of third-party
> software for different modules at once. This will ensure selected versions
> work well together.
>
> Modules could refer then to binaries by a token (say
> "org.eclipse.core.contenttype") and forget about specific versions
> themselves.
>
> The DownloadBinaries.java ant task could then use these properties files
> to download proper versions.
>
> Opnions? Should I give this a go?
>
> Thanks,
> Antonio
>
> [1]
> A sample properties file defining the exact versions of modules
> o.eclipse.core.*, netbinox and o.eclipse.equinox.*
>
> These versions are known to work properly together.
>
> The properties file defines an alias ("org.eclipse.core.contenttype")
> mapped to a SHA-1 hash and a Maven coordinate ("22CC2EBF3A23003F646323CDA38888F31CA6FD15
> org.eclipse.platform:org.eclipse.core.contenttype:3.6.0"), just like in
> external/binaries-list
>
> org.eclipse.core.contenttype=22CC2EBF3A23003F646323CDA38888F31CA6FD15
> org.eclipse.platform:org.eclipse.core.contenttype:3.6.0
> org.eclipse.core.jobs=591A398580D6DFECDA2CA18EDA1A176C79875B7C
> org.eclipse.platform:org.eclipse.core.jobs:3.9.0
> org.eclipse.core.net=60A0B8927D017917546A76F091636DA4DA421DC9
> org.eclipse.platform:org.eclipse.core.net:1.3.100
> org.eclipse.core.runtime=5A1B57E5C1753858B3FF36876014A547EE608129
> org.eclipse.platform:org.eclipse.core.runtime:3.13.0
> org.eclipse.equinox.app=04C01F677E982499789FFA78B628EA67693DB949
> org.eclipse.platform:org.eclipse.equinox.app:1.3.400
> org.eclipse.equinox.common=A22125896FF8E25CE913371F54898AF733953ECB
> org.eclipse.platform:org.eclipse.equinox.common:3.9.0
> org.eclipse.equinox.preferences=78F9996FE3EAFA560A09EEE083C22154C689FFE1
> org.eclipse.platform:org.eclipse.equinox.preferences:3.7.0
> org.eclipse.equinox.registry=9874E42C373D8F90338DBB9A38DAB1DD81EFFFB5
> org.eclipse.platform:org.eclipse.equinox.registry:3.7.0
> org.eclipse.equinox.security=34FF7FB0878EE4297A6E99E5223D1F74D87D9C8D
> org.eclipse.platform:org.eclipse.equinox.security:1.2.300
> org.eclipse.osgi=D06B54D6947E5956694DEAE4AFEC4538711A7D08
> org.eclipse.platform:org.eclipse.osgi:3.12.0
>
>
Re: Centralized external-binary versions?
Posted by Antonio Vieiro <an...@vieiro.net>.
Thanks for this, Yaroslav.
This is exactly the kind of explanation I was looking for.
From my point of view this is a very important architectural decision
and it is important to a) state it clearly, b) adhere to it and c)
make sure everybody adheres to it.
Cheers,
Antonio
2017-10-30 9:53 GMT+01:00 Jaroslav Tulach <ja...@gmail.com>:
> 2017-10-29 10:48 GMT+01:00 Antonio <an...@vieiro.net>:
>
>> Hi all,
>>
>> Currently NetBeans modules define themselves the exact version of
>> third-party binaries, for instance:
>>
>> netbinox depends on org.eclipse.osgi_3.9.1.v20140110-1610
>> and
>> o.eclipse.core.runtime depends on org.eclipse.core.runtime-3.7.0
>>
>> Would it be a good idea to specify the exact versions of these in a
>> separate, centralized, release-specific version file?
>>
>
> -1
>
> I think this is a bad idea as NetBeans and its build system is designed to
> be modular. Having a single centralized location to specify something which
> is not essential for the whole project goes against the modularity. Each
> external library is wrapped in its module. It is responsibility of the
> module to provide proper version of the library. It is responsibility of
> the module to evolve its own version in correspondence with changes in the
> library it wraps.
>
> The consistency of the whole system is kept by versioning of the individual
> modules. Not by a central configuration file which keeps all the versions.
> -jt
Re: Centralized external-binary versions?
Posted by Jaroslav Tulach <ja...@gmail.com>.
2017-10-29 10:48 GMT+01:00 Antonio <an...@vieiro.net>:
> Hi all,
>
> Currently NetBeans modules define themselves the exact version of
> third-party binaries, for instance:
>
> netbinox depends on org.eclipse.osgi_3.9.1.v20140110-1610
> and
> o.eclipse.core.runtime depends on org.eclipse.core.runtime-3.7.0
>
> Would it be a good idea to specify the exact versions of these in a
> separate, centralized, release-specific version file?
>
-1
I think this is a bad idea as NetBeans and its build system is designed to
be modular. Having a single centralized location to specify something which
is not essential for the whole project goes against the modularity. Each
external library is wrapped in its module. It is responsibility of the
module to provide proper version of the library. It is responsibility of
the module to evolve its own version in correspondence with changes in the
library it wraps.
The consistency of the whole system is kept by versioning of the individual
modules. Not by a central configuration file which keeps all the versions.
-jt