Review configuration files in etc

RewriteHandler also has duplicate examples of its configuration xml scattered. This should be standardized, and duplicates removed and pointed to the standard location.

Not sure what other modules are affecetd.

For reference, files in etc that aren't svn:ignored:

jdbcRealm.properties
jetty-bio.xml
jetty-jmx.xml
jetty-plus.xml
jetty-ssl.xml
jetty.xml
jetty-logging.xml
jetty-rewrite.xml
jetty-stats.xml
jetty-xinetd.xml
keystore
realm.properties

athena,

I saw a bit of discussion that you were doing this and maybe putting them into jar files...what are your plans for this? Greg and I talked about this a while back on irc or the dev list and I think the resulting consensus was that we were going to put config files into the resultant jar files, but only for jetty7. Jetty6 was going to remain mostly unchanged, keeping the antrun plugin usage in place to copy files around.

Jetty7 was going to start putting the sample configuration files in the artifacts we publish into the jar, likely in a directory based off of the packaging used in the artifact...so

jetty-rewrite-7.0.0.jar

META-INF/org/mortbay/jetty/rewrite/rewrite-config.xml

Then when we are assembling the bundle we can pull out those resources into an etc directory for the traditional jetty bundle...this jive with what you were working on with this issue?

Another option would be to have a jetty-config artifact that contains all of these sorts of config files, or simply put them in the jetty-assembly artifact itself since these files are not actually useful in the artifact itself. Greg was keen on keeping these things contained within their own artifact and then pushing them out into whatever assembly was needed and I am fine with that...

anyway, not sure about the scope of this issue was but thought I ought to toss this out since I saw some discussion on it again.

jesse

Jesse,

I've been putting the files into src/main/config/org/mortbay/rewrite/jetty-rewrite.xml, with this configuration in the parent POM creating an extra jetty-rewrite-7.0.0.-config.jar, which I believe is what Greg wants.

To be clear:

• For Jetty 6, my plan is to move all the files from etc into their respective module's src/main/config. jetty-rewrite.xml goes into contrib/jetty-rewrite-handler, jetty.xml goes into modules/jetty, and so on and so forth. These files will be copied back into etc/ using the antrun tasks.

• For Jetty 7, files will be moved out from etc/ in the same way, but there's some extra configuration in the parent POM which creates a -config.jar for each subproject when it detects the presence of a src/main/config file.

• For both cases, we will end up with nothing in etc/ that does not come from somewhere else. We can probably svn:ignore the directory.

But,

• Once I have create the config JAR files, in Jetty 7, I'm not sure how to push them to the etc/ directory, other than by doing an antrun task, which we're trying to get away from. What I'm doing now is
  1.) copy the resources into a target/config folder.
  2.) use the maven-jar-plugin to package this into a jar

    <profile>
      <id>config</id>
      <activation>
        <file>
          <exists>src/main/config</exists>
        </file>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-resources-plugin</artifactId>
            <version>2.3</version>
            <executions>
              <execution>
                <id>copy-resources</id>
                <phase>package</phase>
                <goals>
                  <goal>copy-resources</goal>
                </goals>
                <configuration>
                  <outputDirectory>${project.build.directory}/${project.artifactId}-${project.version}-config</outputDirectory>
                  <resources>
                    <resource>
                      <directory>src/main/config</directory>
                    </resource>
                  </resources>
                </configuration>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <executions>
              <execution>
                <id>package-config</id>
                <phase>package</phase>
                <goals>
                  <goal>jar</goal>
                </goals>
                <configuration>
                  <classifier>config</classifier>
                  <classesDirectory>${project.build.directory}/${project.artifactId}-${project.version}-config</classesDirectory>
                </configuration>
              </execution>
            </executions>
          </plugin>

the resulting jar file can be found in target/ and is also pushed to the repository. Does this look reasonable to you? What else do I need to be looking to be able to push them into an assembly as necessary?

• Finally,should I start renaming the files to modulename-config.xml, instead of keeping the existing jetty-modulename.xml convention? I noticed you referred to it that way in your comment above.

Athena

Athena,

producing a -config artifact is cool, but you can make use of the maven assembly plugin for that, the assembly:single or something like that...this will produce the artifact and inject it into the project model so it is uploaded to the repository (and your local repository) which is how you'll make use of it further.

Then you can use the maven-dependency-plugin to pull that artifact apart and move the file you want around as needed, perhaps even the maven-remote-resources-plugin. Take a look at the way the site-component classified artifacts are being generated with assembly xml files, and then take a look at the jetty-site and how it is built out making use of them. While there is a bit of antrun in that setup for copying files around, it is not context based, moving files around outside the project directory, it is operating in the same directory.

