New instructions / reminder :: HOWTO build locally (when switching between milestone branch & trunk)
by Nick Boldt
Max pointed out that there's a "silent killer" in our build process,
which needs to be addressed and avoided. When a user switches from
building in trunk to building in the miletone branch, Tycho may pick the
wrong upstream deps instead of the ones from the milestone branch.
Why? Because Tycho (p2) doesn't care which stream to choose from. It
just picks the latest timestamp between your local ~/.m2 cache and the
staging site on download.jboss.org.
So, if you JUST finished building JMX from trunk locally, there'll be a
recent build of JMX in your ~/.m2 cache, but the latest on the server
for the milestone branch could be an hour old. Therefore, if you start
building Archives from the milestone branch locally, you'll build
against the trunk JMX bits in your local repo, instead of the bits on
download.jboss.org.
The workflow solutions are simple, and I've documented them here:
https://community.jboss.org/wiki/HowToBuildJBossToolsWithMaven3-WorkingWi...
If you have anything to add/fix there, please comment in
https://issues.jboss.org/browse/JBIDE-10647 or just edit the wiki directly.
Thanks!
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
11 years, 10 months
Fixing eclipse marketplace - how was Central, rich faces and AS restructured?
by Max Rydahl Andersen
Hi,
Just seen JBIDE-10640 which reveals eclipse marketplace installation is faulty and I know why - some features was splitup/rearranged and that makes the installation not be complete, i.e. rich faces feature no longer have VPE installed.
Could you who have rearranged features in M5 (and possible previous versions) please comment on jira with the feature ID's you believe should be included/removed to continue to work ?
The current list is:
<ius>
<iu>org.jboss.tools.richfaces.feature</iu>
<iu>org.jboss.tools.seam.feature</iu>
<iu>org.jboss.tools.cdi.feature</iu>
<iu>org.jboss.tools.jmx.feature</iu>
<iu>org.jboss.ide.eclipse.as.feature</iu>
<iu>org.jboss.ide.eclipse.archives.feature</iu>
<iu>org.hibernate.eclipse.feature</iu>
<iu>org.jboss.ide.eclipse.freemarker.feature</iu>
<iu>org.jboss.tools.ws.feature</iu>
<iu>org.jboss.tools.portlet.feature</iu>
<iu>org.jboss.tools.project.examples.feature</iu>
<iu>org.jboss.tools.community.project.examples.feature</iu>
<iu>org.jboss.tools.runtime.feature</iu>
<iu>org.jboss.tools.runtime.core.feature</iu>
<iu>org.jboss.tools.cdi.seam.feature</iu>
<iu>org.jboss.tools.forge.feature</iu>
<iu>org.jboss.tools.ws.jaxrs.feature</iu>
<iu>org.jboss.tools.common.jdt.feature</iu>
<iu>org.jboss.tools.runtime.as.detector.feature</iu>
<iu>org.jboss.tools.runtime.seam.detector.feature</iu>
<iu>org.jboss.tools.maven.feature</iu>
<iu>org.jboss.tools.maven.seam.feature</iu>
<iu>org.jboss.tools.maven.jsf.feature</iu>
<iu>org.jboss.tools.maven.cdi.feature</iu>
<iu>org.jboss.tools.maven.hibernate.feature</iu>
<iu>org.jboss.tools.maven.portlet.feature</iu>
<iu>org.jboss.tools.maven.jaxrs.feature</iu>
<iu>org.jboss.tools.maven.jbosspackaging.feature</iu>
<iu>org.jboss.tools.maven.project.examples.feature</iu>
<iu>org.jboss.tools.central.feature</iu>
<iu>org.jboss.tools.common.jdt.feature</iu>
<iu>org.jboss.tools.openshift.express.feature</iu>
</ius>
(also on the jira)
Let me know which if any you see missing - thanks!
Thanks,
/max
http://about.me/maxandersen
11 years, 10 months
Design Question: WTP Facets
by Rob Cernich
Hey all,
Does anybody have experience adding facets for technologies that use configurable components?
I'm in the process of integrating the SwitchYard tooling with WTP. SwitchYard contains multiple components which allow the developer to integrated with various technologies (e.g. BPM, CDI, Camel, etc.). From the following, wich is best?
1. Use a single SwitchYard facet, along with a property page that allows the user to select various component support.
2. Create a facet for each component type. (I'd probably group these under a "SwitchYard Components" category.)
3. Other???
I'm leaning toward option 2, since those facets could be constrained to include other facets (e.g. BPEL), but it also seems a bit cumbersome.
Any advice appreciated.
Thanks in advance,
Rob
11 years, 10 months
Eclipse target platform features
by Lucia Jelinkova
Hi all,
I am trying to run my SWTBot tests using Maven and Tycho. The problem is, that besides feature under test (in my case it is org.jboss.tools.portlet.feature.feature.group) I need to reference also other Eclipse related features:
org.eclipse.jst.enterprise_ui.feature.feature.group
org.eclipse.jst.web_core.feature.feature.group
org.eclipse.datatools.enablement.hsqldb.feature.feature.group
I also need to specify some plugins where I've not found corresponding feature:
org.eclipse.wst.jsdt.web.core
org.eclipse.wst.jsdt.web.support.jsp
org.eclipse.wst.jsdt.web.ui
I'd like to get rid of these dependencies by referencing only one or two features - the one of Eclipse itself (so that I can run the tests against the full Eclipse installation). I've found in my 'Eclipse Java EE IDE for Web Developers' the following features:
org.eclipse.platform.ide (The basic Eclipse platform)
org.eclipse.epp.package.jee.feature.feature.group (The JEE part)
However, on our target platform URL (http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo.S...) I can find just the first one (although also some JEE features are there). Am I just missing it? Would it be possible to change the target platform to include both of them?
Also, would it be possible to create similar site with JBDS installation so that we can test against the full product?
Thank you for the answer.
Lucia
11 years, 10 months
Project Examples
by Rob Cernich
Hey all,
SwitchYard assembles all its quickstarts into a single zip, which is published to a Maven repository. I was thinking about adding a Maven importer that would use the artifact key to locate the archive and install a specific quickstart. This is what I have envisioned:
* specify artifact key, i.e. group, artifact, version, packaging, e.g. org.switchyard.quickstarts:switchyard-quickstarts-distro:0.3.0.Final:zip.
* specify root folder, e.g. /bean-service or /demos/orders
* import all projects under the specified folder
Any opinions?
Best,
Rob
11 years, 10 months
Adding SwitchYard Tooling to JBT Update Site
by Rob Cernich
Hey all,
As the Eclipse tooling for SwitchYard starts to take form, I'd like to get the SwitchYard feature integrated into the JBT update site (probably SOA tools portion). Any idea how to go about achieving that?
Thanks in advance,
Rob
11 years, 10 months
Removal of plugin, consequences?
by Rob Stryker
Hi All:
As per JBIDE-10598, I removed the as.management.as7 plugin, since it
had been effectively replaced with as71. I also, as per JBIDE-10344,
moved the interfaces for as7 management into their own plugin called
as.management.core.
The only issue I can find so far is that any installation that still has
the old deprecated and removed plugin as.management.as7 in the plugins
folder will experience errors, tons of exceptions, during startup.
These errors are because the previous versions of jbtools will have the
as.management.as7 plugin, and it will still be referencing non-existent
interfaces that previously lived in as.core but now live in
as.management.core.
Does anyone know for sure if performing an update against an update site
will properly remove deprecated plugins which have been removed from
features? Would it be better for me to re-instate as.management.as7 as
am EMPTY plugin, put it back into the feature, and thus any update
against an update site will receive an updated empty plugin, which can
be removed later?
If an update will not remove deprecated plugins which are no longer part
of features, it seems that putting a stub plugin back into place is the
only way to solve this issue.
Any advice?
- Rob
11 years, 10 months
Maven WTP Integration
by Rob Cernich
Hey all,
I just finished adding some basic WTP support for SwitchYard and had a couple of questions regarding WTP and Maven integration. The SwitchYard facet can be added to any JEE type (although it is not currently constrained in this fashion). If the project is not already a JEE type project, the Utility Module facet is added. This effectively allows SY applications to be deployed to any JEE server.
Some of the issues:
Adding the Utility Module facet causes the module nature to be added, which always creates a META-INF/MANIFEST.MF file within the project. Is there a way to disable this behavior for Maven projects (e.g. where Maven may be generating the manifest)?
Maven project configurators run in the order they appear in the lifecycle processing. There is a Utility Module configurator that configures projects containing the Utility Module facet. However, this is executed during the compile phase and the SY configurator, which adds the Utility Module facet, runs during the process-classes phase. Because of this, the "deployables" are not configured correctly on the project (i.e. the test sources and resources are included). The current workaround is to run Maven->Update Project Configuration after the project is created or imported. Is there a way to fix this? (FYI, this is not a problem if the project is based on another JEE technology, e.g. WAR, EJB, etc.)
When running the new faceted project wizard and including the Maven facet, it would be nice if the other facets' configurations were defaulted appropriately (e.g. Java source and output folders, web resources, etc.). Is there a way to provide more useful defaults?
Sorry for the barrage of questions.
Thanks in advance,
Rob
11 years, 10 months
