On Fri, Feb 19, 2010 at 4:42 PM, krats princekart...@gmail.com wrote:
if I do
javac -classpath lib\f1.jar f2\f2.java
then, it doesnt create f1\f1.class. Instead it uses the import f1 class
from
the jar file. The class file for f1 gets created only when I the javac task
from ant. Thats why
On Sun, Jan 17, 2010 at 10:25 PM, Alexey Lunacharsky a...@katlex.comwrote:
Does anybody think about imlementation a Debian APT-like tool on the top
of an Ivy dependency manager. It can manage all java binaries and source
installation in the system on user level,
through home directory located
On Fri, Aug 21, 2009 at 9:46 AM, Dale Anson dan...@grafidog.com wrote:
Does your change improve performance of the delete task at all? I recently
replaced many of the calls to delete in our build files with an exec call to
rm, since profiling showed the delete task was responsible for over
Disassembling the class file shows this:
String.valueOf(null)
- INVOKESTATIC java/lang/String.valueOf:([C)Ljava/lang/String;
String.valueOf((Object)null)
- INVOKESTATIC
java/lang/String.valueOf:(Ljava/lang/Object;)Ljava/lang/String;
In the case of an ambiguous method call, the compiler
Might want to mention the new packager resolver :-)
-Archie
On Sun, Jan 18, 2009 at 4:38 PM, Maarten Coene maarten_co...@yahoo.comwrote:
Hi,
I prepared the announcement text for the 2.0.0 release of Ivy (see below).
Please post your feedback quickly, I would like to announce it on monday or
Thanks!
One question... I noticed that nobody seems to be committing to ivy's trunk
lately... why is that? When will this and other recent changes get merged
upward?
I guess I'm used to changes always going into trunk first, and then being
merged into more stable branches (e.g. using svnmerge),
I think this is a good idea. I think we can also do it in a way that
satisfies the security conscious.
For example, we have add a new setting on the packager resolver e.g.
restricted=true/false that would either restrict the ant operations to the
ones allowed now (if true), otherwise allow all
create.
On 11/12/2008, at 3:56 AM, Archie Cobbs wrote:
I just filed a couple of bugs relating to the nested ant invocations used
by
Ivy's new packager resolver. Basically, errors in the nested ant
invocation
are being ignored by the outer ant invocation. I'm not exactly sure
I just filed a couple of bugs relating to the nested ant invocations used by
Ivy's new packager resolver. Basically, errors in the nested ant invocation
are being ignored by the outer ant invocation. I'm not exactly sure if this
is an ivy problem or an ant problem (I suspect the former) and am
On Sat, Jun 7, 2008 at 3:39 AM, Xavier Hanin [EMAIL PROTECTED] wrote:
OK the name has been changed to packager resolver and the Ivy RoundUp
repository site (which also hosts the ivy patch file) has been updated.
Just getting back to this after a while doing other things...
I don't have
On Thu, May 8, 2008 at 12:28 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
On Wed, May 7, 2008 at 9:05 AM, Archie Cobbs [EMAIL PROTECTED] wrote:
On Wed, May 7, 2008 at 6:40 AM, Nicolas Lalevée [EMAIL PROTECTED] wrote:
So I would say that it is *packaging* modules into an Ivy publishable
structure
On Wed, May 7, 2008 at 9:05 AM, Archie Cobbs [EMAIL PROTECTED] wrote:
On Wed, May 7, 2008 at 6:40 AM, Nicolas Lalevée
[EMAIL PROTECTED] wrote:
So I would say that it is *packaging* modules into an Ivy publishable
structure. A packaging process that can, for some module just do some copy
On Wed, May 7, 2008 at 6:40 AM, Nicolas Lalevée [EMAIL PROTECTED]
wrote:
So I would say that it is *packaging* modules into an Ivy publishable
structure. A packaging process that can, for some module just do some copy,
jar and unjar, and for others some possible call to javac.
Then I am in
On Tue, May 6, 2008 at 11:27 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
I'd like to propose that the new builder resolver be included in ivy.
In
order to do this however, other developers need to vote yes or no. So
I'd
ask that you please let the list know your opinion.
The only thing I
I'd like to propose that the new builder resolver be included in ivy. In
order to do this however, other developers need to vote yes or no. So I'd
ask that you please let the list know your opinion.
Quick summary:
The Builder Resolver is a new Ivy resolver that supports downloading,
extracting
Not sure if my vote counts, but +1 from me in any case :-)
-Archie
On Wed, Apr 23, 2008 at 2:41 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
Hi,
There's been a discussion recently about Ivy's documentation, which end up
discussing user contributed documentation and especially the wiki.
It
On Thu, Apr 17, 2008 at 1:45 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
On Wed, Apr 16, 2008 at 9:48 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
Since Ivy RoundUp builds its repository using ant, it would be easy to
add
meta-data meta-data that would handle things like backward-compatible
On Wed, Apr 16, 2008 at 1:38 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
The link gives a 404, so I can only say what I think of the patch you
attached in your last e-mail. IMO, the patch quality is good overall.
The patch has been updated a few times since I sent that email. New patch is
On Wed, Apr 16, 2008 at 1:24 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
I think we at least need to avoid having the same inconsistencies in names
from the beginning. Having clear rules for module names and orgs (like
following the package name convention) is the only way to avoid the
On Wed, Apr 16, 2008 at 1:45 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
On Wed, Apr 16, 2008 at 8:37 AM, Gilles Scokart [EMAIL PROTECTED]
wrote:
Maven has naming conventions [1], [2].
The problem is that those conventions apeared with maven 2. maven 1
didn't had this and the maven
Xavier et.al.,
Please take a look at the latest Builder resolver patch
(herehttp://code.google.com/p/ivyroundup/wiki/files/builder-resolver.patch.gz)
and let me know what else is needed before this is suitable for inclusion in
Ivy. Hopefully it's pretty close (the documentation gives a good
On Tue, Apr 8, 2008 at 4:07 PM, Xavier Hanin [EMAIL PROTECTED] wrote:
I agree completely and this should be very easy to do... unfortunately I
have zero knowledge of maven. I do have lots of knowledge of XSLT though
so if someone could walk me through what steps need to be done for a
On Tue, Apr 8, 2008 at 2:16 AM, Xavier Hanin [EMAIL PROTECTED] wrote:
I really like it! It's simple to understand, powerful enough yet under
control. One thing that would be nice to ensure a good deal of security
would be to allow only relative paths in the file related operations. This
would
On Mon, Apr 7, 2008 at 2:56 AM, Xavier Hanin [EMAIL PROTECTED] wrote:
About the caching of build artifacts, caching doesn't occur in
findArtifactRef, so you should add some cache code before opening the
stream
on the builder artifact to get it cached.
I'm not completely sure I understand
On Mon, Apr 7, 2008 at 10:31 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
The problem I see with #2 is that now we
are adding a requirement for xalan (or equivalent) to be present when
ivy
runs. This doesn't work e.g. for the situation where ivy itself is used
to
download xalan :-)
Or you
On Thu, Apr 3, 2008 at 8:39 AM, Archie Cobbs [EMAIL PROTECTED] wrote:
I think I have enough information to go and work on a new resolver based
on these ideas... will report back later...
Here's a very rough first cut at a new builder resolver.
Here's the basic idea: it works like URLResolver
...
Thanks,
-Archie
On Thu, Apr 3, 2008 at 12:52 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
On Thu, Apr 3, 2008 at 7:13 AM, Adrian Sandor [EMAIL PROTECTED] wrote:
Archie Cobbs wrote:
Thinking about this more, I think it boils down to this question: do
we
assume the entity creating software
, Archie Cobbs [EMAIL PROTECTED] wrote:
Thanks again for the thoughtful comments.
I think the right approach for now is to stick with the current model of
setting organization as the originator of the code, not the meta-data.
However in doing that we should keep this potential packager issue
Thanks for all the comments so far regarding this idea. The first step was
to get a discussion going and so far that's worked :-)
Some more thoughts... please let me know what you think makes sense and what
doesn't...
*Organizations.* Regarding choice of organization for each module: why not
use
On Wed, Apr 2, 2008 at 11:05 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
*Organizations.* Regarding choice of organization for each module: why
not
use the name of the project as the organization for all of the ivy
modules?
That is what we do internally in our enterprise repository.
On Wed, Apr 2, 2008 at 11:40 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:
2. What happens in ivy when two different repositories in your
settings publish the same organization, name, and version of a module?
It depends on your settings, but most probably the first one will be used
and the
to be able to
separate the producing organization from the packaging organization.
So you either have to make organization the packager.. or, add another
resolution dimension (packager?)
-Archie
On Wed, Apr 2, 2008 at 12:22 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
On Wed, Apr 2, 2008 at 11:40 AM
Hi,
I've been using (and liking) Ivy for a while now and have some thoughts on
how the state of the Ivy world might be improved. I'd appreciate any
feedback...
At work we have created our own Ivy repository. This is normal and works
fine.
However, building this repository is tedious and
Hi,
I've been using (and liking) Ivy for a while now and have some thoughts on
how the state of the Ivy world might be improved. I'd appreciate any
feedback...
At work we have created our own Ivy repository. This is normal and works
fine.
However, building this repository is tedious and
34 matches
Mail list logo
