[Design of JBoss jBPM] - Re: jBPM3 switched to maven
by jbarrez
Thomas,
I've not been able to build the trunk of jbpm3. Any ideas why?
- JBoss snapshot repo added to settings.xml
- run mvn package
This is the stacktrace :
| Listening for transport dt_socket at address: 8000
| [INFO] Scanning for projects...
| Downloading: http://snapshots.jboss.org/maven2/org/jboss/jbpm/jbpm-parent/1.0.0-SNAPSH...
| [INFO] ------------------------------------------------------------------------
| [ERROR] FATAL ERROR
| [INFO] ------------------------------------------------------------------------
| [INFO] Failed to resolve artifact.
|
| GroupId: org.jboss.jbpm
| ArtifactId: jbpm-parent
| Version: 1.0.0-SNAPSHOT
|
| Reason: Unable to download the artifact from any repository
|
| org.jboss.jbpm:jbpm-parent:pom:1.0.0-SNAPSHOT
|
| from the specified remote repositories:
| jboss-snapshots (http://snapshots.jboss.org/maven2),
| central (http://repo1.maven.org/maven2)
|
|
| [INFO] ------------------------------------------------------------------------
| [INFO] Trace
| org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.jboss.jbpm:jbpm-parent for project: org.jboss.jbpm:jbpm:pom:3.2.4-SNAPSHOT for project org.jboss.jbpm:jbpm:pom:3.2.4-SNAPSHOT
| at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
| at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
| at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
| at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
| at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
| at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
| at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
| Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.jboss.jbpm:jbpm-parent for project: org.jboss.jbpm:jbpm:pom:3.2.4-SNAPSHOT for project org.jboss.jbpm:jbpm:pom:3.2.4-SNAPSHOT
| at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
| at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
| at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
| at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
| at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
| at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
| at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
| ... 11 more
| Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.jboss.jbpm:jbpm-parent' not found in repository: Unable to download the artifact from any repository
|
| org.jboss.jbpm:jbpm-parent:pom:1.0.0-SNAPSHOT
|
| from the specified remote repositories:
| jboss-snapshots (http://snapshots.jboss.org/maven2),
| central (http://repo1.maven.org/maven2)
| for project org.jboss.jbpm:jbpm-parent
| at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:603)
| at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1366)
| ... 17 more
| Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository
|
| org.jboss.jbpm:jbpm-parent:pom:1.0.0-SNAPSHOT
|
| from the specified remote repositories:
| jboss-snapshots (http://snapshots.jboss.org/maven2),
| central (http://repo1.maven.org/maven2)
|
| at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:212)
| at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
| at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:556)
| ... 18 more
| Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository
| at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:331)
| at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:200)
| ... 20 more
| [INFO] ------------------------------------------------------------------------
| [INFO] Total time: 3 seconds
| [INFO] Finished at: Thu Jul 17 22:00:54 CEST 2008
| [INFO] Final Memory: 1M/2M
| [INFO] ------------------------------------------------------------------------
|
|
It seems that maven searches the wrong file (see line 3) in the correct folder http://snapshots.jboss.org/maven2/org/jboss/jbpm/jbpm-parent/1.0.0-SNAPSHOT/. Any ideas why?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165187#4165187
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165187
16 years, 4 months
[Design of JBoss jBPM] - Re: Defining the API Mission
by tom.baeyens＠jboss.com
i didn't yet get to mention my view on how we should support BPMN.
I think we should have a (one-way) BPMN to jPDL export functionality in the STP BPMN designer.
That fits right into our vision and strategy. Analysts can then model freely in BPMN. When they're done, they can give that BPMN analysis model as part of the requirements input to the development team. Then the development team can do an export to jPDL and further make the process executable.
After that, further iterations all happen on the jPDL executable process. The analysts will now still recognize the jPDL diagram. They still can discuss it. But further iterations will not be synchronized back to the original BPMN analysis model. (just like no one would keep their analysis UML class diagrams in sync with the implementation UML diagrams.) Once the tranlation is done to an executable process language, it becomes software is it comes under the control of the development team.
That is the bigger picture in which I see the value of a BPMN to jPDL export functionality.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164955#4164955
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164955
16 years, 4 months
[Design of JBoss jBPM] - Re: Defining the API Mission
by tom.baeyens＠jboss.com
"alex.guizar(a)jboss.com" wrote : BPMN is a vendor specification. It addresses BPM requirements from the perspective of those vendors who wrote it, not necessarily from the perspective of users. Even if significant research has gone into it, that does not mean it addresses the needs of the jBPM community.
|
| There are many elements in BPMN 1.1 that have neither been implemented nor requested in jPDL. Examples include the message flow, lanes within pools, and several event triggers and gateway types. Plus, BPMN defines the model semantics but does not address the execution. It is like having the Java Language Spec without the JVM Spec. Some vendors, e.g. Intalio, use BPEL as the execution spec. However, BPEL addresses orchestration, not workflow, and does not really fill the bill.
|
| I see no advantage in centering our execution design on BPMN: it imposes extraneous requirements and shreds no light on our particular challenges. I believe we should center it on our experiences with jBPM 3, and take BPMN compatibility as a secondary criterion.
great concrete explanation of my high level fluffy talk :-)
+1
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164952#4164952
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164952
16 years, 4 months