Re: Dealing with artifacts that have been moved - What to do?
On 3/19/10 1:01 PM, Mark H. Wood wrote: >> If you put something up on Lulu or whatever, I would read it and I would >> probably recommend it to others. There isn't enough documentation about >> Maven; I just don't think the community can produce the type of >> documentation you're describing. > > Depending on what you mean by "produce", I may have to disagree here. > > Community input is vital to discovering which Practices are Best. One > doesn't just sit and think until a nice neat list of BPs drops into > one's brain; one collects a *lot* of stories about what has worked and > not worked, looking for patterns. It can't be done without the > community's data, and it may be done much more easily and quickly if > community members discuss and debate the meaning of the data as they > accumulate. > > I don't mean to say that a sea of voices, all equal, will necessarily > produce a high-quality piece of scholarship. The effort needs a good > leader with an eye for patterns, to guide discussions along promising > paths as they emerge, and to organize the resulting understanding into > a coherent whole. Mark, I think we're actually in agreement. Of course community input is vitial to any documentation effort. But someone (and you could call this an author, editor, curator, etc.) needs to collect these "stories" and contextualize them. And at the end of the day, it is this person who needs to be able to say "These are what I think are the best practices." ...which is what I meant by "Ron's Best Practices." With a wiki free-for-all, I just don't think anyone is going to take on this kind of ownership. Justin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Mark H. Wood wrote: On Thu, Mar 18, 2010 at 04:21:35PM -0400, Justin Edelson wrote: [snip] In all seriousness, you should publish this as "Ron's Best Practices". I'll second that. If you want a Maven Best Practices document, the surest way to get one is to start writing it. If you put something up on Lulu or whatever, I would read it and I would probably recommend it to others. There isn't enough documentation about Maven; I just don't think the community can produce the type of documentation you're describing. Depending on what you mean by "produce", I may have to disagree here. Community input is vital to discovering which Practices are Best. One doesn't just sit and think until a nice neat list of BPs drops into one's brain; one collects a *lot* of stories about what has worked and not worked, looking for patterns. It can't be done without the community's data, and it may be done much more easily and quickly if community members discuss and debate the meaning of the data as they accumulate. I can only speak from experience in a small team developing and maintaining a portal. My ideas about a best practice for this environment are very likely going to be good but will miss some ideas that will make them better. I know that we are not doing everything in Maven that we could. I have no way to even start a Best Practice for someone who has a team of 150 people building and maintaining an on-line banking system for a multinational bank. I will have very little say about how the Maven team uses Maven in an open source community driven tool building project. They have completely different needs and someone else would be much better at leading the effort to describe "Best Practices" in this environment. I could go and on describing my lack of relevant qualifications but you get the picture and there is no point in alarming the rest of my company, demoralizing my staff and worrying our clients. It has to be a community effort if it is going to produce a good set of practices. Ron I don't mean to say that a sea of voices, all equal, will necessarily produce a high-quality piece of scholarship. The effort needs a good leader with an eye for patterns, to guide discussions along promising paths as they emerge, and to organize the resulting understanding into a coherent whole. Or a small group of leaders. Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
On Thu, Mar 18, 2010 at 04:21:35PM -0400, Justin Edelson wrote: [snip] > In all seriousness, you should publish this as "Ron's Best Practices". I'll second that. If you want a Maven Best Practices document, the surest way to get one is to start writing it. > If you put something up on Lulu or whatever, I would read it and I would > probably recommend it to others. There isn't enough documentation about > Maven; I just don't think the community can produce the type of > documentation you're describing. Depending on what you mean by "produce", I may have to disagree here. Community input is vital to discovering which Practices are Best. One doesn't just sit and think until a nice neat list of BPs drops into one's brain; one collects a *lot* of stories about what has worked and not worked, looking for patterns. It can't be done without the community's data, and it may be done much more easily and quickly if community members discuss and debate the meaning of the data as they accumulate. I don't mean to say that a sea of voices, all equal, will necessarily produce a high-quality piece of scholarship. The effort needs a good leader with an eye for patterns, to guide discussions along promising paths as they emerge, and to organize the resulting understanding into a coherent whole. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu pgpNP5rgaj82h.pgp Description: PGP signature
Re: Dealing with artifacts that have been moved - What to do?
Thiessen, Todd (Todd) wrote: Interesting. Much of what you say I think is already documented. For example the definitive guide explains quite well that by convention Maven supports one artifact per project. It also contains many if not most of the best practices that users often ask on this list how to circumvent. But I know what you are getting at. This best practices guide would be a short summary of statements you find in books like the Definitive Guide, Better Builds with Maven and many of the blogs on the Sonatype web site. But the guide would need to at least reference why these practices are in fact best practices. What are the consequences of not following a best practice? In many cases, these explanations would be short but in others it wouldn't. This could make the best practices document turn into a fairly large beast that just re-iterated what is already in other documents. This duplication can be a pain to manage. As the "true" documents change over time, the best practices document would have to change also. Just one more document to update and keep in sync. Who will want to do that? I would hope that the Best Pratices would link to other documents for most of the details. There is no need to get too redundant in this day of easy hyperlinks I don't want to rain on your idea too much, since I think it does have a lot of merit. However, I also am not fully bought into it. As a final note, the best practices guide should NOT say what repository manager or SCM one should use. That isn't a space I think Maven should get into. I think it is valid to say that its a best practice that a repo manager is used, but to get into which one is "best". Same with SCM. It also shouldn't say which which libraries to use. Those can be completely different depending on the project. I agree with this with the caviate that the Best Practice needs to be specific about some things and I would want to have a paragraph discussing the differences in the Best practice that is caused by choosing one SCM over another. "If you use Eclipse and Subversion then you need to do the following but if you use Git then you need to do this other thing." The specification of the use case also has an impact on the Best Practice. If the use case is "We have a Subversion SCM and use Eclipse STS as our IDE and do not have a Maven repository", it will be different than "We are considering either Git or Subversion as our SCM and are using Netbeans as or IDE". A lot will be the same in terms of strategy but the details and reference links will be different. There is a "s" in "Best Practices" for a reason. It could perhaps list certain libraries and discuss the pros/cons of each, but again, this can change over time and isn't really a best practice. It also could perhaps state which SCMs Maven currently works with, which would help someone looking into Maven to decide if they wanted to use it. But again, this kind of information is hard to keep up to date and isn't really a "Best Practices" thing. This is the kind of info that a Best Practice links to rather than documents. -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Thursday, March 18, 2010 3:55 PM To: Maven Users List Subject: Re: Dealing with artifacts that have been moved - What to do? Wayne Fay wrote: - unambiguous - no "you might do this or mayby that" just "if your situation is this and you want the best development environment do exactly this". But notice some recent questions on the list... - how to compile from multiple source directories - migrating a large ant build to maven without any power to reorg the files/projects - etc It seems pretty rare that someone is looking for what you are proposing to create... My suspicion is that these are caused by not following the "Best Practice" for Maven. Under what circumstance would you recommend to a user that they set up a project that required 2 source directories? In the end, I suspect that they really have 2 (or more) projects with 1 source directory each with dependencies between them. Once they "Mavenize" their project structure, they will find that they do not need these gymnastics. Migration is always tough and may be one of the last "Best Practices" to emerge. Your suggestion, if I recall correctly was to not try to Mavenize in the face of an entrenched Ant lobby until you had established a high level buy-in. That in itself could be the root of a "Best Practice" that is less about Maven technical issues and more about how to plan and organize a large scale methodology upgrade and how to justify the investment to management and the rest of the team. The fact that a number of
Re: Dealing with artifacts that have been moved - What to do?
Justin Edelson wrote: On 3/18/10 3:55 PM, Ron Wheeler wrote: Wayne Fay wrote: - unambiguous - no "you might do this or mayby that" just "if your situation is this and you want the best development environment do exactly this". But notice some recent questions on the list... - how to compile from multiple source directories - migrating a large ant build to maven without any power to reorg the files/projects - etc It seems pretty rare that someone is looking for what you are proposing to create... My suspicion is that these are caused by not following the "Best Practice" for Maven. Under what circumstance would you recommend to a user that they set up a project that required 2 source directories? In the end, I suspect that they really have 2 (or more) projects with 1 source directory each with dependencies between them. Once they "Mavenize" their project structure, they will find that they do not need these gymnastics. But in neither of these cases was the question "should I be doing this?" It was "I need to do this. Tell me how do I do it." Migration is always tough and may be one of the last "Best Practices" to emerge. Your suggestion, if I recall correctly was to not try to Mavenize in the face of an entrenched Ant lobby until you had established a high level buy-in. That in itself could be the root of a "Best Practice" that is less about Maven technical issues and more about how to plan and organize a large scale methodology upgrade and how to justify the investment to management and the rest of the team. Except that Wayne's wrong about this :) Management buy-in doesn't mean shit. Thats why it might take a long time to come to a consensus. That should not stop work on other use cases. The fact that a number of people are not looking for the right things is due to a certain extent to the power and flexibility of Maven and the lack of a set of "Best Practices". I don't agree that this is what's going on here. You could be right. I am reading in a bit into the reason that someone would need 2 source directories in a POM. There was not much detail given as to why but I have never seen any of the more experience folks here recommend that as a solution to any development strategy issue. I am jumping to the conclusion that they really have 2 projects and so on. Maven is one of those tools that really needs a warning note "Just because Maven can do it, does not mean that you should do it." Seriously? Yes. Very. How many Maven project structures and development methodologies are radically different but equally recommended can you come up with for a small team of less than 5 developers that are developing a webapp in Java with Spring on Eclipse or Netbeans for deployment on Tomcat, Glassfish or Websphere? How difficult would it be to get a consensus on which one of your suggestions is the "best". How hard would it be to get agreement on what is the criteria for "best". Just for a starting point, in my opinion, the best practice for the above situation would suggest that the project needs a subversion repository, a Nexus community version repository, the Spring STS version of Eclipse, a master POM for the project, a set of library POMs for the shared code and utilities, and a single project POM to build the WAR file. Lots of details to flesh out but they would fit on 1 page with a few pages of POMs, settings and misc. xml samples attached. But IMHO you should be using Git instead of Subversion and STS doesn't have enough management tools to support a large-scale rollout. Are we actually going to be able to reach consensus on those things? I would have no objection to the inclusion of Git in this "Best Practice". I have not used it but I have heard good things about it. I am not sure that a 5 man team would be doing a large roll out. There would have to be another Best Practice for that. I am sure that this "Best Practice" could also be extended to include the use of other IDEs without seriously affecting the methodology. It might require one or 2 pages of addenda to cover minor setup changes but I suspect that it would not affect the POM structure at all. In all seriousness, you should publish this as "Ron's Best Practices". If you put something up on Lulu or whatever, I would read it and I would probably recommend it to others. There isn't enough documentation about Maven; I just don't think the community can produce the type of documentation you're describing. Justin "Ron's Best Practices" would have to be "Ron's Best Practice" I can only make suggestion about what I have learned in my own experience. I have not done a large scale roll-out. I have a small team. For example, I do not need many of the features of Nexus Professional but that does not mean that some of the people starting out with there first project will not have a larger team and a more demanding management structure, I am n
RE: Dealing with artifacts that have been moved - What to do?
Interesting. Much of what you say I think is already documented. For example the definitive guide explains quite well that by convention Maven supports one artifact per project. It also contains many if not most of the best practices that users often ask on this list how to circumvent. But I know what you are getting at. This best practices guide would be a short summary of statements you find in books like the Definitive Guide, Better Builds with Maven and many of the blogs on the Sonatype web site. But the guide would need to at least reference why these practices are in fact best practices. What are the consequences of not following a best practice? In many cases, these explanations would be short but in others it wouldn't. This could make the best practices document turn into a fairly large beast that just re-iterated what is already in other documents. This duplication can be a pain to manage. As the "true" documents change over time, the best practices document would have to change also. Just one more document to update and keep in sync. Who will want to do that? I don't want to rain on your idea too much, since I think it does have a lot of merit. However, I also am not fully bought into it. As a final note, the best practices guide should NOT say what repository manager or SCM one should use. That isn't a space I think Maven should get into. I think it is valid to say that its a best practice that a repo manager is used, but to get into which one is "best". Same with SCM. It also shouldn't say which which libraries to use. Those can be completely different depending on the project. It could perhaps list certain libraries and discuss the pros/cons of each, but again, this can change over time and isn't really a best practice. It also could perhaps state which SCMs Maven currently works with, which would help someone looking into Maven to decide if they wanted to use it. But again, this kind of information is hard to keep up to date and isn't really a "Best Practices" thing. > -Original Message- > From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > Sent: Thursday, March 18, 2010 3:55 PM > To: Maven Users List > Subject: Re: Dealing with artifacts that have been moved - What to do? > > Wayne Fay wrote: > >> - unambiguous - no "you might do this or mayby that" just "if your > >> situation is this and you want the best development > environment do exactly this". > >> > > > > But notice some recent questions on the list... > > - how to compile from multiple source directories > > - migrating a large ant build to maven without any power to > reorg the > > files/projects > > - etc > > > > It seems pretty rare that someone is looking for what you are > > proposing to create... > > > > > My suspicion is that these are caused by not following the > "Best Practice" for Maven. > Under what circumstance would you recommend to a user that > they set up a project that required 2 source directories? > In the end, I suspect that they really have 2 (or more) > projects with 1 source directory each with dependencies between them. > Once they "Mavenize" their project structure, they will find > that they do not need these gymnastics. > > Migration is always tough and may be one of the last "Best > Practices" to emerge. > Your suggestion, if I recall correctly was to not try to > Mavenize in the face of an entrenched Ant lobby until you had > established a high level buy-in. That in itself could be the > root of a "Best Practice" that is less about Maven technical > issues and more about how to plan and organize a large scale > methodology upgrade and how to justify the investment to > management and the rest of the team. > > > The fact that a number of people are not looking for the > right things is due to a certain extent to the power and > flexibility of Maven and the lack of a set of "Best Practices". > Maven is one of those tools that really needs a warning note > "Just because Maven can do it, does not mean that you should do it." > > How many Maven project structures and development > methodologies are radically different but equally recommended > can you come up with for a small team of less than 5 > developers that are developing a webapp in Java with Spring > on Eclipse or Netbeans for deployment on Tomcat, Glassfish or > Websphere? > > How difficult would it be to get a consensus on which one of > your suggestions is the "best". > > How hard would it be to get agreement on what is the criteria > for "best". > > Just for a start
Re: Dealing with artifacts that have been moved - What to do?
On 3/18/10 3:55 PM, Ron Wheeler wrote: > Wayne Fay wrote: >>> - unambiguous - no "you might do this or mayby that" just "if your >>> situation >>> is this and you want the best development environment do exactly this". >>> >> >> But notice some recent questions on the list... >> - how to compile from multiple source directories >> - migrating a large ant build to maven without any power to reorg the >> files/projects >> - etc >> >> It seems pretty rare that someone is looking for what you are >> proposing to create... >> >> > My suspicion is that these are caused by not following the "Best > Practice" for Maven. > Under what circumstance would you recommend to a user that they set up a > project that required 2 source directories? > In the end, I suspect that they really have 2 (or more) projects with 1 > source directory each with dependencies between them. > Once they "Mavenize" their project structure, they will find that they > do not need these gymnastics. But in neither of these cases was the question "should I be doing this?" It was "I need to do this. Tell me how do I do it." > Migration is always tough and may be one of the last "Best Practices" to > emerge. > Your suggestion, if I recall correctly was to not try to Mavenize in the > face of an entrenched Ant lobby until you had established a high level > buy-in. That in itself could be the root of a "Best Practice" that is > less about Maven technical issues and more about how to plan and > organize a large scale methodology upgrade and how to justify the > investment to management and the rest of the team. Except that Wayne's wrong about this :) Management buy-in doesn't mean shit. > The fact that a number of people are not looking for the right things is > due to a certain extent to the power and flexibility of Maven and the > lack of a set of "Best Practices". I don't agree that this is what's going on here. > Maven is one of those tools that really needs a warning note "Just > because Maven can do it, does not mean that you should do it." Seriously? > How many Maven project structures and development methodologies are > radically different but equally recommended can you come up with for a > small team of less than 5 developers that are developing a webapp in > Java with Spring on Eclipse or Netbeans for deployment on Tomcat, > Glassfish or Websphere? > > How difficult would it be to get a consensus on which one of your > suggestions is the "best". > > How hard would it be to get agreement on what is the criteria for "best". > > Just for a starting point, in my opinion, the best practice for the > above situation would suggest that the project needs a subversion > repository, a Nexus community version repository, the Spring STS version > of Eclipse, a master POM for the project, a set of library POMs for the > shared code and utilities, and a single project POM to build the WAR > file. Lots of details to flesh out but they would fit on 1 page with a > few pages of POMs, settings and misc. xml samples attached. But IMHO you should be using Git instead of Subversion and STS doesn't have enough management tools to support a large-scale rollout. Are we actually going to be able to reach consensus on those things? In all seriousness, you should publish this as "Ron's Best Practices". If you put something up on Lulu or whatever, I would read it and I would probably recommend it to others. There isn't enough documentation about Maven; I just don't think the community can produce the type of documentation you're describing. Justin > How many variants would that "Best Practice" need to satisfy 90% of the > target use cases. > > > Ron > > PS- Who is producing and assuming ongoing responsibility for this BPG? >>> The community. >>> >> >> Sounds like the Maven User Wiki is a fine place to start. I started >> the document [1] for "the community" to add/edit as it deems useful. >> >> [1] http://docs.codehaus.org/display/MAVENUSER/Maven+Best+Practice+Guide >> >> Wayne >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Wayne Fay wrote: - unambiguous - no "you might do this or mayby that" just "if your situation is this and you want the best development environment do exactly this". But notice some recent questions on the list... - how to compile from multiple source directories - migrating a large ant build to maven without any power to reorg the files/projects - etc It seems pretty rare that someone is looking for what you are proposing to create... My suspicion is that these are caused by not following the "Best Practice" for Maven. Under what circumstance would you recommend to a user that they set up a project that required 2 source directories? In the end, I suspect that they really have 2 (or more) projects with 1 source directory each with dependencies between them. Once they "Mavenize" their project structure, they will find that they do not need these gymnastics. Migration is always tough and may be one of the last "Best Practices" to emerge. Your suggestion, if I recall correctly was to not try to Mavenize in the face of an entrenched Ant lobby until you had established a high level buy-in. That in itself could be the root of a "Best Practice" that is less about Maven technical issues and more about how to plan and organize a large scale methodology upgrade and how to justify the investment to management and the rest of the team. The fact that a number of people are not looking for the right things is due to a certain extent to the power and flexibility of Maven and the lack of a set of "Best Practices". Maven is one of those tools that really needs a warning note "Just because Maven can do it, does not mean that you should do it." How many Maven project structures and development methodologies are radically different but equally recommended can you come up with for a small team of less than 5 developers that are developing a webapp in Java with Spring on Eclipse or Netbeans for deployment on Tomcat, Glassfish or Websphere? How difficult would it be to get a consensus on which one of your suggestions is the "best". How hard would it be to get agreement on what is the criteria for "best". Just for a starting point, in my opinion, the best practice for the above situation would suggest that the project needs a subversion repository, a Nexus community version repository, the Spring STS version of Eclipse, a master POM for the project, a set of library POMs for the shared code and utilities, and a single project POM to build the WAR file. Lots of details to flesh out but they would fit on 1 page with a few pages of POMs, settings and misc. xml samples attached. How many variants would that "Best Practice" need to satisfy 90% of the target use cases. Ron PS- Who is producing and assuming ongoing responsibility for this BPG? The community. Sounds like the Maven User Wiki is a fine place to start. I started the document [1] for "the community" to add/edit as it deems useful. [1] http://docs.codehaus.org/display/MAVENUSER/Maven+Best+Practice+Guide Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
> - unambiguous - no "you might do this or mayby that" just "if your situation > is this and you want the best development environment do exactly this". But notice some recent questions on the list... - how to compile from multiple source directories - migrating a large ant build to maven without any power to reorg the files/projects - etc It seems pretty rare that someone is looking for what you are proposing to create... >> PS- Who is producing and assuming ongoing responsibility for this BPG? > > The community. Sounds like the Maven User Wiki is a fine place to start. I started the document [1] for "the community" to add/edit as it deems useful. [1] http://docs.codehaus.org/display/MAVENUSER/Maven+Best+Practice+Guide Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Dealing with artifacts that have been moved - What to do?
> > PS- Who is producing and assuming ongoing responsibility > for this BPG? > > > > > The community. > It won't get done. Someone needs to come forward and lead the charge. All these suggestions going to the mailing list I am sure a lot of readers are enjoyoing but I doubt anyone is actually capturing the suggestions and putting them in a formal document available on the web. Its a good idea. It will just need some commitment. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Wayne Fay wrote: Another section for the "Best Practices Guide" There are multiple books written about Maven (many as free PDFs) in addition to the Maven website, various plugin documentation, Maven User Wiki, and many other resources. There is no shortage of documentation but it is not focused on integrating maven into common development environments. At least one third of the questions on this list are straight out of the existing documentation. Some other good percentage is answered in the Maven books that a relatively small portion of the total Maven user population ever reads due to the length. That is where a "Best Practice" would be good. - short, - targeted to each situation - tells you where to get the technical details - unambiguous - no "you might do this or mayby that" just "if your situation is this and you want the best development environment do exactly this". I'm not saying this Best Practices Guide is not a good idea. I just don't think it would necessarily be as useful (especially in reducing traffic on this list) as you might think. PS- Who is producing and assuming ongoing responsibility for this BPG? The community. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
> Another section for the "Best Practices Guide" There are multiple books written about Maven (many as free PDFs) in addition to the Maven website, various plugin documentation, Maven User Wiki, and many other resources. At least one third of the questions on this list are straight out of the existing documentation. Some other good percentage is answered in the Maven books that a relatively small portion of the total Maven user population ever reads due to the length. I'm not saying this Best Practices Guide is not a good idea. I just don't think it would necessarily be as useful (especially in reducing traffic on this list) as you might think. PS- Who is producing and assuming ongoing responsibility for this BPG? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Another section for the "Best Practices Guide" Sonotype has an article that almost describes how to do this. It is pretty good but lacks a bit about how (and why) to create a pom for the jars you need to upload. Ron Wayne Fay wrote: The document has movedhttp://download.java.net/maven/1/javax.jms/jars/jms-1.1.jar";>here. You should not be using the java.net repos for a number of reasons, including this problem related to HTML 301s being saved as jars etc. You should download and manually install these artifacts into Nexus so they can be properly distributed within your team. We are using Sonatype Nexus and I am wondering if this as simple as adding Nexus has its own user list for questions such as these. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
> The document has moved href="http://download.java.net/maven/1/javax.jms/jars/jms-1.1.jar";>here. You should not be using the java.net repos for a number of reasons, including this problem related to HTML 301s being saved as jars etc. You should download and manually install these artifacts into Nexus so they can be properly distributed within your team. > We are using Sonatype Nexus and I am wondering if this as simple as adding Nexus has its own user list for questions such as these. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
