RE: [RANT] This Maven thing is killing us....
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
 |
|
|
|
Re: AW: [RANT] This Maven thing is killing us....
by Steve Loughran
::
Rate this Message:
roger.butenuth@... wrote:
> Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a copy of a snapshot versioned artifact, the jar is not updated when a new jar with same snapshot version is uploaded to the repository. I already filed this as a bug and hope it will be fixed in 2.0.5. It is annoying to increase version numbers during development or sending mails around "please delete xyz in you local repository... > > Roger If artifact sharing at snapshot time is not working, then one of the nominal core features of maven "better x-team dev" isnt. What is the test process here? -steve --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Steve Loughran
::
Rate this Message:
Edwin Punzalan wrote:
> > May I add, that when maven already downloaded a poor/invalid pom, even > after fixing the pom in the repository, maven won't know that it's > changed (unless the version changed) and it will not download it. So > you end up still using your local repo copy. > > To re-download a pom, you have to delete your local copy first. > > This is a good solution though: http://jira.codehaus.org/browse/MNG-1258 A complete forced rebuild is a bit of an opt out, but if you are using http then you can do if-modified-since. Stuff in ftp and filesystems are different, but you could always do a checksum poll. After all, the stuff in the local cache is just that, a cache. Maybe you need a revocation mechanism, in which repositories can not only publish stuff, they can revoke things. I'm not so sure about this, as it would complicate stuff. The big issue is just pom quality. I've heard the blame put on projects that dont actually use maven, but I dont think that is the real problem. Its more that the artifact set needed to build something and the artifact set needed to use something are often different. Developers seem to stop after creating a pom that can build, even if that includes stuff that isnt needed. Possibly this is just ignorance; unless they see the complete list of dependencies, it isnt obvious what really is being pulled in. It can also be that if you explicitly ask for something like junit3.8.1 in test scope, you dont notice that something else is pushing junit3.7 in the runtime scope, but someone downstream who uses your stuff may find out that junit3.7 is creeping in via accidental transitive dependencies. It would be very interesting to do a post-mortem of how well the transitive development stuff is working. Really. This is not an critique of what's been done, but a proposal to do reviews/interviews and a paper that would be of a grade you could present at any tier-1 software engineering conference, something like "Dependency management in community software development, lessons from the field" -review of design goals of M1 and M2 repos, intro concepts of projects/artifacts, dependency lists, snapshots and version logic. -interview people who worked with m2 as end user projects (cocoon, geronimo) -open up the debate on whether transitive dependency is a good thing or not -worry about security implications and explore vulnerabilities -look at other users of the repository (ivy, smartfrog) and what they do differently. -look at alternatives and see whether they are better or worse -.NET strong versions that use MD5 hashes to bind; (secure, good in production, not in dev, no way to tell which version is older) -GGF application repository service (hasnt really realised what the problems are yet) -Java repository stuff in that JCP w.g -CPAN -RPM/APT repositories, esp, JPackage packaged java artifacts Make some serious suggestions about how to fix it, both process-wise and technologically. I'm kind of busy right now, so am not offering to do this, not until, say, September. But otherwise, it would be a really interesting thing to work on. Anyone interesting in co-authoring? -steve --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: AW: [RANT] This Maven thing is killing us....
by brettporter
::
Rate this Message:
The original snapshot feature works just fine.
There was a particular variation of the feature added that doesn't work as designed. (MNG-1908). The variation works exactly the same way but reuses the file on the server. Using uniqueVersion = false (the default) and a clean up script on the server is a workaround. On 3/07/2006 10:00 PM, Steve Loughran wrote: > roger.butenuth@... wrote: >> Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When >> you have a copy of a snapshot versioned artifact, the jar is not >> updated when a new jar with same snapshot version is uploaded to the >> repository. I already filed this as a bug and hope it will be fixed in >> 2.0.5. It is annoying to increase version numbers during development >> or sending mails around "please delete xyz in you local repository... >> >> Roger > > If artifact sharing at snapshot time is not working, then one of the > nominal core features of maven "better x-team dev" isnt. What is the > test process here? > > -steve > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > -- Brett Porter <brett@...> Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by brettporter
::
Rate this Message:
On 3/07/2006 10:22 PM, Steve Loughran wrote:
> I'm kind of busy right now, so am not offering to do this, not until, > say, September. But otherwise, it would be a really interesting thing to > work on. Anyone interesting in co-authoring? Yep, I've been thinking about these issues for a while (and similar timeframe for being able to do any sort of work on it). I'd be interested in writing something on it. In the mean time, I'd like to see some of the problems and ideas collated somewhere. I'm hoping some of it is already written down in the mails I have flagged. I'm really keen to see the repository manager up and running as it will start to give us a better view of the information already in there and the ability to do some repository-wide analysis. Cheers, Brett -- Brett Porter <brett@...> Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Steve Loughran
::
Rate this Message:
Brett Porter wrote:
> On 3/07/2006 10:22 PM, Steve Loughran wrote: >> I'm kind of busy right now, so am not offering to do this, not until, >> say, September. But otherwise, it would be a really interesting thing >> to work on. Anyone interesting in co-authoring? > > Yep, I've been thinking about these issues for a while (and similar > timeframe for being able to do any sort of work on it). I'd be > interested in writing something on it. OK, we could do something there; latex files in svn as an authoring tool unless you have a better suggestion. > In the mean time, I'd like to see some of the problems and ideas > collated somewhere. I'm hoping some of it is already written down in the > mails I have flagged. > > I'm really keen to see the repository manager up and running as it will > start to give us a better view of the information already in there and > the ability to do some repository-wide analysis. yeah, some httpd stats could be interesting too. Perhaps someone hosting an internal repo could see that. Of course, with caching, you explicitly dont get told whenever something builds against log4j, only when something first pulls it down. There's another reason polling would be interesting I guess; statistics. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
|
|
|
Re: AW: AW: [RANT] This Maven thing is killing us....
by brettporter
::
Rate this Message:
On 4/07/2006 12:49 AM, roger.butenuth@... wrote:
> Hi! > > Brett, can you give some more information about the cleanup script on the server? I found nothing in JIRA. It would be a great help for us if a simple server solution exists. There isn't anything prepared, but if you do so I'm sure it would be valuable to share. It need only remove files older than the current one (ie, keep metadata files and the latest snapshot). It's a feature that's been requested for the repository manager too. > > Where is the performance problem with the snapshot feature? I can see maven downloads new metadata (once a day, as specified), it should be visible in the metadata that there is a new version on the server, so there are no wasted server roundtrips. If you use uniqueVersion=false, then the metadata is no longer in play and it has to check if the SNAPSHOT file has changed (using If-Modified-Since). It was doing this far more often than was necessary. It's been a while since I tinkered with it and don't exactly remember the problem, but I think it's all documented in MNG-1908. We should try and get this fixed in Maven 2.0.5. Thanks for your patience. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
|
|
|
Re: [RANT] This Maven thing is killing us....
by Steve Loughran
::
Rate this Message:
Torsten Curdt wrote:
> Sorry, for the cross-post ...but it seems we need a dialog here > somehow. We now have two threads on two different mailing > lists/communities that really should talk to each other. > >> I propose to commit again all JARs into, say, cocoon/trunk/m2repo >> and then tell Maven at build time to use that directory in the >> checkout area as first repository server in the search list. > > So where is the big difference? For every fresh checkout you download > the jars from subversion. > > Guys I have no solution at hand but let's not throw out the baby with > the bath water. I would be good to summarize all the pain points and > post them over in maven land. The pain being so bad that we are > (somehow) considering going back to ant should be alarming enough. Actually, speaking on behalf of the ant team, can I extend a big (tentative) welcome back :) > Another point seems to be forgotten in this discussion so far - the > legal aspects of distributing jars. Does the ASF want to re-distribute > 3rd party jars? Plus: based on a chat Sylvain and me had with Cliff > during ApacheCon it seems we could have blocks providing bridging code > to LGPL ...as long as we do not provide the jar and the block is > optional. (Sylvain, did I summarize that correctly?) There is always the option of a public yet locked down repository with the sun jars and/or the other external dependencies. Working on a sourceforge repo, we keep extra stuff under SCM, and have the dependency logic look there first. you could even have an SCM-managed repo on sourceforge or codehaus for this other stuff, though it would be a somewhat public admission that the main repository has failed. > I agree that the whole maven2 situation is currently far less than > just acceptable ...but TBH I am not sure the maven team is (or was?) > really aware of all the problems we have. > > Maybe we can get a statement on the maven self-update and > unreliable-messed-up-repository situation. From what it sounds they > are working on it. So let's not work this out in our little cocoon > corner but let's hear what they have to say. > In a way, many of the stuff in M2 is experimental; a build tool that effectively encodes beliefs about how a project should be structured and delivered, focusing on component-based development instead of application dev. I also think its time to look at how well some of the experiment is working. Personally, I always experience a bit of fear when adding a new dependency to a project. the repository stuff, and estimate a couple of hours to get every addition stable, primarily by building up a good exclusion list. M2, and <m2:libraries> in ant, has changed the nature of the problem, from "what versions of what things do I need with this?" to "how much of this stuff do I really need?" and "why are my junit tests not compiling with an error about assertTrue not being known", the latter seguing into "where is junit3.7 coming from?". Its a form of progress, but still painful. Similarly, keeping a repository cache under SCM does at least give you a structured layout for storing multiple versions of stuff under SCM, with flick-of-a-switch access to new versions. It just adds an extra step "pom creation/fixup" to the process. Is it worse than before? Better? Or just, well, different? and if things are either worse or not as good as they could be, what can be changed? One underlying cause seems to be pom quality. Open source software dev is a vast collection of loosely coupled projects, and what we get in the repository in terms of metadata matches this model. Each project produces artifacts that match their immediate needs, with POM files that appear to work at the time of publishing. Maven then caches those and freezes that metadata forever, even if it turns out that the metadata was wrong. There's far better coherence within Gump, where the metadata is effectively maintained more by the gump team themselves than by the individual projects. Question is, what to do about it? And if the m2 repository was an attempt to leave the problems of the M1 repository behind, has it worked? -steve --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by cstamas
::
Rate this Message:
Hi,
just to mention a Maven Proxy alternative Proximity, that collects these kind of stats. Currently (ver RC2) contains a simple Stat implementation that is not transient (on restart it "forgets" the stats) and it offers only few a "top10" views just to demonstrate the feature, the final release will have some more advanced capabilities. Proximity (on the screenshot below) actually shows served artifacts (requested by M2 clients), local hits (items found in local cache) and remote hits (items that had to be [re]fetched from proxied remote reposes)... https://is-micro.myip.hu/~cstamas/proximity-stats.jpg Have fun! ~t~ On 7/3/06, Steve Loughran <stevel@...> wrote: > > yeah, some httpd stats could be interesting too. Perhaps someone hosting > an internal repo could see that. > > Of course, with caching, you explicitly dont get told whenever something > builds against log4j, only when something first pulls it down. There's > another reason polling would be interesting I guess; statistics. > |
|
|
Re: RE: [RANT] This Maven thing is killing us....
by Carlos Sanchez-4
::
Rate this Message:
The repository is as good as the users/projects make it. There's no
difference at all with using ant and including the wrong jars, maybe the problem is that how to fix it in maven is not as easy as in ant. If project A says it depends on B 1.0 and C says it depends on B 1.1, there's a conflict in Maven, Ant and anything you want to use, the difference is that Maven tries to do it for you, but you still can override that behaviour. Right now we are in a good position with a huge number of users trying and testing the metadata in the repository, and forcing projects to support maven by providing good data. On 7/4/06, Torsten Curdt <tcurdt@...> wrote: > Sorry, for the cross-post ...but it seems we need a dialog here > somehow. We now have two threads on two different mailing > lists/communities that really should talk to each other. > > > I propose to commit again all JARs into, say, cocoon/trunk/m2repo > > and then tell Maven at build time to use that directory in the > > checkout area as first repository server in the search list. > > So where is the big difference? For every fresh checkout you download > the jars from subversion. > > Guys I have no solution at hand but let's not throw out the baby with > the bath water. I would be good to summarize all the pain points and > post them over in maven land. The pain being so bad that we are > (somehow) considering going back to ant should be alarming enough. > > Another point seems to be forgotten in this discussion so far - the > legal aspects of distributing jars. Does the ASF want to re-distribute > 3rd party jars? Plus: based on a chat Sylvain and me had with Cliff > during ApacheCon it seems we could have blocks providing bridging code > to LGPL ...as long as we do not provide the jar and the block is > optional. (Sylvain, did I summarize that correctly?) > > I agree that the whole maven2 situation is currently far less than > just acceptable ...but TBH I am not sure the maven team is (or was?) > really aware of all the problems we have. > > Maybe we can get a statement on the maven self-update and > unreliable-messed-up-repository situation. From what it sounds they > are working on it. So let's not work this out in our little cocoon > corner but let's hear what they have to say. > > cheers > -- > Torsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Steve Loughran
::
Rate this Message:
Carlos Sanchez wrote:
> The repository is as good as the users/projects make it. There's no > difference at all with using ant and including the wrong jars, maybe > the problem is that how to fix it in maven is not as easy as in ant. > > If project A says it depends on B 1.0 and C says it depends on B 1.1, > there's a conflict in Maven, Ant and anything you want to use, the > difference is that Maven tries to do it for you, but you still can > override that behaviour. > It seems to me that the difference in ant, the duty to set up your classpath belongs to the project alone, so you, the build.xml author are the only one who can make a mess of your CP. However, on any system with transitive dependencies, you are ceding control of your classpath to other programs out there. Even if you think you know exactly what the dependency graph of your app is, an update to a new version of any your dependencies can pull in new metadata, with a new set of dependencies, and potentially a new classpath. This is not a maven-specific problem; anything that supports transitive dependency logic can suffer from it. Gump and Ivy could, though in both cases the descriptors tend to be hand-written tuned to not exhibit the problem. (in gump most projects dont export dependencies, as the default is compile-time-only). > Right now we are in a good position with a huge number of users trying > and testing the metadata in the repository, and forcing projects to > support maven by providing good data. That still assumes that transitive dependencies are a good thing, and that perfect metadata is achievable. I'm not sure about either of those. I also think they're straying dangerously close to one of the big software engineering tar-pits: versioning. -steve --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Jessek
::
Rate this Message:
Please, let's not go overboard....Ant is nice like c is nice when you need
to get small things done. If you have to maintain very large projects with varying releases/users/etc maven is a much better choice. Even with its current flaws. =p On 7/4/06, Steve Loughran <stevel@...> wrote: > > Carlos Sanchez wrote: > > The repository is as good as the users/projects make it. There's no > > difference at all with using ant and including the wrong jars, maybe > > the problem is that how to fix it in maven is not as easy as in ant. > > > > If project A says it depends on B 1.0 and C says it depends on B 1.1, > > there's a conflict in Maven, Ant and anything you want to use, the > > difference is that Maven tries to do it for you, but you still can > > override that behaviour. > > > > > It seems to me that the difference in ant, the duty to set up your > classpath belongs to the project alone, so you, the build.xml author are > the only one who can make a mess of your CP. > > However, on any system with transitive dependencies, you are ceding > control of your classpath to other programs out there. Even if you think > you know exactly what the dependency graph of your app is, an update to > a new version of any your dependencies can pull in new metadata, with a > new set of dependencies, and potentially a new classpath. > > This is not a maven-specific problem; anything that supports transitive > dependency logic can suffer from it. Gump and Ivy could, though in both > cases the descriptors tend to be hand-written tuned to not exhibit the > problem. (in gump most projects dont export dependencies, as the default > is compile-time-only). > > > Right now we are in a good position with a huge number of users trying > > and testing the metadata in the repository, and forcing projects to > > support maven by providing good data. > > That still assumes that transitive dependencies are a good thing, and > that perfect metadata is achievable. I'm not sure about either of those. > I also think they're straying dangerously close to one of the big > software engineering tar-pits: versioning. > > -steve > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. |
|
|
Re: [RANT] This Maven thing is killing us....
by Mario Ivankovits
::
Rate this Message:
Hi!
> If project A says it depends on B 1.0 and C says it depends on B 1.1, > there's a conflict in Maven, Ant and anything you want to use, the > difference is that Maven tries to do it for you, but you still can > override that behaviour. We also ended up putting our jars in svn again and using only system jars with a path to the jar in our pom. We have 50 direct dependencies, maintaining exclusion lists is a pain in the a** as you have really spent a couple of hours to get everything right again when you add a new dependency. And the problem is not only a version number difference. Also a project might decide to change its artifactId - or split into different smaller pieces. THAT was the real bummer for us. Whats missing in pom.xml is something like: replaces and conflicts So a artifact might say, ok, I "replace" any other artifact or I cant work together "conflict" with one. Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server, xmlrpc-client, xmlrcp-all then it can say that it "conflict" with xmlrpc - and for xmlrpc-all it can say that it "replace" xmlrpc. Still, user intervention is required, but thats better than having the same library on the path multiple times, just due to the fact that the name differs. Maybe also a "contains" would be nice, so xmlrpc-all can say it already "contains" the server,client and common part. But I have to admit, I dont want the one programming the dependency solver ;-) Ciao, Mario --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Carlos Sanchez-4
::
Rate this Message:
The "replace" dependency is alredy logged in jira. Not sure about the
conflict one. On 7/4/06, Mario Ivankovits <mario@...> wrote: > Hi! > > If project A says it depends on B 1.0 and C says it depends on B 1.1, > > there's a conflict in Maven, Ant and anything you want to use, the > > difference is that Maven tries to do it for you, but you still can > > override that behaviour. > We also ended up putting our jars in svn again and using only system > jars with a path to the jar in our pom. > We have 50 direct dependencies, maintaining exclusion lists is a pain in > the a** as you have really spent a couple of hours to get everything > right again when you add a new dependency. > > And the problem is not only a version number difference. Also a project > might decide to change its artifactId - or split into different smaller > pieces. > THAT was the real bummer for us. > > Whats missing in pom.xml is something like: replaces and conflicts > So a artifact might say, ok, I "replace" any other artifact or I cant > work together "conflict" with one. > > Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server, > xmlrpc-client, xmlrcp-all then it can say that it "conflict" with xmlrpc > - and for xmlrpc-all it can say that it "replace" xmlrpc. > Still, user intervention is required, but thats better than having the > same library on the path multiple times, just due to the fact that the > name differs. > > Maybe also a "contains" would be nice, so xmlrpc-all can say it already > "contains" the server,client and common part. > > But I have to admit, I dont want the one programming the dependency > solver ;-) > > Ciao, > Mario > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Steve Loughran
::
Rate this Message:
Jesse Kuhnert wrote:
> Please, let's not go overboard....Ant is nice like c is nice when you need > to get small things done. If you have to maintain very large projects with > varying releases/users/etc maven is a much better choice. Even with its > current flaws. =p I'm not arguing with that, its the transitive dependency thing I'm commenting on. when you write a project, your goal is to get it compile, to create whatever artifacts you create. If you include too many things in your dependency list (like commons-logging instead of commons-logging-api), your stuff still build happily, it just has excessive dependencies, as now it thinks logkit comes in. The people consuming your jar either propagate the problem, or have to do stuff like : <dependency groupID="commons-lang" artifactID="commons-lang" version="${commons-lang.version}"> <exclusion groupId="junit" artifactId="junit"/> </dependency> <dependency groupID="commons-logging" artifactID="commons-logging" version="${commons-logging.version}"> <exclusion groupId="junit" artifactId="junit"/> <exclusion groupId="logkit" artifactId="logkit"/> <exclusion groupId="avalon-framework" artifactId="avalon-framework"/> </dependency> That's the issue. With transitive dependencies, you inherit any error made by anything you depend on. And while you can upgrade versions at the touch of a file, you have to recheck the dependencies whenver you upgrade, or junk creeps in. Now, I think its really nice to know what something was built with; its a wonderful hint as to what you should be using, but its nothing more. A hint. Something to be looked at, and, in the case of the example above, then pretty much discarded. -Steve --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Nicolas De Loof
::
Rate this Message:
> Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server, > xmlrpc-client, xmlrcp-all then it can say that it "conflict" with xmlrpc > - and for xmlrpc-all it can say that it "replace" xmlrpc. > Still, user intervention is required, but thats better than having the > same library on the path multiple times, just due to the fact that the > name differs. > > AFAIK this this what the <relocation> element is designed for in POMs If you ask for xmlrpc and new version has split as you suugest, a POM can be deployed with relocation to xmlrpc-all This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Alexandre Poitras
::
Rate this Message:
I think having a transitive dependency repository is good. Of course,
you depend upon the community good willing but it is the same principle for a wiki. Quality will increase if more and more people participate. I think the Maven Evangelisation guide should be more visible on the Maven web site because right now there aren't a lot of people who know how to submit a correction. On 7/4/06, Steve Loughran <stevel@...> wrote: > Jesse Kuhnert wrote: > > Please, let's not go overboard....Ant is nice like c is nice when you need > > to get small things done. If you have to maintain very large projects with > > varying releases/users/etc maven is a much better choice. Even with its > > current flaws. =p > > I'm not arguing with that, its the transitive dependency thing I'm > commenting on. > > when you write a project, your goal is to get it compile, to create > whatever artifacts you create. If you include too many things in your > dependency list (like commons-logging instead of commons-logging-api), > your stuff still build happily, it just has excessive dependencies, as > now it thinks logkit comes in. The people consuming your jar either > propagate the problem, or have to do stuff like : > > <dependency groupID="commons-lang" > artifactID="commons-lang" > version="${commons-lang.version}"> > <exclusion > groupId="junit" > artifactId="junit"/> > </dependency> > <dependency groupID="commons-logging" > artifactID="commons-logging" > version="${commons-logging.version}"> > <exclusion > groupId="junit" > artifactId="junit"/> > <exclusion > groupId="logkit" > artifactId="logkit"/> > <exclusion > groupId="avalon-framework" > artifactId="avalon-framework"/> > </dependency> > > That's the issue. With transitive dependencies, you inherit any error > made by anything you depend on. And while you can upgrade versions at > the touch of a file, you have to recheck the dependencies whenver you > upgrade, or junk creeps in. > > Now, I think its really nice to know what something was built with; its > a wonderful hint as to what you should be using, but its nothing more. A > hint. Something to be looked at, and, in the case of the example above, > then pretty much discarded. > > -Steve > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by brettporter
::
Rate this Message:
On 4/07/2006 9:34 PM, Torsten Curdt wrote:
> I agree that the whole maven2 situation is currently far less than > just acceptable ...but TBH I am not sure the maven team is (or was?) > really aware of all the problems we have. Not until you forwarded a message (and thanks for doing so). We don't really have the bandwidth to follow along with everyone that is converting builds... > > Maybe we can get a statement on the maven self-update and > unreliable-messed-up-repository situation. From what it sounds they > are working on it. So let's not work this out in our little cocoon > corner but let's hear what they have to say. I think we all recognise there are some issues, particularly with ibiblio dropping out consistently, and also issues with transitivity and versioning that have been raised on the dev@maven thread. I'm not sure what "messed up repository" issues you are having, but would like to hear about it. I know this stuff needs a good hard looking at, but I don't believe there is anything insurmountable here. - Brett -- Brett Porter <brett@...> Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
