[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-user
Subject:    RE: Publishing
From:       "Fernandes, Gerard" <gerard.fernandes () lehman ! com>
Date:       2007-12-19 23:00:57
Message-ID: F8B862EC45662D41AE74534FE40BE1C10497429C () lopets1exms002 ! leh ! lbcorp ! lehman ! com
[Download RAW message or body]


You can use the <exclude...> element to exclude specific artifacts e.g.:
		<dependency org="acme" name="common"
rev="latest.integration" conf="COMPILE,TEST->default,RUNTIME">
			<exclude module="servlet-api"/>
		</dependency>

I think that should work for you.

Can't comment on how or why conf="web->common" worked without seeing
your configuration. Perhaps someone with more Ivy experience than me can
commentt.

I use COMPILE, TEST, RUNTIME etc to specifically restrict artifacts
returned by Ivy. Of course the COMPILE and TEST dependencies are only
required to COMPILE and run tests - therefore they're the ones used by
Eclipse through IvyDE.

The RUNTIME configuration is used by me to declare what the component
needs to run and therefore my dependent projects only need to pull in
RUNTIME as demonstrated in the snippet above.

Usually the confs are good enough and quite effective at restricting
what artifacts get pulled in by Ivy. But sometimes an explicit
<exclude...> is required.




-----Original Message-----
From: esumerfd@gmail.com [mailto:esumerfd@gmail.com] On Behalf Of Edward
Sumerfield
Sent: 19 December 2007 21:28
To: ivy-user@incubator.apache.org
Subject: Re: Publishing

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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \
-

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.


[prev in list] [next in list] [prev in thread] [next in thread]