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 Wed, 19 Dec 2007 21:27:35 GMT
I am not actually building Willy Coyote a slingshot so the spelling mistakes
are just typos in the email.

I managed to get that to work, however, I don't understand the concepts
behind these conf declarations or why we are using them with the publish
dependency structure. I went through the tutorials again but nothing seems
to be setting in my little brain.

So, this brings me to two questions:

1) Can someone explain why putting conf="web->common" on my dependency
worked? What do the web and common pieces mean?

2) Now that it is "dependent" it is pulling in all the dependencies that
library had. One of these is the commons-logging jar which has a declared
dependency on servlet-api. This jar should not be deployed in my war file
but Ivy is collecting it together with all the rest anyway causing the
deploy to fail.

How can I control the dependents dependencies and whether they get deployed
or not?

Currently, I am declaring my jars with "web", "ejb", "common", or "nodeploy"
and my ant script is including the jars under the Ivy created web folder
into the war file. It sounds like my nodeploy might be similar to your
COMPILE. If that is the case how to you effect the conf associated with jars
you do not define the dependencies for?

The commons-logging dependency declaration, downloaded into my cache,
contains this line:

    <dependency org="javax.servlet" name="servlet-api" rec="2.4"
force="true"
        conf="provided->compile(*),provided(*),runtime(*),master(*)"/>

On Dec 19, 2007 4:51 AM, Fernandes, Gerard <gerard.fernandes@lehman.com>
wrote:

>
> If you're publishing to the default configuration make sure you have the
> <info> element correctly configured. E.g.:
>
> <ivy-module version="1.4"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>            xsi:noNamespaceSchemaLocation=
>                  "http://www.jayasoft.org/misc/ivy/ivy.xsd">
>        <info organisation="acme" module="web" default="true"/>
> ...
>
> Also make sure your dependency is correctly configured, e.g.:
>                <dependency org="acme" name="common"
> rev="latest.integration" conf="COMPILE,TEST->default,RUNTIME" />
>
> This configuration will pull in the dependencies declared in the
> "acme-common" project under the RUNTIME configuration (conf="RUNTIME")
> and make them available to the current projects' COMPILE and TEST
> configurations (conf="COMPILE,TEST"). This way, you'll use Ivy to
> transitively manage dependencies between projects.
>
> Finally, enable the reporting feature and check the Ivy reports:
> <ivy:report conf="COMPILE,TEST" todir="ivy.report" xml="true"
> outputpattern="[organisation]-[module]-[conf].[ext]"/>
>
> If using Eclipse with IvyDE, you can also use the Ivy Console to see
> detailed messages on why resolution failed.
>
> As someone Crystal, Mayer has mentioned on this thread as well, you seem
> to have a typo - "slingshot" appears to be incorrectly spelled in the
> dependency section:
>
>  slingshot project has
>
>  <artifact name="slingshot"/>
>
>  coyote project has
>
>  <dependencies defaultmapping="*->default">
>      <dependency org="org.acme" name="slinshot" rev="1.0"
> conf="common"/>
>  </dependencies>
>
> -----Original Message-----
> From: esumerfd@gmail.com [mailto:esumerfd@gmail.com] On Behalf Of Edward
> Sumerfield
> Sent: 18 December 2007 22:41
> To: ivy-user@incubator.apache.org
> Subject: Re: Publishing
>
> 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
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - -
>
> 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