[Design of JBoss jBPM] - Re: build error
by msandoz
thanks based on your reply, i will not worry too much about 1-3.
what does concern me though is the build error that results from the script below:
<target name="run-eclipse-plugin-builder" description="launch the f**** atomic black box eclipse plugins build">
| <java classname="org.eclipse.core.launcher.Main" fork="true">
| <classpath path="${eclipse.home}/startup.jar" />
| <arg line="-application org.eclipse.ant.core.antRunner" />
| <arg line="-data ${basedir}/${workspace.dir}"/>
| <arg line="-f mainTargets.xml"/>
| <arg line="-Djbpm.cvs.root=${jbpm.cvs.root}" />
| <arg line="-DbuildDirectory=${basedir}/${workspace.dir}" />
| <arg line="-Ddocs.dir=${docs.dir}" />
| <arg line="-Declipse.dir=${eclipse.home}" />
| <arg line="-Dlib.jbpm.designer.version=${lib.jbpm.designer.version}" />
| <arg line="-Djbpm.gpd.version.tag=${jbpm.gpd.version.tag}" />
| <arg line="-Djbpm.version=${jbpm.version}" />
| <arg line="-Dlocal.repository='${local.repository}'" />
| <arg line="-DskipFetch=true" />
| </java>
| </target>
|
in jbpm.3\build\build.properties the value lib.jbpm.designer.version=3.0.13.1 is set.
what should be in the eclipse.home? is it strictly populated by the build or is it my whole eclipse install? currently i have an eclipse install there. maybe theres some kind of misconfiguration there...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053786#4053786
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053786
19 years
[Design of JBoss jBPM] - Re: build error
by msandoz
i found a few things when i turned on verbose output on ant:
1. jbpm.3/build/readme.html states that the custom build.properties file should be located in ${user.home}/jbpm/build.properties. in the ant output though it was looking for ${user.home}/.settings/jbpm/build.properties. should that be changed?
2. in the building the sources wiki page, it shows eclipse.home=c:/software/eclipse. i saw that the build was looking for the variable eclipse.dir. do i need to specify them both?
3. i have set jbpm.root to the jbpm.3 directory. is that correct?
also in the midst of the build i saw this:
run-eclipse-plugin-builder:
| Property "docs.dir" has not been set
| [java] Executing 'C:\Program Files\Java\jdk1.5.0_11\jre\bin\java.exe' with arguments:
| [java] '-classpath'
| [java] 'C:\software\eclipse\startup.jar'
| [java] 'org.eclipse.core.launcher.Main'
| [java] '-application'
| [java] Java Result: 13
| [java] 'org.eclipse.ant.core.antRunner'
| [java] '-data'
| [java] 'C:\temp\jbpm.3\designer\jpdl\org.jbpm.gd.jpdl.build/target/workspace'
| [java] '-f'
| [java] 'mainTargets.xml'
| [java] '-Djbpm.cvs.root=:pserver:anonymous:@anoncvs.forge.jboss.com:/cvsroot/jbpm'
| [java] '-DbuildDirectory=C:\temp\jbpm.3\designer\jpdl\org.jbpm.gd.jpdl.build/target/workspace'
| [java] '-Ddocs.dir=${docs.dir}'
| [java] '-Declipse.dir=C:/software/eclipse'
| [java] '-Dlib.jbpm.designer.version=3.0.13.1'
| [java] '-Djbpm.gpd.version.tag=HEAD'
| [java] '-Djbpm.version=3.2.Alpha1'
| [java] '-Dlocal.repository=c:/Users/msandoz/jbpm/repository'
| [java] '-DskipFetch=true'
| [java]
| [java] The ' characters around the executable and arguments are
| [java] not part of the command.
is that expected behavior? C:\software\eclipse\ originally had one of my eclipse installations in it but it was removed during one of the builds.
Is there an up-to-date map of what these settings and file locations should be and what the variables mean?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053777#4053777
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053777
19 years
[Design of AOP on JBoss (Aspects/JBoss)] - Annotations for Typed Advices
by flavia.rainone＠jboss.com
Hello everyone!
One of the great features we are adding to JBoss AOP 2.0 are the typed advices (before/after/after-throwing/finally). Currently, only the configuration of those by xml is implemented:
<bind pointcut="pointcut expression">
| <before name="advice name" aspect="aspect class name"/>
| </bind>
|
| <bind pointcut="pointcut expression">
| <after name="advice name" aspect="aspect class name"/>
| </bind>
|
| <bind pointcut="pointcut expression">
| <throwing name="advice name" aspect="aspect class name"/>
| </bind>
|
| <bind pointcut="pointcut expression">
| <finally name="advice name" aspect="aspect class name"/>
| </bind>
For consistency on nomenclature, we added the tag around to represent around advices:
<bind pointcut="pointcut expression">
| <around name="advice name" aspect="aspect class name"/>
| </bind>
The old tag advice will continue to be supported of course and, since we have more than one type of advice now, we say that using this tag is equivalent to using the default type of advice: around.
Now we are defining the annotation API for typed advice bindings. Currently, this API consists solely of @Bind annotation and supports only around interception:
public @interface Bind
| {
| String pointcut();
| String cflow() default "";
| }
The question here is how to extend this API to support typed advices. I am not sure of which approach would be better:
1- We can define annotations @Before, @After, @Throwing and @Finally whose signature/implementation would be equal to the @Bind annotation above. Eventually we could think of writing @Around for uniformity.
2-We can add a parameter to @Bind:
AdviceType type() default AdviceType.AROUND;
The first solution mix bindings (@Bind) with advice types (@Before, @After, etc). but looks shorter.
The second solution specify advice types as a parameter of Bind, that probably makes more sense, but will demand more typing from users.
Any thoughts on which solution would be better?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053772#4053772
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053772
19 years
[Design of JBoss jBPM] - Re: Thinking about transition attrs
by brittm
anonymous wrote : By returning a boolean true or false for displaying it or not
The problem with the EL (afaik) is that it can't call a method, such that evaluating "isUserInRole()" will not work, nor will Set.contains(), even if we could get the appropriate objects in scope.
We would need to ensure that EL has access to a complete listing of the user's roles in the form of a Map with [roleName:true] as entries. Then the EL {userRoles["admin"]} would return 'true' if the user is in the 'admin' role and would return null if not.
This is mighty ugly (but it would work). Though we still would need to figure out a way to produce the roles map and make it available. I'm just brainstorming--does anyone have a clearer idea?
anonymous wrote : What about the namespace extensions?
Sounds like an option.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053763#4053763
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053763
19 years