RE: installing jakarta code Was: using commons components and logging

[Steven Caswell]

> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com] 
> Sent: Friday, November 08, 2002 5:04 PM
> To: Steven Caswell
> Cc: 'Henri Yandell'
> Subject: RE: installing jakarta code Was: using commons 
> components and logging
> 
> 
> 
> 
> On Fri, 8 Nov 2002, Steven Caswell wrote:
> 
> > Confused the user how?
> >
> > I guess I don't understand how using a library like lang can cause 
> > heartburn for a project like Collections. I've never had a problem 
> > adding another jar to the classpath. Seems to me that the "user" 
> > (which, we should keep in mind, are supposedly intelligent 
> developers) 
> > should easily understand an additional dependency. As long as it is 
> > documented in a clear manner.
> 
> Maybe that's the nub. Without really sitting down with users 
> to find out why they didn't install XXX library, it's hard to 
> tell. But I can quite happily goto the Jakarta front page, 
> click on a news item or click on Binary Releases, and 
> download the zip without realising.

That is a good point. I've had on blinders thinking more along
the lines of the initial installation of a project, but your point
About getting a later release is well taken. Unless I explicitly look
at the docs, I may miss an important dependency. And today Maven
doesn't really help this situation.

> 
> Especially as I expect to have an INSTALL.txt or README.txt 
> [or html] which tells me what I need. We tend to put it on 
> the website, which a lot of people probably don't bother to check.
> 
> So, maybe Maven could be generating out an INSTALL.txt as 
> part of its build or some such. Or maybe the current download 
> method of using the default Apache directory is wrong, we 
> need a lot of index.html's throughout the build/ directory.

Could get real messy.

> 
> Or we have an xml file in the releases directory called 
> requires.xml which an Apache module reads, shows a custom 
> Apache directory-page to remind people where to go to get the 
> requirements.
> 
> I like that idea, it's not java, but neither is Jakarta's 
> site. What do you think? [Maven can still generate this xml 
> file out as part of the build]
> 

I think this would be a reasonable short-term solution. I'd really
Like to see things move toward a neutral (i.e.,
project-comprehension-tool-agnostic)
xml description of dependencies that could be used by Maven or whatever
to
Figure out what else needs to be gotten and go get it.

> Hen
> 
> 



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

RE: installing jakarta code Was: using commons components and logging

[Henri Yandell]

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:   
For additional commands, e-mail: 

RE: installing jakarta code Was: using commons components and logging

[Steven Caswell]

> -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 [EMAIL PROTECTED] wrote:
> 
> > Henri Yandell <[EMAIL PROTECTED]> 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-> [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > <mailto:commons-dev-help@;jakarta.apache.org>
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
> 
> 

Steven Caswell
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

Re: installing jakarta code Was: using commons components and logging

[Henri Yandell]

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 [EMAIL PROTECTED] wrote:

> Henri Yandell <[EMAIL PROTECTED]> 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:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: installing jakarta code Was: using commons components and logging

[dion]

Henri Yandell <[EMAIL PROTECTED]> 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:   
For additional commands, e-mail: