www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <steve.lough...@gmail.com>
Subject Re: release process
Date Tue, 06 Jun 2006 15:10:35 GMT
On 06/06/06, Brett Porter <brett.porter@gmail.com> wrote:
> On 06/06/06, Steve Loughran <steve.loughran@gmail.com> wrote:
> > I'm thinking that
> >
> > 1. we should create stub poms for the various JARs
> > 2. integrate pom releases into the process
>
> Sounds good. Each optional JAR should probably declare a dependency on ant:ant.

That assumes we think that transient dependencies are a good thing. I
will attach the pom template for one of my projects as evidence that
it is not there yet. too many things include the jar files needed to
build, not what people downstream want to see. I have mixed feelings
on the whole subject, and do not implement transient downloads in the
smarfrog repository client. this is partly out of laziness, but also
for security. you get the jars whose checksums you have hard coded in
your deployment descriptors, and no otheers.

      <project>
        <modelVersion>4.0.0</modelVersion>
        <groupId>${m2.groupID}</groupId>
        <artifactId>${artifact.name}</artifactId>
        <packaging>jar</packaging>
        <version>${Version}</version>
        <dependencies>
          <dependency>
            <groupId>commons-httpclient</groupId>
            <artifactId>commons-httpclient</artifactId>
            <version>${commons-httpclient.version}</version>
            <exclusions>
              <exclusion>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
              </exclusion>
              <exclusion>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
              </exclusion>
            </exclusions>
          </dependency>
          <dependency>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging-api</artifactId>
            <version>${commons-logging.version}</version>
          </dependency>
          <dependency>
            <groupId>xerces</groupId>
            <artifactId>xercesImpl</artifactId>
            <version>${xerces.version}</version>
          </dependency>
          <dependency>
            <groupId>xerces</groupId>
            <artifactId>xmlParserAPIs</artifactId>
            <version>${xerces.version}</version>
          </dependency>
          <dependency>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging-api</artifactId>
            <version>${commons-logging.version}</version>
          </dependency>
          <dependency>
            <groupId>servletapi</groupId>
            <artifactId>servletapi</artifactId>
            <version>${servletapi.version}</version>
          </dependency>
          <dependency>
            <groupId>xom</groupId>
            <artifactId>xom</artifactId>
            <version>${xom.version}</version>
            <exclusions>
              <exclusion>
                <groupId>dom4j</groupId>
                <artifactId>dom4j</artifactId>
              </exclusion>
              <exclusion>
                <groupId>jdom</groupId>
                <artifactId>jdom</artifactId>
              </exclusion>
              <exclusion>
                <groupId>xalan</groupId>
                <artifactId>xalan</artifactId>
              </exclusion>
              <exclusion>
                <groupId>jaxme</groupId>
                <artifactId>jaxme</artifactId>
              </exclusion>
            </exclusions>
          </dependency>
        </dependencies>
      </project>

>
> If you are going to upload to the Maven 1 repo, you'd need Maven 1
> stub POMs. They're essentially no different to Maven 2 ones, and get
> converted, so that is probably best for you right now.

OK.

>
> We haven't entirely implemented a good mechanism for adding non-Maven
> projects to the Maven 2 repository and populating the required
> metadata yet, but its moving along.
>
> > Looking at the doc, there are way too many manual steps involved.
> > Manual steps get left out, or worse, done in the wrong order. Anything
> > new that we add should be automated, with some retrofitting of more
> > automation into the existing process.
>
> I'd suggest looking at Jakarta Commons wiki pages on the release
> automation wishlist too. At some point, I'm hoping to have automated
> all of that through Maven, and the non-Maven code can easily be
> shared.
>

Will do.

Mime
View raw message