Re: Add maven2 resolver?
On Feb 9, 2008 11:45 AM, Nicolas Lalevée <[EMAIL PROTECTED]> wrote: > > Le 9 févr. 08 à 08:56, Xavier Hanin a écrit : > > > On Feb 8, 2008 11:01 PM, Nicolas Lalevée < > [EMAIL PROTECTED] > > > > > wrote: > > > >> > >> Le 8 févr. 08 à 21:29, Adrian Sandor a écrit : > >> > >>> Hi, IMHO it would be much better to build a clean, well-organized > >>> and reliable ivy repository instead of supporting that maven > >>> garbage. By the way, why was IvyRep abandoned? I think that would be > >>> the best solution, to have an official ivy rep., ideally containing > >>> artifacts too. > >>> I have nothing against [better] supporting maven reps for those who > >>> prefer it, but I don't see why it should have a higher priority than > >>> supporting an ivy rep. > >>> Anyway, I've never used maven (and from what I read about it, I > >>> avoided a world of suffering), and during the few minutes I spent > >>> with the ibiblio resolver before ditching it, I found these main > >>> problems: > >>> - bad org names > >>> - very old versions for some modules > >>> - source and javadoc artifacts not supported (except by IvyDE) > >>> Therefore the only solution was to manually build an "enterprise > >>> repository" from scratch. > >> > >> Well, to build a "entreprise repository", you will need some > >> "entreprise maintainers". And looking at the number of artifacts > >> available on ibiblio, for me it is a kind of magic to have Ivy > >> support > >> maven repositories. And we have to admit that maven is more popular > >> than Ivy, so people will still continue to publish maven artifacts, > >> even non maven-built projects as Lucene. > > > > Agreed, this is a big advantage of leveraging maven 2 repo. > > > >> > >> > >> And on the contrary, we could imagine to have some ivy.xml just next > >> to the pom.xml on the maven repositories, so we could have a IvyRep2 > >> with not that much effort from the developer (non necessarily ivy > >> ones) community. > > > > Yes, but even maintaining ivy files require a strong community if we > > want to > > have good quality metadata. That's what we tried with Ivyrep, while > > Ivy was > > being sponsored by Jayasoft. But it was just too much work compared > > to the > > result on investment. I still think that implementing a good maven 2 > > compatibility is less work than trying to build our own clean > > repository, > > and it helps users to migrate from maven 2 too. So I still think > > having a > > good maven 2 compatibility is mandatory for Ivy 2 final. Once we'll > > have a > > large user community or some sponsorship, we will probably > > reconsider the > > case of public official Ivy repository. > > > > Yes, I totally agree, I was just considering adding the possibility to > the maven2 resolver to also try to look for an ivy.xml just next to > the pom.xml (I haven't looked to the technical consequences though). Technically this is very simple in Ivy, and it just had a GET. > > Then the maven2 community could also be an Ivy community. So the > Ivyrep Adrian is looking for could be nothing more than the ibiblio one. As Adrian says, to have something really clean, you need a separate repository, because of many bad things in maven repo which can't be fixed such as bad org names (for commons modules for instance). Another problem of reusing the same repo and adding ivy files is that you then have a public repo where revision gets updated, which breaks reproducibility (when someone add a maven module without ivy.xml, and ivy.xml is added later). If we really want to provide a clean Ivy repository, I see a better way: leverage the install mechanism with namespaces and other stuff like that to create an Ivy repo from maven 2 one, and sync them over night or something like that. We'd need validation by a community of users to make sure the sync doesn't introduce bad things such as bad org names. We'd also need a policy for updating bad metadata (because we can't ensure nothing we'll ever be wrong), and this would probably require new features in Ivy (this kind of thing has already been discussed on [EMAIL PROTECTED] list in the very beginning of Ivy live at incubator if I remember well). But this is not easy to achieve, and require a good amount of work. And this kind of work require either a strong enough community, or a kind of sponsorship. Xavier > > > Nicolas > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Add maven2 resolver?
On Feb 9, 2008 12:43 PM, Adrian Sandor <[EMAIL PROTECTED]> wrote: > > >>> Therefore the only solution was to manually build an "enterprise > > >>> repository" from scratch. > > >> > > >> Well, to build a "entreprise repository", you will need some > > >> "entreprise maintainers". > > > I was talking about a private repository for me and my coworkers. It's > called "entreprise repository" in the Ivy docs. > But yes, a (public) Ivy rep needs maintainers, and I think it's not that > hard. Users can submit modules and the maintainers just need to check and > add them. A publishing procedure can be designed and enforced in order to > make it easy for maintainers. Yes, but this requires improving tooling, and the work required is not that light, when you know the number of module revisions published every day. > > > > > >> And looking at the number of artifacts > > >> available on ibiblio, for me it is a kind of magic to have Ivy > > >> support > > >> maven repositories. And we have to admit that maven is more popular > > >> than Ivy, so people will still continue to publish maven artifacts, > > >> even non maven-built projects as Lucene. > > > Yes, this is a good thing in the beginning. But in the long term, this > will > encourage people to just continue to publish things to maven, which helps > maven more than ivy. If Ivy is close to 100% compatible with maven, it helps Ivy as well as Maven. And if Ivy grows enough, then having our own repository wold make much more sense. I simply think that it's still too early. I think we first need to make Ivy grow with compelling features rather than trying to build our own repo (also because I've already tried to build an Ivy repo, and know how hard it is). So if we speak about growing, here is what I think is important: - make Ivy close to 100% compatible with maven, and at least never "break". If sometimes Ivy doesn't understand one dependency, or resolve dependencies slightly differently, I don't think it's that important if people can fix it in their ivy.xml. - release Ivy 2 final! - improve out of the box experience, to make it really easy for users to setup their build with Ivy. This is why I suggested EasyAnt recently, because it's still one of the main reason for people to use Maven, and with which Ivy itself can't fight. Maven being so broken, I'd rather let it die :p > > > > >> And on the contrary, we could imagine to have some ivy.xml just next > > >> to the pom.xml on the maven repositories, so we could have a IvyRep2 > > >> with not that much effort from the developer (non necessarily ivy > > >> ones) community. > > > > > > Yes, but even maintaining ivy files require a strong community if we > > > want to have good quality metadata. That's what we tried with Ivyrep, > > > while Ivy was being sponsored by Jayasoft. But it was just too much > > > work compared to the result on investment. > > > I think there are ways to reduce the amount of work. But yeah, community > is > important. I'm willing to help, if it matters :) Help is always welcome! And remember that Apache is all about community, and anybody with good will can get involved. Even if I think building a public Ivy repo now is too early, you can still go ahead and show the opposite. I can help with the tooling required, and I'm pretty sure the Ivy committer team is very open to change in Ivy to support this if ever it's necessary. So feel free to share ideas and show your motivation and what you can achieve! > > I was just considering adding the possibility to > > the maven2 resolver to also try to look for an ivy.xml just next to > > the pom.xml (I haven't looked to the technical consequences though). > > Then the maven2 community could also be an Ivy community. So the > > Ivyrep Adrian is looking for could be nothing more than the ibiblio one. > > > Well, that doesn't solve the problem of bad org names. And it requires > cooperation with the maven/ibiblio people (if they're ok, then it could > work). > > Anyway, for now, I guess it makes sense to enhance maven2 support (with > poms), as it will bring the most results in the short term. > In that case, the first thing I'd request is support for source and > javadoc > artifacts (I understand they're not defined in poms, so Ivy should just > construct the corresponding URLs and check whether they exist). Sources and javadoc artifacts are supported in IvyDE, but if we make a maven2 resolver this could be part of the features provided by this very specific resolver. Xavier > > Obviously, other users have other requests, and it's up to you to sort the > priorities :) > > Regards, > Adrian > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Possible Ivy resolver bug
On Feb 9, 2008 1:00 PM, Adrian Sandor <[EMAIL PROTECTED]> wrote: > On Feb 9, 2008 5:49 PM, Xavier Hanin wrote: > > > > I see that now, but everything I tried with the ant build script ended > > up > > > with this: > > > /mnt/tc/workspace/ivy-trunk/build.xml:50: ivy:settings doesn't support > > the > > > "override" attribute > > > > Check the list archive or JIRA, others have already complained about > that > > very recently, the problem is most probably due to another version of > Ivy > > in > > your ant lib. > > > > Google didn't find anything, hope it will index these messages from one of > the archives. > I found IVY-718 in JIRA, and indeed I had a similar problem (Ivy 2.0.0beta1 > added to the ant home entries in eclipse). > After removing that, deleting the lib folder and the Ivy cache, I was able > to build the jar, and I get no more errors in eclipse. > I think it would help to have more instructions in the README or > somewhere, > explaining the ant targets and perhaps warning against using other Ivy > versions with ant. Or at least a reference to dev.html. Agreed. We'd need to check in our build if another version of Ivy is loaded from ant lib, and output a warning in this case. We'd also need to add maybe a help target pointing to dev.html, and explain also in dev.html that you need to make sure you don't have an ivy.jar in your ant lib. Could you open a JIRA issue about that? Xavier > > > Thanks > Adrian > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
[DISCUSS] release Ivy 2.0.0-beta2?
Hi, We have made good progress on Ivy trunk, and I think it's close to be a good time to release 2.0.0 beta 2. So, do you see anything blocking before cutting this release? Anything you would like to see in? Any pending change that would deserve to wait? IMHO, this beta should be the last beta before a cycle of release candidates. So I'd like us to focus on bug fix (and we have a pretty good list assigned to 2.0) after this beta (probably with some small features or improvements, like a maven2 resolver I suggested recently). So, what do you think? Xavier -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Cactus 1.8 / Ant 1.8 Integration
Hi guys,
it's Petar Tahchiev from the Jakarta Cactus Team (again :-)).
I am trying to integrate the CactusTask with Ant 1.8-alpha.
The CactusTask does:
0) Extends the JUnitTask from Ant.
1) Gets all the tests from JUnitTask
2) Iterates over them and sets different properties to each one of them.
3) Calls the JUnitTask to executes the test-cases.
So, the basis is that we are no longer able to use
execute(org.apache.tools.ant.taskdefs.optional.junit.JUnitTest);
because the delegate field (Object of type JUnitTaskMirror) leaves
uninitialized and thus the CactusTask throws NLPE.
This way to execute the tests we are bound to use the execute() method of
the
JUnitTask (because in that method the delegate object gets initialized).
When calling
the execute() method we have to have our tests configured. But when I get
the tests and configure them with:
===
Enumeration tests = getIndividualTests();
while (tests.hasMoreElements())
{
JUnitTest test = (JUnitTest) tests.nextElement();
if (test.shouldRun(getProject())
&& !theWrapper.isExcluded(test.getName()))
{
test.setFork(true);
if (theWrapper.getToDir() != null)
{
test.setTodir(theWrapper.getToDir());
}
===
I am no longer able to set them in the JUnitTask. The field tests is
private:
private Vector tests = new Vector();
and there is no setter for an individual test, or a vector of tests.
Please, can you look serious to this and supply a setter method for this.
This way I can configure
the tests and set them in the JUnitTask, and after that just call execute().
Thank you very much.
P.S. Please keep me in a CC, because I am not subscribed to the Ant
Developers' lists.
--
Regards, Petar!
Karlovo, Bulgaria.
EOOXML Objections
http://www.grokdoc.net/index.php/EOOXML_objections
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
--
View this message in context:
http://www.nabble.com/Cactus-1.8---Ant-1.8-Integration-tp15396771p15396771.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
Re: Cactus 1.8 / Ant 1.8 Integration
Sorry for the formating :-(.
Hi guys,
it's Petar Tahchiev from the Jakarta Cactus Team (again :-)).
I am trying to integrate the CactusTask with Ant 1.8-alpha.
The CactusTask does:
0) Extends the JUnitTask from Ant.
1) Gets all the tests from JUnitTask
2) Iterates over them and sets different properties to each one of them.
3) Calls the JUnitTask to executes the test-cases.
So, the basis is that we are no longer able to use
execute(org.apache.tools.ant.taskdefs.optional.junit.JUnitTest);
because the delegate field (Object of type JUnitTaskMirror) leaves
uninitialized and thus the CactusTask throws NLPE.
This way to execute the tests we are bound to use the execute() method of
the
JUnitTask (because in that method the delegate object gets initialized).
When calling
the execute() method we have to have our tests configured. But when I get
the tests and configure them with:
===
Enumeration tests = getIndividualTests();
while (tests.hasMoreElements())
{
JUnitTest test = (JUnitTest) tests.nextElement();
if (test.shouldRun(getProject())
&& !theWrapper.isExcluded(test.getName()))
{
test.setFork(true);
if (theWrapper.getToDir() != null)
{
test.setTodir(theWrapper.getToDir());
}
===
I am no longer able to set them in the JUnitTask. The field tests is
private:
private Vector tests = new Vector();
and there is no setter for an individual test, or a vector of tests.
Please, can you look serious to this and supply a setter method for this.
This way I can configure
the tests and set them in the JUnitTask, and after that just call execute().
Thank you very much.
P.S. Please keep me in a CC, because I am not subscribed to the Ant
Developers' lists.
--
Regards, Petar!
Karlovo, Bulgaria.
EOOXML Objections
http://www.grokdoc.net/index.php/EOOXML_objections
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
--
View this message in context:
http://www.nabble.com/Cactus-1.8---Ant-1.8-Integration-tp15396771p15396772.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible Ivy resolver bug
On Feb 10, 2008 4:23 PM, Xavier Hanin wrote: > Could you open a JIRA issue about that? I created IVY-730 Adrian
Re: [DISCUSS] release Ivy 2.0.0-beta2?
On Feb 10, 2008 4:52 PM, Xavier Hanin wrote: > We have made good progress on Ivy trunk, and I think it's close to be a > good > time to release 2.0.0 beta 2. So, do you see anything blocking before > cutting this release? Anything you would like to see in? Any pending > change > that would deserve to wait? Well, nothing critical, but I've been quite shocked by the changes in the cache management: - 3 tags for cache configuration: settings, caches and cache - inconsistent/confusing attributes on the settings tag: defaultCache and resolutionCacheDir - different naming styles although they're both directories; and both of them specify the resolution cache but defaultCache also specifies the repository cache? - some confusion between "defaultCache" on settings, "default" on caches, and "default-cache" - ivy and artifact patterns everywhere I managed to work it out (using only one cache, thank you very much!), but I really think this stuff can be greatly improved, at least by moving/merging all the cache-related attributes from "settings" to "caches" and giving them better names. "cache" tags could be ok as they are now. If there are legacy compatibility requirements, the old-style attributes can still be supported but deprecated. Regards, Adrian
Re: [DISCUSS] release Ivy 2.0.0-beta2?
On Feb 10, 2008 8:18 PM, Adrian Sandor <[EMAIL PROTECTED]> wrote: > On Feb 10, 2008 4:52 PM, Xavier Hanin wrote: > > > We have made good progress on Ivy trunk, and I think it's close to be a > > good > > time to release 2.0.0 beta 2. So, do you see anything blocking before > > cutting this release? Anything you would like to see in? Any pending > > change > > that would deserve to wait? > > > Well, nothing critical, but I've been quite shocked by the changes in the > cache management: > - 3 tags for cache configuration: settings, caches and cache The settings on the settings tag are mainly due to legacy. We could indeed deprecate them to move all cache settings to the caches element. cache element should now only the defition of one cache, so I don't see how we could avoid that. Unless we don't allow changing defaults for all caches at once, and make per cache settings mandatory. > > - inconsistent/confusing attributes on the settings tag: defaultCache and > resolutionCacheDir - different naming styles although they're both > directories; and both of them specify the resolution cache but > defaultCache > also specifies the repository cache? Yes, this is a legacy problem, but I agree it's confusing. Maybe we can rename it to defaultCacheDir, and deprecate defaultCache. > > - some confusion between "defaultCache" on settings, "default" on caches, > and "default-cache" Again, if we rename defaultCache in defaultCacheDir, I think this would be less confusing. Would this be enough in your opinion? > > - ivy and artifact patterns everywhere What's the problem with that? Could you elaborate? Thanks for your feedback, Xavier > > > I managed to work it out (using only one cache, thank you very much!), but > I > really think this stuff can be greatly improved, at least by > moving/merging > all the cache-related attributes from "settings" to "caches" and giving > them > better names. "cache" tags could be ok as they are now. > If there are legacy compatibility requirements, the old-style attributes > can > still be supported but deprecated. > > Regards, > Adrian > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Cactus 1.8 / Ant 1.8 Integration
Hello Peter,
I know you probably know ;-)
that this fast solution which I post now is not so well appreciated due
to its possible privileges unconvenients, but in the meanwhile
if I was you I would access private members with a PrivilegedAction:
public static Object testAccess(Object instance, String s) {
try {
final Field f = instance.getClass().getDeclaredField(s);
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
f.setAccessible(true);
return null;
}
});
Object o = f.get(instance);
return o;
} catch(Exception e) {
e.printStackTrace();
}
return null;
}
Hoping it would be be useful as temporary patch ;-)
Bye
Petar Tahchiev wrote:
>
> Sorry for the formating :-(.
>
>
> Hi guys,
>
> it's Petar Tahchiev from the Jakarta Cactus Team (again :-)).
> I am trying to integrate the CactusTask with Ant 1.8-alpha.
> The CactusTask does:
> 0) Extends the JUnitTask from Ant.
> 1) Gets all the tests from JUnitTask
> 2) Iterates over them and sets different properties to each one of them.
> 3) Calls the JUnitTask to executes the test-cases.
>
> So, the basis is that we are no longer able to use
>
> execute(org.apache.tools.ant.taskdefs.optional.junit.JUnitTest);
>
> because the delegate field (Object of type JUnitTaskMirror) leaves
> uninitialized and thus the CactusTask throws NLPE.
> This way to execute the tests we are bound to use the execute() method of
> the
> JUnitTask (because in that method the delegate object gets initialized).
> When calling
> the execute() method we have to have our tests configured. But when I get
> the tests and configure them with:
> ===
> Enumeration tests = getIndividualTests();
>
> while (tests.hasMoreElements())
> {
> JUnitTest test = (JUnitTest) tests.nextElement();
>
> if (test.shouldRun(getProject())
> && !theWrapper.isExcluded(test.getName()))
> {
> test.setFork(true);
> if (theWrapper.getToDir() != null)
> {
> test.setTodir(theWrapper.getToDir());
> }
> ===
>
> I am no longer able to set them in the JUnitTask. The field tests is
> private:
>
> private Vector tests = new Vector();
>
> and there is no setter for an individual test, or a vector of tests.
>
> Please, can you look serious to this and supply a setter method for this.
> This way I can configure
> the tests and set them in the JUnitTask, and after that just call
> execute().
>
> Thank you very much.
>
> P.S. Please keep me in a CC, because I am not subscribed to the Ant
> Developers' lists.
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
>
> EOOXML Objections
> http://www.grokdoc.net/index.php/EOOXML_objections
>
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>
--
View this message in context:
http://www.nabble.com/Cactus-1.8---Ant-1.8-Integration-tp15396771p15402964.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] release Ivy 2.0.0-beta2?
On Feb 11, 2008 4:24 AM, Xavier Hanin wrote: > > - 3 tags for cache configuration: settings, caches and cache > > The settings on the settings tag are mainly due to legacy. We could indeed > deprecate them to move all cache settings to the caches element. cache > element should now only the defition of one cache, so I don't see how we > could avoid that. I also said "cache" tags could be ok as they are now. Two tags (caches and cache) are acceptable. > > - inconsistent/confusing attributes on the settings tag: defaultCache > and > > resolutionCacheDir - different naming styles although they're both > > directories; and both of them specify the resolution cache but > > defaultCache > > also specifies the repository cache? > > Yes, this is a legacy problem, but I agree it's confusing. Maybe we can > rename it to defaultCacheDir, and deprecate defaultCache. So, if I understand correctly, right now settings/defaultCache is the default for both resolution and repository cache; settings/resolutionCacheDir overrides it for resolution, caches/basedir overrides it for repository, and cache/basedir overrides caches/basedir (for repository). Perhaps we can move settings/resolutionCacheDir to caches/resolutionCacheDir, rename caches/basedir to caches/repositoryCacheDir, and either remove settings/defaultCache or move it to caches/defaultCacheDir. > > - some confusion between "defaultCache" on settings, "default" on > caches, > > and "default-cache" > > Again, if we rename defaultCache in defaultCacheDir, I think this would be > less confusing. Would this be enough in your opinion? It would definitely help. Probably good enough, if the docs are clear. > > - ivy and artifact patterns everywhere > > What's the problem with that? Could you elaborate? settings/cacheIvyPattern and settings/cacheArtifactPattern vs caches/ivyPattern and caches/artifactPattern, they're redundant. Also these have changed since beta 1 (cache/repositoryIvyPattern and cache/repositoryArtifactPattern), and so did the resolution/repository dir attributes. Change itself is not bad, we should just make sure the new way is really better. Adrian
Cactus 1.8 / Ant 1.8 Integration
Hi guys,
it's Petar Tahchiev from the Jakarta Cactus Team (again :-)).
I am trying to integrate the CactusTask with Ant 1.8-alpha.
The CactusTask does:
0) Extends the JUnitTask from Ant.
1) Gets all the tests from JUnitTask
2) Iterates over them and sets different properties to each one of them.
3) Calls the JUnitTask to executes the test-cases.
So, the basis is that we are no longer able to use
execute(org.apache.tools.ant.taskdefs.optional.junit.JUnitTest);
because the delegate field (Object of type JUnitTaskMirror) leaves
uninitialized and thus the CactusTask throws NLPE.
This way to execute the tests we are bound to use the execute() method of
the
JUnitTask (because in that method the delegate object gets initialized).
When calling
the execute() method we have to have our tests configured. But when I get
the tests and configure them with:
===
Enumeration tests = getIndividualTests();
while (tests.hasMoreElements())
{
JUnitTest test = (JUnitTest) tests.nextElement();
if (test.shouldRun(getProject())
&& !theWrapper.isExcluded(test.getName()))
{
test.setFork(true);
if (theWrapper.getToDir() != null)
{
test.setTodir(theWrapper.getToDir());
}
===
I am no longer able to set them in the JUnitTask. The field tests is
private:
private Vector tests = new Vector();
and there is no setter for an individual test, or a vector of tests.
Please, can you look serious to this and supply a setter method for this.
This way I can configure
the tests and set them in the JUnitTask, and after that just call execute().
Thank you very much.
P.S. Please keep me in a CC, because I am not subscribed to the Ant
Developers' lists.
--
Regards, Petar!
Karlovo, Bulgaria.
EOOXML Objections
http://www.grokdoc.net/index.php/EOOXML_objections
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
