You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Michael Goodell <mg...@pdc4u.com> on 2010/03/18 00:38:11 UTC
Dealing with artifacts that have been moved - What to do?
Hello,
I am somewhat new to Maven and running into problems with artifacts being moved and we are not sure how correct the problem.
Seeing this during build (On Hudson):
**error: error reading /var/db/www/.m2/repository/javax/jms/jms/1.1/jms-1.1.jar; error in opening zip file
error: error reading /var/db/www/.m2/repository/com/sun/jdmk/jmxtools/1.2.1/jmxtools-1.2.1.jar; error in opening zip file
error: error reading /var/db/www/.m2/repository/com/sun/jmx/jmxri/1.2.1/jmxri-1.2.1.jar; error in opening zip file**
looking at the files I see that they are HTML documents indicating the artifact has moved.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved<a href="http://download.java.net/maven/1/javax.jms/jars/jms-1.1.jar">here</a>.</p>
<hr>
<address>Apache Server at maven-repository.dev.java.net Port 443</address>
</body></html>
We are using Sonatype Nexus and I am wondering if this as simple as adding "http://download.java.net/maven/1/" in my repository list or would we have to manually download and add
these items as they come up?
Thank you in advance for any direction.
Regards,
M. Goodell
Maven Build Output:
At revision 989
no change for https://builds.pdc4u.com/subversion/parsingValidation/trunk since the previous build
Parsing POMs
[trunk] $ /usr/local/diablo-jdk1.6.0/bin/java -Xms32m -Xmx512m -XX:MaxPermSize=1024m -cp /var/db/hudson/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.340.jar:/usr/local/share/java/maven2/boot/classworlds-1.1.jar hudson.maven.agent.Main /usr/local/share/java/maven2 /usr/local/apache-tomcat-6.0/webapps/hudson/WEB-INF/lib/remoting-1.340.jar /var/db/hudson/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.340.jar 65030 /var/db/hudson/plugins/maven-plugin/WEB-INF/lib/maven2.1-interceptor-1.2.jar
<===[HUDSON REMOTING CAPACITY]===>channel started
Executing Maven: -B -f /var/db/hudson/jobs/parsingValidation/workspace/trunk/pom.xml install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building PDC Web Services File Parsing and Validation
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using encoding: 'UTF-8' to copy filtered resources.
[WARNING] POM for 'javax.mail:mail:pom:1.4:compile' is invalid.
Its dependencies (if any) will NOT be available to the current build.
[WARNING] POM for 'javax.jms:jms:pom:1.1:compile' is invalid.
Its dependencies (if any) will NOT be available to the current build.
[WARNING] POM for 'com.sun.jdmk:jmxtools:pom:1.2.1:compile' is invalid.
Its dependencies (if any) will NOT be available to the current build.
[WARNING] POM for 'com.sun.jmx:jmxri:pom:1.2.1:compile' is invalid.
Its dependencies (if any) will NOT be available to the current build.
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 34 source files to /var/db/hudson/jobs/parsingValidation/workspace/trunk/target/classes
[HUDSON] Archiving /var/db/hudson/jobs/parsingValidation/workspace/trunk/pom.xml to /var/db/hudson/jobs/parsingValidation/modules/com.paydatacenter$parsingValidation/builds/2010-03-17_17-24-41/archive/com.paydatacenter/parsingValidation/1.0.1-SNAPSHOT/pom.xml
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
*error: error reading /var/db/www/.m2/repository/javax/jms/jms/1.1/jms-1.1.jar; error in opening zip file
error: error reading /var/db/www/.m2/repository/com/sun/jdmk/jmxtools/1.2.1/jmxtools-1.2.1.jar; error in opening zip file
error: error reading /var/db/www/.m2/repository/com/sun/jmx/jmxri/1.2.1/jmxri-1.2.1.jar; error in opening zip file
*
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6 seconds
[INFO] Finished at: Wed Mar 17 17:24:52 MDT 2010
[INFO] Final Memory: 11M/80M
[INFO] ------------------------------------------------------------------------
Sending e-mails to: *******************************
channel stopped
Sending e-mails to: *******************************
Finished: FAILURE
RE: Dealing with artifacts that have been moved - What to do?
Posted by "Thiessen, Todd (Todd)" <tt...@avaya.com>.
> > 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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:rwheeler@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 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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dealing with artifacts that have been moved - What to do?
Posted by "Thiessen, Todd (Todd)" <tt...@avaya.com>.
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:rwheeler@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 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Justin Edelson <ju...@gmail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
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 mwood@IUPUI.Edu
Re: Dealing with artifacts that have been moved - What to do?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 not even sure if I am doing everything properly with Maven and
Eclipse yet.
I am sure that a lot of the people in this forum could walk into my
office and improve things a lot, with ideas and tools that I don't even
know about.
It is that expertise that I would like to see captured in a "Best
Practices" set so that the next guys don't take 2 years to get where I
am, spending time cleaning up POMs and libraries that could have been
done much better when we started with Maven, if only someone had laid it
out clearly.
Our builds worked but we did not get a lot of the advantages and control
that we have now.
>> 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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Justin Edelson <ju...@gmail.com>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Wayne Fay <wa...@gmail.com>.
> - 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Wayne Fay <wa...@gmail.com>.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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:
>> <p>The document has moved<a
>> href="http://download.java.net/maven/1/javax.jms/jars/jms-1.1.jar">here</a>.</p>
>>
>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dealing with artifacts that have been moved - What to do?
Posted by Wayne Fay <wa...@gmail.com>.
> <p>The document has moved<a
> href="http://download.java.net/maven/1/javax.jms/jars/jms-1.1.jar">here</a>.</p>
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org