You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Xavier Hanin <xa...@gmail.com> on 2008/04/19 09:18:40 UTC
[Ivy RoundUp] status of current repo
Hi,
I've noticed that Archie has done a very good job recently to update the
roundup repo with more consistent naming conventions:
http://ivyroundup.googlecode.com/svn/trunk/repo/modules.xml
I really like the consistent names, and the way data is displayed with xslt.
Great job!
There's one thing I'd like to discuss though: the jms module. First, I think
the organization should be javax.jms instead of com.sun. It's the package
name used in the API, so I think it'd better fit the naming conventions we
seem to agree on. Secondly, I see that the "build" instructions require to
download manually the archive from sun's site. I think we can do better.
jms-1.1.jar is available at least here:
http://repository.jboss.com/maven2/javax/jms/jms/1.1/jms-1.1.jar
It can also be obtained in this archive:
https://mq.dev.java.net/files/documents/5002/66518/mq4_1-binary-Linux_X86-20070816.jar,
in /mq/lib/jms.jar (it's JMS 1.1 version according to OpenMQ 4.1 Release
Notes).
Sources can be obtained in this archive:
https://mq.dev.java.net/files/documents/5002/66515/mq4_1-source.zip
they are available in /mq/src/share/java/, where only the javax/jms
directory should be used.
Javadoc are more difficult to find, in the openmq binary archive there is
javadoc for jms, but packaged with openmq javadoc, so index files are mixed,
we can't really repackage them without losing the index files.
So I could update the build instructions myself now that I have the
appropriate rights, but first I'd like to ask what do you think about the
organization name, and second what do you think about using jms jar and
sources which are not officially coming from the original source.
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: exclude dependency but resolve *its* dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Tue, Apr 22, 2008 at 9:57 AM, Clements Mark <cl...@ofac.ch> wrote:
>
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > On Mon, Apr 21, 2008 at 4:31 PM, Clements Mark <cl...@ofac.ch>
> wrote:
> > > I would like to be able to define a dependency in ivy.xml something
> like
> > > this:
> > >
> > > <dependency name="OFACOF" rev="HEAD" conf="compile,run"
> > > changing="true" >
> > > <exclude name="OFACOF"/>
> > > </dependency>
> > >
> > > ie resolving and retrieving the dependencies of OFACOF, but not have
> > > OFACOF itself available from Ivy (I want to supply it from a local
> > > project in Eclipse).
> > >
> > > Without publishing my integration version of OFACOF to a local
> > > repository, is it possible to do this? If I've missed something
> obvious
> > > in the docs could someone please point me to it?
> >
> >
> > The exclude you use should work, Ivy should exclude the dependencies
> only
> > if
> > you exclude the whole module, not the artifacts. Which artifact(s)
> does
> > OFACOF publish?
> Hi,
>
> OFACOF publishes
>
> <publications>
> <artifact name="OFACOF" type="jar"/>
> <artifact name="OFACOF" type="source" ext="src.jar"/>
> </publications>
>
> I've tried excluding the artifacts by type
>
> <dependency name="OFACOF" rev="HEAD" conf="compile,run" changing="true"
> >
>
> <exclude name="OFACOF" type="jar"/>
> <exclude name="OFACOF" type="source"/>
>
> </dependency>
>
> But I can still see OFACOF-HEAD.jar in the list for ivy.xml in Eclipse.
> As stated in my reply to Jing, I don't think it's a problem as the
> runner/debugger loads the local project first when it is specified as a
> required project.
Ok, so your problem is solved, but we still need to investigate to see if
artifact exclusion still works in Ivy. Could you open an issue in JIRA?
Xavier
>
>
> Thanks again,
>
> Mark
>
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: exclude dependency but resolve *its* dependencies
Posted by Clements Mark <cl...@OFAC.CH>.
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> On Mon, Apr 21, 2008 at 4:31 PM, Clements Mark <cl...@ofac.ch>
wrote:
> > I would like to be able to define a dependency in ivy.xml something
like
> > this:
> >
> > <dependency name="OFACOF" rev="HEAD" conf="compile,run"
> > changing="true" >
> > <exclude name="OFACOF"/>
> > </dependency>
> >
> > ie resolving and retrieving the dependencies of OFACOF, but not have
> > OFACOF itself available from Ivy (I want to supply it from a local
> > project in Eclipse).
> >
> > Without publishing my integration version of OFACOF to a local
> > repository, is it possible to do this? If I've missed something
obvious
> > in the docs could someone please point me to it?
>
>
> The exclude you use should work, Ivy should exclude the dependencies
only
> if
> you exclude the whole module, not the artifacts. Which artifact(s)
does
> OFACOF publish?
Hi,
OFACOF publishes
<publications>
<artifact name="OFACOF" type="jar"/>
<artifact name="OFACOF" type="source" ext="src.jar"/>
</publications>
I've tried excluding the artifacts by type
<dependency name="OFACOF" rev="HEAD" conf="compile,run" changing="true"
>
<exclude name="OFACOF" type="jar"/>
<exclude name="OFACOF" type="source"/>
</dependency>
But I can still see OFACOF-HEAD.jar in the list for ivy.xml in Eclipse.
As stated in my reply to Jing, I don't think it's a problem as the
runner/debugger loads the local project first when it is specified as a
required project.
Thanks again,
Mark
Re: exclude dependency but resolve *its* dependencies
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Apr 21, 2008 at 4:31 PM, Clements Mark <cl...@ofac.ch> wrote:
> Hi,
>
> I would like to be able to define a dependency in ivy.xml something like
> this:
>
> <dependency name="OFACOF" rev="HEAD" conf="compile,run"
> changing="true" >
> <exclude name="OFACOF"/>
> </dependency>
>
> ie resolving and retrieving the dependencies of OFACOF, but not have
> OFACOF itself available from Ivy (I want to supply it from a local
> project in Eclipse).
>
> Without publishing my integration version of OFACOF to a local
> repository, is it possible to do this? If I've missed something obvious
> in the docs could someone please point me to it?
The exclude you use should work, Ivy should exclude the dependencies only if
you exclude the whole module, not the artifacts. Which artifact(s) does
OFACOF publish?
Xavier
>
> Thanks very much,
>
> Mark
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: ChainResolver
Posted by Ernest Pasour <Er...@sas.com>.
I will file an issue.
I was using the SearchEngine, but unfortunately my environment has resolvers defined that aren't used by my default resolver, and this was causing me to see extra organisations/modules/etc.
Thanks for the response,
Ernest
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Monday, April 21, 2008 12:03 PM
To: ivy-user@ant.apache.org
Subject: Re: ChainResolver
On Mon, Apr 21, 2008 at 2:57 PM, Ernest Pasour <Er...@sas.com>
wrote:
> Hi. I'm use the Ivy api directly (2.0Beta1) and I ran into a small
> annoyance. My default resolver is a ChainResolver. However, the
> ChainResolver class doesn't implement methods such as listOrganisations(),
> listModules(...), or listRevisions(...). Is this intentional or something
> that will eventually be done? Right now, I'm flattening the list of
> children of my ChainResolver until I get down to a list of BasicResolvers
> that can answer those queries.
Well, the listing methods are more intended to be used internally by the
SearchEngine, which has access to each resolver individually, and as such
doesn't require for the ChainResolver to perform the listing. But as an API
it doesn't make sense. The problem is that the Ivy API is not really
defined, and still require work. ATM I'd suggest either using the
SearchEngine, or do what you do now. You can also open an issue to request
better and more consisten API for listing at resolver level.
Xavier
>
> Thanks,
> Ernest
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: ChainResolver
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Apr 21, 2008 at 2:57 PM, Ernest Pasour <Er...@sas.com>
wrote:
> Hi. I'm use the Ivy api directly (2.0Beta1) and I ran into a small
> annoyance. My default resolver is a ChainResolver. However, the
> ChainResolver class doesn't implement methods such as listOrganisations(),
> listModules(...), or listRevisions(...). Is this intentional or something
> that will eventually be done? Right now, I'm flattening the list of
> children of my ChainResolver until I get down to a list of BasicResolvers
> that can answer those queries.
Well, the listing methods are more intended to be used internally by the
SearchEngine, which has access to each resolver individually, and as such
doesn't require for the ChainResolver to perform the listing. But as an API
it doesn't make sense. The problem is that the Ivy API is not really
defined, and still require work. ATM I'd suggest either using the
SearchEngine, or do what you do now. You can also open an issue to request
better and more consisten API for listing at resolver level.
Xavier
>
> Thanks,
> Ernest
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: exclude dependency but resolve *its* dependencies
Posted by Clements Mark <cl...@OFAC.CH>.
-----Original Message-----
> From: Jing Xue [mailto:jingxue@digizenstudio.com]
> Quoting Clements Mark <cl...@OFAC.CH>:
>
> > Hi,
> >
> > I would like to be able to define a dependency in ivy.xml something
like
> > this:
> >
> > <dependency name="OFACOF" rev="HEAD" conf="compile,run"
> > changing="true" >
> > <exclude name="OFACOF"/>
> > </dependency>
> >
> > ie resolving and retrieving the dependencies of OFACOF, but not have
> > OFACOF itself available from Ivy (I want to supply it from a local
> > project in Eclipse).
> >
> > Without publishing my integration version of OFACOF to a local
> > repository, is it possible to do this? If I've missed something
obvious
> > in the docs could someone please point me to it?
>
> Setting up a local file system repo isn't that hard really - all it
> takes is mkdir and copy (or the ant counterparts).
OK - this will probably be the way I go.
>
> The only other way I can think of is to set the local project to be a
> "required project" of the target project in the later's eclipse build
> config. That would override whatever jars from the same project added
> to the classpath. Also automatically gives you association to the
> source code.
Yes, you're right. I'd missed this. I'd allowed myself to be confused by
the fact that the source for certain classes in the inheritance
structure was being loaded from ivy artefacts and others from the local
project.
Thanks - Mark
Re: exclude dependency but resolve *its* dependencies
Posted by Jing Xue <ji...@digizenstudio.com>.
Quoting Clements Mark <cl...@OFAC.CH>:
> Hi,
>
> I would like to be able to define a dependency in ivy.xml something like
> this:
>
> <dependency name="OFACOF" rev="HEAD" conf="compile,run"
> changing="true" >
> <exclude name="OFACOF"/>
> </dependency>
>
> ie resolving and retrieving the dependencies of OFACOF, but not have
> OFACOF itself available from Ivy (I want to supply it from a local
> project in Eclipse).
>
> Without publishing my integration version of OFACOF to a local
> repository, is it possible to do this? If I've missed something obvious
> in the docs could someone please point me to it?
Setting up a local file system repo isn't that hard really - all it
takes is mkdir and copy (or the ant counterparts).
The only other way I can think of is to set the local project to be a
"required project" of the target project in the later's eclipse build
config. That would override whatever jars from the same project added
to the classpath. Also automatically gives you association to the
source code.
HTH.
--
Jing
>
> Thanks very much,
>
> Mark
>
exclude dependency but resolve *its* dependencies
Posted by Clements Mark <cl...@OFAC.CH>.
Hi,
I would like to be able to define a dependency in ivy.xml something like
this:
<dependency name="OFACOF" rev="HEAD" conf="compile,run"
changing="true" >
<exclude name="OFACOF"/>
</dependency>
ie resolving and retrieving the dependencies of OFACOF, but not have
OFACOF itself available from Ivy (I want to supply it from a local
project in Eclipse).
Without publishing my integration version of OFACOF to a local
repository, is it possible to do this? If I've missed something obvious
in the docs could someone please point me to it?
Thanks very much,
Mark
ChainResolver
Posted by Ernest Pasour <Er...@sas.com>.
Hi. I'm use the Ivy api directly (2.0Beta1) and I ran into a small annoyance. My default resolver is a ChainResolver. However, the ChainResolver class doesn't implement methods such as listOrganisations(), listModules(...), or listRevisions(...). Is this intentional or something that will eventually be done? Right now, I'm flattening the list of children of my ChainResolver until I get down to a list of BasicResolvers that can answer those queries.
Thanks,
Ernest
Re: [Ivy RoundUp] status of current repo
Posted by Archie Cobbs <ar...@dellroad.org>.
Xavier,
Thanks, all good and welcome comments. I too would prefer jms to be
downloaded directly, but previously I didn't know about those other sites.
Please feel free to update the builder.xml as you see fit so we can
eliminate the manual step.
Changing the organization name from com.sun to javax.jms is fine with me
too... Sun does in fact "own" the javax.* hierarchy, so this is logical.
Thanks,
-Archie
On Sat, Apr 19, 2008 at 2:18 AM, Xavier Hanin <xa...@gmail.com>
wrote:
> Hi,
>
> I've noticed that Archie has done a very good job recently to update the
> roundup repo with more consistent naming conventions:
> http://ivyroundup.googlecode.com/svn/trunk/repo/modules.xml
>
> I really like the consistent names, and the way data is displayed with
> xslt.
> Great job!
>
> There's one thing I'd like to discuss though: the jms module. First, I
> think
> the organization should be javax.jms instead of com.sun. It's the package
> name used in the API, so I think it'd better fit the naming conventions we
> seem to agree on. Secondly, I see that the "build" instructions require to
> download manually the archive from sun's site. I think we can do better.
> jms-1.1.jar is available at least here:
> http://repository.jboss.com/maven2/javax/jms/jms/1.1/jms-1.1.jar
>
> It can also be obtained in this archive:
>
> https://mq.dev.java.net/files/documents/5002/66518/mq4_1-binary-Linux_X86-20070816.jar
> ,
> in /mq/lib/jms.jar (it's JMS 1.1 version according to OpenMQ 4.1 Release
> Notes).
>
> Sources can be obtained in this archive:
> https://mq.dev.java.net/files/documents/5002/66515/mq4_1-source.zip
> they are available in /mq/src/share/java/, where only the javax/jms
> directory should be used.
>
> Javadoc are more difficult to find, in the openmq binary archive there is
> javadoc for jms, but packaged with openmq javadoc, so index files are
> mixed,
> we can't really repackage them without losing the index files.
>
> So I could update the build instructions myself now that I have the
> appropriate rights, but first I'd like to ask what do you think about the
> organization name, and second what do you think about using jms jar and
> sources which are not officially coming from the original source.
>
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
--
Archie L. Cobbs