Free advice - worth at least what you are paying.
1) Get a repository such as Nexus if you are going to go serious work
with Maven. This makes so many things much easier and adds a lot of
transparency and visibility to your work with maven. There are at least
2 free ones available. I use Nexus but others here use another one and
are happy with it
2) Do things the "Maven" way. If you do not like the Maven way, don't
start with Maven. It will drive you crazy, annoy the hell out of the
rest of us, lead to countless frustrating questions and in the end it
will be worse (more fragile, more complex and less automated) than your
current system.
3) Avoid doing things that require custom plug-ins until you have your
build working without one. Too many people use custom plug-ins to hide
bad practices. They are fine for optimizing your builds but are not
necessary if you are building a normal Java system
4) Read the maven books.
5) When asking for help, start by stating the ultimate goal and give the
high level view of the problem first. The temptation is to ask "How do I
fix my POM to stop it failing when I put this in the POM?" This often
leads to several days of messages going back and forth until someone
figures out what the person really needs and gives a real solution which
often ends up being completely unrelated to the original question since
the project structure or buld strategy was not right in the first
place." It is easy to get bad advice from very talented and well-meaning
experts if you state the problem inadequately.
6) Unless you are building something completely unheard of in the Java
world, someone here has already got the build that you will need working
with Maven. So don't worry, Maven will do the job for you.
7) There are a lot of really competent experts here that regularly
contribute solutions and watch the forum daily, so you are never left
hanging, if you ask for advice here.
Good Luck
Ron
On 26/11/2010 8:41 AM, raphael.jolivet wrote:
Hi,
Thanks for your anwsers.
I will definitely ask the log4j team.
For now, I have found a workaround by deploying log4j in my local repository
as a "jar" package:
mvn deploy:deploy-file -Dfile=d:/Download/log4j-1.2.16.jar -DgroupId=log4j
-DartifactId=log4j -Dversion=2.2.16 -Dpackaging=jar
-Durl=file:///v:/maven/repositories/third-party
Then, I have changed the dependency in my POM file:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
It works well.
But I have some "maven-related" ideas to clarify:
I have looked in the JAR and the MANIFEST is full of Bundle-<Something>
properties.
So I guess this is actually a OSGI "bundle" package as Michael suggest.
So, if "bundle" is a standard packaging option, as maven guys, would you say
that :
- The artifact file in the central repository should have a "jar" extension
or a "bundle" extension.
- In the later case, this means that the log4j team as been able to put
something inconsistent in the central repository.
Isn't the central repository a repository server of some kind that should
have some consistency checks on "upload" ? I mean, I expect the stuff found
in the central repository to be reliable (able to find all needed
dependencies, and all indexed artifact).
I don't criticize or something.
I'm quite a newbie in Maven and I want to know how things are supposed to
work, how much I can rely on the repositories. for example, should I do a
local "proxy" repository of what I need in case some projects got moved or
deprecated?
I'm actually migrating all our projects to maven and I want to be sure of
the durability of the solution I choose.
Thanks in advance for your advice.
Kind regards,
Raphael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
