java-devel February 2013

java-devel@lists.fedoraproject.org

19 participants
25 discussions

Development and maintainership of freemind in fedora
by Johannes Lips 20 Mar '13

20 Mar '13

Hi all, I am currently maintaining freeminda and various other related dependencies in fedora. I am now working full-time and not a student any more, so the time I could devote to work on packaging is reduced a lot. This is not a problem with packages where you have an easy upstream, which is not the case for most of my Java packages. Therefore I am not going to have the time, to put enough effort into packaging up the new version of freemind and adopt all the changes upstream made to plugins and various other parts of the package. This is why I am looking for someone who would like to take over these packages and work on them. I am not going to orphan them straight away but if I am not able to update to the latest stable upstream version there's not a lot of sense in keeping it in fedora. I hope someone will help me to keep freemind in fedora, Johannes

2 5

New Java guidelines
by Mikolaj Izdebski 27 Feb '13

27 Feb '13

Last time the draft[1] of new Java packaging guidelines was announced[2] a week before Java SIG meeting. I didn't hear about *any* concerns until the meeting begun. Are there any concerns[*] about the new guidelines? If there are any problems then it's better to speak up now so we can resolve any possible issues before the meeting. If you care about the guidelines or the future of packaging Maven artifacts in Fedora then please take your time, read the draft and post any thoughts on the mailing list. Thank you, Mikolaj Izdebski [1] https://fedoraproject.org/w/index.php?title=User%3AMsrb%2FJavaPackagingDraft [2] http://lists.fedoraproject.org/pipermail/java-devel/2013-February/004633.ht… [*] besides effective POMs, which were covered in a separate thread

6 16

fixes in new guidelines
by Michal Srb 27 Feb '13

27 Feb '13

Hello guys, I made few corrections in java packaging guildelines draft as decided at the java-sig meeting yesterday. Draft: https://fedoraproject.org/wiki/User:Msrb/JavaPackagingDraft Diff: https://fedoraproject.org/w/index.php?title=User%3AMsrb%2FJavaPackagingDraf… a quick summary: - fixed fedora versions in Maven section - clarify a bit why BR on java-devel is optional in Maven packages Let me know if you think something is still missing or should be fixed. Thanks Michal Srb

1 0

Summary/Minutes for today's Java SIG meeting (2013-02-26)
by Aleksandar Kurtakov 26 Feb '13

26 Feb '13

===================================================================== #fedora-meeting: Java SIG -- https://fedoraproject.org/wiki/SIGs/Java ===================================================================== Meeting started by sochotni at 16:02:56 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-02-26/java_sig.2013-02… . Meeting summary --------------- * roll-call (sochotni, 16:03:04) * New guidelines & XMvn packaging (sochotni, 16:07:36) * LINK: https://fedoraproject.org/wiki/User:Msrb/JavaPackagingDraft (sochotni, 16:07:42) * ACTION: msrb fix up Fedora versions in Apache Maven section (sochotni, 16:17:57) * ACCEPTED: (sochotni, 16:35:25) * Lifting FPC/Fesco temporary ban on XMvn conversions (sochotni, 16:36:02) * AGREED: ban can be lifted at FESCO/FPC discretion (sochotni, 16:38:37) * open floor (sochotni, 16:38:57) Meeting ended at 16:57:04 UTC. Action Items ------------ * msrb fix up Fedora versions in Apache Maven section Action Items, by person ----------------------- * msrb * msrb fix up Fedora versions in Apache Maven section * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * sochotni (74) * akurtakov (40) * neugens (34) * zodbot (22) * vanaltj (10) * mizdebsk (7) * jerboaa (6) * tradej (4) * msrb (3) * rgrunber (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Deprecating tomcat6 in rawhide
by Stanislav Ochotnicky 26 Feb '13

26 Feb '13

We've had tracking bug[1] for migrating away from tomcat6 for quite a while. There's still one bug open for kawa but it doesn't look like it's getting fixed and there are more packages entering Fedora which are again pulling in tomcat6 as dependencies. There's only one way to stop it - deprecate tomcat6 in rawhide now and deal with breakages that will happen. They should be fairly easy to fix (adding a few empty methods here and there). If people have no objections I'd like to ask David to deprecate tomcat6 in rawhide[2]. If needed I can do it myself once David orphans the package. [1] https://bugzilla.redhat.com/show_bug.cgi?id=819505 [2] http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

3 2

Installing effective Maven POM files
by Mikolaj Izdebski 26 Feb '13

