You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2002/11/08 03:28:26 UTC
installing jakarta code Was: using commons components and logging
There has got to be a better way for us to handle installs and
cross-dependencies, withing Commons and within Jakarta projects. It has to
be the number one problem that users have.
Hen
On Thu, 7 Nov 2002, Martin Cooper wrote:
> You need the Commons Logging jar, but that's just a wrapper to allow you to
> use Log4J, JDK 1.4 logging, etc. If you have Log4J in your classpath,
> Commons Logging will find that and use it.
>
> --
> Martin Cooper
>
>
> > -----Original Message-----
> > From: Jason Novotny [mailto:novotny@aei.mpg.de]
> > Sent: Thursday, November 07, 2002 5:04 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: using commons components and logging
> >
> >
> >
> > Hi,
> >
> > I wanted to use the FileUpload classes and then I found
> > out I needed
> > beanutils.jar. OK, yet another Jar in my classpath, so far so
> > good. Then
> > however, I get another class not found exeception
> >
> > java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> > at
> > org.apache.commons.beanutils.MethodUtils.(MethodUtils.java:91)
> >
> > since it needs the logging component. My code already uses
> > Log4J which
> > I've been pretty happy with-- isn't there some properties
> > file I can set
> > to use log4j or setting a method call-- or do I really need
> > yet another
> > logging library?
> >
> > Thanks, Jason
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: installing jakarta code Was: using commons components and logging
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 8 Nov 2002, Steven Caswell wrote:
>
> > -----Original Message-----
> > From: Henri Yandell [mailto:bayard@generationjava.com]
> >
> > So you suggest that we no longer create zips/tar.gz's and
> > just put jars on a Maven repository and tell everyone that to
> > use a library they must build with Maven?
>
> Maven will generate the zips/tar.gz's, so others can still download the
> full distribution. Having [lang] mavenized would not force other
> projects to mavenize just to use the [lang] library.
That's the rub. Full distribution. I want something downloads the
dependencies as well, not just the lang distro but also anything that lang
is dependent on.
Maybe this means a better page than the current download page where users
just click from a list, something where you select something to download
and after you click on that it takes you to a page which lists the
dependencies and says 'do you have all of these?'.
> > What I'm looking for are ideas that will work with the
> > existing structure and not revolutions :) So, how can we
> > re-package our current code so that user's don't plough
> > every-time into the dependency hunt.
> >
>
> I believe Maven provides a great solution to this issue. The site that
> Maven generates does contain a list of a project release's dependencies
> (not that [lang] has any, but this is a nice standard place for a
> project to publish it's dependency list). Personally I'd love to see all
> of commons migrate toward Maven, for this very reason. It provides
> standard documentation and a standard way to build projects.
It still is far away in this respect though. The site has no standardised
download ability. [I'd love to add such a thing, and hope that a thread
like this could decide what that standardised downloading is.]
> And for a project like [lang], Maven is not all that revolutionary. I
> Mavenized a similar commons-type project at my work with very little
> effort. And the bang for the buck was incredible.
Agreed. Lang is mavenised, I use maven at work now accross the board.
Gotta learn reactor though still.
However, Maven isn't really the solution here. We have to assume that our
users are not using Maven. Thus we need to offer a download/install
process which handles the dependency issue without forcing them to enter
the maven-user world.
The fact that thigns like Collections are not wanting to be dependent on
another project [ie Lang] because it confuses the user is a sign that
somethign is very wrong.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: installing jakarta code Was: using commons components and logging
Posted by Steven Caswell <st...@caswell.name>.
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Friday, November 08, 2002 3:55 PM
> To: Jakarta Commons Developers List
> Subject: Re: installing jakarta code Was: using commons
> components and logging
>
>
>
> So you suggest that we no longer create zips/tar.gz's and
> just put jars on a Maven repository and tell everyone that to
> use a library they must build with Maven?
Maven will generate the zips/tar.gz's, so others can still download the
full distribution. Having [lang] mavenized would not force other
projects to mavenize just to use the [lang] library.
>
> I think Maven could help with this, or a similar tool, but in
> a different way. When the tool creates our distribution, it
> also creates an ant file which contains the dependencies that
> are needed and can be run.
>
> ant -f get_dependencies.xml
>
> this sucks each dependency down [no project.xml remember,
> it's just a part of the tar.gz] and puts them in a directory
> called 'dependencies' or 'lib' or something.
>
> It can happily use the maven biblio, though that implies that
> a much faster build -> maven repo turn around is needed.
>
> What I'm looking for are ideas that will work with the
> existing structure and not revolutions :) So, how can we
> re-package our current code so that user's don't plough
> every-time into the dependency hunt.
>
I believe Maven provides a great solution to this issue. The site that
Maven generates does contain a list of a project release's dependencies
(not that [lang] has any, but this is a nice standard place for a
project to publish it's dependency list). Personally I'd love to see all
of commons migrate toward Maven, for this very reason. It provides
standard documentation and a standard way to build projects.
And for a project like [lang], Maven is not all that revolutionary. I
Mavenized a similar commons-type project at my work with very little
effort. And the bang for the buck was incredible.
>
> Hen
>
> On Sat, 9 Nov 2002 dion@multitask.com.au wrote:
>
> > Henri Yandell <ba...@generationjava.com> wrote on
> 08/11/2002 01:28:26
> > PM:
> >
> > >
> > > There has got to be a better way for us to handle installs and
> > > cross-dependencies, withing Commons and within Jakarta
> projects. It
> > > has
> > to
> > > be the number one problem that users have.
> >
> > Hence the development of Maven.
> >
> > >
> > > Hen
> > --
> > dIon Gillard, Multitask Consulting
> > Work: http://www.multitask.com.au
> > Developers: http://adslgateway.multitask.com.au/developers
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> additional commands,
> e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: installing jakarta code Was: using commons components and logging
Posted by Henri Yandell <ba...@generationjava.com>.
So you suggest that we no longer create zips/tar.gz's and just put jars on
a Maven repository and tell everyone that to use a library they must build
with Maven?
I think Maven could help with this, or a similar tool, but in a different
way. When the tool creates our distribution, it also creates an ant file
which contains the dependencies that are needed and can be run.
ant -f get_dependencies.xml
this sucks each dependency down [no project.xml remember, it's just a part
of the tar.gz] and puts them in a directory called 'dependencies' or 'lib'
or something.
It can happily use the maven biblio, though that implies that a much
faster build -> maven repo turn around is needed.
What I'm looking for are ideas that will work with the existing structure
and not revolutions :) So, how can we re-package our current code so that
user's don't plough every-time into the dependency hunt.
Hen
On Sat, 9 Nov 2002 dion@multitask.com.au wrote:
> Henri Yandell <ba...@generationjava.com> wrote on 08/11/2002 01:28:26 PM:
>
> >
> > There has got to be a better way for us to handle installs and
> > cross-dependencies, withing Commons and within Jakarta projects. It has
> to
> > be the number one problem that users have.
>
> Hence the development of Maven.
>
> >
> > Hen
> --
> dIon Gillard, Multitask Consulting
> Work: http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: installing jakarta code Was: using commons components and logging
Posted by di...@multitask.com.au.
Henri Yandell <ba...@generationjava.com> wrote on 08/11/2002 01:28:26 PM:
>
> There has got to be a better way for us to handle installs and
> cross-dependencies, withing Commons and within Jakarta projects. It has
to
> be the number one problem that users have.
Hence the development of Maven.
>
> Hen
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>