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, 6 months
Java SIG Oct 19 meeting minutes & summary
by Stanislav Ochotnicky
Hi everyone,
We had our bi-weekly meeting yesterday so I'm going to summarize what is
happening right now in Fedora-Java world.
People present:
* cspike
* ggraz
* mbooth
* akurtakov
* sochotni
Status updates:
* Maven 3 - work on custom resolver is starting
** will publish git repo on java-devel in due time
* Packages monitored by java sig
** List is getting longer, once semi-finished akurtakov will ask for
java-sig user to be created and added to these packages for
watchcommits
** agreed that commits will be sent to java-devel
* New guidelines are shaping up, several new improvements suggested
** see, comment, improve:
https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate
* Finishing up jakarta->apache rename (packages ready, need maintainers
of original packages to retire them - fnasser, jmrodri)
** also create apache-commons-parent package with proper
requires/pom.xml
Meetbot minutes (note that assigned actions look a bit like two man
show, but that's not the case...we just forgot to do #action properly :-) )
=====================================================================
#fedora-meeting: Java SIG -- https://fedoraproject.org/wiki/SIGs/Java
=====================================================================
Meeting started by akurtakov_ at 17:02:30 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-10-19/fedora-meeting...
.
Meeting summary
---------------
* roll-call (akurtakov_, 17:03:38)
* akurtakov_ cspike ggraz mbooth sochotni present (sochotni,
17:04:00)
* akurtakov_ cspike ggraz mbooth sochotni present (akurtakov_,
17:04:25)
* maven 3 status (akurtakov_, 17:05:33)
* LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm
(sochotni, 17:06:37)
* LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm
maven 3 source rpm (sochotni, 17:06:45)
* LINK: https://fedoraproject.org/wiki/MavenUpdate#Maven_3 may be
helpful, too (cspike, 17:06:58)
* LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc15.noarch.rpm
maven 3 binary rpm (sochotni, 17:07:01)
* ACTION: sochotni will put maven 3 spec for review (sochotni,
17:12:25)
* ACTION: sochotni will create public git repo with custom resolver so
others can see/review (sochotni, 17:12:56)
* new resolver should be basically re-implemented
maven-aether-provider (sochotni, 17:14:45)
* Java packages monitoring (sochotni, 17:15:04)
* LINK: https://fedoraproject.org/wiki/SIGs/Java/Monitored_packages
Wiki to collect Java packages for monitoring (sochotni, 17:15:27)
* LINK: https://fedorahosted.org/fedora-infrastructure/ infra
ticketing system (sochotni, 17:19:26)
* ACTION: akurtakov_ will file infra ticket asking for java pseudo
user (sochotni, 17:19:44)
* java-sig user will forward to java-devel mailing list (sochotni,
17:26:08)
* New packaging guidelines (akurtakov_, 17:26:54)
* LINK:
https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate
Draft (sochotni, 17:27:15)
* ACTION: akurtakov_ to add javadoc:aggregate to guidelines
(akurtakov_, 17:31:31)
* ACTION: akurtakov_ add to guidelines that ant packages that have pom
files MUST install them (akurtakov_, 17:35:38)
* ACTION: akurtakov_ f there is no pom consider using the one from
maven central addition to guidelines (akurtakov_, 17:37:40)
* ACTION: akurtakov_ merge parts from JPPMavenReadme and explain when
usage of depmap is reasonable and when one have to patch the pom.xml
file (akurtakov_, 17:43:42)
* LINK: http://fedoraproject.org/wiki/Fedora_meeting_channel
(cspike, 17:54:56)
* Update Java SIG wiki (sochotni, 17:57:27)
* open-floor (akurtakov_, 17:58:15)
* LINK: http://fedoraproject.org/wiki/JakartaCommonsRename (cspike,
17:59:12)
* LINK:
http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
(cspike, 18:01:11)
* ACTION: sochotni try to contact jmrodri and fnasser about orphaning
their jakarta packages (sochotni, 18:05:32)
Meeting ended at 18:25:51 UTC.
Action Items
------------
* sochotni will put maven 3 spec for review
* sochotni will create public git repo with custom resolver so others
can see/review
* akurtakov_ will file infra ticket asking for java pseudo user
* akurtakov_ to add javadoc:aggregate to guidelines
* akurtakov_ add to guidelines that ant packages that have pom files
MUST install them
* akurtakov_ f there is no pom consider using the one from maven central
addition to guidelines
* akurtakov_ merge parts from JPPMavenReadme and explain when usage of
depmap is reasonable and when one have to patch the pom.xml file
* sochotni try to contact jmrodri and fnasser about orphaning their
jakarta packages
Action Items, by person
-----------------------
* akurtakov_
* akurtakov_ will file infra ticket asking for java pseudo user
* akurtakov_ to add javadoc:aggregate to guidelines
* akurtakov_ add to guidelines that ant packages that have pom files
MUST install them
* akurtakov_ f there is no pom consider using the one from maven
central addition to guidelines
* akurtakov_ merge parts from JPPMavenReadme and explain when usage of
depmap is reasonable and when one have to patch the pom.xml file
* sochotni
* sochotni will put maven 3 spec for review
* sochotni will create public git repo with custom resolver so others
can see/review
* sochotni try to contact jmrodri and fnasser about orphaning their
jakarta packages
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* sochotni (132)
* akurtakov_ (95)
* cspike (43)
* ggraz (27)
* mbooth (12)
* zodbot (3)
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
PGP: 71A1677C
Red Hat Inc. http://cz.redhat.com
13 years, 1 month
depfind
by Adam Young
Having battled the dependency isssues wuith Maven and Buildr on a couple
of occasions, I wrote a bunch of scripts for dealing with this stuff and
posted it on my blog. And someone responded with this:
Why on the Earth one would use Ruby in order to extract deps from the
Java files?! Dude, use the right tool for right purpose.
http://depfind.sourceforge.net/Manual.html
I notice that it isn't in Fedora, nor is it in JPackage, so I wonder if
other members of the team have used it or even know about it. It might
help many of the people with dependency issues.
Boy did that last line have a double meaning. Anyway, figured it was
worth bringin to peoples attention and getting some feedback. I'm not
in Java mode for this project, so I don't have the cycles to spend on
it; maybe someone else does.
13 years, 1 month
Eclipse Fedora Packager: Call for Testers and Contributors
by Severin Gehwolf
Hi Fedora Packagers,
<pitch>
I would like to bring a new Eclipse plug-in to your
attention: Eclipse Fedora Packager[1]
It's a tool which can help speeding up your Fedora
packaging work :-)
In a nutshell, it offers similar features as the command-line
client fedpkg, but with a GUI. Here's a list of its current
features (more to come):
- Conveniently clone Fedora Git projects, switch branches
etc.
- RPM-spec-file editor with syntax highlighting,
auto-completion and changelog support (<Ctrl>+<Alt>+C
keyboard shortcut)
- Download source files and upload new source files
- Prepare local builds (execute %prep section of your
spec-file)
- Create source RPM files based on current spec-file
- Execute local builds
- Push builds to Koji (the Fedora build system)
- Mock builds
- Push Bodhi updates (the Fedora updates system)
- Eclipse Git support (via EGit)
If those features cover all (most) tasks you usually carry
out when packaging your software for Fedora, Eclipse Fedora
Packager may be a tool for you to look into.
Still not sure? It might be the right tool for your Fedora
packaging if:
- You prefer GUI tools over command-line-clients
- You are already familiar with Eclipse or some other IDE
- You are a developer and you use Eclipse on a daily basis
- You have never packaged something for Fedora, but
would like to do so.
- You don't know much about how software gets into Fedora
but need to get it packaged for it.
- Your main goal is to get your software packaged for
Fedora as opposed to learning a lot of tooling.
Sounds interesting? Want to try it out? Here's what you need
to do (please note that Eclipse Fedora Packager will officially
come with Fedora 14 for the first time):
If you have a F14 box, "yum install eclipse-fedorapackager".
Then fire up Eclipse and follow instructions of our user guide:
https://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide
On F13 (I'm using it) and older (untested) you need to install
some rawhide packages. This is what I usually do:
1.) Install dependencies (non-rawhide):
$ yum install eclipse eclipse-changelog eclipse-rpm-editor \
fedora-release-rawhide fedora-packager
2.) Install eclipse-fedorapackager and eclipse-egit from rawhide
$ yum install --enablerepo=rawhide eclipse-fedorapackger
3.) Follow our user guide[2] for information on how to get started
using the plug-in.
The latest version of eclipse-fedorapackager is 0.1.8 (in rawhide).
Here's a link to today's build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=201275
Feedback, testing, bug reports, contributions are very much
appreciated. Our Trac instance is here (use your FAS to login):
https://fedorahosted.org/eclipse-fedorapackager/
If you have questions, run into problems or would be interested in
contributing please let me know:
email: sgehwolf AT redhat DOT com (this list is preferred)
IRC: my nick is "jerboaa" (e.g. #fedora-devel or #fedora-java)
I'll get back to you as soon as possible.
In any case, let us know what you think ;-)
</pitch>
Thanks,
Severin
[1] https://fedorahosted.org/eclipse-fedorapackager/ (Trac/wiki)
[2] https://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide
13 years, 1 month
Maven plugin update status
by Pierre-Yves Chibon
Dear all,
Running my little script there is the status of update for the maven
plugin:
* maven-antrun-plugin is not up to date upstream: 1.6, Fedora:
1.5-1.fc15
* maven-compiler-plugin is not up to date upstream: 2.3.2, Fedora:
2.0.2-2.fc14
* maven-dependency-plugin is not up to date upstream: 2.1, Fedora:
2.2-0.2.svn949573.fc14
* maven-ejb-plugin is not up to date upstream: 2.3, Fedora: 2.2.1-5.fc14
* maven-install-plugin is not up to date upstream: 2.3.1, Fedora:
2.3-8.fc15
* maven-repository-plugin is not up to date upstream: 2.3.1, Fedora:
2.3-3.fc15
* maven-shade-plugin is not up to date upstream: 1.4, Fedora:
1.3.3-2.fc14
* maven-site-plugin is not up to date upstream: 3.0, Fedora: 2.1-3.fc14
- maven-dependency-plugin is a false positive
The other one looks true positive.
Regards,
Pierre
13 years, 1 month
Re: [fedora-java] [Crash-catcher] java reports by crash catcher
by Mark Wielaard
Looks like the java-devel list disgarded any email from non-subscribers
(so that included my initial email and your reply). Hope that is fixed
now. I left all text in the email, even though my reply consists of only
on tiny paragraph so others can catch up on the discussion.
On Mon, 2010-10-11 at 15:32 +0200, Jiri Moskovcak wrote:
> On 10/11/2010 03:19 PM, Mark Wielaard wrote:
> > Hi Jiri,
> >
> > On Wed, 2010-10-06 at 10:11 +0200, Jiri Moskovcak wrote:
> >> what about resurrecting this feature for F15? We made some changes to
> >> abrt so it uses socket instead of the helper app, so we can send you the
> >> info on how to use it if you'd be interested in implementing it to javavm.
> >
> > I currently don't have the time to work on this, but do think they are
> > good ideas that would improve abrt a lot for java/jvm based packages.
> >
> > I added Fedora Java Developers list to the CC in the hope someone would
> > be interested. So if someone is looking for a fun (python!) hack, this
> > might be interesting.
> >
> Actually it would be probably more C fun.
>
> > One idea is that abrt/crash-catcher creates a lot of bugzilla reports
> > against the jvm package. Those do include a native backtrace, but don't
> > include the (often far more useful) hs_err_pid.log file. It would be
> > nice if abrt would find it and offer to automagically attach it to the
> > bug report.
>
> Attaching the file is not a problem, but does it live in some
> predictable location?
It lives in the current working directory of the JVM. In theory one
could hack the hotspot sources to place it somewhere else. But what
would be a good place?
> > The other idea discussed was when a java program exits through an
> > uncaught exception in the main thread. In that case you might want to
> > catch that and create a bug report against the package that contains the
> > main class file (instead of against the jvm package).
> >
>
> This one is actually what I'd like to be done in F15.
>
> > The first idea is probably the least work and has the most benefit in
> > the short term (at least for the java-1.6.0-openjdk bug maintainers).
> >
> >> On 11/16/2009 09:43 AM, Jiri Moskovcak wrote:
> >>> On 11/13/2009 11:00 AM, Mark Wielaard wrote:
> >>>> On Wed, 2009-11-11 at 11:05 +0100, Jiri Moskovcak wrote:
> >>>>> On 11/05/2009 05:49 PM, Mark Wielaard wrote:
> >>>>>> The code is already setup to save if in a different place if necessary
> >>>>>> (in fact if the current directory isn't writable for the user it will
> >>>>>> try saving in /tmp). If /var/log/java is made writable for all users
> >>>>>> that could be a place to dump the log also.
> >>>>>>
> >>>>>> The code can also be modified to actually call abrt (or an helper
> >>>>>> executable/script) if necessary either with the path of the log file or
> >>>>>> even with an open file descriptor to the log.
> >>>>>>
> >>>>> We use a helper to handle the python logs, so I think we could use the
> >>>>> same helper for saving the java logs.
> >>>>
> >>>> Do you have a pointer to the code for this helper?
> >>>
> >>> http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob;f=src/Hooks/ab...
> >>>
> >>>
> >>>>
> >>>>>>> The other thing I have in mind is how to catch an unhandled
> >>>>>>> exception in
> >>>>>>> java programs, because in this case the VM exits "normally" and abrt
> >>>>>>> can't detect it. We managed to catch these exception in python by
> >>>>>>> overriding the default exception handler by script that is
> >>>>>>> automatically
> >>>>>>> loaded everytime when python VM is started. If there would be some way
> >>>>>>> to this for java we could wire this to ABRT.
> >>>>>>
> >>>>>> In principal we could install some uncaught exception handler, but
> >>>>>> uncaught exceptions might not be fatal (although they are admittedly
> >>>>>> sloppy). The program may even happily run even if one thread has an
> >>>>>> uncaught exception (as long as there are other non-daemon threads
> >>>>>> running).
> >>>>>>
> >>>>> ABRT doesn't care if it is or isn't fatal, this is up to your exception
> >>>>> handler - you can just log the exception using the abrt helper (because
> >>>>> even if the exception is not fatal, it's usually a bug..) and contiune
> >>>>> running the program.
> >>>>
> >>>> This part is trickier than the above. In case of a JVM crash there is a
> >>>> clear point where we catch that crash and produce the necessary logs for
> >>>> a bug report. In case of an application specific uncaught exception
> >>>> there is an uncaught exception handler mechanism, but the application
> >>>> could already be using it (either for a specific Thread, the ThreadGroup
> >>>> or system wide). This might require some surgery to get right (and
> >>>> unobtrusive for the application running on the JVM).
> >>>>
> >>>
> >>> This is really up to you as I don't know much about about insides of JVM.
> >>>
> >>>>>> How would you determine which package the exception belongs to? For
> >>>>>> a VM
> >>>>>> crash it is almost always the java VM package that should get the bug
> >>>>>> report (since the VM just shouldn't crash ever).
> >>>>>
> >>>>> If I'm right the Java VM is compiled, so it creates a coredump and would
> >>>>> be handled by a different hook then scripts, but that applies only if
> >>>>> you don't catch the sigsegv, sigabrt (whichI think you do, to create the
> >>>>> logs..) and let it die.
> >>>>
> >>>> Yes, the VM catches fatal signals and creates an hs_err log file based
> >>>> on the information it can still retrieve at that point before dying.
> >>>>
> >>>
> >>> Ok, so we need to find the way how to pass this logs to abrt hook.
> >>>
> >>>>> I think, as Java VM is a non-trivial programme,
> >>>>> we should write a special handler for it, or we can try to improve the
> >>>>> general hook for compiled programs to be able to handle some additional
> >>>>> data as the log file if that would be enough.
> >>>>>
> >>>>>> But for uncaught
> >>>>>> exceptions reporting it against the java VM package is definitely the
> >>>>>> wrong thing to do. How do you solve that in the python case?
> >>>>>>
> >>>>>
> >>>>> The python exception hook is run in the context of the running script,
> >>>>> so it knows the script name and the path to the script and then we can
> >>>>> simply run $ rpm -qf /path/to/script to determine the package, the code
> >>>>> to do this is:
> >>>>>
> >>>>> executable = os.path.abspath(sys.argv[0])
> >>>>
> >>>> Aha. I think we could determine the main class that is being run and the
> >>>> classpath with .jar/.zip files that this class comes from. With that we
> >>>> could probably achieve similar heuristics about the package that
> >>>> provided the classes.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Mark
13 years, 1 month