PR 2 was rejected (incomplete), but PR 3 passed validation here and there have been no subsequent objections in the last 7hrs, so I've pushed it into the repo and will be respinning the TP shortly.

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplat... >=111 If your job(s) break after this new TP rolls out in the next hour or so, please let us know immediately!

Thanks, Nick On 06/04/2013 03:18 AM, Mickael Istria wrote: > Hi all, > > Please review this upcoming change for the 4.30.5.Alpha6-SNAPSHOT target > platform: https://github.com/jbosstools/jbosstools-target-platforms/pull/2 > > Summary of changes: > * Move to versions of Eclipse.org dependencies for Kepler RC2 (which > should be very close to the final version) > * Remove dependency on Eclipse repo and org.eclipse.update bundle > (previously required by old Atlassian connector) > * Use a snapshot SWTBot (include sources when using TP in IDE and fix > some issues with Hamcrest 1.3) > * Replaced "planner" mode by "slicer" to ensure some transitive > dependencies don't leak. This should avoid some occasional glitches we > have between mutliple and unified TP and reduce the quantity of red > builds for TP. > > In order to test it locally, do as follow: > $ cd jbosstools-target-platforms/jbosstools/multiple > $ mvn clean install -P\!multiple2repo > $ cd ~/path/to/my/jbosstools-component > $ mvn clean verify -Dtpc.targetKind=multiple > > If you notice any issue, please report it as a comment on > https://issues.jboss.org/browse/JBIDE-14729 . > > Ideally, this PR will be merged and new TP snapshot should be published > by the end of the day so we can have a look at how CI jobs behave with > this newer versions ASAP. As I'm leaving to EclipseCon France by this > afternoon (5pm in France), I guess Nick will be the one to ask quesitons > on this topic on IRC for the next few days. I'll try to follow emails. > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> > My blog <http://mickaelistria.wordpress.com> - My Tweets > <http://twitter.com/mickaelistria> > > > _______________________________________________ > 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 _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 06/04/2013 11:33 PM, Max Rydahl Andersen wrote: > Await approvals from build, affected team leads and project lead(s). In case of urgency build + one project lead is considered ok, but should be the exception. Updates of Eclipse version are specifically affecting no-one, and I fear it's not about to get much feedback. It's a low-risk change and the later we apply it, the later we'll know whether everything works fine with newer TP. A too long feedback loop (several days) is not very possible in the RC stream with a new release of Eclipse release train every week. > To give feedback the changes looks good on first roll but change from planner to slicing (which I normally would consider good) > should be confirmed first. i.e. what dependencies will *not* be included now ? > These could easily escape being detected in builds thus would be great to outline them in such a change. > Have you compared the list of bundles in generated TP with and without this slicing/planner mode ? It won't affect builds. The mirror-target-to-repo mojo is actually a "slicer", so the output site for target-platform does not depend on planner/slicer, it's always the same output as slicer. So moving TP from planner to slicer in multiple makes it easier/faster to detect mistakes that used to occur only while validation unified target. Those issues are now detected while validating multiple (about 1 hour earlier). -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

OK, so it's now been since Tue, 04 Jun 2013 09:18:04 +0200, which is more than 24hrs and the only feedback received has been discussion about the process for providing sufficient time for providing feedback in a timely manner. This just underscores my point that waiting more than a day is unnecessary because devs will react to breakages forced upon them faster than requests to experiment w/ something new. Glad to know nothing complain-worthy actually broke. :) Cheers, Nick On 06/05/2013 01:29 AM, Max Andersen wrote: > I agree the eclipse update is trivial. If it was those alone I would say > it was normal. > > It's the planner vs slicer I'm surprised about happening now and not > when we talked about it earlier on in good time instead of last minute. > > If slicer vs planner changes nothing in how the TP is generated I must > have misunderstood it's purpose. > > My understanding was that slicer would only include exactly what the > target lists (good) but planner would be able to drag in additional > dependencies especially optional ones - thus if you build and use the > .target file you get a different result - and I actually still think you. > > But good to hear the the target mirror tool is a slicer and thus I can > see how at least the installer would not be affected. > > Next time - include such info in the PR/Jira please :) > > But that raises a question - this means only tycho or pde listens to > this mode and target to repo ignores it ? > > Seems somewhat inconsistent? > /max (sent from my phone) > > > On 04/06/2013, at 23.57, Mickael Istria <mistria(a)redhat.com > <mailto:mistria@redhat.com>> wrote: > >> On 06/04/2013 11:33 PM, Max Rydahl Andersen wrote: >>> Await approvals from build, affected team leads and project lead(s). >>> In case of urgency build + one project lead is considered ok, but >>> should be the exception. >> Updates of Eclipse version are specifically affecting no-one, and I >> fear it's not about to get much feedback. It's a low-risk change and >> the later we apply it, the later we'll know whether everything works >> fine with newer TP. >> A too long feedback loop (several days) is not very possible in the RC >> stream with a new release of Eclipse release train every week. >> >>> To give feedback the changes looks good on first roll but change from >>> planner to slicing (which I normally would consider good) >>> should be confirmed first. i.e. what dependencies will *not* be >>> included now ? >>> These could easily escape being detected in builds thus would be >>> great to outline them in such a change. >>> Have you compared the list of bundles in generated TP with and >>> without this slicing/planner mode ? >> It won't affect builds. >> The mirror-target-to-repo mojo is actually a "slicer", so the output >> site for target-platform does not depend on planner/slicer, it's >> always the same output as slicer. So moving TP from planner to slicer >> in multiple makes it easier/faster to detect mistakes that used to >> occur only while validation unified target. Those issues are now >> detected while validating multiple (about 1 hour earlier). >> >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> >> My blog <http://mickaelistria.wordpress.com> - My Tweets >> <http://twitter.com/mickaelistria> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org <mailto:jbosstools-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > _______________________________________________ > 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

