Build System Meeting Agenda Mar 01, 2007

[pgier]

Progress Since Last Meeting
Created plugin to generate non-maven repository artifacts. The plugin is called jboss-deploy-maven-plugin
Tested the maven-wagon-webdav plugin - IT has started setting up a snapshot repository and we decided that the easiest way to upload artifacts is through webdav. The maven webdav plugin is still in beta, but it seems to work for what we need.
We started discussing some guidelines for uploading artifacts to the repositories. The wiki entries are JBossRepository and MavenRepository
Some progress was made on the JBossRetro maven plugin, but it still needs some more work.
Talked to IT about cvs to svn migration. They are working on it, and said that next week they should be able to start on the projects we requested (Serialization, repository.jboss.com, etc)


Issues to Discuss
Plan for mavenizing app server.
Any other issues to discuss?


Goals for next meeting
Finish jboss-retro plugin, and add configuration to parent pom.
Finish setting up the snapshot repository.
Set up cruise control for maven builds - this is dependent on the snapshot repository
Start creating maven builds for app server and projects that it depends on.

[pgier]

A couple of other issues to discuss
Can we use the mvn release plugin for the next release of common? This would allow us to test the release plugin, and the jboss-deploy plugin.
Can the interface to JBossRetro be changed? Currently the ant task calls the weaver through command line args. Is it ok to add direct setter methods to Weaver so that the maven plugin can call it directly? The ant task could still call Weaver through CLI params, but we could add a more direct way to call it also. Does the maven plugin need to start Weaver in a separate JVM?

[starksm64]

"pgier" wrote:

Can we use the mvn release plugin for the next release of common? This would allow us to test the release plugin, and the jboss-deploy plugin.

Yes.

"pgier" wrote:
Can the interface to JBossRetro be changed? Currently the ant task calls the weaver through command line args. Is it ok to add direct setter methods to Weaver so that the maven plugin can call it directly? The ant task could still call Weaver through CLI params, but we could add a more direct way to call it also.

Yes, the interface can be changed.

"pgier" wrote:

Does the maven plugin need to start Weaver in a separate JVM?

This is typically required in order to change the classpath.

[pgier]

"pgier" wrote:

Can we use the mvn release plugin for the next release of common? This would allow us to test the release plugin, and the jboss-deploy plugin.

Yes.

What is a good time do do this? Can I create a release next week?

"pgier" wrote:

Does the maven plugin need to start Weaver in a separate JVM?

This is typically required in order to change the classpath.

The javassist ClassPool has an appendPathList method. I think I can use this to add the necessary files to the classpath. It seems to be working, but I'm just worried that I will break something that I'm not thinking of.

[starksm64]

"pgier" wrote:

What is a good time do do this? Can I create a release next week?

Do it anytime as there are no issues needed for a 2.0.4.GA release.

[pgier]

Notes from the meeting


Should we create some kind of automatic notification for releases? This could be done through a maven plugin that sends an email or generates an RSS feed.

How should we handle thirdparty jars in our repository? One way is to set up a separate repository just for thirdparty artifacts. Another way is to allow developers to add thirdparty stuff to the snapshot repository, and then copy the required files to the release repository when a release is performed.

I started looking at some maven scripts for app server from about 1 year ago. They are out of date, but I will see what I can use from them and add them to app server 5.0.

What needs to go into the distribution file for microcontainer? We talked about creating an assembly for microcontainer, but I'm not sure if there are any old releases similar to what we want now.

[starksm64]

"pgier" wrote:

Should we create some kind of automatic notification for releases? This could be done through a maven plugin that sends an email or generates an RSS feed.

Sounds good, but this should also be integrated into the jboss.org site. Perhasp the rss feed is sufficient for that.

"pgier" wrote:

How should we handle thirdparty jars in our repository? One way is to set up a separate repository just for thirdparty artifacts. Another way is to allow developers to add thirdparty stuff to the snapshot repository, and then copy the required files to the release repository when a release is performed.

I still need the behavior of snapshot vs non-snapshot described better. We already have 'snapshot' releases in jboss and maven repositories. How does a snapshot repository come into the picture and help things. Layout the pros and cons.