Honestly though, I don't think we needed to mess with jetty6 a whole lot for the build wise...we would like to generally decrease the flux going on in that branch and shift it to more maintenance type activities...sup to greg though

also, jetty-modulename.xml is fine, I misspoke

plugins you should look at using are the maven-dependency-plugin and maven-assembly-plugin...you will not need to use that profile, jar plugin or resources plugin declaration I don't believe...

Hmm okay for Jetty 6 I'm keeping it simple. I've gone through everything that I saw in etc, but i think I should wait to commit until after 6.1.15 as a lot of stuff got moved around.

Athena,

http://fisheye.codehaus.org/changelog/jetty?cs=4682

I wired up a working solution for jetty-rewrite and the jetty-assembly for jetty7 illustrating what I was talking about, using your paths and stuff as well.

You'll see that the jetty-rewrite artifact now produces a jetty-rewrite-7.0-SNAPSHOT-config.jar file which is attached to the project and installed into the local repository along with the normal artifact. It is build based on the contents of src/main/config and is structured in such a way that it can be overlaid the assembly. (src/main/config/etc/jetty-rewrite.xml -> etc/jetty-rewrite.xml)

Now if you look at the jetty-assembly pom.xml you'll see the maven resources plugin is copying the goop from the old distribution that is currently in src/main/resources (added since this is pom project) into an arbitrary location based on a property for now. Then the maven-dependency-plugin kicks in and pulls out the jetty-rewrite-7.0-SNAPSHOT-config.jar artifact out of the local repo and unpacks over the fresh copy of the layout. This puts the jetty-rewrite.xml into the correct location. Then another execution of the dependency plugin puts the jetty-rewrite-7.0-SNAPSHOT.jar into the lib directory, and another entry puts the jetty-start-7.0-SNAPSHOT.jar into the root of the assembly directory named start.jar (so its consistent with the old way of doing things). Then the assembly plugin bundles up that directory into zip, tgz and bz2 bundles which are deployed with the jetty-assembly project.

So that is the step by step that I was thinking about for wiring all this stuff together into the distribution. I like it in that it is only operating through the local repository, there is no copying around between projects, the only way things move around between projects is through the maven repository.

I believe that if we wire this up fully then we can slurp in all the required dependencies and build out that assembly correctly...then hightide will be able to use a similar deal with the dependency plugin to either pull artifacts directly or just snag that assembly and build up from there. Also, the unix-maven-plugin that trgyve wrote has an integration test for jetty that builds the deb and rpm artifacts off of that assembly as well so I think it is on the right track.

Personally I think we are best off having the assembly plugin declaration in each module that will be generating one of these -config classified jar files as it is clear popping open that pom.xml that it is building one of those files...the profile activation mechanism is a little too magic filled for me and with the tighter integration with IDE's going on its another area that can have issues...profiles have always been black magic anyway.

cheers
jesse

Hi Jesse,

Thank you! That cleared up a lot of things. I've talked to Greg, and he gave the go-ahead for doing it using the maven-assembly-plugin, so I've changed Jetty 7 and committed the changes. I've also made the changes for Jetty 6, waiting to commit until after the release.

Below is a list of the files I moved around, and which modules they ended up in:

• can't build the project, so commented out of the jetty-assembly pom.xml for now
  • • means the file is not present in this version of jetty

so...greg wants some magic....bring on the magic

http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html

I wired this up to the trunk build and there is now a jetty-assembly-descriptor module that holds the descriptors. Important to note that these will not be a part of the normal build, but a separate release project, perhaps with the jetty-parent or another one off trunk/tags setup a la the jetty-build-resources we used to share the javadoc.css file around before. I deployed a snapshot of that artifact so that ought to be fine.

Then you just add in the assembly plugin description as I do in the modules I touched and reference each descriptor from the shared descriptors that we wanted to use..

jesse

athena, you will need to update all of trunk and at least install the top level pom, I just deployed a snapshot of that pom so you might not have to anymore...

will be nice once we are back into a good clean svn setup, but for now you can cd into jetty-parent and mvn install there, then back out to top lvl and install from there.

my bet is you were just missing the right updated pom

cheers
jesse

That did the trick – I was missing the new build of jetty-parent. Thanks!

Added an slf4j-version to the jetty-assembly pom.xml, and committed the last bits for fixing up Jetty-7. cheers.