Paul Sandoz wrote:
>
> Aaron Anderson wrote:
>> Hi all,
>>
>> My name is Aaron Anderson and I would like to contribute to the Jersey
>> project. The main area I believe I can assist with is to add maven
>> support to the project. I have built several maven plugins and
>> archetypes in the past and have considerable experience with the maven
>> build and deploy process as well as integrating it in with CI.
>>
>> I have already submitted some comments and an example maven project for
>> building Jersey for the maven support issue #5 Right now I am looking
>> for direction on which java.net maven repository to deploy Jersey to,
>> maven-repository or maven2-repository.
Maven plugins around Jersey tools (I guess a plugin that invokes WADL
compiler, for example) makes a lot of sense, and presumably those are
Maven2-based, so they should be naturally using maven2-repository.d.j.n.
Presumably the jersey itself is today built by Ant, and I'm bit
skeptical about someone else maintaining a parallel build in Maven.
Every time you change the build script you'd have to keep the other up
to date, and more importantly when we spin a build for a release we
don't want to create two slightly different sets of jar files (that has
different md5 hash but otherwise supposed to be the same.) It has
implications for testing, for example.
So my recommendation would be either to switch to Maven completely use
that as the build mechanism, or keep the Ant build and just use the
<maven-repository-importer> task (or mvn deploy:deploy-file) to just
push the artifacts to the maven repository. This approach is somewhat
clunky, but that is what some other projects of ours do, including JAXB
and JAX-WS.
>>
>
> This is the advice from Kohsuke:
>
> "If you are using maven2 to push files, using the m2 repository is
> easier to use, and if you are using maven1 or Ant tasks to push files,
> using the m1 repository is easier. "
>
> I know very little about m1 or m2, so do not know which one is better.
> Since we are using any to build i am guessing m1 would be a better fit.
>
> Paul.
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com