"pgier" wrote:

I started looking at some maven scripts for app server from about 1 year ago. They are out of date, but I will see what I can use from them and add them to app server 5.0.

Before doing that we need to get some of the existing mavenized projects fully working. The jbossxb project is in a essentially unknown branching state. The vfs project unit tests fail because the url handler system property settings are not getting passed to the test correctly.

"pgier" wrote:

What needs to go into the distribution file for microcontainer? We talked about creating an assembly for microcontainer, but I'm not sure if there are any old releases similar to what we want now.

I'm going to create a separate thread on this in the mc forum.

[starksm64]

For the MC mavenization, see the existing dicussion on this:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=96393

I'm summarizing there.

[pgier]

"pgier" wrote:

How should we handle thirdparty jars in our repository? One way is to set up a separate repository just for thirdparty artifacts. Another way is to allow developers to add thirdparty stuff to the snapshot repository, and then copy the required files to the release repository when a release is performed.

I still need the behavior of snapshot vs non-snapshot described better. We already have 'snapshot' releases in jboss and maven repositories. How does a snapshot repository come into the picture and help things. Layout the pros and cons.

The goal of the snapshot repository is to separate development builds from release builds. Eventually we would like to have only a limited number of people with access to the releases (including alpha, beta, etc) repository. The snapshot repository will be available to all developers and will change much more often.
The limitations with the current single repository system are:
1. Release versions of artifacts can be changed by any developer with commit access to the repository.
2. There is not an easy way to clean up old builds.
3. Deploying to the repository requires the extra step of committing, and a time delay before the files appear in the repo.
4. We don't have a way to prevent snapshot versions of dependencies from being included in a release.

Having a separate snapshot repository will resolve these issues. We also don't need to have snapshots under version control. I think that maven repositories are not really meant to be under version control. The snapshot builds are basically temporary files, and the release repository should be add only and part of the release process. But it doesn't really hurt to have the releases in cvs or svn.

The only drawback I can think of is the extra complexity of having the two separate structures.

[starksm64]

How is the repository selected?

While being able to make dev releases is good, a release that is incorporated into a shared build still cannot be an arbitrary thing. Having a graph of unstable dependencies on items in a snapshot release state is a bad thing. If I put out a 2.0.0.Beta3 build of the mc to the snapshot repository and link jbossas to it, I don't expect that it will change. Certainly not in an incompatible way. Why not have a single maven repo under svn where only devs with release tech permission can put out non-snapshot releases? Does svn support that type of filename pattern permissions or is it only path based?

Having the repo under svn (not cvs due to refactoring problems) is a good thing for tracking who changed what.

[pgier]

How is the repository selected?

The deployment repository can be selected automatically based on whether you are doing a release (using the release plugin). This week I will create some documentation in the wiki with more specifics about how this will work.

If I put out a 2.0.0.Beta3 build of the mc to the snapshot repository and link jbossas to it, I don't expect that it will change.

I was thinking that alpha and beta releases would go to the releases repository, and not the snapshot repository. That way they wouldn't change.

Why not have a single maven repo under svn where only devs with release tech permission can put out non-snapshot releases? Does svn support that type of filename pattern permissions or is it only path based?

Having the repo under svn (not cvs due to refactoring problems) is a good thing for tracking who changed what.

I'm not sure if SVN could provide that type of filename matching permissions. It doesn't appear to be available without changes to the svn apache modules.
I agree with you that for now we should leave the release repository under version control, but in the future it may not be necessary.

[dmlloyd]

"pgier" wrote:

Why not have a single maven repo under svn where only devs with release tech permission can put out non-snapshot releases? Does svn support that type of filename pattern permissions or is it only path based?

Having the repo under svn (not cvs due to refactoring problems) is a good thing for tracking who changed what.

I'm not sure if SVN could provide that type of filename matching permissions. It doesn't appear to be available without changes to the svn apache modules.
I agree with you that for now we should leave the release repository under version control, but in the future it may not be necessary.

Actually, by using a pre-commit hook you can enforce any arbitrarily complex [write] permission policy you want. Unfortunately there are no hooks (to my knowledge) that can restrict read access.