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

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.