Re: Question for java/eclipse build

...coming back and asking for advice how to handle that the build of 
java/eclipse depends on the version of maven39.  The new eclipse 4.39 
port build on quaterly installed depended packages is fine with maven39 
version 3.9.12 but breaks with version 3.9.13 - that is the same for 
older eclipse version 4.38...  The architecture like aarch64 or amd64 
does not matter.

To build I made a repository https://github.com/NorbertXYZ/eclipse-maven 
on github getting the maven dependencies...  So the build process does 
not download files.

Thanks for remarks - I am not clear how to handle this a good way, my 
approach of taking a prepared FreeBSD *.tar.gz file is not to a good idea.

Regards, Norbert


On 3/15/26 06:54, Norbert Grundmann wrote:
> thanks.  So I will keep "the old" way and integrate that there is a 
> maven upgrade which affects newer builds...
>
> Regards, Norbert
>
> On 3/14/26 22:09, Mark Millard wrote:
>> On 3/14/26 08:32, Norbert Grundmann wrote:
>>> Hello Ronald,
>>>
>>> thanks for the comments...  :-)
>>>
>>> I think I will take another approach to build eclipse in future on
>>> FreeBSD.  About 2-3 year ago I made a lot patches to make version 4.32
>>> work - the previous one was 4.24.  It took a lot of hours. After months
>>> someone took over and created a github repository with FreeBSD stuff,
>>> which I took as the basis.  The maintainer of that repo also creates
>>> *.tar.gz files which contain a full FreeBSD compilation / package, but
>>> not usable the pkg way.
>> [My notes/questions below are general/generic, not based in a detailed
>> analysis of java/eclipse details.]
>>
>> Such a file exists that includes the compilation/package for each and
>> every combination of the following? [as things stand now]:
>>
>> ) supported arch for the port-package
>>    (amd64 vs. aarch64 vs. i386 . . .)
>>
>> ) quarterly [2026Q1] (all but main below)
>>    vs. latest (all 4 of the below, including main)
>>
>> ) 13.5, 14.3 (14.4 next), 15.0 (15.1 next), and main [so: 16.0 for now]
>>
>> Even limited to tier 1 platforms (amd64 and aarch64) that is 2*(3+4)==14
>> combinations that each have a separate port-package built and
>> distributed by the official FreeBSD build servers. Are all of those 
>> covered?
>>
>> (i386 is still having port-packages built for 13.5 and 14.3 as well.
>> armv7 and the rest are not building such at all, according to
>> <https://people.freebsd.org/~dbaio/pkg-master-report.html> and what it
>> shows for " latest " and " quarterly ", no _ in those Set names.)
>>
>> And, different FreeBSD build servers can use different versions of the
>> port-tree's in overlapping time frames for build activity. So each
>> combination can get into dealing with that type of distinction as well.
>>
>> Are the *.tar.gz based on using the same OPTIONS settings as for
>> official builds? What about other configuration details that might
>> change the build results?
>>
>>> So why recompile?
>> See above and more later below.
>>
>>> I want to take his *.tar.gz
>>> file, extract and do the needed post-install steps.  The end should a
>>> "normal" package usable for FreeBSD :-)
>>>
>>> The first steps of this approach seems to work...  I would like to 
>>> check
>>> before I submit and before other people would confirm, that it works.
>>>
>>> What do you think?  This way is more easy and does not use a long
>>> compilation time - just seconds for download and prepare.  And it is
>>> less error lasting ;-)
>> I doubt that taking externally built binaries not built by the FreeBSD
>> port-package build servers from a port that uses source code would be an
>> acceptable security risk for the official FreeBSD ports folks to 
>> allow such.
>>
>> Also, it is not obvious that an externally built port-package is always
>> built in a fully compatible way with the officially built dependencies
>> that would be involved in each and every official bulk build. A similar
>> point goes for various combinations listed above possibly using
>> different tool chains to do builds. Also, how would the update timing
>> manage to match with the FreeBSD build server bulk build runs for each
>> of those combinations listed earlier? (They various combinations are not
>> synchronized and, overall, span widely distinct build time frames.)
>>
>> Some port-packages that have java/eclipse as a dependency may also
>> otherwise depend on some of the same dependencies that java/eclipse
>> does. Mismatched versions of those need not be coherent for overall
>> operation to actually run and work.
>>
>> At various times, quarterly and latest need not match for what versions
>> of dependencies and/or tool-chains are needed.
>>
>> There is a lot involved in keeping the official port-package build
>> combinations operational. Things to not arbitrarily mix and match in a
>> working way.
>>
>>> Of course I will depend on this github repository and data.  But that I
>>> did the last versions, too...
>>>
>>> Regards, Norbert
>>>
>>> On 3/13/26 13:52, Ronald Klop wrote:
>>>> Rereading your mail I saw some more concerns you mention.
>>>>
>>>> 1. When developing your port for main it can be easier to install
>>>> dependencies for main also. That gives consistency to what is 
>>>> upstream.
>>>> 2. As long as the maintainer of maven39 does not merge the changes to
>>>> the quarterly branch, you don't need to do anything for quarterly. But
>>>> keep the 4.38 tag unchanged in github.
>>>> 3. Your https://github.com/NorbertXYZ/eclipse repo has a nice
>>>> README.md, maybe add something similar to the eclipse-maven repo with
>>>> instructions to your future self on how you did things. 😀 I totally
>>>> recognize going back to some project years later and wondering how
>>>> things worked.
>>>>
>>>> If you get stuck, there are probably some people here or on java@ that
>>>> want to help further.
>>>>
>>>> NB: it can really help to keep ports@ in the cc:, if you want feedback
>>>> from others too.
>>>>
>>>> Regards,
>>>> Ronald.
>>>>
>>>>
>>
>

-- 
I love penguins at the south pole, windows in my house and apples on my tree, but not in my computer :)