Re: [jbosstools-dev] Packaging JBoss Tools for Fedora (issue & potential patches)
Hi Gerard,
Sorry for being late to this thread, but been on 3 weeks vacation.
I see that you solved your original issue by being able to repackage the proper jbossxb
and thus be able to do a JBoss Tools 3.3.x without changing it too much - awesome!
(Rob also seem to have been able to handle this specific case better in 3.4.x so
that's good)
Now that is done I would though like to take the chance to go over a few points in your
email
which triggered my interest/curiosity since this issue is probably not going to be the
only one you
see while going through JBoss Tools codebase :)
Another rule that we have is that only the latest version of stuff
can
be packaged, so that everything can be maintained as cleanly as possible.
I understand the general idea of this but I wonder how this applies to tools which
actually bundles very specific jar's and might even bundle multiple versions of them
to
be able to support functionality/integration of older runtimes.
I'm curious on how Fedora packaging would/should handle this ?
release seemed to work. The problem occured when jbossxb and its
dependencies were being reviewed for inclusion into the Fedora
repositories, and the reviewer noticed that one of the dependencies
for that (jboss-reflect), bundles its own forked version of another
library (objectweb-asm), that isn't fully compatible with the upstream
version. This is also not allowed in Fedora.
Yeah, but sometimes that is needed for compatibility with other things.
In this specific situation we can solve it but I can see cases where it
becomes problematic and wondering how to handle it ?
You're probably wondering why I'm talking to you on
jbosstools-dev ML
about this?
I'm actually amazed this is your first posting - all the issues you post about on
http://blog.grdryn.me/
(I just learned about this recently) looks like perfect topics for this mailing list.
i.e. I really like to get JBoss Tools 3.3.x available under Fedora but since it looks to
be not just a
pure RPM wrapper, but an actual rebuild, with changes and more we really need to be sure
its easy to see in the osgi version string this is *not* the "normal" JBoss
Tools 3.3.x build.
Can you add Fedora or something at the end of the qualifier string to make it unique ?
This "rebuild" stuff also makes me wonder how Eclipse p2 is to be used with this
version of Eclipse/JBoss Tools ?
i.e. SOA Tools users would need to use Eclipse p2 - what happens in this case where JBoss
Tools bundles
aren't the real JBoss Tools bundles ?
Should we tell users to uninstall the Fedora one (how?) and then install the real JBoss
Tools if they want to do this ?
Another aspect is what to do with our JBoss Central feature - which also relies on eclipse
p2 to install additional features.
Similar to how WTP server adapter wizard does, m2eclipse marketplace, mylyn etc. ...any
ideas on how to handle these ?
Also, if you are interested in trying the most recent development
version of the Fedora JBoss Spin, you can find more info on it here[3]
and run it as a live usb image or in a vm.
I need to try that :)
/max