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 ?
I've just committed the last bulk of changes to pom.xml, manifest.mf and feature.xml to implement https://issues.jboss.org/browse/JBIDE-9268
This change makes it so that almost all modules in jboss tools svn can now be easily versioned by using one command in the root of your module:
i.e. for cdi:
mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=3.4.0-SNAPSHOT
will correctly update all child pom's version info to 3.4.0-SNAPSHOT and any p2 metadata such as manifest.mf and feature.xml to 3.4.0.qualifier.
This means no need to manually bump each individual plugin on changes - it can now be done at a module level.
Please be aware I have simply used the highest version found in the module to use as the overall version - I have not checked if
that version is actually correct. That is up to each dev to check.
 There are some exceptions which ill cover in separate email.
The xulrunner have some weird versioning I would like to get cleaned up or at least documented why it is so:
The bundle manifests uses three different versions:
The feature uses a "merged" version in 2 different shapes:
Questions for Yahor/Denis:
1) Does these ever change ? if yes then they should have .qualifiers in the manifest
2) Any reason why a mix of .16/.16b/.19pre and 216/218 ?
I spoke with Igor this morning on IRC. He said he was out from work for
the last couple of weeks and has " a few things to do before [he]'ll get
a chance to look at the update site". Meaning anything could happen
between today and the end of the week.
He knows he's the bottleneck when it comes to m2e-wtp releases and still
expects us to do the releases ourselves, as we discussed when 0.13.0 got
I think it's really time for us to host m2e-wtp. It could be "simple"
... or not :
1 - We need to ask Sonatype to let us change the "provider" name (maybe
other mentions) of the plugins to Red Hat|JBoss by Red Hat| JBoss a Red
Hat division. Current namespace used throughout the plugin is
org.maven.ide.*, it doesn't need to change.
Provided we agree on that, then :
2 - Since we have a Nexus pro instance at JBoss, we could deploy
unzipped update sites there (similar to previous flow at Sonatype). But
I think we need to have a single update site for m2e-wtp releases, as we
do for the nightlies. As soon as we provide the single update site URL
to Igor, we won't need Sonatype, at all, for subsequent releases. Not
having that single URL means asking Igor to point to the new version URL
in their m2e marketplace, every time m2e-wtp is released.
But then it gets trickier :
3 - do we keep the current github repo
(https://github.com/sonatype/m2eclipse-wtp) or should we fork it
elsewhere (on a jboss, jbosstools or m2e-wtp account)
4 - m2e-wtp JIRA is hosted / maintained by Sonatype. It would seem
logical to migrate the issues off of their system. If so, where to and how?
5 - But then, some time in the future, who knows, m2e-wtp might be
managed under the Eclipse umbrella. Not sure we'd want to go through
*another* migration process.
So, in my opinion, doing just #1 and #2 would allow us (and the project)
to keep being productive. We need to decide first if/when we want to go
the eclipse route, before settling on #3/#4/#5.
If we can setup #2, I (or Max) 'll send a mail to Sonatype asking
permission to change the provider name and ask their opinion on the
see Igor's reply :
---------- Forwarded message ----------
From: *Igor Fedorenko* <igor(a)ifedorenko.com
Subject: Re: [m2e-dev] Questions about the Maven Builder
To: m2e-dev(a)eclipse.org <mailto:email@example.com>
In theory, builders order should not matter. Builders produce workspace
changes, so if m2e builder changed any workspace resources, this will
trigger new build cycle (assuming workspace build is ON, of course), and
these changes will be picked up by other builders.
Project metadata changes is another story. Although I have not seen this
is documented anywhere, I believe general assumption is that project
configuration is (relatively) static and does not change as a result of
project build. So if maven builder changes or updates project
configuration (things like application.xml and OSGi bundle manifest), it
sort of falls into a gray territory, in theory everything is supposed to
work, but in practice some tools may get confused and may need extra
help to "notice" new project metadata.
m2e configurators (JDT, WTP, JSF, CDI ...) are all called by the maven
builder, hence the phrase "if m2e builder changed any workspace
resources ...". As a matter of fact, resources are being created/changed
by these configurators, generating new build cycles. HIH.
On 11-07-25 12:00 AM, Fred Bricon wrote:
I'm not sure about the answer so I think it's best if I forward the
question here :
-------- Original Message --------
Subject: Maven builder
Date: Fri, 22 Jul 2011 16:30:55 -0700
From: Alexey Kazakov <akazakov(a)exadel.com
Reply-To: akazakov(a)exadel.com <mailto:firstname.lastname@example.org>
To: fbricon(a)redhat.com <mailto:email@example.com>
<mailto:firstname.lastname@example.org <mailto:email@example.com>>, jbosstools-dev
Fighting with Jose Freitas' problem with not-working code completion
for JSF tags I looked at his .project file:
There is a builder org.eclipse.m2e.core.maven2Builder which
isdeclared as the last one in the list of the builders. Eventually
we found the reason of not-working code completion. It's not related
to maven stuff at all (he didn't install JSF tools:
https://issues.jboss.org/browse/JBIDE-9397 ). But anyway, could it
be a problem if the maven builder declared last? For instance:
1. Java builder build the project.
2. CDI builder builds the project using Java model (cdi builder
should be declared after Java builder and we create a problem marker
if it's not so).
3. KB builder builds the project using Java model (so we check the
build order again).
4. WST validation builder validate the project. We extend this
validation and check if CDI, KB, Seam builders declared before the
So, what about Maven? Does it do anything that could influence CDI,
JSF, Seam and don't trigger a new cycle of building? Should we care
if maven declared after CDI/KB/WST?
I tested Jose's project and everything seems to work, but I could
Thanks for you insights.
"Have you tried turning it off and on again" - The IT Crowd
m2e-dev mailing list
m2e-dev mailing list
"Have you tried turning it off and on again" - The IT Crowd