Trouble with eclipse plugin version matching
by Orion Poplawski
Trying to build eclipse-ptp, getting:
/usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.5.1.R35x_20090820/scripts/build.xml:35:
The following error occurred while executing this line:
/usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.5.1.R35x_20090820/scripts/build.xml:91:
The following error occurred while executing this line:
/usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.5.1.R35x_20090820/templates/package-build/customTargets.xml:19:
The following error occurred while executing this line:
/usr/lib64/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.5.1.R35x_20090820/scripts/genericTargets.xml:106:
Bundle org.eclipse.ptp.pldt.upc_0.0.0 failed to resolve.:
Missing required plug-in org.eclipse.cdt.core.parser.upc_5.0.0.
The requires line is:
<import plugin="org.eclipse.cdt.core.parser.upc" version="5.0.0"
match="greaterOrEqual"/>
The version in cdt-parsers is:
/usr/lib/eclipse/dropins/cdt-parsers/eclipse/plugins/org.eclipse.cdt.core.parser.upc_5.1.0.200906161748.jar
so why isn't it satisfied?
File a bug? Where?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 11 months
Is this specified somewhere?
by Christoph Höger
Hi,
I was just pointed to a strange thing in javas anonymous class features.
Consider the following class:
package javabug;
public class NormalTestClass {
final Integer i; //mark
NormalTestClass() {
i = 101; //mark
foo();
}
public void foo() { }
}
When you create an anonyous class like
final Integer i = 100;
NormalTestClass myClass = new NormalTestClass() {
@Override
public void foo() {
System.err.println(i);
}
};
Instead of 100 the output would be 101.
The problem is that we had discussed a case that used to occur in older
versions of java when you removed the marked lines: In that case in the
first call of foo() the variable i would not yet be initialised and
therefore be null.
This is fixed now. But what you get now is problematic on its own:
Effectively you are forced into not using variables that are privately
used by the superclass (you might not even know of).
Any comments on this issue?
13 years, 11 months
Missing deps for eclipse-ptp
by Orion Poplawski
I'm trying to build eclipse-ptp for F13 and getting:
[eclipse.buildScript] Some inter-plug-in dependencies have not been
satisfied.
[eclipse.buildScript] Bundle org.eclipse.ptp.rdt.core.tests:
[eclipse.buildScript] Missing required plug-in
org.eclipse.cdt.core.tests_5.0.1.
[eclipse.buildScript] Bundle org.eclipse.ptp.rdt.managedbuilder.xlc.ui:
[eclipse.buildScript] Missing required plug-in
org.eclipse.cdt.managedbuilder.xlc.core_5.0.0.
[eclipse.buildScript] Missing required plug-in
org.eclipse.cdt.managedbuilder.xlc.ui_6.0.0.
These don't seem to be in our cdt packages. Any reason why? No idea
what they are....
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 11 months
Status of geronimo
by Orion Poplawski
Can someone shed light on the status of geronimo in Fedora? Seems like
it hasn't managed to build since F11 - and the F11 build was never
pushed. There is a geronimo-spec 1.2 in CVS that doesn't compile
(missing dependencies among other things). Apache's site has version 2.1.4.
Mind you, I know nothing about geronimo other than a package I'm trying
to build depends on geronimo-stax-api.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 12 months
javax.servlet API
by Orion Poplawski
Are the javax.servlet classes packaged in Fedora? Is there a general
way to search for what package/jar would provide a given class?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 12 months
Using Maven in Fedora Koji
by Mike Bonnet
As part of my work developing and maintaining Koji, I've been looking at
ways to better support Java builds. Maven is emerging as the defacto
standard build tool for Java projects, but the design of Maven makes it
difficult to use in the context of rpmbuild. In order to provide the
same reproduceability and auditability for Java builds that we have with
rpm builds, without the complexity of the Maven-in-rpmbuild system we
use now, I've been working on supporting Maven natively in Koji.
The code has been committed to the "mead" branch of the upstream Koji
git repository, and testing has been very successful. I'm planning on
taking the proposal to FESCo soon, but I wanted to get some feedback
from the people most likely to be affect by this, the active Java
packagers/maintainers, first. I've written up a wiki page describing
how the system works and some of the advantages of it here:
http://fedoraproject.org/wiki/KojiMavenSupport
Note that deploying this in Fedora would not force any packages to
change their build process. If you are happy with your current build
process, you're free to continue using it. This is an alternative build
process available to those packages that would benefit from it,
primarily Java packages that build with Maven. The existing
rpmbuild-based process and the new Maven-based process will be fully
interoperable.
I'd appreciate any thoughts or feedback you have on this before we take
it to FESCo and the Fedora Packaging Committee. Though this has the
potential to increase the number of Java packages in Fedora
significantly, it could also make packaging Java apps for Fedora
significantly easier.
Note that this also has implications for building and packaging JBoss in
Fedora. A number of the JBoss projects build with Maven, and more of
them are moving in that direction upstream, but getting them to build
within rpmbuild has been difficult and labor-intensive. Koji Maven
support was designed with this in mind, and will enable us to build
JBoss in a repeatable, trackable way without requiring changes to the
upstream build process, and will make packaging the build output in rpms
dramatically simpler. Getting JBoss packaged in Fedora in a fully
supportable way is a compelling reason for deploying this in the Fedora
build environment.
Please let me know if you have any questions, or need more detail about
any aspect of the proposal.
Thanks,
Mike
13 years, 12 months
Help Requested to Package Bedework
by Trever L. Adams
Hello all,
About a year ago, I suggested that BedeWork (http://bedework.org) be included. I offered to package it with some help. I unfortunately ran out of time. I now have time to package it and hopefully maintain the package. Unfortunately, I haven't written an Java code in a decade or so. I have never messed with Java packages. I also have no experience maintaining for Fedora.
The problems I have:
This package has a bunch of property files that you have to edit before you build/package the program. (http://www.bedework.org/downloads/3.5/BedeworkManual-3.5.pdf#page=18) These include database names, locations, user/passwords for the database, etc. I do not know if this is normal or not. I do not know how to package this, how to suggest people customize this information, etc.
This program also requires JBoss or Tomcat (maybe there are others that will work). Since I do not see JBoss in Fedora, Tomcat would be fine. I have not experience with this. It would be nice if a Tomcat person can help me with documentation on how to get this working and to use AD (Kerberos [SPNEGO/GSSAPI] and LDAP) for the authentication and user/group information as well.
I have a few packages that I have not yet submitted that I have packaged. These include PyKota (and its dependencies), DSPAM, and C-ICAP (not yet ready as I have some code I am writing that will be turned over before I submit this package).
I have no clue about any of the build systems in Fedora, so I will need help with this as well.
Thank you,
Trever
14 years
