>> 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.
>> 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)
>> 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 ;)
I'll be sure to send you a link once it's uploaded.
thanks.
/max