Heads-up: Maven builds might be failing for some period
by Aleksandar Kurtakov
Hi everyone,
Fedora is transitioning to using Maven 3 by default. Up until now it was
working because a lot of things were bringing maven2 into the build system.
Maven2 was part of Fedora for more ~5 years - long enough time to get a lot of
crap accumulated. We are slowly fixing issues as they arrive but there will
surely be a lot of pain until we get Maven 3.x properly working without maven2
being installed.
Example issues can be:
* failing to resolve parent poms
* failing to resolve artifacts
* projects depending on maven2 apis
* you hit one of the few incompatibilities between maven 3.x and maven2
* other issues we are still not aware of
Warning: None of the Java SIG active members has expressed any intention to
work on improving maven2 anymore. So if you hit a problem with your maven
build I strongly encourage you to move to maven 3 as fast as you can.
Realistically, maven2 bug reports might not be even processed for rawhide
because both versions depend on the very same stack and we(Java SIG) as the
maintainers of most of the stack are slightly moving it to maven 3 only. We
will not break maven2 intentionally but we won't stop improvements in maven 3
because of maven2.
In short, if you want to keep maven2 be prepared to put a lot of effort into
it!!!
Help us get a sane Java stack,
Alex
12 years, 5 months
New
by Edwin Jose
I am new to Development in Fedora. I want to Know how can i contribute with
my java knowledge. Thks in advance
--
Regards
*R.Edwin Jose*
12 years, 5 months
JRE not recognised in eclipse IDE
by Yup Yup
Hi,
I installed eclipse-platform-3.5.2-2.fc13.x86_64 on Fedora 13.
Java has been installed on the system.
ca1@localhost ~]$ java -version
java version "1.6.0_18"
......
But, Java runtime is not recognised in the Eclipse IDE.
Under Menu....... Window>Preferences there are no installed JREs options.
Also, no Java project, class options in the menu is available.
12 years, 5 months
Getting rid of maven2-depmap.xml
by Stanislav Ochotnicky
This is just an update on progress on migrating from maven2 to maven
package.
I just committed changes to maven package that will do a few things:
* direct processing of fragment files generated by %add*_maven_depmap
macros
* being able to process fragments in /usr/share/maven-fragments
* being able to resolve pom files in /usr/share/maven-poms
This will mean several things once the whole puzzle is created:
* No need for %update_maven_depmap macro in %post and %postun
* With it - no need for Require(post): jpackage-utils
* No more rpmlint warnings about non-conf file in /etc
* Sane place for pom files :-)
* Simpler packaging (IMO)
* Later on simpler patches to maven once we remove compat code.
For now we are backward compatible, so maven still reads from
/etc/maven/fragments and old _mavenpomdir.
Obviously there is certain performance penalty for processing few
hundred small files instead of one big file. However this performance
hit is rather small and only affects mvn-local and mvn-rpmbuild
so it won't affect users.
Worst case scenario, I'd rather move regenerating of depmaps into
maven shell script (comparing last change of depmap.xml with last
modification of fragments and all that...).
Right now no packaging modifications are necessary, since we don't
want to break maven2 just yet :-)
Next up: jpackage-utils and generation of maven2-depmap.xml even from
/usr/share/maven-fragments (for maven2 compat).
See https://fedoraproject.org/wiki/Migration_from_maven2 for more
details and plan.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
12 years, 5 months
(no subject)
by Abdel Gadiel Martínez Lassonde
abdel.g.martinez.l(a)gmail.com
12 years, 5 months
Introduction and a request for help
by Ruediger Landmann
Hi all;
I'm part of the Red Hat and Fedora documentation teams, and along the
way I've picked up maintainership of a few Java packages that are
important to our publishing process. Unfortunately, one of them is
causing me some trouble on F15, and I wondered if I could get some more
eyes on it please?
The package in question is FOP, which we use to generate PDFs. I can
build the current upstream version (1.0)[1], but it doesn't actually work!
Instead, FOP errors out because it can't find the event-model.xml files
that it needs. There's a bug open that shows the error message --
https://bugzilla.redhat.com/show_bug.cgi?id=689930
Comparing the package built on Koji with the binary available upstream,
it seems that there should be one of these event model files for most of
the classes in the .jar, but they're simply not created at build time.
The problem is in our EventProducerCollector, which is patched to use a
different version of qdox (1.12) from the one that upstream bundles with
FOP (1.6). Specifically, clazz.getParentClass() is always null and would
result in a null pointer exception:
/home/rlandmann/rpmbuild/BUILD/fop-1.0/build.xml:374:
java.lang.NullPointerException
at
com.thoughtworks.qdox.model.JavaMethod.getReturnType(JavaMethod.java:464)
at
com.thoughtworks.qdox.model.JavaMethodDelegate.getReturnType(JavaMethodDelegate.java:26)
at
com.thoughtworks.qdox.model.JavaMethodDelegate.getReturnType(JavaMethodDelegate.java:166)
at
org.apache.fop.tools.EventProducerCollector.createMethodModel(EventProducerCollector.java:142)
at
org.apache.fop.tools.EventProducerCollector.processEventProducerInterface(EventProducerCollector.java:130)
at
org.apache.fop.tools.EventProducerCollector.scanFile(EventProducerCollector.java:99)
at
org.apache.fop.tools.EventProducerCollectorTask.processFileSets(EventProducerCollectorTask.java:213)
at
org.apache.fop.tools.EventProducerCollectorTask.execute(EventProducerCollectorTask.java:69)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
...except that we have a check at lines 125-127 that just quits if
clazz.getParentClass() is null.
If anyone has time and inclination to take a look for me, I'd appreciate
any tips about what to try next. I can't see why getParentClass() isn't
working on the various EventProducer classes in the source. :(
TIA
Rudi
[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=246382
12 years, 6 months
Warning: Removing commons-* symlinks
by spike
Hi,
As some of you may know, apache-commons packages usually install their
jar(s) to apache-commons-*.jar and provides a symlink named
commons-*.jar. Some also provide a similar symlink for the javadoc
directory, some don't.
The shorter symlink doesn't provides any advantage (at least, I don't
know any) but causes trouble from time to time (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=447156) and clutters javadir
and javadocdir. Therefore, I'll remove both the jar and the javadoc
symlink at least for the apache-commons packages I (co-)maintain.
Please check you spec file if you are using one of those and adapt
accordingly. If you are a apache-commons maintainer (Carl, Mat, Mohamed,
Orion and Sandro), please consider to do the same for your packages or
let me know if you want me to do it for you.
Regards, Chris
12 years, 6 months