You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2006/07/26 19:52:44 UTC
website updated, maven2 poms, temporary repository, new artifacts
The new website is 42MB against the old 21MB.
I'm committing it to site/www and publishing it, but maybe we should not
keep the generated stuff in svn anymore. (I already wrote a mail to
site-dev to discuss about this)
==================
I need also to let you know that I added temporarily this repository to
our poms:
----
<id>bago-dist-m1</id>
<name>Temporary Repository</name>
<url>http://people.apache.org/~bago/maven/dist-m1</url>
----
I also published there bouncycastle jars used by james, and builds of
the james-project, maven-skin and jspf-0.9-SNAPSHOT artifacts.
This way jspf, site and server websites can be built with a simple "mvn
site", otherwise we should wait an official release and publication of
the artifact on ibilio before being able to use them or a local "mvn
install" of the previous projects.
"mvn install" is pretty simple, but I thought that it was not so easy
for a maven newbie to checkout, build and install needed artifacts.
==================
I also created 2 new artifacts in sandbox:
"maven-skin" is the maven2 skin project that is used to generate the new
website
"james-project" is a top level pom for the james project: it is a child
of "org.apache:apache-3" pom and defines a few defaults for james
project products.
jSPF, site and server have been updated to use that new parent.
Please let me know where do you think we should move "james-project"
(and maybe you also want to rename it) and where to put the maven-skin.
As far as I understood from maven documentation if we want to be able to
create the full website with a single command we should use the
following structure:
- maven-skin
- james-project
|-pom.xml
|-server
| '-pom.xml
|-jspf
| '-pom.xml
'-site
'-pom.xml
This would mean merging all trunks in a single tree and maybe we should
delay this decision until we decide wether to move server to maven2 or not.
That said, I don't think that it is a big problem to build the website
in 3 different steps.
===================
Stefano
JAMES GUI for Administration - Java Web Start or JSP/Servlet or PHP
Posted by Miroslav Nachev <mi...@space-comm.com>.
Hi,
Is there any GUI application for James Administration?
Best Regards,
Miroslav Nachev
Re[2]: JAMES GUI for Administration - Java Web Start or JSP/Servlet or PHP
Posted by Miroslav Nachev <mi...@space-comm.com>.
I can try it, but to do that I need of documentation for remote
manager and some samples? From where can I find it?
Best Regards,
Miroslav Nachev
NM> Not yet. But we whould be happy if someone will start writing one. In
NM> james-trunk all remotemanager actions can be invoked via JMX so a better
NM> start whould be there.
NM> bye
NM> Norman
NM> Am Sonntag, den 13.08.2006, 10:24 +0300 schrieb Miroslav Nachev:
>> Hi,
>>
>> Is there any GUI application for James Administration?
>>
>>
>> Best Regards,
>> Miroslav Nachev
>>
>>
>> !EXCUBATOR:1,44ded3be114092033610461!
Re: JAMES GUI for Administration - Java Web Start or JSP/Servlet
or PHP
Posted by Norman Maurer <nm...@byteaction.de>.
Not yet. But we whould be happy if someone will start writing one. In
james-trunk all remotemanager actions can be invoked via JMX so a better
start whould be there.
bye
Norman
Am Sonntag, den 13.08.2006, 10:24 +0300 schrieb Miroslav Nachev:
> Hi,
>
> Is there any GUI application for James Administration?
>
>
> Best Regards,
> Miroslav Nachev
>
>
> !EXCUBATOR:1,44ded3be114092033610461!
Re: website updated, maven2 poms, temporary repository, new artifacts
Posted by Stefano Bagnara <ap...@bago.org>.
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
> BJGEAGJAKLIDBKJOPGEAMDKAC.noel@devtech.com%3e
>
> :-)
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?
RE: website updated, maven2 poms, temporary repository, new artifacts
Posted by "Noel J. Bergman" <no...@devtech.com>.
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?
> 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.
> 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
BJGEAGJAKLIDBKJOPGEAMDKAC.noel@devtech.com%3e
:-)
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.
> > 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?
> 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.
> 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.
> 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
Re: website updated, maven2 poms, temporary repository, new artifacts
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>>> More importantly, if [it] is a correct fact, as you state and Alex also
>>> mentioned as a proble, that you need to create a repository for maven to
>>> work at all is reason to not use Maven. If maven cannot work
> standalone, it
>>> should not be used. Please tell me that Maven is not really that stupid
> a
>>> build system.
>
>> Well, it seems that you're really against maven at all.
>
> Read the above again. What I said is that IF Maven cannot run disconnected,
> THEN I am against using it. YES. Absolutely. But if Maven CAN run
> disconnected, then the predicate is false. And you appear to be saying that
> it can ...
Once you have all the dependencies maven works even disconnected.
You need all the plugins in your local repository and all the
dependencies (system/test/runtime/compile) in your local repository.
>> I could change the configuration to use local jars [instead]
>> of using repositories
>
> So that would solve the problem?
This would solve the problem of downloading the dependencies, but not
the one of downloading the maven plugin needed.
Btw 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.
>> but maven repositories are really a good thing. IMO they are
>> the solution, not the problem.
>
> A solution to what?
1) To dependency management
2) To avoid to store the same jars everywhere in the work when we could
simply declare we depend on "groupId:artifactId:version".
(You reference to svn copy and waste of resources are really similar to
this scenario)
> I want to run svn up, then be disconnected from the Internet, and still be
> able to work.
This does not work even with other projects if you don't have dependencies.
Hardware, the Operative System, the JDK, Ant, Maven, ant tools, maven
plugins are all dependencies.
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, but I don't understand what
is the solution you are proposing to this.
>> Furthermore I currently use it in server code just to create the
>> website.
>
> 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.
>
> --- Noel
It depends on when you want to disconnect ;-)
If you already have all of the dependencies installed in your local
repository you're safe.
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 is really modular
and the plugins used in a build process are really many!
If you do this then we can get your repository and publish it as "james
repository" so the whole james build could be done using *ONLY* that
repository.
Btw all of this things are not james specific. I think that the maven
list would be more appropriate for this discussion.
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. In fact most of them have been built by me and have no signature
(phoenix itself has been build by me).
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?
Stefano
Re: website updated, maven2 poms, temporary repository, new artifacts
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> If and when the ASF decides to host our own Maven repository wherein we can
> ensure that for all time we have ALL necessary artfifacts to build all
> historical versions, I'll be happy to revisit whether we should maintain the
> artifacts in SVN.
Can we live for a while with a pom.xml that generates our site and
reports using untrusted libraries?
I will take the risk to run the maven tasks so if it will download
something unexpected no one will care about this.
I agree about the security issues raised by Noel but I would like to
avoid requiring from maven things that we never required from ant.
FWIW maven team is already moving in the right direction:
http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements
The proposal seems to be good but unfortunately it seems that someone
have to integrate already existing code and implement missing parts, so
no ETA for this.
Btw I'd like to have a simple roadmap:
1) now we keep the "unsafe" maven stuff to build server website
2) when we'll be ready to move server to maven2 for build and packaging
we will review what directory project did and the status of that new
security features in maven and will decide wether:
3a) create a maven repository for third party dependencies under
james website or under an svn subfolder of the james repository.
3b) use the new features and skip the creation of our repository
3c) use a third-party repository that ASF created in the mean time.
I believe that 2 won't happen before the end of the year so we could
wait and look out from the window in the mean time.
Is this ok?
Stefano
RE: website updated, maven2 poms, temporary repository, new artifacts
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge Knystautas wrote:
> Stefano Bagnara wrote:
> > This does bring to light an important issue. What maven is doing is
> > little beyond what we ask people to do re javamail and activation...
> > download jars that will invariably not be signature checked. Maven
> > just makes it much easier to do this and otherwise remove jar
> > dependencies from svn.
When people download manually, they are responsible to validate the
authenticity of what they download. Fortunately, the majority of people who
naively don't verify their downloads at least tend to download them from the
author's site, not from an insecure, public, repository of dubious content
that has already had faux artifacts posted, although so far not maliciously.
Maven downloads from that repository and does not authenticate the contents,
which is an impedance mismatch between what it does as a tool, and the
necessary self-policing required of such a tool.
But that issue is separable from the other than you raise:
> do we want to keep dependencies in svn or not?
YES. Except for the JVM, yes. They do not change that often that this is a
problem, and we can trust OUR infrastructure. There is a related thread
currently going on the Directory server development list regarding how
relying upon the repository has turned out to be a problem because it is now
not easy to go back and build versions from as recently as a year ago. The
Maven infrastructure is simply not stable, and you cannot rely upon it to
preserve the necessary artifacts indefinitely.
I am OK to exclude derby, although I find it convenient to have the specific
version we use handy, and we've already removed ant. But at least I know
that I will always be able to find all released versions of ASF projects in
http://archive.apache.org/.
If and when the ASF decides to host our own Maven repository wherein we can
ensure that for all time we have ALL necessary artfifacts to build all
historical versions, I'll be happy to revisit whether we should maintain the
artifacts in SVN.
--- Noel
Re: website updated, maven2 poms, temporary repository, new artifacts
Posted by Serge Knystautas <sk...@gmail.com>.
On 7/29/06, Stefano Bagnara <ap...@bago.org> wrote:
> 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, but I don't understand what
> is the solution you are proposing to this.
This does bring to light an important issue. What maven is doing is
little beyond what we ask people to do re javamail and activation...
download jars that will invariably not be signature checked. Maven
just makes it much easier to do this and otherwise remove jar
dependencies from svn.
If there is an issue, I think it's the one Stefano aludes to... do we
want to keep dependencies in svn or not?
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
RE: website updated, maven2 poms, temporary repository, new artifacts
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano,
> As you already noticed the new site is 42MB
Yes. Discussed that in another thread.
> > I continue to refuse to condone the use of Maven repositories until they
fix
> > the security issues.
> I still don't understand the security issues.
The fact that Maven naively downloads things and never verifies them. This
is an unconscionably naive behavior, as they are well aware by now. And,
yes, they are being pushed to fix this.
When it comes to security, I (and most of the rest of infrastructure) tend
to be extremely conservative. And, no, I am not looking forward to Web 2.0,
which I believe will, for quite some time, make MS-Windows look secure in
comparsion. But I digress ...
> You can manually check signatures of downloaded jars as you would do
> with manual downloads.
Few if any ever do. More, but not nearly enough, do when they download
manually, and a percentage close to nil do when the tool automates the
download process.
> > More importantly, if [it] is a correct fact, as you state and Alex also
> > mentioned as a proble, that you need to create a repository for maven to
> > work at all is reason to not use Maven. If maven cannot work
standalone, it
> > should not be used. Please tell me that Maven is not really that stupid
a
> > build system.
> Well, it seems that you're really against maven at all.
Read the above again. What I said is that IF Maven cannot run disconnected,
THEN I am against using it. YES. Absolutely. But if Maven CAN run
disconnected, then the predicate is false. And you appear to be saying that
it can ...
> I could change the configuration to use local jars [instead]
> of using repositories
So that would solve the problem?
> but maven repositories are really a good thing. IMO they are
> the solution, not the problem.
A solution to what?
I want to run svn up, then be disconnected from the Internet, and still be
able to work.
> Furthermore I currently use it in server code just to create the
> website.
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.
--- Noel
Re: website updated, maven2 poms, temporary repository, new artifacts
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> The new website is 42MB against the old 21MB.
>
> That's bad enough, but how are you counting? I see 111MB online. My 18MB,
> reported in an earlier message, was for a local copy of v2.1, so your 21MB
> is just fine with me as a reference value.
As you already noticed the new site is 42MB (in 111MB you're counting
the .svn folders because it is a checkout and not an export).
Furthermore you already found out that we can even remove 13MB of
duplicated javadocs and this will reduce our size around 30MB.
>> I need also to let you know that I added temporarily this repository to
>> our poms
>
> I continue to refuse to condone the use of Maven repositories until they fix
> the security issues. And you might want to participate on
> repository@apache.org to find out what the policies are regarding maven
> repositories at the ASF.
I still don't understand the security issues.
You can manually check signatures of downloaded jars as you would do
with manual downloads.
>> This way jspf, site and server websites can be built with a simple "mvn
>> site", otherwise we should wait an official release and publication of
>> the artifact on ibilio
>
> More importantly, if this is a correct fact, as you state and Alex also
> mentioned as a proble, that you need to create a repository for maven to
> work at all is reason to not use Maven. If maven cannot work standalone, it
> should not be used. Please tell me that Maven is not really that stupid a
> build system.
>
> --- Noel
Well, it seems that you're really against maven at all. As you are a
member of ASF and maven is an ASF project you should talk with ASF in
order to stop the development of that "dungerous" tool and stop
infecting the world :-P
Beside joking I could change the configuration to use local jars
(<scope>system</scope>) instead of using repositories, but maven
repositories are really a good thing. IMO they are the solution, not the
problem.
Furthermore I currently use it in server code just to create the
website. The old website can be still generated with "ant website" so
people doesn't need it. People won't need maven at all to build james
server yet (even if I think this would be a good thing, and not a bad
thing).
I also had some religious issue with maven at the beginning I was using
it, but the more I learn it the more I like it. It has bad things but
overall it is 300% better than ant or any other similar tool I used (ivy).
The latest update of the free "Better Builds With Maven" book is really
interesting and I suggest reading it to any java project developer!
Stefano
RE: website updated, maven2 poms, temporary repository, new artifacts
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The new website is 42MB against the old 21MB.
That's bad enough, but how are you counting? I see 111MB online. My 18MB,
reported in an earlier message, was for a local copy of v2.1, so your 21MB
is just fine with me as a reference value.
> I need also to let you know that I added temporarily this repository to
> our poms
I continue to refuse to condone the use of Maven repositories until they fix
the security issues. And you might want to participate on
repository@apache.org to find out what the policies are regarding maven
repositories at the ASF.
> This way jspf, site and server websites can be built with a simple "mvn
> site", otherwise we should wait an official release and publication of
> the artifact on ibilio
More importantly, if this is a correct fact, as you state and Alex also
mentioned as a proble, that you need to create a repository for maven to
work at all is reason to not use Maven. If maven cannot work standalone, it
should not be used. Please tell me that Maven is not really that stupid a
build system.
--- Noel