Building Windup JBDS plugin
by Ondrej Zizka
Adding windup-dev list.
On 25.9.2013 04:09, Ondrej Zizka wrote:
> When $SUBJ, I see an exception from Eclipse, see below. The range is
> in MANIFEST.MF.
>
> ondra@lenovo:~/work/JBDS/windup-eclipse-plugin$ git grep 4.8.1
> tests/org.jboss.tools.windup.core.tests/META-INF/MANIFEST.MF:
> org.junit4;bundle-version="[4.8.1,5.0.0)"
How can I solve this?
Thanks,
Ondra
>
>
> [ERROR] Internal error: java.lang.RuntimeException: "No solution found
> because the problem is unsatisfiable.": ["Unable to satisfy dependency
> from org.jboss.tools.windup.core.test 1.0.0.qualifier to bundle
> org.junit4 [4.8.1,5.0.0).", "No solution found because the problem is
> unsatisfiable."] -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.RuntimeException: "No solution found because the problem is
> unsatisfiable.": ["Unable to satisfy dependency from
> org.jboss.tools.windup.core.test 1.0.0.qualifier to bundle org.junit4
> [4.8.1,5.0.0).", "No solution found because the problem is
> unsatisfiable."]
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: java.lang.RuntimeException: "No solution found because the
> problem is unsatisfiable.": ["Unable to satisfy dependency from
> org.jboss.tools.windup.core.test 1.0.0.qualifier to bundle org.junit4
> [4.8.1,5.0.0).", "No solution found because the problem is
> unsatisfiable."]
> at
> org.eclipse.tycho.p2.resolver.AbstractResolutionStrategy.newResolutionException(AbstractResolutionStrategy.java:98)
> at
> org.eclipse.tycho.p2.resolver.ProjectorResolutionStrategy.resolve(ProjectorResolutionStrategy.java:88)
> at
> org.eclipse.tycho.p2.resolver.AbstractResolutionStrategy.resolve(AbstractResolutionStrategy.java:63)
> at
> org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:126)
> at
> org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:81)
> at
> org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:374)
> at
> org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolveDependencies(P2TargetPlatformResolver.java:350)
> at
> org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:109)
> at
> org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:82)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> ... 11 more
>
>
>
> On 25.9.2013 04:02, Ondrej Zizka wrote:
>> Ian, I've built jbosstools-base 4.1.0.Final since Alpha2 build was
>> missing something 4.30.5.yadayada
>> Now I get:
>>
>> [ERROR] Missing requirement: org.jboss.tools.windup.core.test
>> 1.0.0.qualifier requires 'bundle org.junit4 [4.8.1,5.0.0)' but it
>> could not be found
>>
>> Isn't that the infamous maven version ranges bug? Did you hit it
>> ever? Mvn 3.0.4
>>
>> Thx
>>
>>
>>
>> On 25.9.2013 03:36, Ondrej Zizka wrote:
>>>
>>> On 25.9.2013 03:28, Ondrej Zizka wrote:
>>>> Hi Ian,
>>>>
>>>> I see that windup eclipse plugin needs org.jboss.tools:parent
>>>> 4.1.0.Alpha2-SNAPSHOT.
>>>>
>>>> 1) Ian, I just ponder: Why does it need JBDS and not just eclipse?
>>>> 2) Ian, Max, do I need JBDS source or can I find the artifacts
>>>> somewhere? I only found 0.0.4-SNAPSHOT
>>>> 3) Max, where do I get JBDS source code? I only found in [1] that
>>>> it's in customer portal.
>>> Found on GitHub. Now, could you please send a "how to build"
>>> link? Like, which all repos do I need to clone etc. to get the basic
>>> eclipse api to build windup against. Thx
>>>>
>>>> Thanks, Ondra
>>>>
>>>> [1]
>>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Develope...
>>>>
>>>
>>
>
12 years, 12 months
Getting the xPath or other information
by Robb Greathouse
Hi,
By the time the ArchiveMetadata is passed to SwitchYardController (or anything in Post Processing) the actual object that holds the information from the decorator is an XmlLine object. It has no information on the xPath.
I think there will have to be a lot of rework to get this to do what we want.
Robb Greathouse
Partner Enablement
Middleware Business Unit
JBoss, a Division of Red Hat
cellphone 505-507-4906
13 years
Increasing depth of rules
by Robb Greathouse
Hi,
I was wondering if you could point me to the place you found that limits the search depth?
Robb Greathouse
Partner Enablement
Middleware Business Unit
JBoss, a Division of Red Hat
cellphone 505-507-4906
13 years
POST pipeline exploration
by Rebecca Searls
As a means of not polluting the existing framework too much but to add some needed
flow of control functionality for post processing, I've been playing around with
adding a new pipeline, POST. The intent of pipeline POST is to provide a place
to add a defined order of post processing of rules flagged during the analysis
phase. I've added attribute "id" to the xpath-value rule. The 'id' is ref-ed
by rules in POST. Within POST "action" rules are provided with 0 or more ids
to be associated with an action. A list of actions are processed in the order they
are defined.
The problem I am encountering with this design is that all POST pipeline contents are
merged into a single POST pipeline class for the analysis phase. This can be
a problem if there is more than 1 POST pipeline acting upon the same ref ID.
For example if switchyard and airport both altered some_common.xml file the
last one who touched it wins. I don't see any easy way to instruct Windup
to only run switchyard if there are multiple POST pipelines present.
There is the same last-in problem if the action is associated directly with the xpath-value rule
and there is some product specific information being placed in the file.
I suppose I could add a cmd-line option and require the user to point to the file containing the POST pipeline to run.
I really hate to require that of the user however.
I'm open to suggestions.
Here is a general idea of what the pipeline would look like.
<windup:pipeline type="POST" id="My Switchyard Post Processor Pipeline">
<windup:post-process class="org.jboss.post.process.switchyard.SwitchyardController">
<windup:decorators>
<windup:action class="org.jboss.post.process.switchyard.Service">
<property name="references">
<list>
<value>switchyard:Action:create service</value>
<value>switchyard:Action:set ref</value>
</list>
</property>
</windup:action>
<windup:action class="org.jboss.post.process.switchyard.Binding">
<property name="references">
<list>
<value>switchyard:Action:binding config jms-bus</value>
<value>switchyard:Action:binding config camel</value>
</list>
</property>
</windup:action>
<!--
<windup:action class="org.jboss.post.process.common.ConfigUpdate">
<property name="references">
<list>
<value>Adjust:some_common.xml file</value>
</list>
</property>
</windup:action>
<windup:decorators>
</windup:post-process>
</windup:pipeline>
13 years
Re: [windup-dev] mvn compile requirement of switchyard in forge and Windup
by Lincoln Baxter
Hey Rebecca, thanks for the update.
Requiring a build to update configuration still seems strange to me, my guess is that this Mojo probably does some sort of class scanning to generate missing config. I can't imagine that it would be required to actually build the final config.
According to the switchyard documentation: "The SwitchYard Maven plugin merges SwitchYard application information from the source switchyard.xml file and annotated source code within the project (e.g. @Transformer)." - https://docs.jboss.org/author/display/SWITCHYARD/Project+Build+and+Valida... , so I keep my stance that building the project should not be required. There must be a way to simply write the final XML without requiring a build step - the maven plugin simply generates XML - we should be able to do so also. To require a project build would mean to require the internet, which is not a very safe thing to do when running a report. I know brad wants to limit internet access as much as possible from within windup.)
HOWEVER - As an intermediate step or a shortcut, depending on how you look at it. Doing a project build would be OK just to get things working until we figure out how to generate the final XML (either manually, or via the Switchyard config code in the switchyard-plugin.) Forge can build the project for you. That's not a big deal, no need to include anything else in the integration module. Just do this:
"switchyardProject.getFacet(PackagingFacet.class).createBuilder().build();"
That will execute a maven build, because you have included the Maven addon, which is providing the underlying `Project` implementation:
`install(furnace, AddonId.fromCoordinates("org.jboss.forge.addon:maven,2.0.0-blahblah"));`
~Lincoln
----- Original Message -----
From: "Rebecca Searls" <rsearls(a)redhat.com>
To: "Lincoln Baxter" <lbaxter(a)redhat.com>
Cc: "Robb Greathouse" <robb.greathouse(a)redhat.com>, "Brad Davis" <bdavis(a)redhat.com>
Sent: Sunday, September 8, 2013 4:05:06 PM
Subject: mvn compile requirement of switchyard in forge and Windup
Lincoln,
I have confirmed that the current switchyard plugin code for forge requires
the user compile the maven project in order for the a service or ref-service
to be listed in the switchyard.xml and accessible by SwitchYardConfigurator or SwitchyardFacet.
See (attached) the pom file of the generated switchyard project. There is a Maven mojo for configuring SwitchYard. Code is in
project https://github.com/jboss-switchyard/core.git
class tools/maven/plugins/switchyard/src/main/java/org/switchyard/tools/maven/plugins/switchyard/ConfigureMojo.java
The classes listed for execution in the pom file, introspect the generated classes and build an in memory model that is then
written to the XML file.
When creating a service or ref-service in forge the user is directed to run
mvn install. see https://github.com/jboss-switchyard/components/tools/forge/bean/src/main/...
classes org.switchyard.tools.forge.bean.BeanServicePlugin and org.switchyard.tools.forge.bean.BeanReferencePlugin
How do we want to address this in Windup moving forward?
I started playing around with the maven-invoker-plugin API's to kick off the mvn compile
but its usage appears to conflict with Furnace code.
Also I see that the following plugins are in https://github.com/jboss-switchyard/components/tools/forge/bean/src/main/... but not in https://github.com/forge/plugin-switchyard.git
common
http
jca
sca
soap
Windup may not need all of these. sca is needed for migrating soa 5 listeners.
I would be happy to add the plugin-switchyard code for sca if you would like.
13 years
Re: [windup-dev] [windup] Forge integration (changes to have windup generating switchyard classes using plugin-switchyard api) (#62)
by Rebecca Searls
Here is what I am thinking of in providing an ActionDecorator.
<!--
An example of the addition of an "actions" tag to the existing rules structure
ServiceCreationDecorator must implement an MetaActionDecorator interface.
It would have access to a generated xpath to the specific node found and
possible other information from the rule decorator.
The SwitchyardController would call the process method of this class
which would call the plugin-forge code to create the service.
-->
<windup:xpath-value description="Action : convert action class"
xpath="//*[local-name()='action' and not(starts-with(@class, 'org.jboss.soa.esb.actions'))]/@class"
effort="1" inline="true">
<windup:actions>
<windup:action description="Create Switchyard Intf/Impl service classes"
class="org.jboss.windup.switchyard.ServiceCreationDecorator" />
</windup:actions>
</windup:xpath-value>
--------------
-- Here is the schema
<xs:complexType name="xpathType">
<xs:sequence>
<xs:element name="namespace" type="xmlNamespace" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="hints" type="allBeans" minOccurs="0" maxOccurs="1"/>
<xs:element name="decorators" type="allBeans" minOccurs="0" maxOccurs="1"/>
<xs:element name="actions" type="actionsType" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="xpath" use="required" type="xs:string" />
<xs:attribute name="description" use="required" type="xs:string" />
<xs:attribute name="effort" type="xs:int" />
</xs:complexType>
<xs:complexType name="actionType">
<xs:annotation>
<xs:documentation>
Attribute class must be the fully qualified name of the class that
implements the ActionDecorator interface. The class must be available
in a jar file in the classpath of this tool. The class will be executed
in the post-analysis phase of Windup.
Attribute condition indicates when the action is to be executed.
The default value is true; (i.e. when the test condition yields true
the action will be run.) A setting of false will run this action if
the test condition yields false.
</xs:documentation>
</xs:annotation>
<xs:attribute name="description" use="optional" type="xs:string" />
<xs:attribute name="class" use="required" type="xs:string" />
<xs:attribute name="condition" use="optional" type="xs:string" default="true"/>
</xs:complexType>
-----------------
Here is the Interface
public interface MetaActionDecorator {
public void setCondition(String inline);
public boolean isCondition();
public void setDescription(String description);
public String getDescription();
public void setActionClass(String fullyQualifiedName);
public String getActionClass();
public abstract boolean process();
}
-----------------
Here is a convenience class
public abstract class ActionDecorator implements MetaActionDecorator {
private static final Log LOG = LogFactory.getLog(ChainingDecorator.class);
private boolean condition = true;
private String description;
private String fullyQualifiedName;
public void setCondition(String condition){
this.condition = BooleanUtils.toBoolean(condition);
}
public boolean isCondition(){
return condition;
}
public void setDescription(String description){
this.description = description;
}
public String getDescription(){
return this.description;
}
public void setActionClass(String fullyQualifiedName){
this.fullyQualifiedName = fullyQualifiedName;
}
public String getActionClass(){
return this.fullyQualifiedName;
}
/**
* Add rule specific processing here.
* @return
*/
public abstract boolean process();
}
----- Original Message -----
> From: "Robb Greathouse" <robb.greathouse(a)redhat.com>
> To: "Rebecca Searls" <rsearls(a)redhat.com>
> Cc: "Lincoln Baxter" <lbaxter(a)redhat.com>, "Robb Greathouse" <robb.greathouse(a)jboss.com>, "windup/windup"
> <windup(a)noreply.github.com>, "Brad Davis" <bdavis(a)redhat.com>
> Sent: Thursday, September 5, 2013 12:26:38 PM
> Subject: Re: [windup] Forge integration (changes to have windup generating switchyard classes using
> plugin-switchyard api) (#62)
>
> Hi,
>
> Ran into same issues. Agree with your analysis. As stop gap I am using the
> windup:xpath-value to test mappings. But as you point out this is not a
> good long term solution.
>
> We will need to create a migration-decorator that can handle command and
> parameter mappings.
>
> When Brad gets back we can discuss the best way to create these in accordance
> with his architecture. In the meantime, we should start collecting use case
> for mapping decorators.
>
>
> Robb Greathouse
> Partner Enablement
> Middleware Business Unit
> JBoss, a Division of Red Hat
> cellphone 505-507-4906
>
> ----- Original Message -----
> >
> > I will be interested to hear what you found out about ShrinkWrap. It seems
> > this project is just getting started up again.
> >
> > Changing the subject slightly. The implementation I currently have in
> > place
> > is not really what we want going forward.
> > My questions to Brad about how to handling the, "Action : convert action
> > class: class=org.jboss.thing.MySeviceAction"
> > and such was trying to ferret this out. Based upon information that came
> > out
> > in our conf call, the design that is wanted
> > is for each rule to have a "Post-Action-Decorator" which gets executed at
> > the
> > end of the analysis phase. For SOA we want
> > the current controller to execute each Post-Action-Decorator it finds.
> > Each
> > of these decorators performs a small (limited)
> > task. One will generate the Intf/Impl class. One will create a JMS-bus
> > service binding. One will create and bind a
> > Camel route. These are based upon the "Action : *" stmts currently
> > generated.
> >
> > As a short term workaround critical information has been appended in the
> > description message (e.g. class=org.jboss.thing.MySeviceAction,
> > busid=helloFTPChannel). This is not the desired way to this pass
> > information as we move
> > forward. Its fraught with all kinds of issues.
> >
> > I am thinking the issues and though ways to address them. I will be sharing
> > my thoughts and asking for feedback.
> > It would also be good to have this discussion in the community. I don't
> > think there are yet may subscribers to
> > windup-dev or followers of the forum. Should I start the discussion on the
> > email list anyway or should I look
> > to some other alias?
> >
> >
> >
> >
> > ----- Original Message -----
> > > From: "Lincoln Baxter, III" <notifications(a)github.com>
> > > To: "windup/windup" <windup(a)noreply.github.com>
> > > Cc: "rsearls" <rsearls(a)redhat.com>
> > > Sent: Wednesday, September 4, 2013 4:18:16 PM
> > > Subject: Re: [windup] Forge integration (changes to have windup
> > > generating
> > > switchyard classes using
> > > plugin-switchyard api) (#62)
> > >
> > > > + LOG.warn("No class attribute for
> > > > action
> > > > tag class="
> > > > + + nName.getNodeValue());
> > > > + }
> > > > +
> > > > + } else {
> > > > + String className =
> > > > StringUtils.substringAfterLast(
> > > > + nClass.getNodeValue(), ".");
> > > > + String packageName =
> > > > StringUtils.substringBeforeLast(
> > > > + nClass.getNodeValue(), ".");
> > > > +
> > > > + LOG.debug("Action tag's baseName: " +
> > > > className
> > > > + + " package: " + packageName);
> > > > +
> > > > + BeanFacet beanFacet =
> > > > facetFactory.create(project, BeanFacet.class);
> > > > + beanFacet.install();
> > > > + BeanServiceConfigurator
> > > > beanServiceConfigurator =
> > >
> > > Excellent, this is exactly the kind of integration we want to drive :)
> > > Sucks
> > > you have to use XPath, though. In reality, it's possible that ShrinkWrap
> > > Descriptors could be leveraged to provide a DSL to inspect the jbossesb
> > > XML
> > > file. Let me see what Andrew Rubinger thinks about this.
> > >
> > > ---
> > > Reply to this email directly or view it on GitHub:
> > > https://github.com/windup/windup/pull/62/files#r6165297
> > >
> >
>
13 years
