ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Sumerfield" <esume...@bitbashers.org>
Subject Re: Publishing
Date Tue, 18 Dec 2007 22:41:21 GMT
You are bending me to your ways.

I now have one project, one ivy file producing one artifact. I am able to
publish my jar to the local repository.

The problem now is getting the dependent project to find and use it. The
error is:

    [ org.acme | slingshot | 1.0 ]: configuration(s) not found in
[org.acme| slinshot |
1.0]: default.
    It must be required from [org.acme | coyote | working@12341234] common

I don't see how the conf values in the publish or the dependency tags is
driving this:

  slingshot project has

  <artifact name="slingshot"/>

  coyote project has

  <dependencies defaultmapping="*->default">
      <dependency org="org.acme" name="slinshot" rev="1.0" conf="common"/>
  </dependencies>



On Dec 18, 2007 11:32 AM, Fernandes, Gerard <gerard.fernandes@lehman.com>
wrote:

>
> You're really talking three projects here - but I suppose you've
> structured it so that it's under one source tree.
>
> I'd have one project each for "acme-web", "acme-ejb" and "acme-common".
> I'd then set-up dependencies via Ivy, e.g. "acme-web" depends on
> "acme-common" and "acme-ejb" depends on "acme-common". And it'd all come
> together under an "acme-ear" project that'd be primarily a packaging
> project (i.e. not a java project).
>
> I find this way of working more manageable.
>
> But you don't have to do it the way I do it of course.
>
> If you really want different publications in the situation you're
> mentioning, you'd need one ivy.xml per project (acme-web-ivy.xml,
> acme-ejb-ivy.xml and acme-common-ivy.xml) - each with a different
> org/module name (e.g. acme/webmodule, acme/commonmodule and
> acme/ejbmodule). You'd then have to pass that ivy.xml to your ant
> target, resolve it and then publish.
>
> -----Original Message-----
> From: esumerfd@gmail.com [mailto:esumerfd@gmail.com] On Behalf Of Edward
> Sumerfield
> Sent: 18 December 2007 15:49
> To: ivy-user@incubator.apache.org
> Subject: Re: Publishing
>
> One Ivy file per project but multiple artifacts for a single project.
> Does that make this solution impossible?
>
> If publish will only copy to a single artifact name for a single ivy
> file then I don't see how I can have multiple artifacts from a single
> project/ivy file.
>
> Perhaps, a code snippet will help.
>
>   ivy.xml:
>       <publications>
>           <artifact name="acme-web"/>
>           <artifact name="acme-ejb"/>
>           <artifact name="acme-common"/>
>       </publications>
>
>    build.xml:
>        <target name="proc.build.jar">
>            <jar
> jarfile="${ouput.jar.dir}/${parm.jar.name}-${parm.conf}.jar"
> .../>
>
>            <ivy:publish
>                artifactpattern="${ouput.jar.dir}/${parm.jar.name}-${
> parm.conf}.[ext]"
>                pubrevision="${parm.jar.version}"
>                resolver="local"
>            />
>        </target>
>
> Then proc.build.jar is called 3 times with the web, ejb and common conf
> names but each publish copies the same jar to the three different names
> declared in the ivy.xml.
>
> On Dec 18, 2007 10:08 AM, Fernandes, Gerard
> <gerard.fernandes@lehman.com>
> wrote:
>
> >
> > Well, I'm doing something similar - at least it would appear so,
> > provided I've understood you correctly.
> >
> > I have a common build script that does all the compiling, testing,
> > packaging and publishing. I use this for multiple projects.
> >
> > The way to tell Ivy to publish just one (or more) artifacts is by the
> > ivy.xml <publications> element.
> >
> > So you can have a publish in Ant that does all possible combinations
> > of patterns. And you have a <publications> element that informs Ivy
> > what patterns the current project will produce. And <ivy:publish>
> > works as expected - it will only publish artifacts your project says
> > it will publish.
> >
> > Presuming one ivy.xml per project of course.
> >
> > -----Original Message-----
> > From: esumerfd@gmail.com [mailto:esumerfd@gmail.com] On Behalf Of
> > Edward Sumerfield
> > Sent: 18 December 2007 13:57
> > To: ivy-user@incubator.apache.org
> > Subject: Re: Publishing
> >
> > So, maybe I am making this harder than it needs to be. I have a set of
>
> > common targets in a build-common.xml file that are included into each
> > projects build. There is a proc.build.jar target that perform the
> > standard jaring process and it is here that I added the publish.
> >
> > So, I need a way of telling publish to only publish one jar, the one
> > that was just created. The solution below forces me to make the
> > publish ant code project specific.
> >
> > The artifactpattern solution ends up selecting the 3 different jars
> > correctly but publishing them to the same name in the local
> repository.
> >
> > I am passing into this common target the "conf", "jar name" and "jar
> > version". Can't I tell the publish task the target name of the
> > artifact for the repository?
> >
> > On Dec 18, 2007 4:31 AM, Fernandes, Gerard
> > <gerard.fernandes@lehman.com>
> > wrote:
> >
> > >
> > > I believe the default in Ivy is to look for and publish an artifact
> > > with the same name as the module in the ivy.xml configuration file.
> > >
> > > If you need to publish more than one artifact, you'd have to declare
>
> > > them under the <publications> element. E.g.:
> > >        <publications>
> > >                <artifact name="myProject" type="jar" />
> > >                <artifact name="myProject-examples" type="jar" />
> > >                <artifact name="myProject" type="source" ext="zip" />
> > >                <artifact name="myProject-examples" type="source"
> > > ext="zip" />
> > >                <artifact name="myProject-doc" type="javadoc"
> ext="zip"
> > > />
> > >                <artifact name="myProject-conf" type="jar" ext="zip"
> />
> > >        </publications>
> > >
> > > Then you need an <ivy:publish...> ant task in an appropriate ant
> > > target that will pick up appropriate artifact patterns and publish
> > > them - after your ant script has built and packaged artifacts that
> > > match the pattern you will pick up. E.g.
> > >
> > >                <ivy:publish
> > >                                resolver="publishedLibraries"
> > >                                pubrevision="${artifact.version}">
> > >                        <artifacts
> > > pattern="${basedir}/${dist.dir}/[artifact].[ext]"/>
> > >                        <artifacts
> > > pattern="${basedir}/${dist.dir}/[artifact]-examples.[ext]"/>
> > >                        <artifacts
> > > pattern="${basedir}/${dist.dir}/[artifact]-doc.[ext]"/>
> > >                        <artifacts
> > > pattern="${basedir}/${dist.dir}/[artifact]-conf.[ext]"/>
> > >                </ivy:publish>
> > >
> > > Have a look at the Apache Ivy documentation as well for more
> details.
> > >
> > > Gerard
> > >
> > > -----Original Message-----
> > > From: esumerfd@gmail.com [mailto:esumerfd@gmail.com] On Behalf Of
> > > Edward Sumerfield
> > > Sent: 18 December 2007 00:03
> > > To: ivy-user@incubator.apache.org
> > > Subject: Publishing
> > >
> > > I am just starting to understand publishing and am trying to publish
>
> > > jars generated by one eclipse project. What appears to be happening
> > > is
> >
> > > that each jar produced by the project file is being published to the
>
> > > same place in the local repository.
> > >
> > > How should I approach the problem of multiple jars being published
> > > form the same project?
> > >
> > > --
> > > Ed
> > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > -
> > > - -
> > > - - - - - - -
> > >
> > > This message is intended only for the personal and confidential use
> > > of
> >
> > > the designated recipient(s) named above.  If you are not the
> > > intended recipient of this message you are hereby notified that any
> > > review, dissemination, distribution or copying of this message is
> > > strictly prohibited.  This communication is for information purposes
>
> > > only and should not be regarded as an offer to sell or as a
> > > solicitation of an offer to buy any financial product, an official
> > > confirmation of any transaction, or as an official statement of
> > > Lehman Brothers.  Email transmission cannot be guaranteed to be
> secure or error-free.
> > > Therefore, we do not represent that this information is complete or
> > > accurate and it should not be relied upon as such.  All information
> > > is
> > subject to change without notice.
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Ed
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - -
> > - - - - - - -
> >
> > This message is intended only for the personal and confidential use of
>
> > the designated recipient(s) named above.  If you are not the intended
> > recipient of this message you are hereby notified that any review,
> > dissemination, distribution or copying of this message is strictly
> > prohibited.  This communication is for information purposes only and
> > should not be regarded as an offer to sell or as a solicitation of an
> > offer to buy any financial product, an official confirmation of any
> > transaction, or as an official statement of Lehman Brothers.  Email
> > transmission cannot be guaranteed to be secure or error-free.
> > Therefore, we do not represent that this information is complete or
> > accurate and it should not be relied upon as such.  All information is
> subject to change without notice.
> >
> >
> >
> >
>
>
> --
> Ed
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - -
>
> This message is intended only for the personal and confidential use of the
> designated recipient(s) named above.  If you are not the intended recipient
> of this message you are hereby notified that any review, dissemination,
> distribution or copying of this message is strictly prohibited.  This
> communication is for information purposes only and should not be regarded as
> an offer to sell or as a solicitation of an offer to buy any financial
> product, an official confirmation of any transaction, or as an official
> statement of Lehman Brothers.  Email transmission cannot be guaranteed to be
> secure or error-free.  Therefore, we do not represent that this information
> is complete or accurate and it should not be relied upon as such.  All
> information is subject to change without notice.
>
>
>
>


-- 
Ed

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message