-
1. Re: jbpm project structure
tom.baeyens Feb 21, 2006 4:46 AM (in response to tom.baeyens)oops, i meant to put the new proposed structure in code format:
jbpm + jbpm (gop + config framework + jpdl + jpdl services) + etc + examples + main + the main jbpm sources + resources + config.files + test + test + identity + main + test + database (a version of the jbpm.db project that doesn't include the driver libs) + console (user console + admin console) + server + all jboss integration stuff + userguide
regards, tom. -
2. Re: jbpm project structure
jimrigsbee Feb 21, 2006 8:36 AM (in response to tom.baeyens)Are we still going to use Maven? If so, the libraries would come from the Maven repository.
Also, the directory structure should be based on the best practices for Maven for a multiproject.
Regards, Jim -
3. Re: jbpm project structure
tom.baeyens Feb 21, 2006 8:45 AM (in response to tom.baeyens)agreed.
i'm having a meeting with the QA team this afternoon. they manage the overall jboss build and think of switching to maven. there are a few issues to be resolved. since it seems that jboss is moving towards maven, i am going to check wether i can do it with maven, rather then with the jboss build system.
the only thing i really care about is the dependency resolution mechanism. both the jboss build and maven have such a dependency mechanism. ideally, i should be able to use that and still keep the project buildable with plain ant.
do you know if i can use the maven dependency resolution without a dependency on a maven installation... just ant ?
regards, tom. -
4. Re: jbpm project structure
aguizar Feb 21, 2006 1:04 PM (in response to tom.baeyens)Putting the jbpm, gpd and bpel codebases together sounds like a good idea to me. How do you think they should be integrated? I believe something along these lines
+ jbpm + jbpm + identity + database + console + server + userguide + gpd [the gpd structure] + bpel + main + examples + resources + test
-
5. Re: jbpm project structure
jimrigsbee Feb 21, 2006 7:22 PM (in response to tom.baeyens)"tom.baeyens@jboss.com" wrote:
do you know if i can use the maven dependency resolution without a dependency on a maven installation... just ant ?
No you cannot..the dependency mechanism is supplied by the core maven plugins that have nothing to do with ant.
Once you and the JBoss team define a Maven standard structure that everyone can live with, it will be a simple matter to convert it to Maven. I have lots of starter files to get us up and running quickly. I've been working with Maven very intensely for the past six months.
The other question will be Maven 1.0.2 or 2.0. I'm using 1.0.2 right now.
Regards, Jim -
6. Re: jbpm project structure
jimrigsbee Feb 21, 2006 7:35 PM (in response to tom.baeyens)Typical version 1.0.2 Maven structure:
+main root directory - project.xml <--------- this one drives the entire build + component 1 - project.xml <---------- this one builds this sub-component only + component N - project.xml <------------ "" ""
Within each of the component trees for a typical java component:+component 1 - project.xml - maven.xml - project.properties - build.properties (optional and typically in developer's home dir) +src +main +java +resources <---- any non-Java files that need to be copied to classpath +webapp <----- root of web application +test +java <---- Junit classes +resources <----- *.properties, *.xml, test files, etc. for testing only +target <----- gets built by Maven runs and can always be destroyed
Keep in mind it is best to have one product from each directory. You can also nest projects within projects within projects if it makes sense.
You can also have a project setup as a template and not have it build anything. Other projects can inherit from this...I do this with EJB and Xdoclet stuff all the time. They inherit the maven.xml, project.xml, and project.properties settings.
Regards, Jim -
7. Re: jbpm project structure
tom.baeyens Feb 22, 2006 5:16 AM (in response to tom.baeyens)alex,
the internal structure of subprojects will depend on which build system is chosen by jboss in the next two weeks. for the jbpm sub project structure, i would like something like this:+ jbpm + jbpm + identity + database + console + server + userguide + starters-kit + designer + bpel
we also might need a separate build subproject. as we now have with the jbpm.build cvs module. although i'm not sure. i think that the usage of a repository will eliminate this need and that we can rework the build so that each part can be build and tagged independently.
we will have to identify the different products that need an independant versioning. probably only the designer and bpel will remain their own release cycles as they have now.
over time, (perhaps in jbpm 4.0) i want to split jbpm into a core (=GOP) and a jpdl project. that is the time when we can also think about DB-schema extensibility. meaning, how can we have a core set of tables that jpdl and bpel can extend...
regards, tom. -
8. Re: jbpm project structure
tom.baeyens Feb 22, 2006 5:19 AM (in response to tom.baeyens)jim,
if we go for maven (and chances are quite high) then we will follow the maven guidelines as close as possible like one artifact per subproject, sub project structure, ...
regards, tom. -
9. Re: jbpm project structure
aguizar Mar 28, 2006 3:10 PM (in response to tom.baeyens)over time, (perhaps in jbpm 4.0) i want to split jbpm into a core (=GOP) and a jpdl project. that is the time when we can also think about DB-schema extensibility. meaning, how can we have a core set of tables that jpdl and bpel can extend...
+1, would be a nice design to have. Maybe the db-schema extensibility can be achieved by using different prefixes (GOP_, JPDL_, BPEL_).
A good feature of this separation is the gop module changing less frequently that the jpdl module, which would allow jpdl and bpel processes to coexist in the same database regardless the jpdl and bpel modules having different release cycles. -
10. Re: jbpm project structure
tom.baeyens Mar 29, 2006 3:11 AM (in response to tom.baeyens)yes.
i think it is possible. mainly i think there is a solution for the specific node type attributes.
these could be resolved with metadata. the data of bean style XML in a persistable object model.
i will work that out for 4.0
regards, tom.