Publish Maven Build To Central #625
Comments
|
@wimjongman Do you or anyone you know have experiencing setting this up? What we would like is to be able to automatically deploy/publish the Runtime to Maven Central. To date, we have been doing this by hand, it would be great if we could do this in the easiest way possible. @SteveSchafer-Innovent |
|
I have tried once and failed... However, it seems doable with some focus. https://docs.github.com/en/actions/guides/publishing-java-packages-with-maven |
|
Thanks Wim,
We will take a look in the upcoming days using those links.
Scott
…On Thu, Apr 29, 2021 at 1:46 PM Wim Jongman ***@***.***> wrote:
I have tried once and failed...
However, it seems doable with some focus.
https://docs.github.com/en/actions/guides/publishing-java-packages-with-maven
https://dzone.com/articles/publish-your-artifacts-to-maven-central
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#625 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKF2BOJ6UWXBORNJMMBOLLTLGSO5ANCNFSM4ZYBQNVA>
.
--
Scott Rosenbaum
Innovent Solutions, Inc.
612 220 6006 cell
|
|
Hello there, We were able to build the BIRT runtime locally and will probably integrate the runtime by using the build jars Can we help you, in order to get a public build release on Maven Central? |
Yes, that would be great. You can create PR's referencing this issue. |
|
What are the release problems? |
|
We could setup a release workflow, where a release is uploaded to Github first We have done it for our project as well: https://github.com/minova-afis/aero.minova.core.application.system/blob/master/.github/workflows/release.yml The only thing needed to my knowledge are a username and an access token for Github, |
|
@splitcells, @pipebaum can we re-start working on this? |
|
@wimjongman It is not known, what is needed or if a Maven Central release is desired. |
|
Hi, I'm not sure what your problem is, but for sure a Maven Central release is desired by us, see #863 |
|
This is what is currently inside the maven repo [1]. Our official build is in Jenkins [2]. [1] https://mvnrepository.com/artifact/org.eclipse.birt |
|
Which one is the release workflow or what are the commands used for release? |
|
The birt-master job creates all the artifacts. The artifacts are then uploaded here [1] We used to have a process to make milestones and release candidates but we are going to skip that for now. Finally, there will be a job that will move the artifacts from the downloads/snapshots and update-site/snapshots to a final release location. Then there could be another job that uploads these artifacts to maven central. I guess the artifacts to upload are the bundles in update-site/snapshots/plugins |
|
You mentioned earlier, that you tried something? That way, we have a common process to start from. |
That was for a different project and a long while ago. |
|
I can take this on and I'd like to publish 4.9 manually to make sure all the requirements are met before automating it. Maybe have automation a goal for 4.10. Do we want to publish just the runtime or everything? |
|
+1 to doing a manual build for now and get the automated build into 8.10
I think that we should just publish the Runtime, if people want to use the
design elements, I think they would use a different path.
Scott
…On Wed, Mar 16, 2022 at 3:36 PM Steve Schafer ***@***.***> wrote:
I can take this on and I'd like to publish 8.9 manually to make sure all
the requirements are met before automating it. Maybe have automation a goal
for 8.10.
Do we want to publish just the runtime or everything?
—
Reply to this email directly, view it on GitHub
<#625 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKF2BN4YYU5TJBPBBGQG7TVAJA4JANCNFSM4ZYBQNVA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Scott Rosenbaum
Innovent Solutions, Inc.
612 220 6006 cell
|
|
Yes, it's 4.9 not 8.9 ;) |
|
Thanks, Steve! I'm not sure what is meant with the Runtime. This is what is currently on maven: |
|
If that's of any help, this is what I'm interested with: https://mvnrepository.com/artifact/org.eclipse.birt.runtime/viewservlets What I'm looking for is a security fix: #863 |
|
Quite happy to see BIRT is alive again :) We are stuck on 4.4.2 and would love to upgrade 4.9.0 but need maven artifacts in central. BTW, the 4.4.2 runtime artifact loads lots of dependencies, better if most of the data connectors are made separate artifacts. |
|
Thanks, Amit. We are looking forward to your patches ;) |
|
Also quite interested in seeing this published to Maven. Would appreciate both the runtime and also viewservlets. Super excited to see activity in this project again! |
|
birt.war is part of the runtime. |
When I think of runtime I think of what's built into build/birt-packages/birt-runtime/target and also what we could download called "birt runtime". It includes all the classes you need to be able to generate BIRT reports in your own application. It also includes the web app and the war file. I think when people want a maven repo, it's so they can conveniently include the necessary classes in their own app. I'll need to find out if there's a way to build the runtime independently or construct a pom that will do that. That will be the root and then everything it depends on will need to be also published to central. All the pom's will need to meet the maven requirements including <licenses>, <scm>, and PGP signatures. Since this will involved a lot of changes to pom.xml files and 4.9 is now frozen I'll probably need to publish from my fork in order to publish 4.9. Once we get 4.9 successfully published we can make sure 4.10 is ready to go. https://maven.apache.org/repository/guide-central-repository-upload.html When I published 4.8 under the Innovent name I pushed all the jar files to Sonatype OSSRH. There is also a mechanism for running your own repository manager. That might be overkill for us but let me know what you think. |
|
Sounds good Steve. I don't think we need our own repo manager, but you be the judge. I am happy to release 4.10 early, there is no reason to postpone a release when we have some great new stuff to offer. Here is a link to the platform publish wiki: https://wiki.eclipse.org/Platform-releng/Publish_to_Maven_Central |
|
I can publish to the group com.innoventsolutions, but in order to publish to org.eclipse or any sub-groups, I would need the sonatype jira credentials of whoever owns org.eclipse. |
|
It would be quite better if it was under org.eclipse. |
What commands are you using? Sry, for the noobish question. |
|
We're also using the BIRT engine embedded in a Java webapp to generate reports. |
|
My company uses an embedded birt runtime for report generation. We have recently manufactured a custom POM with a recent zip distribution version as the source, however its still a manual un-maven-esk method for creation and updating. It would be most ideal if the birt build was switched to maven/gradle (as opposed to Ant), so that it would automatically produce acceptable and updatable artefacts, ready for publication into maven central with little further effort. |
|
The build uses Maven Tycho, with some ant spit and glue thrown in for confusion... In other contexts, we "simply" use the CBI p2 Aggregator to "mirror" a "normal" p2 repository to a maven-compatible p2 repository and then a subset of that is published to maven central. I.e., using this: https://github.com/eclipse-cbi/p2repo-aggregator E.g., this does that to publish EMF's (Maven/Tycho) builds In any case, the releng work around this is highly non-trivial, e.g., things need to be PGP signed, and as I understand it, Javadoc bundles are required for all the contributed jars. So while publishing to Maven is undoubtedly urgent to the consumers, "urgently waiting" is an oxymoron and that non-activity will accomplish exactly nothing. It would seem that everyone expects or hopes that someone else will implement and contribute the solution, preferably for free and preferably as soon as possible. As they say, hope dies last... |
|
For those interested in technical details and perhaps planning to contribute toward the required effort, this is where all the infrastructure that the Platform uses for publishing to maven central is located: As far as I know, no company interested in BIRT is also a member or sponsor of the Eclipse IDE WG: https://eclipseide.org/working-group/#about Also BIRT project does not currently participate in the Eclipse Simulations release. As such, the pooled funding that the IDE WG has at its disposal for releng-related work and/or for SimRel-related will not be invested in anything needed by BIRT. Perhaps companies with urgent needs should consider investing/participating in some more direct way... |
|
No sooner is it about money, no one writes any more. @merks, how is it possible to donate directly? |
|
I think it would be awesome to see an organization specifically interested in BIRT be listed as a sponsor: It's also possible to sponsor in this way: https://www.eclipse.org/sponsor/ide/ And while that too is great, it is "anonymous"... |
|
Ed, how does that sponsorship take care of creating this feature? I'm just curious on how this works. |
|
It doesn't directly do such a thing. The best way to ensure that any given specific feature is addressed is to pay someone directly to do it or to do that yourself. That being said, I've spent a not-insignificant part of my "releng" budget a few months ago, funded by the IDE WG, to get BIRT's builds back into shape, partly with an eye to some organization who might actually help fund the IDE WG. After all, BIRT is really cool, but it depends on the sustainability of other upstream Eclipse Projects so folks should consider investing in their future needs. |
|
@rajn @scooterGrun Did you try the instruction I posted earlier ( https://gist.github.com/siepkes/00f0c410933271b4f4e0d5eab18d7469 )? We've successfully used these to embed BIRT in to our application running Java 17. |
|
Any updates on this? What is the expectation of the BIRT team to pull the 4.13 BIRT runtime libraries into projects that want to use them? |
|
I cannot talk for the others, but here is my personal impression:
So, from my POV, the expectation to publish the BIRT 4.14 runtime to the Maven repo is near zero. It seems nowadays most Java developers seem to be 100% dependent from Maven. In fact using the BIRT runtime in your own Java projects is quite easy. You just need to add I think what is actually a weakness of BIRT is not so much the missing Maven upload, but a working example for a simple "BIRT server" process that handles the creation of BIRT reports and an example of a client program communicating with this server. Note: The The companies that are using BIRT internally or inside their products have certainly developed more sophisticated "BIRT servers" (this includes the company I'm working for) for their own purposes, but these servers are not Open Source. A more sophisticated server process would probably use a REST API, authentication, user management etc, but that's not necessary to show the principle and would make it much more difficult to keep the server lean and easy to understand IMHO. Note that such a separate server process can be built and run using plain old Java, its build process and its runtime architecture is then completely independent from your main application. |
|
Strong vote on this. Publish latest BIRT version to Maven will help in many ways:
|
|
Yes. Strongly vote on this too: Publish latest BIRT runtime to Maven Central. |
|
Congrats on 4.14.0 release. Why are we still not on Maven Central though? |
|
@ILyaCyclone I can't speak for the project but I think the reasons are outlined pretty well in this comment: #625 (comment). Long story short: The same reason why (seemingly) reasonable requests in a lot of open source projects aren't implemented: The projects are under-staffed and none of the maintainers share this particular itch. |
Because no one wants to manage direct dependencies and transitive dependencies manually when there is a dependency management software (Maven) that will easily do it for you. Yes, sometimes there are conflicts when projects use different version of the same dependency and those need to be resolved manually. However 99% of the time it is automated. An upgrade from Birt 4.14 to 4.15 should be as easy as a one-line change in a build property. As long as there were no breaking changes. Engineers shouldn't swapping out Birt jars and Birt dependencies for upgrades or installs. I understand we could write a script that does automation. But why write a script when this is what Maven already does? |
|
FYI, I created a BIRT runtime maven artifact for BIRT 4.14.0 |
|
We made a service for working with p2-artifacts from maven-projects. |
|
@eureka-bpo eureka-bpo/p2repository.com#1 Who are you and how safe is your site? |
First note that the Birt component is currently disabled because of eclipse-birt/birt#625 To test OFBIZ-12957 I enabled it and got this incomprehensible error: > Task :compileGroovy startup failed: C:\projectsASF\Git\ofbiz-framework\plugins\birt\src\main\groovy\org\apache\ofbiz\birt\order\NetBeforeOverheadReport.groovy: 21: unable to resolve class org.apache.ofbiz.base.util.UtilDatetime @ line 21, column 1. import org.apache.ofbiz.base.util.UtilDatetime ^ 1 error > Task :compileGroovy FAILED FAILURE: Build failed with an exception. This fixes it (still incomprehensible, it's disabled anyway) Also import java.sql.* is unused
|
I recently had to work on the integration of an updated BiRT dependency as the solution of @siepkes broken some of my transitive dependencies for logging (no offense, at least you shared something that was extremely valuable). You'll find it below. https://gist.github.com/Marks13/94fd7de500297e9c6b9830a5f167e5c1 |
|
Can this issue be resolved anytime sooner? |
|
@m-thirumal Yes, if you provide a solution to it. If you have read this issue in detail, you should have seen that there is no easy solution. You should not expect a solution soon. A solution seems to depend on understanding and cleaning up the build process, besides others, AFAIK. The build process is "historical grown", meaning that is a complicated mess. |
It no longer is thanks to Ed @merks 💞 |
|
There have been some discussions with folks potentially willing to provide sponsorship to align with their wishes. If wishes were fishes… |
and others
Currently, there is no automated feature to publish the BIRT-Runtime to Maven. Wouldn't it be nice to fix this.
The text was updated successfully, but these errors were encountered: