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

[Dan Allen]

On 08/20/2012 12:08 PM, Gerard Ryan wrote:
> 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?

The customizations that Gerard is referring to in this case are of the 
Linux environment itself, not specific to JBoss Tools (or even Eclipse). 
We are setting up the user's home directory so that they can start 
coding as soon as the boot finishes. This includes things like 
customizing terminal settings, adding git awareness to the bash prompt, 
setting the Eclipse workspace directory and default perspective and 
things of that sort.

We've been shooting ideas back and forth through the Fedora kickstart 
file hosted at gitorious: 
https://gitorious.org/fedora-jboss-spin/kickstart/ and I've been posting 
ideas on Google+. Now that those passing ideas are turning into 
conversations, I'll be sure to post on a mailinglist. The ideal place 
for this discussion is probably the Fedora Java mailinglist: 
https://lists.fedoraproject.org/mailman/listinfo/java-devel

>>
>>> 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.

Exactly, the idea is for them to boot Fedora, open Eclipse and be able 
to deploy right away. We can't use the auto-discover at the moment 
because JBoss Tools doesn't properly auto-discover the "user instance" 
of JBoss AS that is prepared by the "jboss-as-cp" script in the JBoss AS 
package. This script creates a skinny standalone instance of JBoss AS 
that only has the configuration files and uses JBOSS_BASE_DIR to point 
to the real installation. This is the proper way (IMO) to properly 
handle permissions on an operating system that properly handles 
permissions :)

The server configuration that we added is partly necessary because it 
requires the vm arguments to be customized to isolate the configuration 
from the base installation. Since that would require hand editing those 
arguments, it's much easier on the developer if we setup the instance 
for them. Of course, once JBoss Tools can configure a user instance of 
JBoss AS (or even autodetect it), then that becomes unnecessary. I'll 
hold firm on the requirement that when they start Eclipse the first 
time, they should have a JBoss AS server already ready to go (that's one 
of the key goals of this spin).

Btw, you can grab a spin ISO, pop it into a virtual machine (like 
VirtualBox) and try it out:

http://ryan.lt/fedora-java-remix/

We *really* want to get feedback about whether this remix gives you a 
Java development environment you can rely on. It's still an early 
release (particularly the JBoss AS and JBoss Tools packages) so don't 
expect it to be perfect yet. But hopefully you'll like what you see, or 
let us know if you don't. Fedora + Java FTW!

-Dan

-- 
Dan Allen
dallen at redhat.com

Principal Software Engineer
Middleware Engineering
Red Hat, Inc.