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?

>> Another aspect is what to do with our JBoss Central feature - which also relies on eclipse p2 to install additional features.

>> 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? >> > That's it, but more generally, it happens be qualifier is higher, not only date. yes, but for us it is the date; which is our fault and another reason why we should not have date be the significant decider.

I believe eclipse.org does this by doing releases like 3.2.0, 3.2.100, 3.2.200 ...giving room for 99 "custom" version builds.

>> 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? >> > Qualifier pattern for us is v<...>. If you want your build pattern to be lower, don't deal with dates. You can change simply qualifier to something like: f<...> or fedora-v<...>. Since 'f' < 'v' our bundles will be preferred by p2 and OSGi independently of the date on so on. I like the fedora-v<...> since it answers this issue and a previous one at the same time. > Be aware that you are dealing with conventions here. You should strongly document them and get other people working on them aware of them. It's easy to have someone changing this pattern for a "better" one without knowing such rules and then breaking it. This doesn't really solve it does it ? not unless all jboss.org updatesites are removed from p2 since when the user does Help > Update it will bump everything.

>>>> Another aspect is what to do with our JBoss Central feature - which also relies on eclipse p2 to install additional features. > Did you change the JBoss Central feature to rely on yum instead of p2? > If yes, that's a different feature, and it modified bundles and features probably requires a new name. > If no, then it means there is nothing to worry about. It will be installed and will refer to our sites, and will work as always. No it won't if the bundles done in fedora doesn't have the same API (i.e. hibernatetools not bundling hibernate 3.5 for example) It will *seem* to work, but funky sideeffects will eventually happen the more differences there are.

On 20 Aug 2012, at 12:56, Mickael Istria <mistria(a)redhat.com&gt; wrote: > On 08/20/2012 12:39 PM, Max Rydahl Andersen wrote: >>>> 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? >>>> >>>> >>> That's it, but more generally, it happens be qualifier is higher, not only date. >>> >> yes, but for us it is the date; which is our fault and another reason why we should not have date be the significant decider. > Having date in qualifier makes it very readable and user-friendly. It's quite useful. I did not say *remove* the date, I said it should not be the significant decider for p2. i.e. Release of a version should make any nightly/snapshot builds of that version invalid; today it does not because the data comes *before* the release type flag. proper versioning that has semantic API meaning instead of just rely on what date the build was made.

>> I believe eclipse.org does this by doing releases like 3.2.0, 3.2.100, 3.2.200 ...giving room for 99 "custom" version builds. > Only platform does that. I'm not aware of any other project using this versioning AFAIK. WTP does too afaik. >>>> 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? >>>> >>>> >>> Qualifier pattern for us is v<...>. If you want your build pattern to be lower, don't deal with dates. You can change simply qualifier to something like: f<...> or fedora-v<...>. Since 'f' < 'v' our bundles will be preferred by p2 and OSGi independently of the date on so on. I like the fedora-v<...> since it answers this issue and a previous one at the same time. >>> Be aware that you are dealing with conventions here. You should strongly document them and get other people working on them aware of them. It's easy to have someone changing this pattern for a "better" one without knowing such rules and then breaking it. >>> >> This doesn't really solve it does it ? not unless all jboss.org updatesites are removed from p2 since when the user does Help > Update it will bump everything. > So we want to prevent updates of JBT plugins from inside Eclipse when installed with Fedora? I did not understand it that way. > IF we want to block install of JBT ww probably can't rely on p2 as it. p2 compares version, we can't prevent it to update from 3.3.0.fedora-v2012 to 3.4.0.v2012... If we need to block this behavior, we'll probably need to hack p2 to prevent from any installation of org.jboss* IUs. no, I'm saying as long as Fedora needs to do changes to the content and not *just* rebuild it then anything like p2 updates and jboss central and m2e connectors (anything that uses p2) will be very fragile under the Fedora distribution. >>>>>> Another aspect is what to do with our JBoss Central feature - which also relies on eclipse p2 to install additional features. >>>>>> >>> Did you change the JBoss Central feature to rely on yum instead of p2? >>> If yes, that's a different feature, and it modified bundles and features probably requires a new name. >>> If no, then it means there is nothing to worry about. It will be installed and will refer to our sites, and will work as always. >>> >> No it won't if the bundles done in fedora doesn't have the same API (i.e. hibernatetools not bundling hibernate 3.5 for example) >> >> It will *seem* to work, but funky sideeffects will eventually happen the more differences there are. >> > Yet another use-case I didn't have in mind. This Fedora integration is a real puzzle. Is there a document that sums up the installation scenario to be allowed/forbidden when using Fedora JBT package? I don't think we can do an "Allowed/forbidden" one - we can basically just say "if central installs seem to work great! if it does not and you used the Fedora install please uninstall it via yum and install from marketplace" /max _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

