Noel J. Bergman wrote:
Stefano Bagnara wrote:
Once you have all the dependencies maven works even disconnected.
You need all the plugins [and] all the
dependencies (system/test/runtime/compile)
in your local repository.
What is the fastest way to assure that to be the case? For example, if I
run svn up, and do a maven build, is it then safe to disconnect?
From:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
The build lifecycle for maven is:
validate, compile, test, package, integration-test, verify, install, deploy.
I'm not sure what the site lifecycle include, but you will need also to
run at least once a "mvn site" if you want to be sure you have the
plugins to generate the website.
The lifecycle phases are executed in order and executing one imply the
execution of the previous one.
one of the main maven feature is that it automatically do this
stuff, maybe it does not make sense to use maven if you want
to manage it all manually.
Believe me, if someone had done this work with ant instead of maven, I'd be
a lot happier. However, several of our components, and the web-sites, are
now built with maven, so unless we decide to ban maven or I redo it in ant
(both are equally unlikely at the moment), making this work properly is
important.
Something can be done by running mvn ant:ant (it generates a build.xml
for the basic goals). Something else can be done by actually using ant
plugins (doxia can be run in ant too.. ) but the whole thing does not
make sense to me: maven is MUCH better than ant (IMO).
With ant you don't have the choice to automcatically download its plugin
or manually download it. In maven you have the choice.
What I don't understand is that we talked a lot of time about removing
jars from our svn repository because jars should not be included in svn
within sources and everyone seemed to agree
You must have missed
http://mail-archives.apache.org/mod_mbox/james-server-dev/200509.mbox/%3cNBB
[EMAIL PROTECTED]
:-)
I reread it but I don't get your opinion: in a perfect world what would
you like to see in the svn source repository?
Here is a pratical example from james:
Should dnsjava be there? (build dep)
Should junit be there? (test dep)
Should derby be there? (runtime dep library )
Should ant be there (build tool)
Should any build plugin used be there?
Should phoenix be there? (container)
Should the JVM be there? (vm)
My idea is that we can expect that a developer already have tools (jvm,
ant, maven). The I also think that it is no good to have all of the
other things in the source repository I would try to keep them in a
different repository (maven repository).
As an example we would have a dnsjava.jar for each product (a copy for
james, a copy for jspf). With maven we can keep a single copy of that
library.
One of the recent repository related discussions was regarding third party
dependencies, and we've talked about a repository maintained by ASF projects
containing those artifacts upon which they depend. Under such
circumstances, I might consider trusting the repository, although still
requiring Maven to fix their security issues.
Ok, this is similar to the solution I proposed to you: just create a
maven repository for james dependencies. It is not the source repository
for the project, it is the dependencies repository. It makes sense to me.
If apache does this thing apache-wide imho this is ok. If you want us to
start creating this repository for james just tell where we should
publish it and I'll try to do something.
(IMHO all this stuff is not good, but if this is needed to reach a
consensus I'll try to work on it).
As a practical matter, I'm more concerned about our project builds than
the
web-site builds, although I'd like to be able to do everything while
disconnected.
If you already have all of the dependencies installed in your local
repository you're safe.
As asked above, how do we ensure that?
I have to run at least once every command you want to run later.
About maven plugins after a while you'll start using maven you will have
every needed plugin in your home in the ".m2" folder, about the project
dependencies you can run a "mvn package" and you should have anything
you need.
If you have all of the dependencies in non-maven2 form (official
download) you can mannually install each of them in your local
repository but this will become a PITA because maven
Norman tells me that although he uses Maven to build, but he either manually
installs the jars, or checks them by hand.
I tested this now: delete all my ".m2" local repository. clean checkout
of our projects. I have been able to build all without running any "mvn
install".
The artifacts I uploaded to my people.apache.org home have been uploaded
for this very thing.
If it is not working this way then it is a bug and I missed something.
Maybe Norman was referring to manually looking for artifacts for
dependencies and plugins when you create a pom.xml, but I don't know: we
should wait for him to give us more details.
Btw I still don't get where you add security: I bet that you never
checked that the jars I uploaded to our repository are official and
signed.
Anything I pull down from SVN is considered trusted because we presume that
our Committers *ARE* doing the right things. No, I would never trust
ibiblio. There have already been instances of false artifacts. Again,
without signed artifacts, nothing should be trusted that cannot have its
origin validated.
Ok, I almost share this view. Let's say that we trust apache svn
repository and apache's maven2 repositories (committers put stuff there
as like for svn).
In order to build our products without using codehaus and ibiblio we
have to put the artifacts we use from there in an ".apache.org"
repository: tell me where and how and I'll do the manual work ;-)
Why should you trust things in our svn more than things automatically
downloaded by the temporary maven repository I setup on
people.apache.org for the current poms?
I could trust your stuff, since it is downloaded directly from the ASF
infrastructure, but that is also the problem. We cannot permit every
committer to create their own private repositories on the infrastructure.
We need mirroring to support scaling (which surfaces maven's security
issue). You really don't want to do what you did, which is why I keep
trying to get you communicate on the repository@ list.
--- Noel
I subscribed repository@ 18 hours ago and I read the last month
archives. Unfortunately, if I have not missed anything, there is not a
solution to the third party libraries as official maven repositories
defined by the last email to all committers have the rule "only ASF stuff".
So we can either:
1) wait until repository@ find a solution to thirdparty stuff
2) put every third party library into a james repository.
I'm fine with the 1 (wait) as I'll be on holiday (not connected) from 8
to 24 august ;-).
Q: is svn.apache.org mirrored? I don't understand why downloading a jar
from our svn scale better than downloading it from my people.apache.org
home. Furthermore we can put the maven2 repository in svn.apache.org if
this helps and this way the jars would be in the same position.
Stefano
PS: I don't understand the mood behind this thread: are we discussing
about improving the current way or are we discussing of bad things
introduced (by me) that have to be fixed or reverted?
