[jbosstools-dev] Packaging JBoss Tools for Fedora (issue & potential patches)

Sun Aug 19 13:10:22 EDT 2012

On Fri, Aug 17, 2012 at 01:38:50PM +0200, Max Rydahl Andersen wrote:
>> Sorry for being late to this thread, but been on 3 weeks vacation.
>>
>> Hi Max, welcome back. Don't worry about being late - Rob was fantastic help!
>
>Is it me or you that keeps taking jbosstools-dev of the cc list ?
>
>With 1000s unread emails in my inbox things drown very fast these days - please keep it on the list ;)

Me, it seems, sorry about that! I didn't notice it.

>> 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 ?
>>
>> I'm still relatively new to working with Fedora Java stuff, but the general idea seems to be to try to
>> patch the source if it's possible, and then submit and try to get the patches accepted into the upstream
>> code, so that future versions of the Fedora package will be closer to the upstream and be easier to
>> maintain. It often doesn't seem to make sense for Java related stuff, for the reasons you mention above,
>> but I think the reason that the guideline to only have one version of a package at a time, is because each
>> requires time/effort, and there aren't a lot of people to maintain everything.
>
>Sure, but for some cases it actually is necessary to get the right functionality - i.e. hibernate tools won't work
>correctly without hibernate tools 3.5 being available.
>
>> Yeah, luckily in this case, the older version of jboss-reflect that we eventually
>> packaged was the one that was specified as the dependency for jbossxb. For other
>> situations, I think it would work on a case by case basis. There is the possibility,
>> like in this case, to package older or multiple versions of stuff if there's a really good
>> reason. If something bundles a forked third party library, one can apply for an exception,
>> but I think that's a last resort and only granted if absolutely necessary.
>
>For Hibernate Tools it looks like a absolute necessity for me ;)
>
>how do you view it ?

If, such as in this case, it's absolutely necessary, then I guess it
would have to be done. :) The older version would get a modified name
indicating the version, and the latest version would have a reqular
unversioned name. Examples of this would be maven and maven2; or
hibernate3 and hibernate (work in progress I think).
Speaking of Hibernate Tools, it looks like someone is already on to
that: https://bugzilla.redhat.com/show_bug.cgi?id=826701

>
>>
>> > 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.
>>
>> Really? Hmm, I don't think I've had too many problems with JBoss Tools - most has been with Eclipse
>> Webtools stuff, which (imho) is painful to build/package compared to JBoss Tools! Your documentation
>> for building is great too!
>
>Well, I would have assumed questions like "what stuff from JBoss Tools does it makes sense in upcoming fedora build? "
>
>Then I would point out a few bundles that definitely doesn't make sense (i.e. deltacloud, struts and others)

Good point! I think the main reason I haven't come up with questions
like that is probably because it took me so long to get AS Tools and
its dependencies sorted out.
So, are there any other bundles that you would suggest avoiding, along
with deltacloud and struts?

>> 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 should be possible - it's not being done for any other eclipse stuff at the moment, but it might not be a bad
>> idea. I'll talk to the Fedora Eclipse guys and see what their opinion on the matter is.
>
>Any news on this one ? Now knowing current repackaging does have some significant differences I'm
>really interested in having a proper qualifier so we:
>
>A) can see that users are using the Fedora variant
>
>B) our usage stats can show how many are actually using the fedora version.
>
>Can you tell me what the exact version of the usage plugin is in your builds ?
>Then I can filter on those to let you know how many tried it so far (assuming the usage stats are enabled in your package ;)

I haven't gotten around to this yet (mainly because it slipped my
mind!).

The current version of the usage plugin differs slightly depending on
which version of Fedora, as it gets buit separately for each. Also,
I've just noticed that there it's built twice for each, once for i686
and once for x86_64 (I'm pretty should it should be done independently
of architecture, I'll have to look back and see why it's not).
So here are the versions for the current builds of the usage plugin:
Fedora 17 i686: 1.1.0.v20120803-1433-Final
Fedora 17 x86_64: 1.1.0.v20120803-1435-Final
Fedora 18 i686: 1.1.0.v20120813-0307-Final
Fedora 18 x86_64: 1.1.0.v20120813-0301-Final
Fedora 19 (Rawhide) i686: 1.1.0.v20120813-0304-Final
Fedora 19 (Rawhide) x86_84: 1.1.0.v20120813-0259-Final

If I change the BUILD_ALIAS variable to Fedora in build/parent/pom.xml
would that be better?

>> 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 ?
>>
>> It's still possible to install other bundles the usual way from the update sites. In this case, because it sees that the
>> new bundles require different versions of the already installed bundles, it downloads them also.
>
>No it doesn't - p2 works on version ranges so if your package falls within that it will use yours instead of the originals.
>
>> When Eclipse is restarted
>> and the new bundles are activated, the existing Fedora packaged versions of any stuff that duplicates were downloaded for
>> always seems to 'win' - it's chosen over the newly downloaded version. This probably isn't what one would expect.
>
>well, because the version is *higher* right?

Ah ok, I wasn't aware why that was happening. I guess it would be
'higher' because of the build date in the qualifier, right? How about
if I force the date to be lower than the your build from the update
site? That way, if one downloads from the eclipse marketplace, or
somewhere else, then that would be used instead of the Fedora
installed version. Am I right in thinking that?

>
>> Related (I think) - is there a 'stable' update site url for Eclipse 4.2 yet? All I could find were the older Indigo and Helios ones.
>
>http://www.jboss.org/tools/download.html lists them all: http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ is the most 4.2 one.
>
>> Should we tell users to uninstall the Fedora one (how?) and then install the real JBoss Tools if they want to do this ?
>>
>> That one is easy: yum remove eclipse-jbosstools-*
>
>Yeah I know its easy but I just wanted to hear if that is what we should be saying.
>
>"Want to try out JBoss  Tools on Fedora ? Do yum install eclipse-jbosstools-*.
>But if you want the full JBoss tools use the eclipse marketplace...."
>
>> 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 ?
>>
>> I haven't gotten that far yet, but I'd imagine that that should still work exactly the same. Even once we've got all of the JBoss Tools
>> modules packaged, I wouldn't expect the JBoss Central feature to start installing stuff via yum! :) If a user wants the Fedora package
>> of something, they can install via yum; if they want to install from an update site, then that will be possible too. Trying to update a
>> Fedora packaged version from within Eclipse will likely fail though!
>
>Yeah - thats what i'm fearing; this mix of behaviors...but I guess that is just the way things works :(
>
>> > 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 :)
>>
>> That might be a little old at this stage but basically the same. Since that, there are a few new JBoss Tools modules ready. I'm in
>> slow internet hell at the moment, but when I get back to a decent connection I'll upload updated ISOs. That one should give you the
>> general gist though!
>
>Got link on where the latest greatest is to try out ?
>/max

I'll be uploading tomorrow, as that's the deadline for GSOC. I'd
upload ISO images more often but I don't have the network
resources. Dan Allen has been helping me with it this week, and we've
got quite a few new customizations that should be useful, including a
user instance of JBoss AS managed by JBoss Tools, configured by
default! :)
I'll be sure to send you a link once it's uploaded.

-- 
Gerard Ryan :: gerard at ryan.lt :: http://blog.grdryn.me :: @grdryn
PGP Fingerprint: AA11 A666 C98E B6D8 231C 11ED 6EDC 7E4A 62BC 4A15