Development and maintainership of freemind in fedora
by Johannes Lips
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
10 years, 6 months
Summary/Minutes for today's Java SIG meeting (2013-02-26)
by Aleksandar Kurtakov
=====================================================================
#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-...
.
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
10 years, 7 months
Deprecating tomcat6 in rawhide
by Stanislav Ochotnicky
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
10 years, 7 months
Installing effective Maven POM files
by Mikolaj Izdebski
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-me...
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
10 years, 7 months
Searching Job in Java Packaging
by Thomas Koch
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
10 years, 7 months
Help with build problem
by Anthony Sasadeusz
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
10 years, 7 months
About XMvn project
by Mikolaj Izdebski
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
10 years, 7 months
