Those aren't "minimal" changes, it is possible to set a pom.xml without
moving the file hierarchy around.
On 18. 7. 2024 20:00, Marián Konček wrote:
Sorry, I didn't answer to your questions.
# Licensing * core-1.0.0.jar: https://github.com/spreiter301/Core --
GPL / Commercial * twinkle seems to be this:
https://github.com/spreiter301/Twinkle -- GPL / Commercial others are
either free or are present on Maven Central from which I deduce they
should be free
I spent some time moving the file hierarchy to using Maven and i have
a result, see my commits in my fork:
https://github.com/mkoncek/cie-middleware-linux/commits/master/
Note that the two aforementioned artifacts: core and twinkle need to
be build locally from sources, they are not present in the Maven
Central, fortunately building them is simple and only requires bumping
the source/target version to "1.8" in their pom.xml files.
Note that my commits are dirty and I am not proposing them as changes,
they show that it is possible to adopt Maven.
On 18. 7. 2024 18:12, Cristian Le via devel wrote:
Hi Marian,
Thanks for the comments. We all had our turns being horrified by this
project. The more you look at it the more you want to use bleach as
eye-drops. Germano is trying to write an issue to at least try to
steer the upstream project in a more sensible directions.
On the CMake side, I gave some comments on what are the minimal
changes that are required. On Java side though, I don't know what the
build process is. Vitaly mentioned that java environment is tricky
with things like Kotlin compiler being removed, so that's why we are
asking for some second-opinions on this. The project seems to use
only plain java, and taking a quick look at the dependencies, it
doesn't seem that they are all packaged, but are there among them any
red flags that would be a complete deal-breaker?
Probably for the Java build it would be better to use Maven. Are
there other pointers of what upstream developers should look
into/implement on the Java side?
Re: Sergio, so far it seems all Italian, Portuguese and Estonian are
using different infrastructures.
On 2024/07/18 17:31, Marián Konček wrote:
Hi, I am a member of Fedora Java package maintainers.
I see several problems with this project:
1. *.jar, *.a, *.o files not only do not belong into Fedora sources,
they should not even be in *any* GitHub repository unless they are
used for testing. Binary components are not sources.
2. Requiring graphical Eclipse to build some Java code is a heavy
overkill, you should instead add a standard Java build system like
Maven or add CMake targets to build Java code using standard tools
like `javac` and `jar`.
3. generated files like *.d, *.mk should also not be in a source
repository, unless there is a good reason for them.
4. You will do the others a great service if you use the English
language in GitHub commits and READMEs. Open-source software is not
there for you but for the whole world.
5. (minor) The project is missing a README information what it
actually is about. All I could read about is that it is "some
middleware for Linux".
You should really take a look at other more standard projects on
GitHub, how they handle builds and library dependencies.
On 18. 7. 2024 16:42, Germano Massullo wrote:
Hello, I discussed the feasibility of packaging
https://github.com/italia/cie-middleware-linux
in Fedora devel Matrix channel with Cristian Le and xvitaly. With
the help of Cristian Le I wrote the following [1] draft that will
be used to open an upstream ticket to request various improvements
to make it possible to include the software in the Fedora repository.
We ended up needing the comment from Java package maintainers, if
they see any other no-go. I am in particular concerned about
https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_pre_built_dependencies
Thank you
[1]: https://germano.fedorapeople.org/canc/cie_middleware.md
--
Marián Konček
--
Marián Konček
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
