Re: Howto publish a JAR that was not generated by Maven to the m2 repo ?

[Xavier Hanin <xa...@gmail.com>]

On 6/30/07, Steve Loughran <st...@gmail.com> wrote:
>
> On 28/06/07, Xavier Hanin <xa...@gmail.com> wrote:
> > On 6/28/07, tomdz <to...@apache.org> wrote:
> >
> > > Steve Loughran wrote:
> > >
> > > > This is something I have to write up, maybe we can extend Ivy to
> make
> > > > it easier.
> > > >
> > > > Right now here is my build file to create an izpack installer, rpms
> > > > and publish artifacts to a maven2 compatible repository:
> > > >
> > > >
> >
> http://svn.sourceforge.net/viewvc/smartfrog/trunk/core/release/build.xml?view=markup
> > > >
> > > >
> > > > The pom files and md5s are done elsewhere; every jar has a template
> > > > pom that is copied with ant property expansion (one of the
> properties
> > > > includes a comment that creates an audit trail of who created the
> pom
> > > > and when), then <checksum> is used to create the md5 signatures.
> These
> > > > are all scp'd up to the target server.
> > >
> > > Mhmm, this seems to be quite complex a thing to do with Ant (even if
> not
> > > generating an izpack installer or an rpm). An Ivy task would certainly
> > > be a nice thing to have for this.
> >
> > We already have a task for publishing artifacts to a repository, in
> these
> > artifacts you can have a pom. So it shouldn't be too hard to work on
> > something which would make it dead simple for Ant+Ivy users. For now
> using
> > maven for this seems to be pretty straightforward, so no problem :-)
>
> One thing we could do with an ivy task would be to do the resolution
> of all artifacts/versions at build time and upload a POM with a
> complete dependency graph as calculated by ivy, rather than leaving it
> to maven. I'm not 100% sure if that is a good idea, because you lose
> some of the audit trail (if an app includes, say jaxen and xom 1.0,
> does it really need jaxen or because Xom needs it, and if I update to
> xom1.1 will the dependency on jaxon go away (yes it will, as the
> classes get embedded). At the same time I like the idea of preserving
> the complete closure of build-time-dependencies (including SHA1
> checksums), even if (unlike the .NET assembly model) people have the
> right to override it with their own dependency data.


Yes, you already suggested the idea of having the complete dependency
closure in the published metadata. This could be a good improvement for
easier build reproducibility and easier integration between dependency
managers. We could avoid the lose of audit trail if the audit trail was
included with the dependency closure (something very similar to the content
of an xml Ivy report). But this means changing the format of metadata. The
solution to alter the dependencies to put all dependencies as direct
dependencies doesn't require any change in the metadata format, but you lose
too much information IMO (not only for audit trail, but also for conflict
management, the dependency depth is used to compute conflicts).

BTW, I think the initial request is just to be able to publish artifacts to
a maven repository with ease, without speaking about metadata consolidation.
For this using the Ivy publish task is pretty easy, but using maven seems to
be even easier. The main advantage I see of using Ivy for this is to avoid
installing Maven for Ant users who don't already use it. Maybe another
advantage would be to avoid the signature files copying by hand... I'll
study that more deeply when we'll publish Ivy to the maven repository.

Xavier

Can I add. that compared to testing that you have good RPMs, working
> with POMs is much easier. We could test the ivy task by running them
> past maven.
>
> To test the production RPMs I need two vmware images, one to check out
> and build the RPMs from the repository on an untainted system, then,
> another vm where we scp the rpms and sshexec the install instructions.
> VM#2 doesnt have the user who created the RPMs, and I have to parse
> the output of the rpm --install -vv operation to verify that no
> warnings about unknown users are created, then running the installed
> programs on the remote box and verifying the version strings are
> correct.  That's the kind of thing that has kept me busy yesterday:
>
> http://jira.smartfrog.org/jira/browse/SFOS?report=com.atlassian.jira.plugin.ext.subversion:subversion-project-tab
>
> I cant imagine how people did this without vmware/xen
>
> -steve
>



-- 
Xavier Hanin - Independent Java Consultant
Creator of Ivy, xooki and xoocode.org
More about me: http://xhab.blogspot.com/