August 2012 - jbosstools-dev - Jboss List Archives

p2 : make feature A updateable over feature B

by Fred Bricon

Hello p2 gods, we're about to release m2e-wtp <https://www.eclipse.org/m2e-wtp/> from Eclipse.org and, in order to minimize user disruption, would like to make the m2e-wtp feature upgradeable over it's ancestor (m2eclipse-wtp<https://github.com/sonatype/m2eclipse-wtp>, from github). So basically our requirements are : 1 - m2e-wtp and m2eclipse-wtp can not be installed together 2 - m2e-wtp should be able to upgrade itself AND m2eclipse-wtp Pascal kindly helped me setup (and understand) #1 using some p2.inf configuration ( http://git.eclipse.org/c/m2e-wtp/org.eclipse.m2e.wtp.git/tree/org.eclipse...), similar to what's done for m2e actually. Now #2 is where we're hitting a wall. I tried Pascal's suggestion to modify the content.xml from the update site's content.jar by doing the following : 1 - add "providedCapabilities.exists(pc | pc.namespace == 'org.eclipse.equinox.p2.iu' && (pc.name == 'org.maven.ide.wtp.feature.feature.group' || pc.name == 'org.eclipse.m2e.wtp.feature.feature.group' && pc.version < '${version}'))" to feature.update.match 2 - remove the id and range attributes from feature.update This is all scripted in http://git.eclipse.org/c/m2e-wtp/org.eclipse.m2e.wtp.git/tree/org.eclipse... The whole script works as expected (the content.xml is properly tweaked, after the site is generated by tycho) but the problem is, the hack doesn't work : m2e-wtp 0.16.0 is still not upgradeable over m2eclipse-wtp 0.15.2 and complains about the conflict declared in p2.inf The whole issue is tracked as https://bugs.eclipse.org/bugs/show_bug.cgi?id=385746 Any help/ideas are more than welcome. Regards, Fred Bricon -- "Have you tried turning it off and on again" - The IT Crowd

12 years, 4 months

1
0
0 / 0

Re: [jbosstools-dev] Proposed New Github Component Chunks for JBoss Tools 4.0

by Max Rydahl Andersen

> The reason to have xulrunner out of jee component is it has been changed for a while, so I don't want build something over and over again. > > I think we can have maven included in central component and runtime included in common when dependencies from seam and as are reversed. > > +1 freemarker and forge to be in common. Freemarker should just be built and released once - no further builds needed until someone has time to add/maintain features. Forge - it is not obvious to me that Forge would stay "low" in the dependency cycle. It actually depends on m2e and others and probably more over time - how would that be handled ? /max > > that would give us 9 big chunks. > > Denis > > On 08/27/2012 11:35 AM, Nick Boldt wrote: >> I've digested Denis' diagram so it aligns with what I proposed in terms of chunks (git repos) and tiers (collections of builds that must be done before the next collection can proceed). >> >> My view includes 7 chunks and 4 tiers of builds, +0 through +3, starting with the "base" or "common" module (tests, common, and usage), all the way up to Central at the top as a +3. >> >> Denis' view includes 13 chunks (git repos) and 7 tiers of builds. >> >> See https://issues.jboss.org/browse/JBIDE-12475?focusedCommentId=12714042&pag... for details and discussion. >> >> That's 6 more 'git clone' commands to run, and 3 more collections of builds, making our "release train" almost twice as long and seemingly twice as complex. >> >> I'm not sure we gain much by removing things like Xulrunner into their own git repo when it's ONLY used by VPE. Similarly, OpenShift and WS use AS and have no downstream deps, so why not include them in that git repo so you only need to fetch a single repo to do any work on OpenShift, WS, AS, Archives or JMX? >> >> We could simplify further by moving Forge into the Base repo. (Denis has Freemarker as a candidate to put in the Base chunk, but as it's only needed by Hibernatetools, why not keep it in there?) >> >> Nick >> >> On 08/24/2012 07:28 AM, André Dietisheim wrote: >>> On 08/24/2012 02:56 AM, Denis Golovin wrote: >>>> Below is the diagram I've got by analyzing dependencies it let reduce >>>> amount of components to 13 without any changes to dependencies we have >>>> now ( transitive dependencies aren't shown like openshift->common, >>>> because openshift->as and as->common). >>>> >>>> Opened questions: >>>> * openshift in as component? >>> >>> not sure if that makes sense feature-wise. AS aka sever adapter tooling >>> is only an aspect of OpenShift. >>> >>>> * forge and freemarker inside common? >>>> >>>> If we would revert central and examples dependencies and let >>>> interested components inject examples and certain functionality into >>>> central (not sure if that possible) that would be logical to have them >>>> in common component >>>> >>>> That would reduce 13 to 9 counting forge, freemarker and openshift >>>> consumed by bigger components. >>>> >>>> >>>> # Current dependencies: >>>> >>>> >>>> >>>> # final git modules dependencies >>>> >>>> >>>> >>>> Denis >>>> >>>> >>>> On 08/23/2012 12:00 PM, Nick Boldt wrote: >>>>> 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! >>>>> >>>> >>> >> > > >

12 years, 4 months

1
0
0 / 0

Maven Tools : What's next?

by Fred Bricon

After Alexey's post on the future of CDI tooling in JBT 4.X/JBDS 6.X, here's my take on the major changes happening in our Maven tooling in JBT : 1/ Although not fully Maven related : rework the JBoss Central Experience wrt our Maven archetypes : we'll provide the ability to better handle archetype/runtime compatibility, add the possibility to generate "blank" projects. All that should be made possible thanks to the JBoss Developper Framework Stacks initiative (https://issues.jboss.org/browse/JBIDE-12472). Ideally the Stacks approach should be extended to all our project examples. 2/ Provide the best Eclipse to Maven Conversion experience possible. We'll release a first iteration of a Classpath Dependency -> Maven Dependency conversion in M1 https://issues.jboss.org/browse/JBIDE-8973 But this will need to be improved : support conversion of component dependencies (from EAR projects), ability to convert jars (or a selection of jars) from a right click Automatically add remote repositories for identified dependencies which needs it. 3/Move the JAX-RS, JSF, JPA Maven configurators out of JBT and into m2e-wtp. It makes sense as nothing here depends on any JBoss technologies. Other m2e-wtp adopters requested it and Max agreed to it. This would happen for the Juno SR2 release. 4/Ideally, I'd spend more time on m2e itself to fix a number of usability issues, like being able for a user to manually set the error/warning levels, properly handle workspace dependencies with classifiers. Same thing goes for m2e-wtp : work on adding support for stuff like ejb-client 5/ Fix bugs and polish what we already have. Maybe use a profiler to see what we do wrong in our code. These are the thing I personally think should be dealt with in priority (even if other enhancement requests exist in JIRA), now if you'd really like to see something else fixed/added in JBT 4/JBDS 6, please speak up. Regards, Fred Bricon

12 years, 4 months

2
1
0 / 0

Theming in JBDS

by Mickael Istria

Hi all, I made some work on adding a theme to JBDS, as described in https://issues.jboss.org/browse/JBDS-2250 This theme is also available in JBT, although it's not activated by default. You'll need to go to Window > Preference > General > Appearance to enable it. This is currently a kind a pink/red one, and you can see it at work on the attached screenshot, or by downloading and testing a recent build of JBDS. Although I like those colors, I don't feel myself good at UI design to force JBDS to keep this theme. But, it's a luck, because CSS in Eclipse is very easy to customize and share, so if you're interested, you can easily edit this theme locally ( Window > Preference > General > Appearance ). If you don't feel easy with CSS, I recommand you to install this plugin: http://marketplace.eclipse.org/content/eclipse-4-chrome-theme . This will help you to develop some themes just by picking colors. It's way easier than writing CSS, I used this to create current one. If you have any CSS you like, please share it on ticket JBDS-2250 and attach a screenshot, we can go for a vote to choose which one we enable by default in JBDS. -- 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>

12 years, 4 months

1
0
0 / 0

Fwd: Jenkins build is back to normal : jbosstools-3.3_trunk.component--common #1056

by Rob Stryker

Hi all: I went ahead and committed a significant change to the 'common' component. I had +1's from build and from the PM (max). I had what seemed like a +1 from the common lead (Dennis), but I know in my heart he hadn't fully had time to evaluate the patch. The reasons I went ahead and committed this patch on the weekend are that we have only 1 week left for freeze. With everyone pushing tons of small changes in this week, the merge would only get more and more difficult to perform, and a broken build would become more and more troublesome. Even still, I had to merge in changes from Viacheslav Kabanovich who made commits to o.j.t.common. So, what does this mean for everyone? It means anyone doing any work on 'common' at all, anyone who has it in their dev workspace, or anyone who builds it often locally, will need to cd trunk/common; svn update; They will also need to make sure that the o.j.t.common.core plugin is added to their workspace. There was only a small hiccup in the first build after commit. Two classes I had crafted by hand by accident were not properly svn-added. THe second and third builds all went off perfectly, however. I hope I didn't step on anyone's toes here, but I figured if we had any hope on getting it in before m1 is frozen, it had to be done this weekend, and I figured the weekend is a very quiet and safe time to do it (so long as I don't mess it up ;) ). Anyway, I am now resolving JBIDE-12469 which was associated with this bug, and will open a new bug for m2. Remember: anyone doing any dev work on common will need to svn update! If they have any uncommitted changes in their workspace against o.j.t.common, they will probably need to merge these changes in locally to the same class in the o.j.t.common.core plugin. Anyone importing o.j.t.common packages will be unaffected at this time. HOWEVER, after m1 is released, there *WILL* be a package rename, and at that time, ALL consumers of these classes will need to re-organize their inputs. Just be alert everyone. WIth JBT scheduled for 4.0.0 next year, this is going to be a very active year, with plugins, features, and entire components being added, removed, moved around, or significantly changed. Let's keep communication open to make sure everything gets done. - Rob Stryker, still making trouble. -------- Original Message -------- Subject: Jenkins build is back to normal : jbosstools-3.3_trunk.component--common #1056 Date: Sat, 25 Aug 2012 02:30:37 -0400 (EDT) From: ci-builds(a)redhat.com To: rob.stryker(a)jboss.com See <http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.component--com...>

12 years, 4 months

3
2
0 / 0

Number One Prize Winning European Manufacturer of Consumer, Professional and Industrial Wipes in Global Distribution

by Marketing - European OPS - NO REPLY See Below

WE MANUFACTURE AND EXTENSIVE LINE OF CHEMICAL, INDUSTRIAL, PROFESSIONAL VEHICULAR, AND OTHER PRODUCTS For Further Information Including Distribution Opportunities Contact FALKEN EUROPE INC – Clean Plus® Product Group, Holbergs Gate 19; 0166 Oslo, Norway Tel : +47 2298 2080 Fax : +47 2298 2089 Email : info(a)cleanplus.com www.cleanplus.com Love Clean Plus®, but at this time, please Unsubscribe Nature of communication : transactional or relationship Opt’in It is agreed and confirm, that you indicated your desire to receive news and similar communications when you registered on our website(s), at a tradeshow, or at a business or collegial meeting. We respect your privacy and will never release data we’ve collected from you to anyone. This Email as used in a a business setting is intended to fully comply with the dispositions of the CAN-SPAM act (The Act), and provides the recipient the unconditional right to ensure that no further Email is forthcoming. The Act is not limited to bulk mail. It covers any electronic message the primary purpose of which is the advertisement or promotion of a product, regardless of to whom addressed. Thus, in the absence of an immediate “Opt-Out” by recipient, it is agreed, as the case may be and apply, that the foregoing Email is deemed (i) to have been addressed by the person or business who initiated it, and is fully compliant with the requirement of truthful routing information, (ii) the subject line accurately reflects the content, (iii) if relevant, to conspicuously disclose that it is an advertisement, (iv) to contain the valid physical or registered address of the sender, (v) to include a clear and conspicuous explanation on how the recipient may opt out from all future mailings, (vi) to contain a free opt out mechanism. Moreover, recipient is deemed to confirm that he or she has not previously opted out in respect of to the Email address of recipient herein. All parties herein agree to a binding presumption of good faith compliance. Whenever reasonable, or whenever so asserted, this Email shall be deemed of a transactional or relationship basis, intent on facilitating an update of an ongoing or past transaction.

12 years, 4 months

1
0
0 / 0

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

by Max Rydahl Andersen

> Sorry for being late to this thread, but been on 3 weeks vacation. > > Hi Max, welcome back. Don't worry about being late - Rob was fantastic help! Is it me or you that keeps taking jbosstools-dev of the cc list ? With 1000s unread emails in my inbox things drown very fast these days - please keep it on the list ;) > I see that you solved your original issue by being able to repackage the proper jbossxb > and thus be able to do a JBoss Tools 3.3.x without changing it too much - awesome! > (Rob also seem to have been able to handle this specific case better in 3.4.x so that's good) > > Now that is done I would though like to take the chance to go over a few points in your email > which triggered my interest/curiosity since this issue is probably not going to be the only one you > see while going through JBoss Tools codebase :) > > > Another rule that we have is that only the latest version of stuff can > > be packaged, so that everything can be maintained as cleanly as possible. > > I understand the general idea of this but I wonder how this applies to tools which > actually bundles very specific jar's and might even bundle multiple versions of them to > be able to support functionality/integration of older runtimes. > > I'm curious on how Fedora packaging would/should handle this ? > > I'm still relatively new to working with Fedora Java stuff, but the general idea seems to be to try to > patch the source if it's possible, and then submit and try to get the patches accepted into the upstream > code, so that future versions of the Fedora package will be closer to the upstream and be easier to > maintain. It often doesn't seem to make sense for Java related stuff, for the reasons you mention above, > but I think the reason that the guideline to only have one version of a package at a time, is because each > requires time/effort, and there aren't a lot of people to maintain everything. Sure, but for some cases it actually is necessary to get the right functionality - i.e. hibernate tools won't work correctly without hibernate tools 3.5 being available. > 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 ? > > > 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) > 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 ;) > 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? > Related (I think) - is there a 'stable' update site url for Eclipse 4.2 yet? All I could find were the older Indigo and Helios ones. http://www.jboss.org/tools/download.html lists them all: http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ is the most 4.2 one. > Should we tell users to uninstall the Fedora one (how?) and then install the real JBoss Tools if they want to do this ? > > That one is easy: yum remove eclipse-jbosstools-* Yeah I know its easy but I just wanted to hear if that is what we should be saying. "Want to try out JBoss Tools on Fedora ? Do yum install eclipse-jbosstools-*. But if you want the full JBoss tools use the eclipse marketplace...." > Another aspect is what to do with our JBoss Central feature - which also relies on eclipse p2 to install additional features. > Similar to how WTP server adapter wizard does, m2eclipse marketplace, mylyn etc. ...any ideas on how to handle these ? > > I haven't gotten that far yet, but I'd imagine that that should still work exactly the same. Even once we've got all of the JBoss Tools > modules packaged, I wouldn't expect the JBoss Central feature to start installing stuff via yum! :) If a user wants the Fedora package > of something, they can install via yum; if they want to install from an update site, then that will be possible too. Trying to update a > Fedora packaged version from within Eclipse will likely fail though! Yeah - thats what i'm fearing; this mix of behaviors...but I guess that is just the way things works :( > > Also, if you are interested in trying the most recent development > > version of the Fedora JBoss Spin, you can find more info on it here[3] > > and run it as a live usb image or in a vm. > > I need to try 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

12 years, 4 months

6
27
0 / 0

jbosstools-4.0_trunk.aggregate - Build # 5499 - Failure!

by ci-builds＠redhat.com

jbosstools-4.0_trunk.aggregate - Build # 5499 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-4.0_trunk.aggregate/5499/ to view the results.

12 years, 4 months

1
3
0 / 0

Fwd: Proposed New Github Component Chunks for JBoss Tools 4.0

by Max Rydahl Andersen

moving to jbosstools-dev Begin forwarded message: > From: Denis Golovin <dgolovin(a)exadel.com> > Subject: Re: Proposed New Github Component Chunks for JBoss Tools 4.0 > Date: 24 Aug 2012 02:56:58 GMT+02:00 > > Below is the diagram I've got by analyzing dependencies it let reduce amount of components to 13 without any changes to dependencies we have now ( transitive dependencies aren't shown like openshift->common, because openshift->as and as->common). > > Opened questions: > * openshift in as component? > * forge and freemarker inside common? > > If we would revert central and examples dependencies and let interested components inject examples and certain functionality into central (not sure if that possible) that would be logical to have them in common component > > That would reduce 13 to 9 counting forge, freemarker and openshift consumed by bigger components. > > > # Current dependencies: > > > > # final git modules dependencies > > > > Denis > > > On 08/23/2012 12:00 PM, Nick Boldt wrote: >> 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! >> >

12 years, 4 months

2
2
0 / 0

Codefreeze friday 31st august for a Juno JBoss Tools 4.0 M1 release

by Max Rydahl Andersen

Hi, We would like to get a M1 release out for deeper Juno testing. Any objections/concerns on what is trunk by friday being branched of and released as a JBT 4 M1 ? Please answer back: Yes or No, <reason> Thanks, /max

12 years, 4 months

6
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-dev August 2012