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

[Gerard Ryan]

On Mon, Aug 20, 2012 at 12:34:47PM +0200, Max Rydahl Andersen wrote:
>>>> 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
>
>If someone = Marek Goldman then I chatted with him and it was that chat that got me looking
>for possible followups from you ;)
>
>His conclusion was to skip hibernatetools - which might be fine for now - but not really in future.
>
>>>> > 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?
>
>well depends on your goals - but I would stay focused on stuff within JavaEE/JBoss AS stuff
>
>Thus things like birt, drools, esb, modeshape, portlet, flow, bpel..I would take on last unless
>you got some specific usecase.
>

Thanks, I'll keep that in mind.

>>>> 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:
>
>Thanks, and it does look like I can spot some of these the last month ;)
>
>> Fedora 17 i686: 1.1.0.v20120803-1433-Final
>
>9 starts
>
>> Fedora 17 x86_64: 1.1.0.v20120803-1435-Final
>
>69 starts
>
>> Fedora 18 i686: 1.1.0.v20120813-0307-Final
>
>0 detected
>
>> Fedora 18 x86_64: 1.1.0.v20120813-0301-Final
>
>
>34 starts
>
>> Fedora 19 (Rawhide) i686: 1.1.0.v20120813-0304-Final
>
>0 detected
>
>> Fedora 19 (Rawhide) x86_84: 1.1.0.v20120813-0259-Final
>
>0 detected.
>
>>
>> If I change the BUILD_ALIAS variable to Fedora in build/parent/pom.xml
>> would that be better?
>
>It should be the qualifier - and I suggest you add it in the end, i.e. 1.1.0.v20120813-0259-Final-Fedora
>
>or even better 1.1.0.v20120813-0259-F17
>
>F18
>F19 etc.
>
>but not sure if all builds are to a specific version ?
>
>>>> 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?
>
>Yes.
>
>> 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?
>
>That would be correct, but mocking with the datetimestamp is evil too IMO.
>
>I don't think there is a good solution so better to just have the info that is there correct and mark
>it clearly as a *fedora* build (i.e. the -Fedora or -F17 markers from above)
>

Got it. I'll add F17/18/19 to the end of the qualifier. Thanks.

>>>> 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,
>
>such as ? Where is this discussed/done - i'm curious ?
>
>> including a
>> user instance of JBoss AS managed by JBoss Tools, configured by
>> default! :)
>
>yikes - I really don't like the sound of having more and more customizations of JBoss Tools in Feodra.
>
>Why not just add this to JBoss Tools already existing autodetecton instead ? i.e. we already have automatic detection of servers
>in JBoss Tools and it makes no sense to only let the Fedora distro be the one that knows how to find
>the Fedora packaged one does it ? (cc'ed Dan Allen to hear more ;)
>

It's not the default for Fedora, and there isn't any modification to
that effect to the JBoss Tools package in Fedora; it's just for the
'Fedora Java Remix' live distribution. We see it as a way of making it
easier for people to get started. Of course, it should still be
possible to use other servers.

>> I'll be sure to send you a link once it's uploaded.
>
>thanks.
>
>/max

The latest, and hopefully greatest, is now available[0], with
information in my latest blog post[1].

Thanks again,
Gerard.

[0] http://ryan.lt/fedora-java-remix/
[1] http://blog.grdryn.me/2012/08/20/fedora-java-remix-gsoc-update-13-final/

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