Is this something that can help us for 64 bit VPE ?
Begin forwarded message:
> From: Alex DeLara <do-not-reply(a)jboss.com>
> Subject: [JBoss Tools] - Re: Could not open the Visual Page Editor: Current platform 'win32.win32.x86_64' is not supported.
> Date: August 23, 2011 18:12:01 GMT+02:00
> To: Max Rydahl Andersen <max.andersen(a)redhat.com>
> JBoss Community
> Re: Could not open the Visual Page Editor: Current platform 'win32.win32.x86_64' is not supported.
> created by Alex DeLara in JBoss Tools - View the full discussion
> No kidding !!!!! I looked twice and now it's gone...
> Apparently someone is toying with renaming and moving stuff around..... how nice is that ? :|
> Did a quick navigation and came up with the link again... just remove "b5"
> Reply to this message by going to Community
> Start a new discussion in JBoss Tools at Community
With codefreeze for M3 in effect its a good time to refresh the whats new and noteworthy docs for the M3 release.
I've created https://issues.jboss.org/browse/JBIDE-9610 as usual with each component owner
as subtask owner. If some category is missing please speak up and just add it as a subtask.
If you component does have changes then add content to trunk/documentation/whatsnew and
add your component to index.html.
If your component does *not* have any changes then please *reject* the issue - *do not* just resolve it
since I use the subtask list of green/red to know if the component needs to be listed in the final docs.
p.s. there is 50+ this time (vs 9 last time) so seems new_and_noteworthy have been remembered this time - awesome ;)
But of course if you know of something else then please add them in.
On Tue, Aug 30, 2011 at 4:08 PM, Max Rydahl Andersen <
> Hi Xavier,
> you keep forgetting jbosstools-dev list for these things.
> Not this time ;-)
> > I just commited a fix to a trivial issue (
> https://issues.jboss.org/browse/JBIDE-9333), although this fix had been on
> my machine for several days (sorry about that).
> > I'm also working on fixing the other bugs, and to do so, I'm rewriting a
> the part of code that listens to changes. Before, it was an
> IncrementalProjectBuilder that would deal with ResourceDeltas, it's now a
> JavaElementChangesListener that is be notified of fine grained changes such
> as methods/fields changes, or classpath changes, for exemple. This listener
> filters the events that the JAX-RS Metamodel might be interested in and then
> notifies the Metamodel of the changes that occurred.
> > This rewrite takes more time than I expected, so I'm afraid it won't be
> done for the upcoming 3.3M3.
> But the current code in trunk is releasable correct ?
> Yes, nothing is commited yet, so it's the same as in the previous milestone
> > On the good side : instead of having to wait for a resource change (ie:
> saved), the JAX-RS Metamodel may reflect the changes while the working
> copies are modified (ie: when the developer writes code). Also, I hope that
> some pieces of the code that deal with content assist/code completion may be
> factorized or simplified.
Just a reminder, today's supposed to be the code freeze for M3, so that
I can branch SVN, get the _stable_branch jobs running again and get
something into QE's hands by Wednesday Aug 31.
Any objections? Requests for delay? I can do the branch tonight (eg., in
5-6 hrs) if that buys everyone more time to squeeze in their last few
commits before the branch happens.
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
JBIDE-8734 have a bunch of subtasks assigned to be fixed in M4 - some even been marked as resolved against M4.
Even though trunk is still M3.
I completely missed all these issues until now because they were targeted M4 - i'm going to bulk update them to M3 and reassign those that are pointing to me to my best guesses while i'm away.
And for those who have closed issues as fixed in M4 - please fix that too.
Snjezana have been working on https://issues.jboss.org/browse/JBIDE-8548 (easy Attach to Remote debugger)
and Fred is about to work on https://issues.jboss.org/browse/JBIDE-8972 (copy classpath library to project)
which both are things that actually should exist/be contributed to Eclipse JDT at some point.
The question is where do we put them today ?
Looking at existing modules putting it in common under a new plugin named org.jboss.tools.common.jdt.* is probably the best fit,
but since common is also much more than that its not the best - its actually mostly related to xmodel than anything else - and
I could see the interest in installing these JDT features without having to require all of xmodel and its editors extensions installed.
The alternative I see is creating a new module (sigh) named jdt with org.jboss.tools.jdt.* as its base and
we create a matching feature named "JBoss Tools JDT - Extensions for Eclipse JDT"
I'm leaning to the JDT module approach, but since i'm really not a fan of adding more and more modules without
a good reason I would like to hear if anyone has convincing arguments for or against this move ?
During my work on JBIDE-9268 I noticed a few "leftovers" we should either cleanup or move out. Questions inline for Kris and Koen:
bpmn - this is the leftover from the experimental work Koen did for bpmn2 editor which is now superseded by the new bpmn2 effort by KrisV and team.
I've asked Koen if it was still being used and he said no but it was a full fledged bpmn2 editor - so I suggested he move it to github and we remove it from our trunk
since its currently not being worked on.
flow - anyone know if this is used by anything but jbpm4 ? Would it make sense to move it inside jbpm instead of having it separate ?
tptp - TPTP is not present anymore in indigo/3.7 and doesn't seem to be released. Have not been in our build for a while so it is now deleted. If needed we can resurrect it.
profiler and workspaces - this still works but not used by anything. considering moving it to jbosstools github.
Comments ? Objections ?
jbpm has a bunch of different versions in play:
Any sense of aligning these so there is a uniform version for the jbpm module ?