Missing org/apache/maven/archetype/catalog/ArchetypeCatalog
by John W. Himpel
Good evening,
I hope this is the correct place to ask this type of question, if not,
please provide a referral to the correct place.
When creating a new maven project using eclipse in F19, I get:
Problem Occurred
'Retrieving archetypes:' has encountered a problem.
An internal error occurred during "Retrieving archetypes:"
An internal error occurred during "Retrieving archetypes:".
org/apache/maven/archetype/catalog/ArchetypeCatalog.
I don't know if this is a packaging error or I haven't performed some
necessary configuration work. Or perhaps my firewall isn't allowing
communications with a central repository. To my knowledge, I haven't
modified any configuration settings.
Current packages that might be relevant:
maven-eclipse-plugin-2.9-5
eclipse-m2e-core
Suggestions appreciated.
Thanks.
10 years, 6 months
Upcoming jline change in rawhide.
by Severin Gehwolf
Hi,
Currently jline2 (v 2.10) is the newest packaged version in Fedora. Note
that there is another jline version packaged in Fedora, namely 1.x.
However, jline2 is packaged as a compatibility package which is wrong.
That's what's going to change. We are going to make jline what is jline2
now and move what is jline now to a new jline1 package. jline2 then gets
retired with jline as its successor.
For more information on compat packages please see Mikolaj's email this
subject here:
https://lists.fedoraproject.org/pipermail/java-devel/2013-October/005000....
I've filed bugs against all packages which have jline as a dependency
(R/BR). Those packages might fail to build from source once jline is
what jline2 currently is. All of those bugs are blocking the main
tracker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1022897
What do you have to do?
Please make sure that your package builds using jline 2.x. If that's not
the case we strongly advise to patch your package to work with newest
jline. It would be best to propose such patches upstream for inclusion.
If you really must, you may use the new jline1 compatibility package in
rawhide. Please note that jline1 may get retired in a newer Fedora
version however. That is why you should not change your BR/R to jline1
lightly. You have been warned :)
Thanks for your help!
Cheers,
Severin
10 years, 6 months
netty - request for comaintainer(s)
by Mikolaj Izdebski
I am the owner of package netty because it used to be required by Maven.
Maven doesn't require it any longer, so I would prefer to give this
package to someone else.
Currently netty is required by a few other projects (including hadoop,
resteasy, thermostat, wildfly), so I would expect maintainers of these
packages to help with maintenance of netty by becoming comaintainers or
taking ownership.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
10 years, 6 months
Headless JRE in Fedora
by Jiri Vanek
Hi all!
With https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.60-2.4.3... beeing stable,
would like to make this more visible:
The jdk in Fedora, being inspired in Debian, now supports headless version. During the life of F20
(as in f21 all expected packages should be correctly headless)i would like to recommend all java
packages maintainers, who do not need audio, or X or whatever (this is still "on QA" on our side)
to swap theirs dependence to java-headless.
Alos, maintainers, please do not forget, that when you update your package, also packages you are
depending on must become "just hedless dependent". Anyway - all libraries should be jut java-headless :)
I would like to suggest especially wildFly and tomcat to try to migrate asap, as this change was
designed for them :)
Btw - the update above is now somehow stuck - it not in testing, nor in updates. Maybe the relengs
can help.
Best regards
J.
10 years, 6 months
About compat packages
by Mikolaj Izdebski
Recently there were some discussions about compat packages on IRC.
I wanted to present how I think compat packages should be used.
I hope it will bring some sanity on this matter.
Imagine the following situation. You are maintainer of a package.
There is a new upstream version, but you know or suspect it may be
incompatible with previous version and update could cause breakage for
some dependants of your package.
The first thing you should do is announce such update in advance. Try
to be specific in terms of planned update schedule (what is going to
happen at which point of time). Either send this announcement to some
mailing list (devel or SIG) or to all maintainers of dependant
packages.
After discussing potential problems with interested parties you can
proceed with updating your package. It's nice to have a consensus,
but that's not always possible.
After you prepared your update you can share it with other
maintainers. You can use a repo on your fedorapeople.org account, a
side tag in Koji or push it directly to rawhide. Then maintainers of
dependant packages can test if their packages work with the updated
version of your package and if not then take some action.
Lets look at three different possibilities:
Case 1. A dependant package works without change with the updated
dependency version. That's great, it can immediately benefit from
features and bugfixes of new version. Nothing more to do.
Case 2. A dependant package needs a simple modification to work with
updated version. Package maintainer prepares a patch, applies it in
Fedora package and sent it upstream. Fedora package immediately
starts to benefit from new version of dependency. Upstream can accept
the patch and benefit too.
Case 3. A dependant package does not work with new version of your
package and needs some changes to port it. Package maintainer for
some reason cannot prepare the patch (lack of time, skills etc.).
Fedora package maintainer takes a copy of old version your library and
turns it into a compatibility package. A comaintainer or other person
reviews it and they add new package to Fedora. A RFE is sent to
upstream asking to update to new dependency version. Hopefully in
future upstream will implement the RFE and compatibility package will
be removed from Fedora.
To sum up, procedure of dang:
1. announce big updates in advance
2. push the update
3. fix dependant packages (if needed)
4. only if absolutely needed, package a compatibility version
The above works in all cases. If you package newer version as
compatibility package you are only preventing innovation and make
dependant packages using old, obsolete software.
Some (other) best practices:
0. Introduce compat packages only if absolutely needed.
1. All compat packages should have older version than default package.
2. Compat packages should have version suffixes, default package
should not.
3. Compat packages should be retired as soon as they are no longer
needed.
4. Prefer requires on default package, even if you need to patch
your package
--
Mikolaj Izdebski
IRC: mizdebsk
10 years, 6 months
Re: [fedora-java] [Fedora-packaging] Package Android Studio in Fedora 21/20
by Stanislav Ochotnicky
Quoting Petr Hracek (2013-10-23 12:25:58)
> Hello folks,
>
> I would like to package Android Studio in Fedora 20/21.
> The URL for Android Studio is
> (http://developer.android.com/sdk/installing/studio.html)
>
> What do you think about it?
> Is it possible to package the IDE?
Possible? Sure, anything is...
Feasible? Unlikely
> What about the license?
I couldn't even bother going through the steps to get to the source code...It's
just too damn hard[1]. So...no idea about license but there would likely be a
few glitches
>
> If it is not possible to package them into Fedora,
> can we use rpmfusion non-free as a plugin?
As Dridi mentioned, this is based on IntelliJ IDEA (or however it's
capitalized). It uses some custom build scripts to build, internally uses gradle
to actually build those android projects...It's a mess on top of mess. Yes,
people could package it. But it would take some serious effort and is definitely
not a one-man-job. Not to mention maintaining it afterwards.
We have enough packaged and unmaintained software in Java world as it is...
As for rpmfusion: rpmfusion has *identical* guidelines to Fedora. Only
difference is that they let in patented stuff (more or less). You can't package
something with unclear licensing or redistribution problems in rpmfusion either.
> Thank you very much.
Yeah, I don't think you like my answer but...
[1] http://source.android.com/source/downloading.html
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
10 years, 6 months
spring-* vs springframework-*
by Orion Poplawski
I'd like to get some kind of consensus on naming of the spring/springframework
packages. We have some of both:
spring-ldap-javadoc.noarch
spring-ldap.noarch
spring-maps-default.noarch
spring-retry-javadoc.noarch
spring-retry.noarch
springframework-aop.noarch
springframework-beans.noarch
springframework-context-support.noarch
springframework-context.noarch
springframework-expression.noarch
springframework-instrument.noarch
springframework-javadoc.noarch
springframework-jdbc.noarch
springframework-jms.noarch
springframework-orm.noarch
springframework-oxm.noarch
springframework-security-javadoc.noarch
springframework-security.noarch
springframework-struts.noarch
springframework-tx.noarch
springframework-web.noarch
springframework-webmvc-portlet.noarch
springframework-webmvc.noarch
springframework.noarch
The core/parent package is currently "springframework", but one could argue it
should be called "spring-framework".
I think the spring-* names more closely match current upstream. However,
"spring" itself is:
Name : spring
Arch : x86_64
Version : 94.1
Release : 3.fc19
Size : 16 M
Repo : updates/19/x86_64
Summary : Multiplayer, 3D realtime strategy combat game
URL : http://springrts.com
License : GPLv2+ and GPLv3+ and LGPLv2 and GFDL and (GFDL or CC-BY)
Description : Spring is a project aiming to create a new, versatile, full 3D
Real Time
: Strategy Engine.
: Spring is designed to be played as online multiplayer matches,
but some AI are
: also available to play against the computer.
: Please read the README.Fedora file to get started. The Spring
wiki is also a
: great resource, read it here:
http://spring.clan-sy.com/wiki/Main_Page
and spring-installer is a helper program for spring.
springframework-* seems to have been what is most commonly used and probably
what we should standardize on?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
10 years, 6 months
XMvn 1.2.0 release notes
by Mikolaj Izdebski
What's new in XMvn 1.2.0
* Minor features
* Artifact information in manifests
Since version 1.2.0 XMvn injects artifact coordinates to
manifests of artifact files it installs. XMvn Subst can read
this information and use it to locate artifacts in the system.
This way artifacts that do not contain pom.properties can still
be correctly replaced with symbolic links by XMvn Subst.
* Artifacts using native code
Previous versions only tried to detect artifacts containing
native code. In addition to that XMvn version 1.2.0 also
attempts to detect JAR files using native code. This means that
such JARs can be installed to a different location than JARs not
containing and not using native code.
* Major bugfixes
* Stereotype support in auto-requires
XMvn Installer did not take into account artifact stereotypes.
This caused generated auto-requires to be incorrect in some
cases. This bug was partially fixed by embedding default Maven
artifact type mappings. This means that any non-standard
stereotypes may still be handled incorrectly and produce
unsatisfiable dependencies.
* Generated self-requires
Auto-requires generator was corrected to generate correct
auto-requires in complex cases involving compatibility versions,
namespaces and dependencies on artifacts provided by the same
package.
10 years, 6 months
Java Packages Tools 3.4.0 release notes
by Mikolaj Izdebski
Java Packages Tools 3.4.0 was released and pushed to rawhide.
Changes in this version are described below.
Some error messages that cause build failure were improved to make it
more clear what they mean.
A lot of test cases were added. Existing test cases were extended and
improved.
Some legacy manual pages were rewritten from scratch. Some others were
fixed or updated.
Now injected pom.properties contain classifiers and extensions which
means that XMvn Subst will be able to locate JAR files with classifiers
or nonstandard extensions.
Several bugs related to namespaces (related to software collections)
were fixed.
Two bugs related to handling whitespace in XML were fixed.
Python implementation was fully migrated from "xml.dom" to "lxml" DOM.
Compatibility with Python 2.6 was improved.
Java packaging HOWTO was extended and improved.
10 years, 6 months