>>> >> I did not say *remove* the date, I said it should not be the significant decider for p2. >> >> i.e. Release of a version should make any nightly/snapshot builds of that version invalid; today it does not because the data comes *before* the release type flag. >> >> proper versioning that has semantic API meaning instead of just rely on what date the build was made. > > In trunk it is now uses release type in front of the date. It was fixed a month ago and works fine since. > I uses '${BUILD_ALIAS}-v'yyyyMMdd-HHmm' for local builds and '${BUILD_ALIAS}-v'yyyyMMdd-HHmm'-H${BUILD_NUMBER}' for hudson Oh - nice; that is news to me! Didn't see any notification on this ? Shouldn't we get that out since this changes things for QE/testers/bleeding edge installs and bumping versions becomes that more important. /max _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

whats missing here ? seems to me it renders it correctly ? i.e. 3.4.0.M1-v20120821-2129-H1039 /max On 22 Aug 2012, at 18:24, Nick Boldt <nboldt(a)redhat.com&gt; wrote: > FWIW, this is an incomplete implementation. The features' & plugins' qualifiers have been reordered as noted below via the parent pom config, but the update site index pages (site names as generated via the XSL) have as yet not been: > > http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ > http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-6.0_trunk.... > http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-6.0_trunk.... > > etc. > > I've assigned myself this JIRA to finish the cleanup work: > > https://issues.jboss.org/browse/JBDS-2251 > > On 08/22/2012 08:07 AM, Max Rydahl Andersen wrote: >>>>> >>>> I did not say *remove* the date, I said it should not be the significant decider for p2. >>>> >>>> i.e. Release of a version should make any nightly/snapshot builds of that version invalid; today it does not because the data comes *before* the release type flag. >>>> >>>> proper versioning that has semantic API meaning instead of just rely on what date the build was made. >>> >>> In trunk it is now uses release type in front of the date. It was fixed a month ago and works fine since. >>> I uses '${BUILD_ALIAS}-v'yyyyMMdd-HHmm' for local builds and '${BUILD_ALIAS}-v'yyyyMMdd-HHmm'-H${BUILD_NUMBER}' for hudson >> >> Oh - nice; that is news to me! Didn't see any notification on this ? Shouldn't we get that out since this changes things for QE/testers/bleeding edge installs >> and bumping versions becomes that more important. >> >> /max >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > >

>>> I did not say *remove* the date, I said it should not be the significant decider for p2. >>> >>> i.e. Release of a version should make any nightly/snapshot builds of that version invalid; today it does not because the data comes *before* the release type flag. >>> >>> proper versioning that has semantic API meaning instead of just rely on what date the build was made. >> In trunk it is now uses release type in front of the date. It was fixed a month ago and works fine since. >> I uses '${BUILD_ALIAS}-v'yyyyMMdd-HHmm' for local builds and '${BUILD_ALIAS}-v'yyyyMMdd-HHmm'-H${BUILD_NUMBER}' for hudson > Oh - nice; that is news to me! Didn't see any notification on this ? Shouldn't we get that out since this changes things for QE/testers/bleeding edge installs > and bumping versions becomes that more important. We probably should, but I believe it is fine, because changed components should bump the version and it means bumped version in X.X.X.M1_vXXXXXXXX-XXXX-HXXX format should be higher than version in old format X.X.X.vXXXXXXXX-XXXX-HXXX-M1.

Well, there's always the option of having the timestamp PRECEDE the alias, like for the last 2 releases. :)

That way it's up to the user to decide if they want to upgrade from 1.2.3.v20120824-1234-M2 to the next dev milestone 1.2.3.v20120924-2345-Beta1 or stick to nightlies. By switching to alias-first, you force a preferred sequence on the user and remove the option for that user to select which upgrade path they want -- to the stable branch or to the next trunk nightly.

But by starting with a timestamp, as long as the update was built after the current, you can select that as an upgrade path (or pick an older newer build). Then you can call the milestone whatever you want, be it M1 or Alpha1. (This is why I pushed for this convention in the first place.)

There's also the option of adopting Eclipse's Itimestamp (integration build) or Mtimestamp (maintenance build) and vtimestamp (release build) convention. This is how projects like Mylyn, for example, handle weekly builds (I lead up to a .0 release, M lead up to .1 and .2 releases) vs. their final/GA release builds, since I and M are always "older" ASCII-wise than v, and M is always "newer" than I so a maintenance build will trump a pre-GA build.