26 Feb '13

Yesterday at the Java SIG meeting we started discussion about future of packaging of Maven artifacts in Fedora (i.e. the new guidelines). We didn't get very far with discussion about the guidelines and the main reason for that seems to be that the new way of packaging Maven artifacts described in the guidelines causes effective POM files to be installed in place of raw POM files. Let me begin with my apologies for not communicating this matter earlier, but I didn't consider this change as controversial and I didn't think that anyone would have any problems with it. Because there were many doubts (and even accusations) I'll try to describe in detail why in my opinion this change is needed. The current problem =================== Maven has advanced and powerful dependency mechanism. It has such features as dependency scopes, exclusions, and optional dependencies (if you want you can get more detailed information about them in Maven documentation [5], describing them here wouldn't make much sense). On the other hand RPM has much simpler dependency mechanism. You can either require some package along with all its requirements or not require it at all. There is no way to express different dependency scopes in RPM packages. Let me give you a simple example. A and B are JAR artifacts, X is a POM artifact (aka parent POM), P is some Maven plugin. artifact B requires artifact A (scope: compile) artifact A inherits from artifact X artifact X requires plugin P And some ASCII-art graph (feel free to skip it if you don't like it of if it's unreadable for you, all the information represented in the graph is present in the text too). ,---. ,---. | X |--->| P | `---' `---' ^ | ,---. ,---. | B |--->| A | `---' `---' In this case there is no wonder that package B should require package A because its needed even during runtime. Question whether A should require X or if X should require P is more problematic. There are 4 possibilities in this case which I'll try to describe in more detail. Case 1. A requires X and X requires P. In this case if you want to install package B you'll have to install P as a transitive dependency. All dependencies of P will be installed too. For example Maven plugins require Maven, but possibly much more. This solution is not good because it causes many unneeded packages to be installed. Case 2. A does not require X (and X does require P). Now you get correct runtime dependencies from perspective of package B. But to build package B you'll need to manually add BuildRequires: X because Maven would otherwise fail to resolve artifact X which is referenced from POM A. This solution is not good because (1) you'd need to manually specify BuildRequires: X when in spec file of package B and (2) because plugin P is installed when building package B even that this plugin is not needed. Case 3: X does not require P (but A does require X). Now when installing B you get only a single uneeded dependency (i.e. package X). We could live with that, especially because X is a small POM-only package. Building B is simple - you don't need to specify extra BuildRequires. However in this case to build package A you need to add BuildRequires: P in spec file of package A. If package X changes (for example a plugin is added or removed) then you need to change package A too (to add or remove respective BuildRequires). This is error prone and tedious. Case 4 in which X does not require P and X does require P is just a combination of cases 2 and 3. It adds no benefits and combines their disadvantages. For this reason this case is not acceptable. To summarize: cases 1 and 4 were unacceptable. 2 and 3 could work, but have major disadvantages. These disadvantages get much more problematic as number of involved packages increases. Both cases require maintaining BuildRequires in different places from where they arising. When updating a single package one would need to investigate if any of related packages need updating. If you don't update related packages then you get inaccurate requires (which itself leads to build failures, dependency bloat, or two at the same time). I tried to improve the situation of Maven packaging in Fedora and I have thought of many different solutions. I can't really explain you in one email (which gets too long anyway) all the possibilities I considered in the whole 6-month process of designing and implementing XMvn. Explaining at least some of them would require knowledge about Maven internals. Instead I'll propose a solution which in my judgement is the best and try to show that it's better than current situation. [5] http://maven.apache.org/guides/introduction/introduction-to-dependency-mech… Proposed solution - effective POMs ================================== First let me explain what I mean by "effective POM". Effective POM is basically a POM with included metadata from all ancestor POMs (parent POM, parent of parent and so on). Effective POMs don't need to explicitly declare parent POM because they have all settings copied from ancestors. Inheriting from parent would be a NOP. So what happens in the previous example if package A installed effective POM instead of raw (upstream) POM? The most important consequence is that we can simplify requires: ,---. ,---. | X |--->| P | `---' `---' ,---. ,---. | B |--->| A | `---' `---' All requires are accurate now (minimal and correct). 1) Package A no longer needs to require X because POM A is effective and doesn't reference POM X. 2) Installing binary packages (A or B) doesn't bring any unneeded dependencies on parent POM packages or Maven plugins. 3) Building package B doesn't bring plugin P (which is not needed to build B). 4) Building package A automatically brings plugin P (which is needed to build A). Plugin P is installed automatically because A BuildRequires X, which pulls in P. 5) All packages declare Requires or BuildRequires for stuff that are specified only in their POMs. With this solution you don't *ever* need to declare Requires or BuildRequires on dependencies added in POMs from other packages. Let me highlight two things: 1) With this solution effective POMs need to be installed only in packages shipping binaries (like A). POM-only packages (like X) still install raw POMs. 2) As I showed, the noticeable improvement in dependencies is a direct consequence of installing effective POM instead of raw POM in package A. Any proposal like "let's keep XMvn but revert installing effective POMs" would nullify the benefit gained - pretty much the whole reason of using XMvn and automated dependency generation in the first place. Some time ago automated Maven and OSGi provides and requires generation was implemented. It was fully enabled for OSGi (mainly because OSGi dependencies are much simpler than Maven), but auto-requires for Maven artifacts were not enabled. They were disabled because we didn't install effective POMs and without that generated automatic requires wouldn't be sane (as I showed above). Effective POMs - evil or not ============================ There were several matters related to effective POMs touched at the meeting (and after). I'll try to comment on them. 1. "Effective POMs are bundling other POMs and because of that they need to be forbidden in Fedora." Explanation: The only thing that needs to be copied from parent POM is simple metadata. To be more specific - groupId, dependency artifact names and extension artifact names. No code is bundled or anything like that. Only simple, small metadata that would otherwise have to be included in form of package Requires or BuildRequires manually in order to get things working. 2. "Effective POMs are unreadable." Explanation: Effective POMs aren't supposed to be read by people, but for machine processing. You can install raw POMs next to effective POMs if you feel there is a need to have them for people to read (as a form of documentation). This is as if you said that we should install C code and interpret it instead of installing machine code because the second is unreadable. 3. "Using effective POMs breaks compatibility of Fedora system artifact repository with upstream Maven." Explanation: First of all, our repository has different structure from upstream Maven and there is no way to directly use it from upstream Maven. Secondly, effective POMs are valid POMs (not some custom format) and as such they can be parsed and used by unmodified upstream Maven. Installing effective POMs instead of raw POMs doesn't bring any change in terms of compatibility with upstream Maven. 4. "If there is a bug in parent POM then all dependant packages have to be rebuilt to fix the bug." Explanation: If the bug is not about declared in dependencies then dependant packages don't need to be rebuilt because all metadata besides dependencies is meaningless when used by effective POM in installed binary packlage (in future all the meaningless data will be stripped off to reduce POM size and improve readability). But if the bug is in dependencies declared in the POM then dependant packages would have to be rebuilt anyways, no matter if raw or effective POMs are used. Rebuild is needed because if a dependency in parent POM changed then this cange needs to be reflected in updated Requires or BuildRequires of other packages. If you don't update dependant packages then you silently introduce packaging bugs. 5. "If some packages install effective POMs and some raw POMs then dependencies become incorrect." Explanation: That is simply not true. Mixing effective POMs and raw POMs in Fedora could expose *existing* packaging bugs in other packages. There are cases that packages don't declare all of their dependencies but people don't experience that bugs because other package have excessive dependencies that cover missing requires in other packages. Reducing dependencies to minimum creates a possibility that fixing one bug (excessive dependencies) can expose another bug in a different package. Using effective POMs doesn't introduce new bugs by itself. Moreover, having both effective and raw POMs in distribution is hopefully a transitive state and I hope that at some point in future all non-POM packages will install effective POMs. 6. "Installing effective POMs instead of raw POMs is a deviation from upstream." The reason why POM files are installed with Fedora packages is that they are needed to be automatically processed by Maven during build of dependant packages. Internally Maven creates effective POM very soon in the build process and uses this effective POM during the build. Hence installing effective POMs has the same semantics as installing raw POMs. The difference is that our installed POMs will have a bit different structure, possibly won't include all the information (which would be meaningless in that context anyways) and won't be byte-identical to upstream POMs. But again, POMs should be treated as data for machine processing, so different structure is acceptable as long as semantics are the same. It's like in Fedora we install JAR files (or .so files) different (not bit-identical) from upstream, but with the same semantics (the same runtime behaviour; implementing exactly the same algorithm because they are compiled from the same source code). I hope that this explains why installing effective POMs is needed and covers most of concerns about them. If you have any questions or comments, please feel free to comment. Contrary to what some people seem to believe, I do not refuse to listen to any concerns about stuff related to Maven in Fedora and I would appreciate any (constructive) criticism or comments. -- Mikolaj Izdebski

3 28

Java SIG MEETING Feb 26 (tomorrow) 4 PM UTC
by Stanislav Ochotnicky 25 Feb '13

25 Feb '13

Seems like late announcements will become norm for our meetings :-) Since the issues surrounding effective poms seem to have been solved (or at least we have consensus on idea and some POC packages), we can revisit our SIG agenda from last week[1,2]. Any specific notes you'd like discussed (i.e. java-devel BR) I'd like to as you to add to the agenda. [1] https://fedoraproject.org/wiki/Meeting:Java_SIG_2013-02-26 [2] https://fedoraproject.org/wiki/User:Msrb/JavaPackagingDraft -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

1 0

Searching Job in Java Packaging
by Thomas Koch 25 Feb '13

25 Feb '13

Hi, after having me on site for interviews, Google told me last week that I barely missed it. What I also would love to work on would be to improve the situation of Java packaging in linux distros, especially the collaboration between Fedora and Debian. If you know any company that would be interested in hiring or funding me for that work, please contact me or have a look at my CV: http://www.koch.ro/temp/thomas_koch_developer.pdf For the Fedora List: Sorry that I've not yet introduced myself. I'm working on Debian-Java packaging since 3 years and also work on generalising debians tools so that they could become usable also for other distros. Thank you for your attention, Thomas Koch, http://www.koch.ro

1 0

Help with build problem
by Anthony Sasadeusz 25 Feb '13

25 Feb '13

I'm trying to build jboss-web 7.2.0 and I can't resolve this error: [WARNING] Could not load depmap file /builddir/build/BUILD/jboss-web-7.2.0.Final: java.io.FileNotFoundException: (No such file or directory) [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building JBoss Web 7.2.0.Final [INFO] ------------------------------------------------------------------------ [WARNING] The POM for org.eclipse.jdt.core.compiler:ecj:jar:3.7.2 is missing, no dependency information available You can find my spec file here: http://cerberus.fedorapeople.org/jboss-web/7.2.0/ Here are my scratch build logs: http://koji.fedoraproject.org/koji/taskinfo?taskID=5047437

2 1

About XMvn project
by Mikolaj Izdebski 22 Feb '13

22 Feb '13

This message describes briefly XMvn project, which is the behind the implementation of mvn-rpmbuild/mvn-local scripts and %mvn_build/%mvn_install macros. In the past Maven projects used to be build in Fedora using a heavily-patched Maven. XMvn is an alternative solution, it doesn't need any patches and it works with unmodified upstream Maven. XMvn is a set of extensions for Maven. XMvn tries to be a good citizen in Maven worls. As Maven itself, XMvn is written in Java, uses the same coding conventions as Maven (code style, Plexus components, Modello etc.) and it's licensed in the same way (Apache License version 2.0). The project is modularized and consists of several parts. XMvn core implements the essential functionality such as resolution of artifacts from system repository. XMvn core is needed by all other modules. It is also used by Tycho in Fedora. XMvn connector is a set of Plexus components that replace a few default components provided by Maven. This module effectively connects Maven with XMvn. XMvn MOJO is a Maven plugin, which provides goals useful in building packages. So far there are 2 MOJOs, but more are planned in future. XMvn launcher is a very simple module responsible for bootstrapping XMvn. It calls Plexus classworlds to create class realm and populate it with all classes necessary to run Maven and XMvn. There are also XMvn tools - command line utilities that expose some of XMvn functionality via command-line interface. Currently documentation is mostly missing because I was the only person working on the project and I simply didn't have enough time to document everything. Situation improves with time and I hope that with next version (0.4.0) more detailed documentation will be available. XMvn is a free software projects, contributors are welcome. There are many ways to help, it's up to you what you want to do. It you are looking for an idea what may be missing then you can check TODO file in sources or contact me. Some links: Project homepage: http://mizdebsk.fedorapeople.org/xmvn/ (for now very limited, a richer webpage is coming with version 0.4.0) Code repository: git://git.fedorahosted.org/xmvn.git Besides that I would like to ask you: * do you want do be periodically informed about the project progress? * do you mind if XMvn announcements are made on this mailing list, or do you think that a separate mailing dedicated to development of XMvn should be created? * would you like to see developer documentation? (how to contribute, coding style, structure of SCM, future features and milestones, release schedule etc.) (I count no reply as "no" or "I don't care") If you want to know more or have any suggestions please don't hestitate to ask. -- Mikolaj Izdebski

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel February 2013