RFE: JDT module or put in common ?
by Max Rydahl Andersen
Hi,
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 ?
Thanks,
/max
http://about.me/maxandersen
15 years
Trunk cleanup - TPTP deleted, bpmn and flow moving?
by Max Rydahl Andersen
Hi,
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 ?
/max
http://about.me/maxandersen
15 years
jbpm versioning
by Max Rydahl Andersen
Hi Kris/Koen,
jbpm has a bunch of different versions in play:
Bundle-Version: 1.0.0.qualifier
Bundle-Version: 1.2.0.qualifier
Bundle-Version: 1.3.0.qualifier
Bundle-Version: 3.2.0.qualifier
Bundle-Version: 3.4.0.qualifier
Bundle-Version: 4.3.0.qualifier
Bundle-Version: 4.4.0.qualifier
Any sense of aligning these so there is a uniform version for the jbpm module ?
/max
http://about.me/maxandersen
15 years
Version alignment completed - now you got the power and responsibility! :)
by Max Rydahl Andersen
Hi,
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[1] modules in jboss tools svn can now be easily versioned by using one command in the root of your module:
i.e. for cdi:
cd trunk/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.
[1] There are some exceptions which ill cover in separate email.
/max
http://about.me/maxandersen
15 years, 1 month
Xulrunner/VPE versioning fun
by Max Rydahl Andersen
Hi,
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:
Bundle-Version: 1.9.2.16
Bundle-Version: 1.9.2.16b
Bundle-Version: 1.9.2.19pre
The feature uses a "merged" version in 2 different shapes:
/features/org.mozilla.xpcom.feature/feature.xml: version="1.9.216.qualifier"
./features/org.mozilla.xulrunner.feature/feature.xml: version="1.9.218.qualifier"
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 ?
/max
http://about.me/maxandersen
15 years, 1 month
"non-aligned" pom versions projects
by Max Rydahl Andersen
FYI, the remainder of projects that I can't cleanup without help (see previous emails) are:
find . -name pom.xml -depth 2 -maxdepth 2 -exec grep -Hi 0.0.1 {} \;
./bpel/pom.xml: <version>0.0.1-SNAPSHOT</version>
./bpmn/pom.xml: <version>0.0.1-SNAPSHOT</version>
./drools/pom.xml: <version>0.0.1-SNAPSHOT</version>
./flow/pom.xml: <version>0.0.1-SNAPSHOT</version>
./jbpm/pom.xml: <version>0.0.1-SNAPSHOT</version>
/max
http://about.me/maxandersen
15 years, 1 month
Lion VPE
by Max Rydahl Andersen
Hey,
Just to let you know that VPE at least from the basic testing I've done works as well as it did on Snow Leopard.
So that was easier than feared ;)
/max
http://about.me/maxandersen
15 years, 1 month
About m2e-wtp releases
by Fred Bricon
Hi,
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
out.
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
other questions.
WDYT?
Regards,
Fred Bricon
15 years, 1 month
Fwd: Fwd: [m2e-dev] Questions about the Maven Builder
by Fred Bricon
Hi Alexey,
see Igor's reply :
---------- Forwarded message ----------
From: *Igor Fedorenko* <igor(a)ifedorenko.com
<mailto:igor@ifedorenko.com>>
Date: 2011/7/25
Subject: Re: [m2e-dev] Questions about the Maven Builder
To: m2e-dev(a)eclipse.org <mailto:m2e-dev@eclipse.org>
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.
--
Regards,
Igor
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.
Regards,
Fred Bricon
On 11-07-25 12:00 AM, Fred Bricon wrote:
Hello World,
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
<mailto:akazakov@exadel.com> <mailto:akazakov@exadel.com
<mailto:akazakov@exadel.com>>>
Reply-To: akazakov(a)exadel.com <mailto:akazakov@exadel.com>
<mailto:akazakov@exadel.com <mailto:akazakov@exadel.com>>
To: fbricon(a)redhat.com <mailto:fbricon@redhat.com>
<mailto:fbricon@redhat.com <mailto:fbricon@redhat.com>>, jbosstools-dev
<jbosstools-dev(a)lists.jboss.org <mailto:jbosstools-dev@lists.jboss.org>
<mailto:jbosstools-dev@lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>>>
Hi Fred,
Fighting with Jose Freitas' problem with not-working code completion
for JSF tags I looked at his .project file:
http://pastebin.com/bDLDDq2C
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
WST builder.
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
miss something.
Thanks for you insights.
Regards,
Fred Bricon
--
"Have you tried turning it off and on again" - The IT Crowd
_______________________________________________
m2e-dev mailing list
m2e-dev(a)eclipse.org <mailto:m2e-dev@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________
m2e-dev mailing list
m2e-dev(a)eclipse.org <mailto:m2e-dev@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/m2e-dev
--
"Have you tried turning it off and on again" - The IT Crowd
15 years, 1 month