Nick On 08/23/2012 11:26 PM, Max Rydahl Andersen wrote: >> >>>>> I did not say *remove* the date, I said it should not be the significant decider for p2. >>>>> >>>>> i.e. Release of a version should make any nightly/snapshot builds of that version invalid; today it does not because the data comes *before* the release type flag. >>>>> >>>>> proper versioning that has semantic API meaning instead of just rely on what date the build was made. >>>> In trunk it is now uses release type in front of the date. It was fixed a month ago and works fine since. >>>> I uses '${BUILD_ALIAS}-v'yyyyMMdd-HHmm' for local builds and '${BUILD_ALIAS}-v'yyyyMMdd-HHmm'-H${BUILD_NUMBER}' for hudson >>> Oh - nice; that is news to me! Didn't see any notification on this ? Shouldn't we get that out since this changes things for QE/testers/bleeding edge installs >>> and bumping versions becomes that more important. >> We probably should, but I believe it is fine, because changed components should bump the version and it means bumped version in X.X.X.M1_vXXXXXXXX-XXXX-HXXX format should be higher than version in old format X.X.X.vXXXXXXXX-XXXX-HXXX-M1. > > okey - but M1 is higher than Beta1 afaics so this is not clean as it stands. > > Do we need to move to use Alpha's instead ? .... not too fond of that because milestone is more neutral but don't see many other options ? > > /max > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

>>>> I did not say *remove* the date, I said it should not be the significant decider for p2. >>>> >>>> i.e. Release of a version should make any nightly/snapshot builds of that version invalid; today it does not because the data comes *before* the release type flag. >>>> >>>> proper versioning that has semantic API meaning instead of just rely on what date the build was made. >>> In trunk it is now uses release type in front of the date. It was fixed a month ago and works fine since. >>> I uses '${BUILD_ALIAS}-v'yyyyMMdd-HHmm' for local builds and '${BUILD_ALIAS}-v'yyyyMMdd-HHmm'-H${BUILD_NUMBER}' for hudson >> Oh - nice; that is news to me! Didn't see any notification on this ? Shouldn't we get that out since this changes things for QE/testers/bleeding edge installs >> and bumping versions becomes that more important. > We probably should, but I believe it is fine, because changed components should bump the version and it means bumped version in X.X.X.M1_vXXXXXXXX-XXXX-HXXX format should be higher than version in old format X.X.X.vXXXXXXXX-XXXX-HXXX-M1. okey - but M1 is higher than Beta1 afaics so this is not clean as it stands. Do we need to move to use Alpha's instead ? .... not too fond of that because milestone is more neutral but don't see many other options ? /max

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

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

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.

>>>>>> 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. cool - but what needs to change concerning eclipse workspace directory and default perspective?

> 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 Overall java sure, but I'm mostly curious in if there are things we could do better in jbosstools or even other places that would make things better/easier not only for a specific Fedora Java spin.

>>>> 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. Maybe i'm just coming from a different world but I would rather see JBoss Tools server adapter be able to detect and setup the JBoss AS Fedora version out-of-the-box independent on you having a Fedora Java Remix installed or where your jboss tools installation came from.

> 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. Exactly - this is what i'm curious about - getting server adapter to identify the server.

> 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 :) Please open JBIDE jiras for stuff we don't handle properly - just fixing it in fedora java remix is not a good long term solution.

Seems like most of this can be solve by having firstclass support for more "base dirs" > 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). Yes, please open jiras so we can now what you actually need - adding yet another autosetup is IMO backwards. (fine for this gsoc java respin as a proof of concept, but for me being able to have the autodetect pick up such installation no matter how you got jboss tools is much more interesting) Could you open a jira and optimally point to the source for whatever configuration you do externally to the existing autodetection and server adapter setup ?

> 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/ thanks, i'll try it out.

>>> 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. >> cool - but what needs to change concerning eclipse workspace directory and default perspective? > > We pre-selected the workspace directory ($HOME/workspace) so that the user is not prompted when running the LiveCD. We've put settings in that directory, so if they pick another location they don't get those settings, so we want them to get the full experience. > We set the default perspective to the JBoss perspective (instead of Resource) to highlight the area with the main features (and the configured server). hmm - didn't see any of that when running the builds from http://ryan.lt/fedora-java-remix/ which I downloaded yesterday ? no predefined server nor JBoss perspective ?

>>> 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 :) >> Please open JBIDE jiras for stuff we don't handle properly - just fixing it in fedora java remix is not a good long term solution. > Agreed. What we've done so far has been a proof of concept to understand the requirements for whatever feature request we would file. I think what I wrote above is sufficient for a JIRA report and I will file it as such... > > Voila! https://issues.jboss.org/browse/JBIDE-12452 Thanks! >>> 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). >> Yes, please open jiras so we can now what you actually need - adding yet another autosetup is IMO backwards. (fine for this gsoc java respin as a proof of concept, but for me being able to have the autodetect pick up such installation no matter how you got jboss tools is much more interesting) >> >> Could you open a jira and optimally point to the source for whatever configuration you do externally to the existing autodetection and server adapter setup ? >> >>> 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/ >> thanks, i'll try it out. > > Please do. And please pass it on. > done: https://community.jboss.org/en/tools/blog/2012/08/22/summer-time-with-new... /max