Note that between M7 and RC2, org.eclipse.ecf.provider.filetransfer.httpclient_4.0.300 was removed in favour of org.eclipse.ecf.provider.filetransfer.httpclient4_1.0.300 So, if you depend on that plugin, you'll need to refactor your MANIFEST.MF in master so that Beta2 won't be broken / uninstallable. A user ran into this problem already [1]: > Missing requirement: JBoss Tools Common Core 3.5.0.Beta1-v20130525-0108-B68 (org.jboss.tools.common.core 3.5.0.Beta1-v20130525-0108-B68) requires 'bundle org.eclipse.ecf.provider.filetransfer.httpclient I've opened a JIRA [2] to fix the problem [3] in org.jboss.tools.common.core. If your project ALSO depends on this plugin, please fix it in Beta2 / master branch as well. [1] https://community.jboss.org/message/821652 [2] https://issues.jboss.org/browse/JBIDE-14773 [3] https://github.com/jbosstools/jbosstools-base/pull/120 On 06/04/2013 10:32 AM, Nick Boldt wrote: > PR 2 was rejected (incomplete), but PR 3 passed validation here and > there have been no subsequent objections in the last 7hrs, so I've > pushed it into the repo and will be respinning the TP shortly. > > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplat... > >=111 > > If your job(s) break after this new TP rolls out in the next hour or so, > please let us know immediately! > > Thanks, > > Nick > > On 06/04/2013 03:18 AM, Mickael Istria wrote: >> Hi all, >> >> Please review this upcoming change for the 4.30.5.Alpha6-SNAPSHOT target >> platform: >> https://github.com/jbosstools/jbosstools-target-platforms/pull/2 >> >> Summary of changes: >> * Move to versions of Eclipse.org dependencies for Kepler RC2 (which >> should be very close to the final version) >> * Remove dependency on Eclipse repo and org.eclipse.update bundle >> (previously required by old Atlassian connector) >> * Use a snapshot SWTBot (include sources when using TP in IDE and fix >> some issues with Hamcrest 1.3) >> * Replaced "planner" mode by "slicer" to ensure some transitive >> dependencies don't leak. This should avoid some occasional glitches we >> have between mutliple and unified TP and reduce the quantity of red >> builds for TP. >> >> In order to test it locally, do as follow: >> $ cd jbosstools-target-platforms/jbosstools/multiple >> $ mvn clean install -P\!multiple2repo >> $ cd ~/path/to/my/jbosstools-component >> $ mvn clean verify -Dtpc.targetKind=multiple >> >> If you notice any issue, please report it as a comment on >> https://issues.jboss.org/browse/JBIDE-14729 . >> >> Ideally, this PR will be merged and new TP snapshot should be published >> by the end of the day so we can have a look at how CI jobs behave with >> this newer versions ASAP. As I'm leaving to EclipseCon France by this >> afternoon (5pm in France), I guess Nick will be the one to ask quesitons >> on this topic on IRC for the next few days. I'll try to follow emails. >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> >> My blog <http://mickaelistria.wordpress.com> - My Tweets >> <http://twitter.com/mickaelistria> >> >> >> _______________________________________________ >> 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 _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 06/07/2013 02:48 PM, Max Rydahl Andersen wrote: > Doesn't this require a fix in our TP also or is this all done via > transitive dependencies ? I think it's the other way round: updating TP revealed this change in Bundle-SymbolicName and then requires a fix in consumers. As we include this bundle as part of a feature, this is not something that is visible in target platform definition. Cheers, -- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>