On Wed, Apr 16, 2008 at 9:48 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
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
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 9, 2008 at 9:14 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
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
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 repository actully contains an export of
the maven 1 repository. That's why the naming convention didn't
seemed to be always followed.
Note however, that
On Fri, Apr 11, 2008 at 8:44 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
Xavier et.al.,
Please take a look at the latest Builder resolver patch
(here
http://code.google.com/p/ivyroundup/wiki/files/builder-resolver.patch.gz)
and let me know what else is needed before this is suitable for
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 repository actully contains an export of
the maven 1 repository. That's why the
On 16/04/2008, 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 repository actully
On Wed, Apr 16, 2008 at 8:56 AM, Gilles Scokart [EMAIL PROTECTED] wrote:
On 16/04/2008, 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
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
2008/4/7 Archie Cobbs [EMAIL PROTECTED]:
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
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 Tue, Apr 8, 2008 at 6:20 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
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
On Sat, Apr 5, 2008 at 5:05 AM, Archie Cobbs [EMAIL PROTECTED] wrote:
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
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 4:56 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
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
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 10:20 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
One last question what purpose does the organization attribute
really
serve anyway?
Is it only to allow for two different organizations to create modules with
the same name?
Yes, mainly.
If so, I wonder if that
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
On Wed, Apr 2, 2008 at 7:22 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
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
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 jfoobar is the same as the entity
creating the ivy.xml file for jfoobar?
In an ideal
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 in
mind, and if it eventually looks like a
One last question what purpose does the organization attribute really
serve anyway?
Is it only to allow for two different organizations to create modules with
the same name?
If so, I wonder if that ability is really needed. Look at the RPM namespace
for example. There are lots more RPMs in
On Wed, Apr 2, 2008 at 12:48 AM, Archie Cobbs [EMAIL PROTECTED] wrote:
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
Speaking for me, I agree that the maven repository is sometimes crapy.
But how would you do better? If you think you can, please do.
Note anyway that it will never replace an internal repository that
will always be much more secure (security = availability , integrity
and confidentiality).
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 5:30 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
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...
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 6:22 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
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
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
Thinking about this more, I think it boils down to this question: do we
assume the entity creating software jfoobar is the same as the entity
creating the ivy.xml file for jfoobar?
In an ideal world, yes I agree: this would be true, and then there is no
question who the organization is.
However,
Archie Cobbs wrote:
Thinking about this more, I think it boils down to this question: do we
assume the entity creating software jfoobar is the same as the entity
creating the ivy.xml file for jfoobar?
In an ideal world, yes I agree: this would be true, and then there is no
question who the
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
Hello Archie,
I see two issues here. One is to find volunteers contributing for a work
of description. The other is to find a balance between very simple
configurations and very complicated ones.
There are potentially a lot of different dimensions along which one
could define
Archie Cobbs wrote:
So here's my dream: I want there to be an open source project somewhere out
on the web that captures the end result of performing the above steps for
any and all Java projects that exist.
I'm with you Archie :)
Also see
39 matches
Mail list logo
