-
|
We have our own fork with some modifications. I try to update this to the latest BIRT version once or twice a year or so, but sometimes, the changes in the official BIRT are more than I can test, so I want eg to cherry-pick only a handful of commits. I know how this can be done with Git and my source code looks the way I want it. But in many cases, I am not able to build, and I think the reason for this is that the For example, yesterday I performed this work for a branch I last built in February 2024 (and it was up-to-date with master then), and referenced the repository ... which no longer exists. I changed this line to and had to fix some issues in several MANIFEST.MF files caused by the renaming of This way I was able to run the All-In-One from within Eclipse, but the Maven build still failed (complained about JustJ version): [ERROR] Cannot resolve target definition: Similar problems occur when one tries to build an older BIRT release from source (at least without a Nexus server). My questions are:
I guess the suffix
If the file system or repo-software that is used internally deduplicates BLOBs, keeping it (instead of deleting it) should be no problem.
Note: I'm not even talking about reproducible builds, which would mean that the build artefacts are bit-wise identical everytime they are built. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 7 replies
-
The terms of the EPL require you to make such modifications public. 😨
Note that for the most recent releases I've been stabilizing the target platform fix repository locations: The only repo left with moving content is this one: https://download.eclipse.org/justj/jres/21/updates/release/latest Because I generally expect that no matter when one builds one will want the latest Java release with the latest CVE fixes.
In the middle of a release cycle there will be many update sites with content that changes over time.
Yes, such as this one, which is actually deleted after the release.
To ship quality result we should generally try to ship with the latest version of every dependency. The those dependencies decide to rename their bundles is beyond our control. Generally using package imports instead of bundle requirements helps avoid that, but the code base how it is.
I'm not sure which update sites have for that. These two sites should generally always work:
There was just a new release of Java 21 yesterday so that sites have new content today.
The final commits at the end of the release cycle strive to do that.
Hopefully yes. But the target is generated so it's possible (but not very likely) that such a simple change is not sufficient.
Yes, that's how the Platform does it.
Use the URLs I showed above.
Because all such content is out-dated pre-release content. Even for BIRT, one nightly build is basically deleted every time there is a new nightly build and all the milestones are deleted when new version is started. But we do it a little more nicely so that there are stable "latest" repository URLs that will always work. The Platform does not do it this way.
All this is just content in a plain old file system served by a plain old http server.
I've tried to stabilize the target platform at the end of the release so that there is a stable starting/ending point.
I think so, but in the end, that's not my problem because we don't provide maintenance releases. There's more than enough to do already.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Ed, for your answers.
They are of course: https://gitub.com/triestram-partner/birt
But you overwrote this change with 9d4731c "Prepare for the 4.18 release": The target file contains 4.34-I-builds again!
As a default, that expectation is certainly ok.
Fun fact: Just yesterday, one of our Eclipse RCP experts told me that an external consultant told him exactly this ...
... and I told him that I thought that the BIRT project probably uses best practices. Now I stand corrected. Maybe it was best practice when BIRT was started decades ago.
Of course, I know. Regarding JustJ, I'll try your hint. |
Beta Was this translation helpful? Give feedback.
-
Yes, of course. During ongoing release cycle we build against all the latest dependencies including the Platform's latest I-builds. It's only at the end of the cycle that projects produce permanent stable sites.
Of course anyone building a fork is able to choose whatever they want to build against. Permanent choices are available here:
It's considered a best practice. But then, many projects to version the packages properly or at all, and then it because less useful. Or there is the fun split-package problem.
It's moving in the right direction, but there was not so much best practice when I started the releng work.
|
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, the Maven build does not work with the recommeded changes for JustJ. [ERROR] Cannot resolve target definition: Probably there's more to do, but I don't know what. |
Beta Was this translation helpful? Give feedback.
-
|
The problem is I don't know what state you are in. Older Java 17 versions (which is not what the most recent release is using) are here: https://download.eclipse.org/justj/jres/17/updates/ |
Beta Was this translation helpful? Give feedback.
-
OK. My colleague will invest 1-2h to see if we can make the Maven build work. If it succeeds, I'll report here. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's the intent, i.e., that the target platform is based on stable repositories for state of the git repository at the release tag. If you have problems, I will try to help. |
Beta Was this translation helpful? Give feedback.
-
|
Hi. I'm the colleague @hvbtup was talking about. I was experimenting with the target platform today and encountered a strange error: I had created a new target file in my workspace and wanted to add the necessary repos and dependencies one by one, starting with the JREs. After adding the software site https://download.eclipse.org/justj/jres/17/updates/release/17.0.13, I immediately got an error message in the target editor stating that several dependencies are unsatisfiable. One of them for example is a missing dependency
What is wrong here? It sounds like the repo is missing a dependency to itself... |
Beta Was this translation helpful? Give feedback.
-
|
How might someone else reproduce this problem? Note that birt is not using jre.minimal so I have not the first clue what exactly you are doing. |
Beta Was this translation helpful? Give feedback.
-
|
I created a new blank target definition and added the software site https://download.eclipse.org/justj/jres/17/updates/release/17.0.13 to reproduce the issue. It looks like this: |
Beta Was this translation helpful? Give feedback.
-
|
I can't see the definition from this picture. Moreover, I don't know what you are trying to do nor I why you are trying to do something this way. I did mention the target is generated so it would seem better that you generate it by changing the setup definition:
And using Perform Setup tasks to resolve the targlet definition to regenerate the target platform:
I believe I've also mentioned that for the past two releases the state of the *.target file should be usable to rebuild from the release tag. |
Beta Was this translation helpful? Give feedback.
The terms of the EPL require you to make such modifications public. 😨
Note that for the most recent releases I've been stabilizing the target platform fix repository locati…