Fwd: Proposed New Github Component Chunks for JBoss Tools 4.0
by Max Rydahl Andersen
moving to jbosstools-dev
Begin forwarded message:
> From: Nick Boldt <nboldt(a)redhat.com>
> Subject: Proposed New Github Component Chunks for JBoss Tools 4.0
> Date: 23 Aug 2012 21:00:37 GMT+02:00
> To: Max Rydahl Andersen <max.andersen(a)redhat.com>, Denis Golovin <dgolovin(a)exadel.com>, Michael Istria <mistria(a)redhat.com>,
>
> As part of the planned migration to git [0] it's been suggested that we combine some of the existing components into larger groups [1] so that it's more manageable in terms of checking out sources and tagging/branching [2].
>
> Because 25 is a large number, and 1 is a small number, and we need some happy compromise.
>
> Here's my proposal for how to divide the JBT 4.0 sources into 7 github repos (chunks), comprising 4 tiers of dependency. This is akin to the +0, +1, +2, +3 labels assigned to projects within the annual Eclipse release trains [3], used to define delivery times based on dependencies between projects.
>
> == TIER 0: no upstream JBoss.org chunks ==
>
> Base = tests + common + usage
>
> == TIER 1: 1 upstream chunk, Base ==
>
> AppServer = openshift + as + archives + jmx
> -> depends on Base
>
> Hibernate/Birt/Freemarker = hibernate + birt + freemarker
> -> depends on Base
>
> Visual Editing = vpe + xulrunner + gwt + struts + jsf + jst + cdi
> -> depends on Base
>
> Web Services = WS + Forge
> -> Depends on Base
>
> == TIER 2: 4 upstream chunks ==
>
> Seam/Runtime = Seam + Runtime
> -> depends on Hib + Vis + AppServer + Base
>
> == TIER 3: 5 upstream chunks ==
>
> Central/Examples/Maven/Portlet = central + examples + maven + portlet
> -> depends on Seam/Runtime + Hib + Vis + AppServer + Base
>
> I'm not thrilled with the names of the chunks, as something like "Central/Examples/Maven/Portlet" doesn't exactly roll off the tongue. If you have better names for the chunks, please suggest them.
>
> But regardless of name, I think the above separation of concerns, and the implied build sequence workflow makes a lot of sense.
>
> [0] http://tinyurl.com/git-migration-plan
> [1] http://ether-man.rhcloud.com/p/build.next
> [2] http://ether-man.rhcloud.com/p/jbosstools-2012-08-23
> [3] http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#Milestones_and_Rel... - "These delivery times are based on the dependencies between projects. They are labeled +0, +1, +2, and +3, with +0 coming first (the Platform) and +3 coming last (EPP). Projects themselves decide if they are +0, +1, +2, or +3."
>
> If you have comments or suggestions regarding this migration plan, please post them here or in https://issues.jboss.org/browse/JBIDE-12475.
>
> Thanks!
>
> --
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
>
11 years, 11 months
Request for comment on introduction of org.jboss.tools.common.core
by Rob Stryker
Hi all:
Since the 'common' component is our lowest level component, which almost
all of jbt has a dependency on, this issue affects basically everyone here.
As was mentioned before, for all the reasons common needs to be split,
the beginning step is the creation of a new plugin. To avoid adding yet
another junk plugin with no benefit, I've drafted a new process for
additions of new plugins:
https://community.jboss.org/wiki/ApprovalProcessForAddingAPluginAndOrFeat...
The new plugin will possibly be named org.jboss.tools.common.core, and
will hold about 60-70% of what is currently in org.jboss.tools.common.
Strong efforts will be made to make sure all consumers have no issues,
that package names aren't changed, that class names aren't changed, and
that everything continues to go smoothly, but, since things don't always
go 100%, it is very important we all stay aware of this issue.
The jira requesting approvals for this issue is here:
https://issues.jboss.org/browse/JBIDE-12469
This is just a first step. Assuming this split goes well, the next steps
will be (up to discussion of course) to continue organizing the common
module in a safe way with clear boundaries between plugins and features.
Let's not get too far ahead of ourself, though. For now, I'd like
everyone (if they have time) to read and comment on the above jira,
which simply creates org.jboss.tools.common.core and moves all non-ui
classes from o.j.t.common into o.j.t.common.core.
If *anyone* sees anything wrong in the plan, PLEASE mention it. I'd also
like to mention that voting yes now does not mean you agree to the patch
(as there isn't one yet). It just means you agree to the plan.
Thanks again.
- Rob Stryker, troublemaker
11 years, 11 months
研k发o人e员a的h考e核w与y激m励
by chenruihua＠whctv.com
研 发 人 员 的 考 核 与 激 励
8月27-28日----深圳、8月30-31日----北京
【培-训-对-象】企业CEO/总经理、研发总经理/副总、公司总工/技术总监、研发项目经理
产品经理、中试部经理、研发质量部经理、PMO主任、管理岗位的技术人员
【培-训-费-用】4000元/两天 "买一赠一,不再打折" 需在同一个月的同一课程才享有此优惠,
单独一人收费2600元。（含两天中餐、指定教材、证书、茶点、发票等）
【深 圳－☏】０７５５-６１ ２８ ８９ ０７
【上 海－☏】 ０２１-３１ ２６ １５ ８０
【北 京－☏】 ０１０-５１ ６６ ８１ ２５
期 待 您 的 来 电 ！
【课 程 背 景】
研发人员的考核与激励是企业高层领导、研发经理、人力资源经理最为头疼的问题之一，高层
领导和研发管理者在进行研发绩效管理时经常遇到以下问题：
1)如何通过绩效管理的方法引导开发人员为公司市场目标的达成而努力？
2)研发体系是否应该有严格的考核制度，这样会不会挫伤研发人员的积极性？
3)研发的KPI指标体系如何进行分解，KPI指标如何进行量化和过程跟踪？
4)技术工作如何进行量化，不能量化的工作是否可以考核？
5)绩效目标制定和考核结果反馈的过程中如何与员工进行沟通？
6)研发绩效管理中如何处理好考核的结果与过程并重的特点？
7)如何平衡研发结果的滞后和研发人员的及时激励之间的关系？
8)在激励不足的情况下如何达到预期目标并不至于产生负面作用？
9)研发内部如何针对不同的职位进行分类的考核（部门主管、项目经理、员工……）？
……本课程在过去4年讲授的基础上作了大量的更新,结合企业主管面临的这些问题总结出适合不同
发展阶段的企业研发人员绩效管理的解决之道，非常强调从业务的角度来进行研发的绩效管理，通
过多年的总结得出的一些理论及实践来指导研发及人力资源部门的主管对于研发绩效管理有一个明
确的、理论与实践结合的、可操作的方法，从而提高研发的管理效率，提高投入产出比。
【课 程 收 益】
1.分享讲师数百多研发管理培训的专业经验，通过现场的互动帮助学员理清适合自己企业的研发绩
效管理方案
2.分析并了解业界公司在研发人员考核和激励方面存在的主要问题及解决办法
3.掌握研发的价值链，研发价值创造、价值评价和价值分配的各环节的重点
4.掌握研发中高层管理者述职管理的制度、方法和操作技巧
5.掌握如何从整个企业的价值链来分解企业的KPI指标，从源头理清研发的价值链
6.掌握研发团队和个人的绩效目标制定的方法（PBC）
7.掌握研发团队和个人的绩效辅导的方法和行之有效的操作技巧
8.掌握绩效管理的PDCA循环，绩效的评价和反馈的技巧
9.掌握研发绩效管理结果的应用和研发体系的奖金分配方法，结合企业的自身情况设计激励措施
10.分享讲师30多个咨询项目的绩效管理的案例资料（模板、表格、样例……）,帮助学员制定
Action Plan，使得学员参训后回到自己的公司能够很好实践
【导 师 简 介】[Jay]
研发管理资深顾问
■ 专业背景
多年高科技企业研发管理实践，具有丰富的研发创新及产品规划管理、研发项目管理、研发人力资
源管理的理论与实战经验。在国内某大型知名企业工作期间，成功担任了多个产品线的研发项目管
理工作；长期与国际顶尖咨询顾问一起工作，全程参与并协助推动该公司研发管理变革项目 （IPD
项目）,同时兼任该公司高级讲师.后任某知名软件企业信息安全事业部研发总监，很好的将研发管
理变革的理论和实际经验与公司的现状相结合，全面建立产品研发管理体系，具有丰富的研发管理
经验。在进行的各类公开课、内训培训中，广泛受到客户的一致好评和肯定。
■ 咨询背景
从事研发管理咨询工作以来，成功的主持了国内最大的某网络安全厂商、国内最大的某建筑软件厂
商、某大型自动控制设备生产厂商、某大型电信运营商的研发中心、某大型系统集成公司（上市公
司）等数十家企业的产品战略规划、产品开发管理（产品开发流程、研发项目管理、研发的创新管
理等）、组织设计、研发人力资源管理及CMM/CMMI等方面的管理咨询项目。
■ 培训背景
曾在各地多次举办产品经理管理、研发项目管理、研发绩效考核、新产品开发流程优化与管理等公
开课，为数千家企业提供了研发管理公开课的培训，为数百家企业进行了研发管理的内训；从事研
发管理咨询工作以来，作为咨询项目总监和项目经理成功完成了数十个研发管理咨询项目体系的建
设<产品战略规划、产品开发管理 （产品开发流程、研发项目管理、研发的创新管理等）、组织设
计、研发人力资源管理及CMM/CMMI等方面>，有着丰富的研发管理咨询经验，涉及的行业包括通信、
软件、家电、电信运营商，芯片、医疗器械、交通运输等，帮助这些企业建立高效、完备的研发管
理体系。
11 years, 11 months
Re: [jbosstools-dev] CDI Tools. What's next?
by Max Rydahl Andersen
> As I read idea #4 (diagram), I wonder if it would be possible to have some Arquillian tooling based on the CDI context to generate something like this:
>
> package org.arquillian.example;
>
>
>
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.JavaArchive;
> import org.junit.runner.RunWith;
>
>
>
> @RunWith(Arquillian.class)
> public class BasketTest {
>
>
> @Deployment
>
>
> public static JavaArchive createDeployment() {
>
>
> return ShrinkWrap.create(JavaArchive.class, "test.jar")
>
>
> .addClasses(Basket.class, OrderRepository.class, SingletonOrderRepository.class)
>
>
> .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
>
>
> }
> }
> The idea would be that from a custom Arquillian Test wizard, you could specifiy with Bean is to be tested, and then generate the proper test skeleton, including the 'createDeployment()' method.
Something like https://issues.jboss.org/browse/JBIDE-8553 ?
> Also, some validation tooling could report problems if other required beans (that are injected in the one to be tested) are not declared in the archive.
> I understand that it does not cover all use cases, especially when m2 dependencies should be included in the test archive, but it could be a starting point..
Sounds good, but not sure if this last one is technical feasible since you would actually need to *execute* the @deployment method to validate it....aka. run the test.
thoughts ?
/max
11 years, 11 months
CDI Tools. What's next?
by Alexey Kazakov
Hi,
Here are my thought abut possible features/tasks that we can implement
in the next versions of JBT.
1. Performance issues. I believe CDI Tools don't work perfectly for
really big projects (thousands of CDI beans).
Right now we are investigating such issues (creating test projects,
looking for bottlenecks and so on).
When we will finish this work we will be able to tell what problems
we have, how big they are and how long it can take to fix the problems.
2. Some minor improvements such as: Continue to implement QuickFixes and
OpenOns based on documents which are being edited and have not been
saved yet.
Not a big work since it's based on what we already have.
3. Continue to support new features introduced by Delta Spike (which is
still in progress and new features are coming).
4. CDI project view and/or Injection Dependency Diagram (have no idea
yet how such a diagram may look like but we can start to think about it
and maybe such a digram may be useful for CDI developers).
5. ?...
Suggestions/comments are welcome.
11 years, 11 months
JBoss Tools 3.4 is now called 4.0
by Nick Boldt
Jenkins jobs with "3.4" in their name have been renamed. 3.3_trunk jobs
will soon be called 4.0_trunk, and after we branch for the first
milestone, we'll need to create a series of 4.0_stable_branch jobs.
I've also renamed the JBIDE JIRA targets from 3.4.* to 4.0.*, so please
update your queries accordingly.
See also JBDS-1987 for the rationale behind this rename (basically it's
about moving from Eclipse 3.x to 4.x and reflecting that in our
versioning too).
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
11 years, 11 months
Voting for removal of deltacloud from trunk
by Rob Stryker
Hi All:
I've opened a jira to track the potential removal of deltacloud from
trunk. Deltacloud is outdated and no longer supported. From what I
understand (but I may be wrong) it is no longer enabled in build.
The jira is: https://issues.jboss.org/browse/JBIDE-12458
We are requesting feedback from any and all users and developers who
have an opinion on the matter. We are also requesting that the component
lead (Andre?), a build system representative (nboldt or mistria), and
the JBoss Tools lead (Max) vote on the jira. We require +1's from all
three, and no -1's from any committers.
Once voting is finished, if the task is approved, subtasks will be
created and tracked. If the task is not approved, it will remain open
for discussion or retargeted depending on the discussions that go on.
Everyone give a look and express any comments you have for or against
removal.
Thanks.
- Rob Stryker, troublemaker.
11 years, 11 months
m2e-wtp 0.16.0 RC1 available
by Fred Bricon
Yes I meant m2e-wtp. Sorry.
/me goes back to his padded room
Fred
On Wed, Aug 22, 2012 at 6:48 PM, Ian Robertson <irobertson(a)overstock.com>wrote:
> Don't you mean m2e-wtp is available?
>
>
> On 08/22/2012 10:25 AM, Fred Bricon wrote:
>
> Hi all,
>
> m2e 0.16.0 RC1 (0.16.0.20120822-0913) is available from the m2e-wtp
> 0.16.0 milestones update site [1].
>
> Notable changes since the last M1 build :
> * The update site contains mavenarchiver 0.15.0.201207090125 which is
> compatible with the upcoming m2e 1.2. [2]
> * The overlay preferences page has been fixed [3]
>
> The complete changelog includes bug fixes released in 0.16.0 M1 [4]
> I expect to release at least another RC, where the plugins will be signed
> with the eclipse.org certificate, before the final release before the end
> of september.
>
> As usual, please report bugs to bugzilla [5].
>
> [1] http://download.eclipse.org/m2e-wtp/milestones/0.16.0/
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=387712
> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=387694
> [4]
> https://bugs.eclipse.org/bugs/buglist.cgi?query_based_on=Open%20m2e-wtp%2...
>
> [5] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=M2E-WTP
>
> Regards,
>
> Fred Bricon
>
> --
> "Have you tried turning it off and on again" - The IT Crowd
>
>
> _______________________________________________
> m2e-users mailing listm2e-users@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/m2e-users
>
>
>
> ------------------------------
> CONFIDENTIALITY NOTICE: This message is intended only for the use and
> review of the individual or entity to which it is addressed and may contain
> information that is privileged and confidential. If the reader of this
> message is not the intended recipient, or the employee or agent responsible
> for delivering the message solely to the intended recipient, you are hereby
> notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify sender immediately by telephone or
> return email. Thank you.
>
--
"Have you tried turning it off and on again" - The IT Crowd
11 years, 11 months
