Just to confirm the problem Jorg originally reported is a regression starting in 6.5 SP1. It has been logged and the engineering team will be addressing it as soon as possible.

We, new Composer users, need more documentation on Composer, so please keep doing your great job writing new articles.

Rima

Many thanks for taking the time to comment. I am delighted that you are going to give Composer a shot. There is nothing more satisfying for me than user-adoption. I hope that you will find the later release of Composer “less interesting” and more inline with your initial expectations. If it is not then you know where I am.

I realized that I had not replied to Tim’s comment which I have now done. Please see this comment.

I do think that replacing the original content file (as opposed to pointing the jardef artifact at a new copy) is a simpler approach. And I’m hoping that adding the “checkout” step to the script will sort out your file handle issue. Please do let me know.

Many thanks
_Paul

Apologies for the very long wait for a reply. Unforgiveably I completely missed this comment.

Many thanks for your comment. I think you raise an excellent point with the source control issue. Let me try and answer your questions.

Firstly, I do think replacing the existing “managed” content file, as opposed to pointing the jardef artifact at a new copy, is a simpler approach overall.

As per this post you can place the content folder under source control.

Typically these content files are not derived and therefore you must place then under version control.

However, in this case the jar truely is derived so it is really up to you. If do dont it will get created/built when the project itself is built. But if you go this route you must make sure the project does get built.

If you do then I would also modify the build script to checkout the content file prior to replacing it. This should get rid of your read/write access errors and also lend itself to your standard version control workflow; i.e. the content file will be in the change set along with all your other modified files.

We know this is a hot topic. My hope is that we will productize some internal plugins to provide “BOF projects” and a much better BOF development model. I also hope that in the fullness of time we will also revisit how artifact content is managed and make this more user-oriented and inline with standard eclipse “file link” behaviors so that it can handle derived as well as non-derived use cases.

HTH
_Paul

Great article – it gave me the courage to start using Composer. Its been an interesting ride up to now, but with the advent D6.5 SP1, we’re going to take the plunge with a production implementation.

One thing thats been a rather major irritation to our developers is precisely what Tim Telcik describes above. Do you know if this is being addressed? We had a great deal of fun this week when a old BOF jar was repeatedly being uploaded. It only takes one person to forget to relink the jardef.

I’ve tried modifying the jardef artifact xml to pick up the original JAR file rather than the copy, but that causes the builder to fail since something is keeping a file handle open.

Keith

Thanks for your comments. You appear to be seeing some strange behavior “out-of-the-box” there. A new project should build /src to /bin and /Web Services/src to /Web Services/bin/classes. So, I am not sure how you ended up with different build targets?

Anyhow, the real problem is that the artifact builder builds its artifacts into /bin which is not right and sadly cant be configured either (yes I have been on at the team about this for months). As-is you would end up with artifacts in your jar! So the easiest solution to this is to build /src to a different target and then jar that up.

That is all that step really attempts to achieve. There are a few ways to achieve it and it sounds like you managed another way.

HTH to clarify the situation.
_Paul

The rule of thumb is that you check in all source files but ignore all “derived” files. One tip here is that derived files (and folders actually) should be checked as such if you view their properties. Another useful tip when deciding what needs placing under source control is to view the project using the Navigator view so you can see everyhting, rather than some filtered view.

Artifacts source files (*.type, *.jardef, *.module, *.lifecycle etc), content attached to artifact source files (i.e. content/xx/xxxxxxxx), project model files (i.e. all the dot files at the root of your project) need to be checked in. And also don’t forget the two “managed” source files in the /dar folder too.

All derived files; /bin/*, /bin-dar, classes, etc can be ignored.

I will try to document this more thoroughly in an up-coming post. Thanks for the great question.

We are trying to take advantage to Composer and Subversion to manage our Business Process. We created the process using BPM and then pulled it into Composer so that it can be added to Subversion. However when we checkout the project on the test machine there are errors when we open the Composer project.

We’re not exactly sure which files to check into Subversion. As Tim Telcik asked in his comment on Oct 6, do we need the content/xx/xxxxxx files? Composer is storing the definition for the custom activity in this directory. Your example above for the jardef changed the location to help bridge the gap between BOF and Workflow. Is there a similar bridge for BPM and Workflow?