Re: critique of maven 2.0.2
To overcome the license issue, maybe a tool which use a gpl prolog to the queries shown by Steve can be created at mojo.codehaus.org ? I don't remember the license policy. So whatever the means and the licences issues, are we agree about the task such a tool have to do (the needs expressed by Steve) ? In advance, thanks for any answer. Regards, Raphaël 2006/2/8, Piéroni Raphaël <[EMAIL PROTECTED]>: > > > > 2006/2/8, Steve Loughran <[EMAIL PROTECTED]>: > > > > Piéroni Raphaël wrote: > > > 2006/2/8, Steve Loughran <[EMAIL PROTECTED]>: > > >> Piéroni Raphaël wrote: > > >>> I don't know if it is the right tool. i jumped on Steve proposition > > as i > > >> was > > >>> found of prolog during my school years. > > >>> > > >> I don't know if it is right either. One good reason for not using it, > > >> but for sticking in java, is ease of integration with the existing > > maven > > >> codebase; nobody could add anything that depended on GPL code to the > > >> repository, even LGPL is a bit sensitive. > > > > > > > > > I do not understand this license issue. > > > is it because Jlog is GPL that its artifact and pom are not in ibiblio > > ? > > > > no, it should be on ibiblio if it is popular. Lots of GPL things are > > (like the mysql jdbc driver, bits of JBoss, etc) > > > > > is it because Jlog is GPL that we could not import class of jlog into > > maven > > > code ? > > > > yes > > > So we can't use Jlog i checked the amine-platform (another prolog) : it is > LGPL. does LGPL also not usable in maven ? > if yes, the prolog approach is not the correct one as i don't know any > other open source prolog library. > > Regards, > > Raphaël > >
Re: critique of maven 2.0.2
2006/2/8, Steve Loughran <[EMAIL PROTECTED]>: > > Piéroni Raphaël wrote: > > 2006/2/8, Steve Loughran <[EMAIL PROTECTED]>: > >> Piéroni Raphaël wrote: > >>> I don't know if it is the right tool. i jumped on Steve proposition as > i > >> was > >>> found of prolog during my school years. > >>> > >> I don't know if it is right either. One good reason for not using it, > >> but for sticking in java, is ease of integration with the existing > maven > >> codebase; nobody could add anything that depended on GPL code to the > >> repository, even LGPL is a bit sensitive. > > > > > > I do not understand this license issue. > > is it because Jlog is GPL that its artifact and pom are not in ibiblio ? > > no, it should be on ibiblio if it is popular. Lots of GPL things are > (like the mysql jdbc driver, bits of JBoss, etc) > > > is it because Jlog is GPL that we could not import class of jlog into > maven > > code ? > > yes So we can't use Jlog i checked the amine-platform (another prolog) : it is LGPL. does LGPL also not usable in maven ? if yes, the prolog approach is not the correct one as i don't know any other open source prolog library. Regards, Raphaël
Re: critique of maven 2.0.2
Piéroni Raphaël wrote: 2006/2/8, Steve Loughran <[EMAIL PROTECTED]>: Piéroni Raphaël wrote: I don't know if it is the right tool. i jumped on Steve proposition as i was found of prolog during my school years. I don't know if it is right either. One good reason for not using it, but for sticking in java, is ease of integration with the existing maven codebase; nobody could add anything that depended on GPL code to the repository, even LGPL is a bit sensitive. I do not understand this license issue. is it because Jlog is GPL that its artifact and pom are not in ibiblio ? no, it should be on ibiblio if it is popular. Lots of GPL things are (like the mysql jdbc driver, bits of JBoss, etc) is it because Jlog is GPL that we could not import class of jlog into maven code ? yes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
2006/2/8, Steve Loughran <[EMAIL PROTECTED]>: > > Piéroni Raphaël wrote: > > > > I don't know if it is the right tool. i jumped on Steve proposition as i > was > > found of prolog during my school years. > > > > I don't know if it is right either. One good reason for not using it, > but for sticking in java, is ease of integration with the existing maven > codebase; nobody could add anything that depended on GPL code to the > repository, even LGPL is a bit sensitive. I do not understand this license issue. is it because Jlog is GPL that its artifact and pom are not in ibiblio ? is it because Jlog is GPL that we could not import class of jlog into maven code ? all the same, if you are doing graph work, it is the language to use. > Its a lot more painful to do in java. Which reminds me, I have work to > do... Regards, Raphaël
Re: critique of maven 2.0.2
Piéroni Raphaël wrote: 2006/2/7, Brett Porter <[EMAIL PROTECTED]>: Piéroni Raphaël wrote: The programs which needs to be created are : - the crawler which reads the poms from a local or remote repository. called from command line. outputs the fact base in a file. You should definitely peek into the maven-repository-manager in the SVN repo. We already have a tree walker and reports that analyse poms for this information. I'd like to see anything added done there if possible. Thanks i downloaded yesterday the components/trunk but guessed which library to use. Issue, is the prolog approach a correct one ? for : the queries are quite easy to create and the answers are complete. for : I know some bit of prolog and always liked this language. against : querying the facts is quite slow. If it's the right tool for the job, go for it, though I know nothing about it. I don't know if it is the right tool. i jumped on Steve proposition as i was found of prolog during my school years. I don't know if it is right either. One good reason for not using it, but for sticking in java, is ease of integration with the existing maven codebase; nobody could add anything that depended on GPL code to the repository, even LGPL is a bit sensitive. all the same, if you are doing graph work, it is the language to use. Its a lot more painful to do in java. Which reminds me, I have work to do... -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
2006/2/7, Brett Porter <[EMAIL PROTECTED]>: > > Piéroni Raphaël wrote: > > The programs which needs to be created are : > > - the crawler which reads the poms from a local or remote repository. > called > > from command line. outputs the fact base in a file. > > You should definitely peek into the maven-repository-manager in the SVN > repo. We already have a tree walker and reports that analyse poms for > this information. I'd like to see anything added done there if possible. Thanks i downloaded yesterday the components/trunk but guessed which library to use. > Issue, is the prolog approach a correct one ? > > for : the queries are quite easy to create and the answers are > complete. > > for : I know some bit of prolog and always liked this language. > > against : querying the facts is quite slow. > > If it's the right tool for the job, go for it, though I know nothing > about it. I don't know if it is the right tool. i jumped on Steve proposition as i was found of prolog during my school years. Raphaël
Re: critique of maven 2.0.2
Piéroni Raphaël wrote: > The programs which needs to be created are : > - the crawler which reads the poms from a local or remote repository. called > from command line. outputs the fact base in a file. You should definitely peek into the maven-repository-manager in the SVN repo. We already have a tree walker and reports that analyse poms for this information. I'd like to see anything added done there if possible. > Issue, is the prolog approach a correct one ? > for : the queries are quite easy to create and the answers are complete. > for : I know some bit of prolog and always liked this language. > against : querying the facts is quite slow. If it's the right tool for the job, go for it, though I know nothing about it. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Hello, Here are my toughs about this. Needs: from Steve Loughran : reverse analysis, who uses "junit", or junit-3.7 cycle detection; who depends on a dependency missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) scale: who depends on the most stuff stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Definitions : project( m(Group,Artifact,Version) ). means that the project of group, artifact and version exists in the repository. where m(group,artifacy,version) is a prolog term. depends( Project1, Project2). means that project1 depends on project2. The first thing the is to create the base of facts. Issue : does reading all the poms in the evangelism's cvs is enough or do use of a remote repository is needed ? the facts are created this way : for each pom.xml found in the repository, read the model using the model builder (real class ?) create the fact project(m(groupId,artifactId,version)) of the project in the prolog fact base check if the project's artifact exists in the remote repository, if yes, create the fact exists(m(groupId,artifactId,version)) for each of projects direct dependencies, create the fact depends(m(groupId,artifactId,version),m(depGroupId,depArtifactId,depVersion)) store the prolog fact base into a file. Issue : how to represent an exclusion ? what is an exclusion ? Issue : how to handle snapshots ? To query the fact base, we need to a list of rules about the fact predicates defined in the fact base. The programs which needs to be created are : - the crawler which reads the poms from a local or remote repository. called from command line. outputs the fact base in a file. - the fact queryer which loads the fact base and the rules. called from the command line, lets the user input its queries (using the Jlog applet ?) - the graphing tool which loads the fact base and create an SVG from the fact base. Issue, is the prolog approach a correct one ? for : the queries are quite easy to create and the answers are complete. for : I know some bit of prolog and always liked this language. against : querying the facts is quite slow. Regards, Raphaël
Re: critique of maven 2.0.2
I made some prolog at school, but never had since. but i remember well enough. Obviously the first thing to do is to create the facts by reading the poms. Which means reading all the poms at ibiblio (i remember there is a CVS/SVN of all the poms but where ?) I do not get the point about exclusion (as i never used exclusion in maven2). Will try to sent a better email of what i am understanding this nite after work. Raphaël 2006/2/7, Steve Loughran <[EMAIL PROTECTED]>: > > Piéroni Raphaël wrote: > > Hello, > > > > I have not so much time, but i am volunteering on this if some one can > point > > me to the 'dependency graph api'. > > And i needed some idea of code to work at home. this one is especially > > insterresting part (obviously the prolog one - Steve, if you can point > me to > > the java-prolog library you know. the only one i know (and never used) > is > > http://sourceforge.net/projects/amine-platform) > > > I have not so much time, but i am volunteering on this if some one > can point > > me to the 'dependency graph api'. > > And i needed some idea of code to work at home. this one is especially > > insterresting part (obviously the prolog one - Steve, if you can > point me to > > the java-prolog library you know. the only one i know (and never used) > is > > http://sourceforge.net/projects/amine-platform) > > I didnt know of that one. > > The one I know of is "Jlog": http://jlogic.sourceforge.net/ . > > Our deployment runtime (smartfrog) can use this or other logic engines > that can be dropped in to our constraint API, so that when you deploy > things you can declare constraints in the logic language; let the system > work out for itself what a good solution is to some of the constraints. > We explicitly support other back ends so that we remain LGPL instead of > GPL; > > I don't know what maven has in terms of a dependency API; what I'd do is > -grab the pom files (well, be pointed at a repository and walk the tree) > -extract the XML data > -assert that all as facts in the prolog database > -add extra rules > > resolve out interesting facts > > e.g > > m(junit,junit,3.8.1). > m(log4j,log4j,1.2.8). > depends(m(junit,junit,3.8.1),m(log4j,log4j,1.2.8)). > > Otherwise It is easy to declare transitive dependencies > > depends(X,Y) :- depends(X,Z),depends(Z,Y). > > Then you can get all solutions to a problem : > > depends(m(me,myapp,3.4)),X). > > exclusions complicate this model. Not having written proper prolog for a > decade, it doesnt come to me off the top of my head. Something like X > depends on m(G,A,V) if there isnt an excludes(X,m(G,A,_)), but prolog > isnt great for specifying negative facts. > > Version rules are the other complexity. You can declare that a module is > newer than something with the same group/artefact if its version tag is > newer: > > newversion(m(Group,Artefact,Version),m(Group,Artifact,Version2)) :- > Version > Version2. > > Then add rules about only the newest version of anything being used. > > If you've never done Prolog, it is a different way of thinking. It > should mesh very well with XML work. I've done RDBMS stuff with it in > the past, and makes some things wonderfully easy (if desperately > inefficient) > > -steve > > > > > > > > Regards, > > > > Raphaël > > > > 2006/2/7, Steve Loughran <[EMAIL PROTECTED]>: > >> > >> > >> I personally think an interesting project for someone with time on > their > >> hands would be to write some code to walk the repository and derive > >> useful facts from the dependency graph. I know this is on Brett's todo > >> list, but it doesnt actually need repository/CVS access, and could be > >> written by anyone. > >> > >> Things you could do with the right tool > >> > >> -reverse analysis, who uses "junit", or junit-3.7 > >> > >> -cycle detection; who depends on a dependency > >> > >> -missing artifacts: what depends on things that arent there (split into > >> sun, OSS, proprietary) > >> > >> -scale: who depends on the most stuff > >> > >> -stability: who is most bleeding edge, versus trailing > >> > >> output: generate fancy SVG graphs from it, or RDF triples for the fun > of > >> it. > >> > >> Having just been doing complex graph work in Java, I'd actually > consider > >> using Prolog for working with the dependency graph; the plugins for > java > >> are usually LGPL or GPL based though, especially the working ones (like > >> JLog). > >> > >> -steve > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: critique of maven 2.0.2
Piéroni Raphaël wrote: Hello, I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) > I have not so much time, but i am volunteering on this if some one can point > me to the 'dependency graph api'. > And i needed some idea of code to work at home. this one is especially > insterresting part (obviously the prolog one - Steve, if you can point me to > the java-prolog library you know. the only one i know (and never used) is > http://sourceforge.net/projects/amine-platform) I didnt know of that one. The one I know of is "Jlog": http://jlogic.sourceforge.net/ . Our deployment runtime (smartfrog) can use this or other logic engines that can be dropped in to our constraint API, so that when you deploy things you can declare constraints in the logic language; let the system work out for itself what a good solution is to some of the constraints. We explicitly support other back ends so that we remain LGPL instead of GPL; I don't know what maven has in terms of a dependency API; what I'd do is -grab the pom files (well, be pointed at a repository and walk the tree) -extract the XML data -assert that all as facts in the prolog database -add extra rules resolve out interesting facts e.g m(junit,junit,3.8.1). m(log4j,log4j,1.2.8). depends(m(junit,junit,3.8.1),m(log4j,log4j,1.2.8)). Otherwise It is easy to declare transitive dependencies depends(X,Y) :- depends(X,Z),depends(Z,Y). Then you can get all solutions to a problem : depends(m(me,myapp,3.4)),X). exclusions complicate this model. Not having written proper prolog for a decade, it doesnt come to me off the top of my head. Something like X depends on m(G,A,V) if there isnt an excludes(X,m(G,A,_)), but prolog isnt great for specifying negative facts. Version rules are the other complexity. You can declare that a module is newer than something with the same group/artefact if its version tag is newer: newversion(m(Group,Artefact,Version),m(Group,Artifact,Version2)) :- Version > Version2. Then add rules about only the newest version of anything being used. If you've never done Prolog, it is a different way of thinking. It should mesh very well with XML work. I've done RDBMS stuff with it in the past, and makes some things wonderfully easy (if desperately inefficient) -steve Regards, Raphaël 2006/2/7, Steve Loughran <[EMAIL PROTECTED]>: I personally think an interesting project for someone with time on their hands would be to write some code to walk the repository and derive useful facts from the dependency graph. I know this is on Brett's todo list, but it doesnt actually need repository/CVS access, and could be written by anyone. Things you could do with the right tool -reverse analysis, who uses "junit", or junit-3.7 -cycle detection; who depends on a dependency -missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) -scale: who depends on the most stuff -stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Having just been doing complex graph work in Java, I'd actually consider using Prolog for working with the dependency graph; the plugins for java are usually LGPL or GPL based though, especially the working ones (like JLog). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Piéroni Raphaël wrote: Hello, I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) There are a couple attempts on graphing that have been merged and the code is available in the Mojo project: http://svn.mojo.codehaus.org/trunk/mojo/mojo-sandbox/maven-graphing/ Jung is a fine graphing library and it's BSD licensed and is what we intend to use for graph visualization. You can find it here: http://jung.sf.net Joekim and myself have been playing around with this and Joekim has something that looks pretty cool already. I highly recommend you look in there before attempting to start something different. The source for the graphs will come from the Maven Repository Manager which will have a pluggable mechanism for performing any sort of analysis on the repository you wish. There is a mechanism now for walking around the repository which we are currently using for indexing the contents of a repository. Regards, Raphaël 2006/2/7, Steve Loughran <[EMAIL PROTECTED]>: I personally think an interesting project for someone with time on their hands would be to write some code to walk the repository and derive useful facts from the dependency graph. I know this is on Brett's todo list, but it doesnt actually need repository/CVS access, and could be written by anyone. Things you could do with the right tool -reverse analysis, who uses "junit", or junit-3.7 -cycle detection; who depends on a dependency -missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) -scale: who depends on the most stuff -stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Having just been doing complex graph work in Java, I'd actually consider using Prolog for working with the dependency graph; the plugins for java are usually LGPL or GPL based though, especially the working ones (like JLog). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Hello, I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) Regards, Raphaël 2006/2/7, Steve Loughran <[EMAIL PROTECTED]>: > > > > I personally think an interesting project for someone with time on their > hands would be to write some code to walk the repository and derive > useful facts from the dependency graph. I know this is on Brett's todo > list, but it doesnt actually need repository/CVS access, and could be > written by anyone. > > Things you could do with the right tool > > -reverse analysis, who uses "junit", or junit-3.7 > > -cycle detection; who depends on a dependency > > -missing artifacts: what depends on things that arent there (split into > sun, OSS, proprietary) > > -scale: who depends on the most stuff > > -stability: who is most bleeding edge, versus trailing > > output: generate fancy SVG graphs from it, or RDF triples for the fun of > it. > > Having just been doing complex graph work in Java, I'd actually consider > using Prolog for working with the dependency graph; the plugins for java > are usually LGPL or GPL based though, especially the working ones (like > JLog). > > -steve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: critique of maven 2.0.2
Brett Porter wrote: I think the solution is easier: Anyone that proves they are capable will be given access to do this. We won't be handing out responsibility to volunteers who have not yet proven they are capable at the task through patches - just like how commit access is granted in general. We do need better revision control, and at some point to draw a line in the sand and not change things. My single biggest regret about the first release is not sorting this out better, even though I knew it was coming I thought it would peak and get sorted out. I can't believe we *still* can't agree on how hibernate should be done. I actually wonder if we'd been better off starting from scratch and adding lovingly hand-crafted POMS by people that needed them. I guess there's still time to start over in a new repo :) Cheers, Brett I personally think an interesting project for someone with time on their hands would be to write some code to walk the repository and derive useful facts from the dependency graph. I know this is on Brett's todo list, but it doesnt actually need repository/CVS access, and could be written by anyone. Things you could do with the right tool -reverse analysis, who uses "junit", or junit-3.7 -cycle detection; who depends on a dependency -missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) -scale: who depends on the most stuff -stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Having just been doing complex graph work in Java, I'd actually consider using Prolog for working with the dependency graph; the plugins for java are usually LGPL or GPL based though, especially the working ones (like JLog). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
I think the solution is easier: Anyone that proves they are capable will be given access to do this. We won't be handing out responsibility to volunteers who have not yet proven they are capable at the task through patches - just like how commit access is granted in general. We do need better revision control, and at some point to draw a line in the sand and not change things. My single biggest regret about the first release is not sorting this out better, even though I knew it was coming I thought it would peak and get sorted out. I can't believe we *still* can't agree on how hibernate should be done. I actually wonder if we'd been better off starting from scratch and adding lovingly hand-crafted POMS by people that needed them. I guess there's still time to start over in a new repo :) Cheers, Brett Arik Kfir wrote: > Hi, > > IMO the most urgent thing the ibiblio repository needs now is > decentralized management - meaning: assiging certain people (or groups > of people) to be responsible for managing a specific part of the repo > (e.g. "joe is managing all hibernate-related POMs"...) > > These people can be among the maven dev team - but I think a more > reasonable approach would be that these peole come from the maven > community (see my mail on the user mailing list on december about > this: http://mail-archives.apache.org/mod_mbox/maven-users/200512.mbox/[EMAIL > PROTECTED]) > > This has the potential to solve most of the issues the author of the > blog (justifiably) raises. > > I think that will remove most of the (heavy) load burdened on Carlos, > Edwin and the other Maven team members and free some of their time. Of > course, to make that happen, a set of guidelines for those maintainers > will have to be laid out (if/when to update an existing POM, when to > define dependencies as optional, etc) but once that is done, I think > the QoS of the central repository will increase ten-folds and make > Maven 2.x a real joy cruise for users: both quality-wise of the > artifacts and the response time for fixes. > > Best regards, > Arik Kfir. > > On 2/3/06, Robert Watts <[EMAIL PROTECTED]> wrote: >> http://www.ctoforaday.com/archives/49.html >> >> Seems fair to me, has mirrored may of the headaches with our own >> implementation. Rob. >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Regards, > _ > Arik Kfir[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Yep, that's it. Sorry, force of habit. Steve Loughran wrote: > Brett Porter wrote: >> Steve Loughran wrote: >>> something below hibernate3.1 pulls in junit3.7, which really annoyed me >>> when I tracked it down. >> >> Do you know what it is from -X? I'm thinking commons-something. > > -X? do you mean verbose="true" in the task? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Brett Porter wrote: Steve Loughran wrote: something below hibernate3.1 pulls in junit3.7, which really annoyed me when I tracked it down. Do you know what it is from -X? I'm thinking commons-something. -X? do you mean verbose="true" in the task? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Steve Loughran wrote: > something below hibernate3.1 pulls in junit3.7, which really annoyed me > when I tracked it down. Do you know what it is from -X? I'm thinking commons-something. > I think I'd also like a global set of exclusions, telling apps not to do > anything related to xml parsers unless I ask for it by hand. I think that's in JIRA for a future version. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Carlos Sanchez wrote: It doesn't include optional transitive dependencies, and hibernate latest poms have been fixed long time ago. I guess it depends on what bit of hibernate you use My patches to get hibernate-annotations/entity-manager to work are here: http://cvs.sourceforge.net/viewcvs.py/antbook/examples/diary/persist/build.xml?view=markup I have to -remove junit -add jboss-common - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Piotr Bzdyl wrote: Hello, http://www.ctoforaday.com/archives/49.html I agree with the author about dependency management and transitional dependency handling. I don't know why Maven 2 includes all optional dependencies by default. Why must I care what all possible features hibernate has and exclude all unneeded libraries? IMHO I should just include what I need for my project (I would like to not think about that Hibernate adds new cache implementation and lists it as another optional dependency. Hibernate is just an example). I also noticed that I have the same or even more exclusions than dependencies. something below hibernate3.1 pulls in junit3.7, which really annoyed me when I tracked it down. But whose fault is that? it is that of whoever wrote the dependency that hibernate itself depends on. The ability to play with makes it possible for you to work around stuff. At the same time, the ability to do time-critical workarounds to I think I'd also like a global set of exclusions, telling apps not to do anything related to xml parsers unless I ask for it by hand. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
exclusions are a method of last resort, to help you compensate for bad upstream metadata...usage of in the dependency declaration makes this method much more prone to [ab]use IMO. When we decided to include , we understood that it *should* be a fleeting problem, depending on the community's guidance to help us keep the repository metadata clean. If a project cannot break itself up into modules with no optional dependencies, fine; use optional dependencies. However, if a project is correct in its use of optional deps, there should *never* be a reason to use . Also, as that project's metadata is improved in the repository (again, by community participation), these should become redundant. We really don't want to promote dependency-level modifications a la and for this type of management...it doesn't really help others using that bad metadata. Instead, the publisher of that project should be under some pressure to correct its dependency specifications. My US$0.02 -john Piotr Bzdyl wrote: Hello, AFAIK maven does not include optional dependencies (unless you specify you want them). The problem is that usually, they are not declared as optional in the POMs in the repository (though I could be wrong here..) I am not sure not but I tried some time ago and I think that it included. Anyway, does it support element in the ? Best regards, Piotrek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
It doesn't include optional transitive dependencies, and hibernate latest poms have been fixed long time ago. On 2/3/06, Piotr Bzdyl <[EMAIL PROTECTED]> wrote: > Hello, > > AFAIK maven does not include optional dependencies (unless you specify > > you want them). The problem is that usually, they are not declared as > > optional in the POMs in the repository (though I could be wrong > > here..) > > > I am not sure not but I tried some time ago and I think that it > included. Anyway, does it support element in the ? > > Best regards, > Piotrek > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Hello, AFAIK maven does not include optional dependencies (unless you specify you want them). The problem is that usually, they are not declared as optional in the POMs in the repository (though I could be wrong here..) I am not sure not but I tried some time ago and I think that it included. Anyway, does it support element in the ? Best regards, Piotrek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
AFAIK maven does not include optional dependencies (unless you specify you want them). The problem is that usually, they are not declared as optional in the POMs in the repository (though I could be wrong here..) On 2/3/06, Piotr Bzdyl <[EMAIL PROTECTED]> wrote: > Hello, > > http://www.ctoforaday.com/archives/49.html > > > I agree with the author about dependency management and transitional > dependency handling. I don't know why Maven 2 includes all optional > dependencies by default. Why must I care what all possible features > hibernate has and exclude all unneeded libraries? IMHO I should just > include what I need for my project (I would like to not think about that > Hibernate adds new cache implementation and lists it as another optional > dependency. Hibernate is just an example). I also noticed that I have > the same or even more exclusions than dependencies. > > Best regards, > Piotrek > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, _ Arik Kfir[EMAIL PROTECTED]
Re: critique of maven 2.0.2
Hello, http://www.ctoforaday.com/archives/49.html I agree with the author about dependency management and transitional dependency handling. I don't know why Maven 2 includes all optional dependencies by default. Why must I care what all possible features hibernate has and exclude all unneeded libraries? IMHO I should just include what I need for my project (I would like to not think about that Hibernate adds new cache implementation and lists it as another optional dependency. Hibernate is just an example). I also noticed that I have the same or even more exclusions than dependencies. Best regards, Piotrek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Hi, IMO the most urgent thing the ibiblio repository needs now is decentralized management - meaning: assiging certain people (or groups of people) to be responsible for managing a specific part of the repo (e.g. "joe is managing all hibernate-related POMs"...) These people can be among the maven dev team - but I think a more reasonable approach would be that these peole come from the maven community (see my mail on the user mailing list on december about this: http://mail-archives.apache.org/mod_mbox/maven-users/200512.mbox/[EMAIL PROTECTED]) This has the potential to solve most of the issues the author of the blog (justifiably) raises. I think that will remove most of the (heavy) load burdened on Carlos, Edwin and the other Maven team members and free some of their time. Of course, to make that happen, a set of guidelines for those maintainers will have to be laid out (if/when to update an existing POM, when to define dependencies as optional, etc) but once that is done, I think the QoS of the central repository will increase ten-folds and make Maven 2.x a real joy cruise for users: both quality-wise of the artifacts and the response time for fixes. Best regards, Arik Kfir. On 2/3/06, Robert Watts <[EMAIL PROTECTED]> wrote: > http://www.ctoforaday.com/archives/49.html > > Seems fair to me, has mirrored may of the headaches with our own > implementation. Rob. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, _ Arik Kfir[EMAIL PROTECTED]
