Looking briefly it seems you may just have a typo:
[ org.acme | slingshot | 1.0 ]: configuration(s) not found in
[org.acme| slinshot |
^^^^^^^^
missing the "g" in slingshot (maybe a typo in the module's ivy.xml
file?)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edward
Sumerfield
Sent: Tuesday, December 18, 2007 5:41 PM
To: [email protected]
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 | [EMAIL PROTECTED]
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
<[EMAIL PROTECTED]>
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Edward Sumerfield
> Sent: 18 December 2007 15:49
> To: [email protected]
> 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
> <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> > Edward Sumerfield
> > Sent: 18 December 2007 13:57
> > To: [email protected]
> > 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
> > <[EMAIL PROTECTED]>
> > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> > > Edward Sumerfield
> > > Sent: 18 December 2007 00:03
> > > To: [email protected]
> > > 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
