Re: Code conventions

[Ceki Gulcu]

Ted,

The reason I brought up the issue on the PMC list rather than on
general was to see if there was consensus on the subject in a smaller
group. There seems to be no such consensus. Consequently, it does not
make sense to submit the proposal to the jakarta community.

This has been a good lesson which I am not about to renew. Have a nice 
day, Ceki

At 17:33 01.01.2002 -0500, you wrote:
>Ceki Gulcu wrote:
>> Peter I do not need your permission to bring up a subject on the PMC
>> list. It was uncourteous of you to forward my message to the general
>> list without permission. If you had read my proposal carefully you
>> would have seen that my proposal was to reach agreement on the PMC
>> list first and than consult with the wider jakarta community.
>
>Peter has a point, in that we're only suppose to use the PMC list for
>security or other sensitive issues, much the way the Committer list is
>used. Anything else should be handled on General. I didn't bring it up
>myself, since I was hoping it would just go away. Discussing coding
>conventions just creates a lot of traffic, and never accomplishes very
>much. 
>
>AFAIK, a formal change to the guidelines like this will require a 3/4
>vote of the PMC, and it would seem unlikely that a proposal like this
>would receive the requisite number of votes. Personally, I'm happy with
>the guideline we already have
>
>http://jakarta.apache.org/site/source.html
>
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Building Java web applications with Struts.
>-- Tel +1 585 737-3463.
>-- Web http://www.husted.com/struts/
>
>
>
> Original Message 
>Subject: Code conventions
>Date: Tue, 01 Jan 2002 02:18:18 +0100
>From: Ceki Gülcü <[EMAIL PROTECTED]>
>Reply-To: "Jakarta Project Management Committee List"
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>
>
>Hello all,
>
>As a follow up to the indentation discussion on the members list, I
>would like to propose the following text to popular (=committer) vote.
>
>Please indicate if you agree with the procedure of PMC draft followed
>by popular vote. Although the PMC may have the mandate to impose
>indentation
>rules, I feel it is wiser to consult the wider committer population.
>
>Here is my first draft of the text to be submitted to popular vote.
>
>==
>
>In order to enforce cohesion across Jakarta projects as well as the
>jakarta brand, the jakarta PMC would like to submit the following two
>articles to popular vote.
>
>Article 1)
>
>   All Java Language source code in the repository must be written in
>conformance to the "Code Conventions for the Java Programming
>Language" (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html)
>as
>published by Sun.
>
>Article 2)
>
>   Recognizing that migrating large amounts of code is no trivial
>matter, a transition period of 6 months, starting after the adoption
>of Article 1, is hereby granted to every subproject. After the
>transition period every project is expected to fully adhere to the
>code conventions adopted in Article 1.
>
>The above articles will be adopted if and only if at least two thirds
>of expressed votes are cast in favor. 
>
>Note that article 1 implies K&R style indentation of braces.
>
>
>
>Regards, Ceki
>
>ps. Best wishes for the new year.
>
>--
>
>Ceki Gülcü - http://qos.ch
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 


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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 9:56 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:

> 
> 
> On Tue, 1 Jan 2002, Ted Husted wrote:
> 
>> Date: Tue, 01 Jan 2002 14:54:30 -0500
>> From: Ted Husted <[EMAIL PROTECTED]>
>> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
>> To: Jakarta General List <[EMAIL PROTECTED]>
>> Subject: Re: Just the JARs
>> 
>> "Geir Magnusson Jr." wrote:
>>> Putting aside *all* the stuff we are talking about for a moement, and
>>> looking at the simple notion of just having release jars available w/o docs,
>>> source, etc I don't think this is a bad idea :)
>>> 
>>> However
>>> 
>>> Any license issues?  Wouldn't we want to package the jar w/ a license ?
>> 
>> This simple notion -- and my putting together a Jakarta release HOWTO --
>> is why I opened this particular thread.
>> 
>> The license issue is well taken. I think it would be a good practice for
>> us to include a license in all of our JARs. Even when we don't
>> distribute them seperately ourselves, they are intended to be
>> distributed seperately by our licensees. Point noted.
>> 
> 
> How about including a copy of the "LICENSE" file in the META-INF
> subdirectory of each JAR file produced by an Apache project?
> 

If that is sufficient from the perspective of licensing, then that's simple
enough...  We'll do that for vel's next release

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Now what do we do?"


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

Re: Just the JARs

[Craig R. McClanahan]

On Tue, 1 Jan 2002, Ted Husted wrote:

> Date: Tue, 01 Jan 2002 14:54:30 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: Re: Just the JARs
>
> "Geir Magnusson Jr." wrote:
> > Putting aside *all* the stuff we are talking about for a moement, and
> > looking at the simple notion of just having release jars available w/o docs,
> > source, etc I don't think this is a bad idea :)
> >
> > However
> >
> > Any license issues?  Wouldn't we want to package the jar w/ a license ?
>
> This simple notion -- and my putting together a Jakarta release HOWTO --
> is why I opened this particular thread.
>
> The license issue is well taken. I think it would be a good practice for
> us to include a license in all of our JARs. Even when we don't
> distribute them seperately ourselves, they are intended to be
> distributed seperately by our licensees. Point noted.
>

How about including a copy of the "LICENSE" file in the META-INF
subdirectory of each JAR file produced by an Apache project?

> -Ted.

Craig


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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 8:43 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Geir Magnusson Jr. wrote:
>> 
>> However, I will continue the riff that released versions are important and
>> different.
> 
> Just curious, why does the December 9th release of jakarta-velocity contain
> a milestone version of commons-collections.jar dated May 11th, when there
> was a release of commons-collections dated July 14?

Because I made a mistake in not updating the collections jar for that
release.  Thanks for pointing that out. It will be corrected.

> 
> I'll leave it to others to decide whether this is important, or merely
> different.

I'll be the first to say that it's important to me (as I can't speak for
others), and will be corrected ASAP.

> 
> Meanwhile, if there are any byproducts of the things I build from public
> cvs that other find useful, I will endeavor to support their requests.
> 

Why does it appear that it is not wanted?  I'm confused...  I was just
pointing out that keeping the distinction between 'released' and 'gump' is
important. Both are useful, and in Vincent's case, they seem to be
equivalent, but not in all cases here in Jakarta.


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable


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

Re: Just the JARs

[Sam Ruby]

Geir Magnusson Jr. wrote:
>
> However, I will continue the riff that released versions are important and different.

Just curious, why does the December 9th release of jakarta-velocity contain
a milestone version of commons-collections.jar dated May 11th, when there
was a release of commons-collections dated July 14?

I'll leave it to others to decide whether this is important, or merely
different.

Meanwhile, if there are any byproducts of the things I build from public
cvs that other find useful, I will endeavor to support their requests.

- Sam Ruby


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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 7:12 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> AFAIK, all the Jakarta sub-projects try to ensure (but cannot guarantee)
> that the nightly builds remain usuable. The idea being you build and
> test it on your own machine before committing it to the CVS. Of course,
> since we are human and our tests are imperfect, the nigthly builds
> sometimes break. But I believe that is the exception rather than the
> rule, especially for products that already have a release under their
> belt. I believe we all hope and expect that a good number of people will
> be putting the nightly builds to use, so we know if what we are
> developing is working for everyone else.

Error isn't the only issue - I think that the projects have the right to do
whatever they want with their CVS HEAD.  Gump tells them that they are
straying from previous API commitments if that's the case, or functionality
changes or whatever...  The nightly (for many, anyway) is just a convenience
for those that are unable to get the CVS tree (because of corporate firewall
policy) or don't want to (for whatever reason).

> 
> My only point is that some products are developing against another
> product's nightly build, and to build product A you need the JAR from
> product B's nightly build.

Yep - that's a good thing - I am long overdue for committing my JJAR
changes, and would be happy to add CVS HEAD as a version choice when
available, to be supplied by gump.  That's a great thing.  However, I will
continue the riff that released versions are important and different.
 
> So, in addition of providing JARs alongside the formal releases, I would
> say it's a good idea to provide nightly JARs alongside the nightly
> builds, so long as it is not difficult to make this part of the
> automatic process.

Yep - it shouldn't be hard with JJAR if Sam puts things in the same place
all the time - after all, it's always going to be the same version...
 
> -Ted.
> 
> 
> Vincent Massol wrote:
>> I would say it depends on the project and the meaning you give to the
>> word "release". For the Cactus project, a nightly build produces exactly
>> the same files as a "release" and can be used with a great deal of
>> confidence.  The only difference with a release is that a release has a
>> goal, i.e. we have voluntarily decided that when such and such features
>> are put in, then it would warrant a release.
>> 
>> I like to use GUMP for 2 purposes :
>> * Early detection of contentions with dependent projects,
>> * Automated builds/integration, leading to a daily "release" (in the
>> agile way). Users are encouraged to use the nightly builds and not wait
>> for releases.
>> 
>> It may be different for other projects though but I tend to like this
>> philosophy ... :-)
>> 
>> [snip]
>> 
>> -Vincent
>> 
>> --
>> To unsubscribe, e-mail:   
>> For additional commands, e-mail: 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



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

Re: Just the JARs

[Ted Husted]

AFAIK, all the Jakarta sub-projects try to ensure (but cannot guarantee)
that the nightly builds remain usuable. The idea being you build and
test it on your own machine before committing it to the CVS. Of course,
since we are human and our tests are imperfect, the nigthly builds
sometimes break. But I believe that is the exception rather than the
rule, especially for products that already have a release under their
belt. I believe we all hope and expect that a good number of people will
be putting the nightly builds to use, so we know if what we are
developing is working for everyone else. 

My only point is that some products are developing against another
product's nightly build, and to build product A you need the JAR from
product B's nightly build. 

So, in addition of providing JARs alongside the formal releases, I would
say it's a good idea to provide nightly JARs alongside the nightly
builds, so long as it is not difficult to make this part of the
automatic process.

-Ted.


Vincent Massol wrote:
> I would say it depends on the project and the meaning you give to the
> word "release". For the Cactus project, a nightly build produces exactly
> the same files as a "release" and can be used with a great deal of
> confidence.  The only difference with a release is that a release has a
> goal, i.e. we have voluntarily decided that when such and such features
> are put in, then it would warrant a release.
> 
> I like to use GUMP for 2 purposes :
> * Early detection of contentions with dependent projects,
> * Automated builds/integration, leading to a daily "release" (in the
> agile way). Users are encouraged to use the nightly builds and not wait
> for releases.
> 
> It may be different for other projects though but I tend to like this
> philosophy ... :-)
> 
> [snip]
> 
> -Vincent
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

RE: Just the JARs

[Vincent Massol]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 23:19
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> On 1/1/02 6:04 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> 
> > Geir Magnusson Jr. wrote:


[snip]

> > Many of the nightly builds for various subprojects are published
based
> on
> > what gump produces in the manner desired by the communities for
these
> > subprojects.  Many of these include in bundled form the jars
referenced
> by
> > the build.
> >
> 
> But a nightly build isn't a release, right?  Wasn't this discussion
> motivated by Ted looking into getting projects to offer release build
jars
> alone w/o the whole source/docs distro to make for convenient
downlaod?
> 

I would say it depends on the project and the meaning you give to the
word "release". For the Cactus project, a nightly build produces exactly
the same files as a "release" and can be used with a great deal of
confidence.  The only difference with a release is that a release has a
goal, i.e. we have voluntarily decided that when such and such features
are put in, then it would warrant a release.

I like to use GUMP for 2 purposes :
* Early detection of contentions with dependent projects,
* Automated builds/integration, leading to a daily "release" (in the
agile way). Users are encouraged to use the nightly builds and not wait
for releases.

It may be different for other projects though but I tend to like this
philosophy ... :-)

[snip]

-Vincent



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

Re: Just the JARs

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Ted Husted writes:
>The license issue is well taken. I think it would be a good practice for
>us to include a license in all of our JARs. Even when we don't
>distribute them seperately ourselves, they are intended to be
>distributed seperately by our licensees. Point noted.

+1





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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 6:04 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Geir Magnusson Jr. wrote:
>> 
>>> My rationale was that the goal of GUMP as I understand it now, is to
>>> ensure that all projects play well with each other in term of
>>> compatibility. It seems natural to extend it so that it can also be
>>> asked to retrieve all dependent jars for a given project.
>> 
>> Not to me.  Gump to me is an early warning tool to ensure API stability
>> across dependent projects, and must, by definition, always work on the
>> current bleeding edge of all projects.  It must do this because once you
>> test a set of released versions, nothing changes :)
>> 
>> So gump doesn't even have the dependent jars for the released versions - it
>> uses more bleeding edge jars it makes itself to satisfy the dependencies.
> 
> Gump can and does use jars checked into cvs:
> 
>  http://jakarta.apache.org/builds/gump/latest/cvsjars.html

Ok - these seem to be jars you can't or don¹t want to build yourself?

> 
> Gump can and does use jars installed on the machine:
> 
>  http://jakarta.apache.org/builds/gump/latest/packages.html
> 

Which appear to be things you can't build either.

I don't understand what you are trying to say here.

> Many of the nightly builds for various subprojects are published based on
> what gump produces in the manner desired by the communities for these
> subprojects.  Many of these include in bundled form the jars referenced by
> the build.
> 

But a nightly build isn't a release, right?  Wasn't this discussion
motivated by Ted looking into getting projects to offer release build jars
alone w/o the whole source/docs distro to make for convenient downlaod?

> For more information on what the goal of Gump is (or more precisely, why it
> was written), please see
> 
>  http://jakarta.apache.org/gump/why.html

That's good.  Here's your summary :

* It is easier to get a patch accepted against the most current version of a
project than some previous baseline.
* It is much more effective to express your opinion on a change that will
affect you before that change is released than afterwards.

So since this is indeed the goal of gump ( actually, I think they are
reasons rather than a goal...) then I think that my understanding relative
to this discussion is correct, isn't it?


> 
> - Sam Ruby
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin



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

Re: Just the JARs

[Sam Ruby]

Geir Magnusson Jr. wrote:
>
>> My rationale was that the goal of GUMP as I understand it now, is to
>> ensure that all projects play well with each other in term of
>> compatibility. It seems natural to extend it so that it can also be
>> asked to retrieve all dependent jars for a given project.
>
> Not to me.  Gump to me is an early warning tool to ensure API stability
> across dependent projects, and must, by definition, always work on the
> current bleeding edge of all projects.  It must do this because once you
> test a set of released versions, nothing changes :)
>
> So gump doesn't even have the dependent jars for the released versions - it
> uses more bleeding edge jars it makes itself to satisfy the dependencies.

Gump can and does use jars checked into cvs:

   http://jakarta.apache.org/builds/gump/latest/cvsjars.html

Gump can and does use jars installed on the machine:

   http://jakarta.apache.org/builds/gump/latest/packages.html

Many of the nightly builds for various subprojects are published based on
what gump produces in the manner desired by the communities for these
subprojects.  Many of these include in bundled form the jars referenced by
the build.

For more information on what the goal of Gump is (or more precisely, why it
was written), please see

   http://jakarta.apache.org/gump/why.html

- Sam Ruby


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

Re: Code conventions

[Ted Husted]

Ceki Gulcu wrote:
> Peter I do not need your permission to bring up a subject on the PMC
> list. It was uncourteous of you to forward my message to the general
> list without permission. If you had read my proposal carefully you
> would have seen that my proposal was to reach agreement on the PMC
> list first and than consult with the wider jakarta community.

Peter has a point, in that we're only suppose to use the PMC list for
security or other sensitive issues, much the way the Committer list is
used. Anything else should be handled on General. I didn't bring it up
myself, since I was hoping it would just go away. Discussing coding
conventions just creates a lot of traffic, and never accomplishes very
much. 

AFAIK, a formal change to the guidelines like this will require a 3/4
vote of the PMC, and it would seem unlikely that a proposal like this
would receive the requisite number of votes. Personally, I'm happy with
the guideline we already have

http://jakarta.apache.org/site/source.html


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/



 Original Message 
Subject: Code conventions
Date: Tue, 01 Jan 2002 02:18:18 +0100
From: Ceki Gülcü <[EMAIL PROTECTED]>
Reply-To: "Jakarta Project Management Committee List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]


Hello all,

As a follow up to the indentation discussion on the members list, I
would like to propose the following text to popular (=committer) vote.

Please indicate if you agree with the procedure of PMC draft followed
by popular vote. Although the PMC may have the mandate to impose
indentation
rules, I feel it is wiser to consult the wider committer population.

Here is my first draft of the text to be submitted to popular vote.

==

In order to enforce cohesion across Jakarta projects as well as the
jakarta brand, the jakarta PMC would like to submit the following two
articles to popular vote.

Article 1)

   All Java Language source code in the repository must be written in
conformance to the "Code Conventions for the Java Programming
Language" (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html)
as
published by Sun.

Article 2)

   Recognizing that migrating large amounts of code is no trivial
matter, a transition period of 6 months, starting after the adoption
of Article 1, is hereby granted to every subproject. After the
transition period every project is expected to fully adhere to the
code conventions adopted in Article 1.

The above articles will be adopted if and only if at least two thirds
of expressed votes are cast in favor. 

Note that article 1 implies K&R style indentation of braces.



Regards, Ceki

ps. Best wishes for the new year.

--

Ceki Gülcü - http://qos.ch

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

Re: Code conventions

[Ceki Gulcu]

At 07:39 02.01.2002 +1100, Peter Donald wrote:
>Hi,
>
>This is not something that should have been brought up on the PMC list - it 
>should be discussed on general.

Peter I do not need your permission to bring up a subject on the PMC
list. It was uncourteous of you to forward my message to the general
list without permission. If you had read my proposal carefully you
would have seen that my proposal was to reach agreement on the PMC
list first and than consult with the wider jakarta community.

>On Tue, 1 Jan 2002 20:28, Ceki Gülcü wrote:
>> Conventions are a matter of taste and habit.
>
>Some are and some are designed to force programmers to implement things in 
>particular ways and indirectly force good programming habits.
>
>> Each subproject can
>> indeed adopt and publish a convention of its own. However, most
>> projects with the exception of Turbine and Velocity did not publish
>> conventions. (Please correct me if I am wrong.)
>
>Avalon has one ... based on an earlier version of Turbines.
>
>> I am not suggesting that we jettison the code and fire the committers,
>> that would be pointy-haired.
>
>no but you are suggesting that the people who actually do the work no longer 
>get to have a say in how they write code. Thats not pointy-haired at all!
>
>As soon as I see my first jakarta paycheck I will happily change over.

You are saying the individual first collectivity second. How about 
collectivity first and the individual second?

>If it was a legitimate concern then maybe we could do something about 
>it. About the only thing I can think of that we would want to change is 
>when people use conventions like
>
>a_class_name anObject = ...;
>anObject.do_something();
>
>And that is mainly due to the fact that it effects people outside the project 
>aswell. 
>
>However I don't think any of the jakarta projects use those conventions and I 
>am not going to be the one to force anyone to change if they do.

Again, my proposal required al least two thirds majority of jakarta
committers in order for the conventions to be adopted.  You nor I
alone, do we represent a two thirds majority.  However, a two thirds
majority represents the will of the community. If that is contested as
seems to be the case here, then the only remaining possibility is that
there is no community but a loose gathering of unruly individuals.

Regards, Ceki



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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 3:05 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:

> 
> 
>> -Original Message-
>> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>> Sent: 01 January 2002 19:24
>> To: Jakarta General List
>> Subject: Re: Just the JARs
>> 
>> On 1/1/02 12:57 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
>> 
>>> What would be nice would be to have a JJAR/CJAN project coupled with
>>> GUMP. This application would have both an Ant task (for developers)
> to
>>> retrieve versions of dependent jars (latest or specified version or
>>> date) and a GUI/Applet in the download area so that end user could
> use
>>> it to download dependent jars. What is needed is :
>>> 1/ a repository for the jars where GUMP would copy nightly builds
> and
>>> where releases would be put
>>> 2/ dependency information (what Jason is building or what the
> Commons
>>> JJAR project has) so that dependent jars can be easily downloaded
>>> 
>>> I think it might be a good idea for JJAR/CJAN to be a subproject of
>>> Alexandria.
>> 
>> I disagree.
>> 
> 
> You have the right ... ;-) But why ?

I don't even know what alexandria is, so I wouldn't advocate putting any
code in there.

I know what Gump is, but that's a proposal in alexandria, and different in
nature than JJAR.  JJAR is more akin to ant than Gump in my view.
 
> My rationale was that the goal of GUMP as I understand it now, is to
> ensure that all projects play well with each other in term of
> compatibility. It seems natural to extend it so that it can also be
> asked to retrieve all dependent jars for a given project.

Not to me.  Gump to me is an early warning tool to ensure API stability
across dependent projects, and must, by definition, always work on the
current bleeding edge of all projects.  It must do this because once you
test a set of released versions, nothing changes :)

So gump doesn't even have the dependent jars for the released versions - it
uses more bleeding edge jars it makes itself to satisfy the dependencies.
 
> -Vincent
> 
> P.S.: I said Alexandria instead of GUMP in my previous post but I'm not
> cleat on the relations between these 2 in the future ... :-)

Well, maybe Gump becomes a top level project dedicated to aspects of
development like API contracts and such (I would love to see functional
contract testing as well :)

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin



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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 3:08 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:

> 
> 
>> -Original Message-
>> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>> Sent: 01 January 2002 19:26
>> To: Jakarta General List
>> Subject: Re: Just the JARs
>> 
>>
>> 
>> You don't want to use the results of Gump for JJAR.  Gump isn't
> bulding
>> releases - it's building CVS-tree-du-jour...  There is no reason to
>> believe
>> anything built by Gump works.
>> 
>> I hope I'm just confused on what you are advocating.
>> 
> 
> For me, GUMP is doing much more than building the CVS-tree-du-jour,
> whatever this means. It is building "releases" every day of all projects
> and produces project outputs.
> 

But is that what it does?  I don't think so.  As I understand it, it takes
the CVS HEAD from each project and builds - the purpose being to be an early
warning system to detect when API's change through alteration of interfaces
or classes.

CVS HEAD is generally not considered the current release of a given project,
but the ongoing development efforts of the project.

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert


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

Re: Just the JARs

[Ted Husted]

"Geir Magnusson Jr." wrote:
> So it wouldn't be right to base JJAR fetches of those jars - except when you
> specify the non-released latest. (JJAR lets you choose which version of a
> jar you want...)

And some of the things I've been trying to build lately wanted the
non-released latest. 

I would say that, if Sam wants to set it up, that GUMP could break out
the JARs for a nighly build, and post them alongside the ZIPs and TARs
in the folders that we already have.

Meanwhile, when we make future releases, we might want to post the
product's JAR alongside the ZIPS and/or TARs, so that there will be
something for JJAR or whatever to fetch. Even without a gizmo, being
able to download the JARs seperately, just by hyperlink, is becoming
more and more important as the products start making better use of each
other. 

Vincent and I are working on a very simple package, which with unit
tests, ending needing eight Jakarta JARs. So to assemble everything, a
user has to download about 20mb instead of like 800kb. A gizmo would be
nice, but I'll happily settle for not having to delete 80% of what I'm
downloading.

I'm *not* trying to launch CJAN or JJAR here, but just confirm that
distributing naked JARs is acceptable, and that we should encourage
Jakarta products to do this as a standard practice.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

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

Re: Code conventions

[Peter Donald]

Hi,

This is not something that should have been brought up on the PMC list - it 
should be discussed on general.

On Tue, 1 Jan 2002 20:28, Ceki Gülcü wrote:
> Conventions are a matter of taste and habit.

Some are and some are designed to force programmers to implement things in 
particular ways and indirectly force good programming habits.

> Each subproject can
> indeed adopt and publish a convention of its own. However, most
> projects with the exception of Turbine and Velocity did not publish
> conventions. (Please correct me if I am wrong.)

Avalon has one ... based on an earlier version of Turbines.

> I am not suggesting that we jettison the code and fire the committers,
> that would be pointy-haired.

no but you are suggesting that the people who actually do the work no longer 
get to have a say in how they write code. Thats not pointy-haired at all!

As soon as I see my first jakarta paycheck I will happily change over.

If it was a legitimate concern then maybe we could do something about 
it. About the only thing I can think of that we would want to change is 
when people use conventions like

a_class_name anObject = ...;
anObject.do_something();

And that is mainly due to the fact that it effects people outside the project 
aswell. 

However I don't think any of the jakarta projects use those conventions and I 
am not going to be the one to force anyone to change if they do.

-- 
Cheers,

Pete

--
Kitsch never goes out of style
--

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

RE: Just the JARs

[Vincent Massol]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 19:26
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> On 1/1/02 2:00 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
> 
> >
> >
> >> -Original Message-
> >> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> >> Sent: 01 January 2002 18:39
> >> To: Jakarta General List
> >> Subject: Re: Just the JARs
> >>
> >> I think Lucene is already doing something very similar. Except that
> > the
> >> JARs are just put in with the other builds. Perhaps we can just
> >> recommend that everyone follow suit.
> >>
> >> http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/
> >>
> >> http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/
> >>
> >
> > I'm not sure what you mean. I've had a look and the dependent jars
are
> > _not_ put with the gump build (or the release build). The only jar
there
> > is is the junit one but if you look at the GUMP definition of Lucene
> >
(http://jakarta.apache.org/builds/gump/latest/module_jakarta-lucene.html
> > ) you'll find that it depends on xerces, ant and javacc, which are
not
> > included.
> >
> >
> >> People could then just provide hyperlinks to the appropriate build
> >> directories (say in a build.html file next to the build.xml), and
let
> >> people choose what they want to download.
> >>
> >
> > I agree that it would be nice if the GUMP results were put somewhere
> > publicly accessible (they may be but I have no idea where). However,
the
> > second step is to automatically fetch the correct dependent jars
(and
> > possibly in a validated working state, proved by unit testing of
each
> > project).
> >
> 
> You don't want to use the results of Gump for JJAR.  Gump isn't
bulding
> releases - it's building CVS-tree-du-jour...  There is no reason to
> believe
> anything built by Gump works.
> 
> I hope I'm just confused on what you are advocating.
> 

For me, GUMP is doing much more than building the CVS-tree-du-jour,
whatever this means. It is building "releases" every day of all projects
and produces project outputs.

-Vincent

> 
> >> A front-end application that made all of our products more
accessible
> >> would also be a Good Thing, and something I would like to do some
> > time.
> >> But if were to publish some recommendations now, and lead by
example,
> > I
> >> think things could get much easier for us all without much effort.
> >>
> >
> > yep, but also an Ant task (like the one in JJAR) for project
developers.
> >
> >> I'm not suggesting we all run around and post JARs for the old
> > releases,
> >> but as new releases are issued, we might want to follow Lucene's
> > example
> >> (among others).
> >>
> >
> > I guess this is currently done for most projects, isn't it (I mean
that
> > GUMP nightly builds are put in http://jakarta.apache.org/builds/) ?
What
> > I have done in Cactus, but I'm not sure it is the right way is to
> > package an Ant distribution containing all the needed
tasks/dependent
> > jars to build the Cactus project / run Cactus tests in a project,
using
> > Ant. We also package the dependent jars in the release and nightly
> > builds.
> >
> > -Vincent
> >
> >> -Ted.
> >>
> >>
> >>
> >> Vincent Massol wrote:
> >>>
> >>> What would be nice would be to have a JJAR/CJAN project coupled
with
> >>> GUMP. This application would have both an Ant task (for
developers)
> > to
> >>> retrieve versions of dependent jars (latest or specified version
or
> >>> date) and a GUI/Applet in the download area so that end user could
> > use
> >>> it to download dependent jars. What is needed is :
> >>> 1/ a repository for the jars where GUMP would copy nightly builds
> > and
> >>> where releases would be put
> >>> 2/ dependency information (what Jason is building or what the
> > Commons
> >>> JJAR project has) so that dependent jars can be easily downloaded
> >>>
> >>> I think it might be a good idea for JJAR/CJAN to be a subproject
of
> >>> Alexandria.
> >>>
> >>> -Vincent
> >>>
>  -Original Message-
>  From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
>  Sent: 01 January 2002 15:52
>  To: Jakarta General List
>  Subject: Re: Just the JARs
> 
>  On 1/1/02 10:39 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> 
> > Does anyone have a page regarding how to make a Jakarta release?
> > I'd
> > like to put one together and post it with the other guideline
> >>> materials.
> 
>  I tried to make a dist target for helping with a release. The
> > target
> >>> makes
>  source and binary distributions and can be found in the BCEL,
> > XmlRpc
> >>> and
>  Fulcrum. I was going to add this target to the build file that
> > Berin
>  offered
>  the Alexandria project.
> 
>  With dependency information I've been adding to the gump
> > descriptors
> >>> it
>  would be possible to combine a standard target for building
> > release
>  bundles
>  with that dependency

RE: Just the JARs

[Vincent Massol]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 19:24
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> On 1/1/02 12:57 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
> 
> > What would be nice would be to have a JJAR/CJAN project coupled with
> > GUMP. This application would have both an Ant task (for developers)
to
> > retrieve versions of dependent jars (latest or specified version or
> > date) and a GUI/Applet in the download area so that end user could
use
> > it to download dependent jars. What is needed is :
> > 1/ a repository for the jars where GUMP would copy nightly builds
and
> > where releases would be put
> > 2/ dependency information (what Jason is building or what the
Commons
> > JJAR project has) so that dependent jars can be easily downloaded
> >
> > I think it might be a good idea for JJAR/CJAN to be a subproject of
> > Alexandria.
> 
> I disagree.
> 

You have the right ... ;-) But why ?

My rationale was that the goal of GUMP as I understand it now, is to
ensure that all projects play well with each other in term of
compatibility. It seems natural to extend it so that it can also be
asked to retrieve all dependent jars for a given project.

-Vincent

P.S.: I said Alexandria instead of GUMP in my previous post but I'm not
cleat on the relations between these 2 in the future ... :-)

> --
> Geir Magnusson Jr.
[EMAIL PROTECTED]
> System and Software Consulting
> "They that can give up essential liberty to obtain a little temporary
> safety
> deserve neither liberty nor safety." - Benjamin Franklin
> 
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

> 




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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 2:54 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> "Geir Magnusson Jr." wrote:
>> Putting aside *all* the stuff we are talking about for a moement, and
>> looking at the simple notion of just having release jars available w/o docs,
>> source, etc I don't think this is a bad idea :)
>> 
>> However
>> 
>> Any license issues?  Wouldn't we want to package the jar w/ a license ?
> 
> This simple notion -- and my putting together a Jakarta release HOWTO --
> is why I opened this particular thread.
> 
> The license issue is well taken. I think it would be a good practice for
> us to include a license in all of our JARs. Even when we don't
> distribute them seperately ourselves, they are intended to be
> distributed seperately by our licensees. Point noted.
> 

It was more of a question than a point :)  I was painting a bathroom (sort
of like a bike shed, but my wife dictated the color :) and started wondering
about binary distribution issues...

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin



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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 2:43 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Geir Magnusson Jr. wrote:
>> 
>>> I agree that it would be nice if the GUMP results were put somewhere
>>> publicly accessible (they may be but I have no idea where). However, the
>>> second step is to automatically fetch the correct dependent jars (and
>>> possibly in a validated working state, proved by unit testing of each
>>> project).
>> 
>> You don't want to use the results of Gump for JJAR.  Gump isn't bulding
>> releases - it's building CVS-tree-du-jour...  There is no reason to believe
>> anything built by Gump works.
> 
> I believe that the operative words were "validated working state, proved by
> unit testing of each project".

That still doesn't mean anything other than the CVS-du-jour is
self-consistent with it's own unit tests, and says nothing about behavior
expected by something dependent upon it.

> To pick a random example... the http://jakarta.apache.org/gump/ is produced
> by anakia .  Which version of anakia?  The one built by gump.  How am I
> confident that it is going to work?  For starters, there is the unit tests
> of velocity itself.  Then there are other projects which use velocity that
> build and unit test successfully.
> 

That's fine.  That still is no guarantee that the functionality can be
depended upon.  I mean, what gump really tells you is that the API contracts
of a project that are used by dependent projects are being preserved
(because you can build using the gump-produced jars), but there are no
functional contracts that you can dependably test.  Further, you don't have
a provably complete API contract test because you depend on other projects,
which I bet just use a subset, to tell you if something changed.  (Food for
thought for Gump moving forward, I guess...)

So it wouldn't be right to base JJAR fetches of those jars - except when you
specify the non-released latest. (JJAR lets you choose which version of a
jar you want...)


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin



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

Re: Just the JARs

[Ted Husted]

"Geir Magnusson Jr." wrote:
> Putting aside *all* the stuff we are talking about for a moement, and
> looking at the simple notion of just having release jars available w/o docs,
> source, etc I don't think this is a bad idea :)
> 
> However
> 
> Any license issues?  Wouldn't we want to package the jar w/ a license ?

This simple notion -- and my putting together a Jakarta release HOWTO --
is why I opened this particular thread. 

The license issue is well taken. I think it would be a good practice for
us to include a license in all of our JARs. Even when we don't
distribute them seperately ourselves, they are intended to be
distributed seperately by our licensees. Point noted.

-Ted.

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

Re: Just the JARs

[Sam Ruby]

Geir Magnusson Jr. wrote:
>
>> I agree that it would be nice if the GUMP results were put somewhere
>> publicly accessible (they may be but I have no idea where). However, the
>> second step is to automatically fetch the correct dependent jars (and
>> possibly in a validated working state, proved by unit testing of each
>> project).
>
> You don't want to use the results of Gump for JJAR.  Gump isn't bulding
> releases - it's building CVS-tree-du-jour...  There is no reason to believe
> anything built by Gump works.

I believe that the operative words were "validated working state, proved by
unit testing of each project".

To pick a random example... the http://jakarta.apache.org/gump/ is produced
by anakia .  Which version of anakia?  The one built by gump.  How am I
confident that it is going to work?  For starters, there is the unit tests
of velocity itself.  Then there are other projects which use velocity that
build and unit test successfully.

- Sam Ruby


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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 2:33 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> Vincent Massol wrote:
>> I'm not sure what you mean. I've had a look and the dependent jars are
>> _not_ put with the gump build (or the release build).
> 
> I mean that if we all start offering our JARs as a separate download,
> like Lucene and some others are doing, then people who need these JARs
> can get them without downloading the entire distribution.
> 
> Once that happens, someone could build an automated process on top of
> that. 
> 
> Or, even without an automated process, you can just provide a hyperlink
> to the download direcory and let people choose whether they want the JAR
> or the distribution. Right now, most often, you have to download a 3mb
> archive just to get a 150kb JAR.
> 
> I'm just thinking of doing a page about "How to make a Jakarta release",
> and thought we might suggest this as a convention. If we start
> suggesting this now, then by the time we get through the next release
> cycle, we would all have JARs out where an automated process can get at
> them. (Or where they can at least be quickly downloaded the old-fasioned
> way.)
> 

Putting aside *all* the stuff we are talking about for a moement, and
looking at the simple notion of just having release jars available w/o docs,
source, etc I don't think this is a bad idea :)

However

Any license issues?  Wouldn't we want to package the jar w/ a license ?

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin



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

RE: Just the JARs

[Sam Ruby]

Vincent Massol wrote:
>
> I agree that it would be nice if the GUMP results were put somewhere
> publicly accessible (they may be but I have no idea where). However, the
> second step is to automatically fetch the correct dependent jars (and
> possibly in a validated working state, proved by unit testing of each
> project).

To date, I've been posting binaries in an ad-hoc fashion.  Some projects
have explicitly requested that binaries NOT be posted.  Others prefer to
build their nightly binaries in their own way.

If there is consensus on what is desired, I will see what I can do.

- Sam Ruby

P.S.  Gump is well aware of what dependent jars were used to execute the
build (including any unit tests, if present).


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

Re: Just the JARs

[Ted Husted]

Vincent Massol wrote:
> I'm not sure what you mean. I've had a look and the dependent jars are
> _not_ put with the gump build (or the release build). 

I mean that if we all start offering our JARs as a separate download,
like Lucene and some others are doing, then people who need these JARs
can get them without downloading the entire distribution. 

Once that happens, someone could build an automated process on top of
that. 

Or, even without an automated process, you can just provide a hyperlink
to the download direcory and let people choose whether they want the JAR
or the distribution. Right now, most often, you have to download a 3mb
archive just to get a 150kb JAR.

I'm just thinking of doing a page about "How to make a Jakarta release",
and thought we might suggest this as a convention. If we start
suggesting this now, then by the time we get through the next release
cycle, we would all have JARs out where an automated process can get at
them. (Or where they can at least be quickly downloaded the old-fasioned
way.)


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

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

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 2:00 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:

> 
> 
>> -Original Message-
>> From: Ted Husted [mailto:[EMAIL PROTECTED]]
>> Sent: 01 January 2002 18:39
>> To: Jakarta General List
>> Subject: Re: Just the JARs
>> 
>> I think Lucene is already doing something very similar. Except that
> the
>> JARs are just put in with the other builds. Perhaps we can just
>> recommend that everyone follow suit.
>> 
>> http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/
>> 
>> http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/
>> 
> 
> I'm not sure what you mean. I've had a look and the dependent jars are
> _not_ put with the gump build (or the release build). The only jar there
> is is the junit one but if you look at the GUMP definition of Lucene
> (http://jakarta.apache.org/builds/gump/latest/module_jakarta-lucene.html
> ) you'll find that it depends on xerces, ant and javacc, which are not
> included.
> 
> 
>> People could then just provide hyperlinks to the appropriate build
>> directories (say in a build.html file next to the build.xml), and let
>> people choose what they want to download.
>> 
> 
> I agree that it would be nice if the GUMP results were put somewhere
> publicly accessible (they may be but I have no idea where). However, the
> second step is to automatically fetch the correct dependent jars (and
> possibly in a validated working state, proved by unit testing of each
> project).
> 

You don't want to use the results of Gump for JJAR.  Gump isn't bulding
releases - it's building CVS-tree-du-jour...  There is no reason to believe
anything built by Gump works.

I hope I'm just confused on what you are advocating.


>> A front-end application that made all of our products more accessible
>> would also be a Good Thing, and something I would like to do some
> time.
>> But if were to publish some recommendations now, and lead by example,
> I
>> think things could get much easier for us all without much effort.
>> 
> 
> yep, but also an Ant task (like the one in JJAR) for project developers.
> 
>> I'm not suggesting we all run around and post JARs for the old
> releases,
>> but as new releases are issued, we might want to follow Lucene's
> example
>> (among others).
>> 
> 
> I guess this is currently done for most projects, isn't it (I mean that
> GUMP nightly builds are put in http://jakarta.apache.org/builds/) ? What
> I have done in Cactus, but I'm not sure it is the right way is to
> package an Ant distribution containing all the needed tasks/dependent
> jars to build the Cactus project / run Cactus tests in a project, using
> Ant. We also package the dependent jars in the release and nightly
> builds.
> 
> -Vincent
> 
>> -Ted.
>> 
>> 
>> 
>> Vincent Massol wrote:
>>> 
>>> What would be nice would be to have a JJAR/CJAN project coupled with
>>> GUMP. This application would have both an Ant task (for developers)
> to
>>> retrieve versions of dependent jars (latest or specified version or
>>> date) and a GUI/Applet in the download area so that end user could
> use
>>> it to download dependent jars. What is needed is :
>>> 1/ a repository for the jars where GUMP would copy nightly builds
> and
>>> where releases would be put
>>> 2/ dependency information (what Jason is building or what the
> Commons
>>> JJAR project has) so that dependent jars can be easily downloaded
>>> 
>>> I think it might be a good idea for JJAR/CJAN to be a subproject of
>>> Alexandria.
>>> 
>>> -Vincent
>>> 
 -Original Message-
 From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
 Sent: 01 January 2002 15:52
 To: Jakarta General List
 Subject: Re: Just the JARs
 
 On 1/1/02 10:39 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
 
> Does anyone have a page regarding how to make a Jakarta release?
> I'd
> like to put one together and post it with the other guideline
>>> materials.
 
 I tried to make a dist target for helping with a release. The
> target
>>> makes
 source and binary distributions and can be found in the BCEL,
> XmlRpc
>>> and
 Fulcrum. I was going to add this target to the build file that
> Berin
 offered
 the Alexandria project.
 
 With dependency information I've been adding to the gump
> descriptors
>>> it
 would be possible to combine a standard target for building
> release
 bundles
 with that dependency information to produce whatever we felt was
> the
 desired
 result for a release.
 
 Maybe we could take this over to the alexandria list?
 
> I've noticed that a few releases now include the JARs as a
> seperate
> download. Personally, I think that's a good idea, since more and
>>> more
> products have inter-dependancies. Would we want to suggest that
> as a
> standard practice?
> 
> This could save a lot of effort and bandwidth, since now you
> often
>>> have
> to download a 3mb archive when all you want is a 150k JAR.
> 
> 

Re: Just the JARs

[Geir Magnusson Jr.]

On 1/1/02 12:57 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:

> What would be nice would be to have a JJAR/CJAN project coupled with
> GUMP. This application would have both an Ant task (for developers) to
> retrieve versions of dependent jars (latest or specified version or
> date) and a GUI/Applet in the download area so that end user could use
> it to download dependent jars. What is needed is :
> 1/ a repository for the jars where GUMP would copy nightly builds and
> where releases would be put
> 2/ dependency information (what Jason is building or what the Commons
> JJAR project has) so that dependent jars can be easily downloaded
> 
> I think it might be a good idea for JJAR/CJAN to be a subproject of
> Alexandria.

I disagree. 

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin



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

Re: Just the JARs

[Sam Ruby]

Ted Husted wrote:
>
> I think Lucene is already doing something very similar. Except that the
> JARs are just put in with the other builds. Perhaps we can just
> recommend that everyone follow suit.
>
> http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/

I post the contents of those directories.  I certainly can do that for
every project that gump tracks.  And separate things out any way that
people find sensible.

- Sam Ruby


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

RE: Just the JARs

[Vincent Massol]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 18:39
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> I think Lucene is already doing something very similar. Except that
the
> JARs are just put in with the other builds. Perhaps we can just
> recommend that everyone follow suit.
> 
> http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/
> 
> http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/
> 

I'm not sure what you mean. I've had a look and the dependent jars are
_not_ put with the gump build (or the release build). The only jar there
is is the junit one but if you look at the GUMP definition of Lucene
(http://jakarta.apache.org/builds/gump/latest/module_jakarta-lucene.html
) you'll find that it depends on xerces, ant and javacc, which are not
included.


> People could then just provide hyperlinks to the appropriate build
> directories (say in a build.html file next to the build.xml), and let
> people choose what they want to download.
> 

I agree that it would be nice if the GUMP results were put somewhere
publicly accessible (they may be but I have no idea where). However, the
second step is to automatically fetch the correct dependent jars (and
possibly in a validated working state, proved by unit testing of each
project).

> A front-end application that made all of our products more accessible
> would also be a Good Thing, and something I would like to do some
time.
> But if were to publish some recommendations now, and lead by example,
I
> think things could get much easier for us all without much effort.
> 

yep, but also an Ant task (like the one in JJAR) for project developers.

> I'm not suggesting we all run around and post JARs for the old
releases,
> but as new releases are issued, we might want to follow Lucene's
example
> (among others).
> 

I guess this is currently done for most projects, isn't it (I mean that
GUMP nightly builds are put in http://jakarta.apache.org/builds/) ? What
I have done in Cactus, but I'm not sure it is the right way is to
package an Ant distribution containing all the needed tasks/dependent
jars to build the Cactus project / run Cactus tests in a project, using
Ant. We also package the dependent jars in the release and nightly
builds.

-Vincent

> -Ted.
> 
> 
> 
> Vincent Massol wrote:
> >
> > What would be nice would be to have a JJAR/CJAN project coupled with
> > GUMP. This application would have both an Ant task (for developers)
to
> > retrieve versions of dependent jars (latest or specified version or
> > date) and a GUI/Applet in the download area so that end user could
use
> > it to download dependent jars. What is needed is :
> > 1/ a repository for the jars where GUMP would copy nightly builds
and
> > where releases would be put
> > 2/ dependency information (what Jason is building or what the
Commons
> > JJAR project has) so that dependent jars can be easily downloaded
> >
> > I think it might be a good idea for JJAR/CJAN to be a subproject of
> > Alexandria.
> >
> > -Vincent
> >
> > > -Original Message-
> > > From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> > > Sent: 01 January 2002 15:52
> > > To: Jakarta General List
> > > Subject: Re: Just the JARs
> > >
> > > On 1/1/02 10:39 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Does anyone have a page regarding how to make a Jakarta release?
I'd
> > > > like to put one together and post it with the other guideline
> > materials.
> > >
> > > I tried to make a dist target for helping with a release. The
target
> > makes
> > > source and binary distributions and can be found in the BCEL,
XmlRpc
> > and
> > > Fulcrum. I was going to add this target to the build file that
Berin
> > > offered
> > > the Alexandria project.
> > >
> > > With dependency information I've been adding to the gump
descriptors
> > it
> > > would be possible to combine a standard target for building
release
> > > bundles
> > > with that dependency information to produce whatever we felt was
the
> > > desired
> > > result for a release.
> > >
> > > Maybe we could take this over to the alexandria list?
> > >
> > > > I've noticed that a few releases now include the JARs as a
seperate
> > > > download. Personally, I think that's a good idea, since more and
> > more
> > > > products have inter-dependancies. Would we want to suggest that
as a
> > > > standard practice?
> > > >
> > > > This could save a lot of effort and bandwidth, since now you
often
> > have
> > > > to download a 3mb archive when all you want is a 150k JAR.
> > > >
> > > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > > -- Building Java web applications with Struts.
> > > > -- Tel +1 585 737-3463.
> > > > -- Web http://www.husted.com/struts/
> > > >
> > > > --
> > > > To unsubscribe, e-mail:    > > [EMAIL PROTECTED]>
> > > > For additional commands, e-mail:  > > [EMAIL PROTECTED]>
> > >
> > > --
> > >
> > > jvz.
> > >
> >

Re: Just the JARs

[Ted Husted]

I think Lucene is already doing something very similar. Except that the
JARs are just put in with the other builds. Perhaps we can just
recommend that everyone follow suit. 

http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/

http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/

People could then just provide hyperlinks to the appropriate build
directories (say in a build.html file next to the build.xml), and let
people choose what they want to download. 

A front-end application that made all of our products more accessible
would also be a Good Thing, and something I would like to do some time.
But if were to publish some recommendations now, and lead by example, I
think things could get much easier for us all without much effort.

I'm not suggesting we all run around and post JARs for the old releases,
but as new releases are issued, we might want to follow Lucene's example
(among others). 

-Ted.



Vincent Massol wrote:
> 
> What would be nice would be to have a JJAR/CJAN project coupled with
> GUMP. This application would have both an Ant task (for developers) to
> retrieve versions of dependent jars (latest or specified version or
> date) and a GUI/Applet in the download area so that end user could use
> it to download dependent jars. What is needed is :
> 1/ a repository for the jars where GUMP would copy nightly builds and
> where releases would be put
> 2/ dependency information (what Jason is building or what the Commons
> JJAR project has) so that dependent jars can be easily downloaded
> 
> I think it might be a good idea for JJAR/CJAN to be a subproject of
> Alexandria.
> 
> -Vincent
> 
> > -Original Message-
> > From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> > Sent: 01 January 2002 15:52
> > To: Jakarta General List
> > Subject: Re: Just the JARs
> >
> > On 1/1/02 10:39 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> >
> > > Does anyone have a page regarding how to make a Jakarta release? I'd
> > > like to put one together and post it with the other guideline
> materials.
> >
> > I tried to make a dist target for helping with a release. The target
> makes
> > source and binary distributions and can be found in the BCEL, XmlRpc
> and
> > Fulcrum. I was going to add this target to the build file that Berin
> > offered
> > the Alexandria project.
> >
> > With dependency information I've been adding to the gump descriptors
> it
> > would be possible to combine a standard target for building release
> > bundles
> > with that dependency information to produce whatever we felt was the
> > desired
> > result for a release.
> >
> > Maybe we could take this over to the alexandria list?
> >
> > > I've noticed that a few releases now include the JARs as a seperate
> > > download. Personally, I think that's a good idea, since more and
> more
> > > products have inter-dependancies. Would we want to suggest that as a
> > > standard practice?
> > >
> > > This could save a lot of effort and bandwidth, since now you often
> have
> > > to download a 3mb archive when all you want is a 150k JAR.
> > >
> > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > -- Building Java web applications with Struts.
> > > -- Tel +1 585 737-3463.
> > > -- Web http://www.husted.com/struts/
> > >
> > > --
> > > To unsubscribe, e-mail:    > [EMAIL PROTECTED]>
> > > For additional commands, e-mail:  > [EMAIL PROTECTED]>
> >
> > --
> >
> > jvz.
> >
> > Jason van Zyl
> >
> > http://tambora.zenplex.org
> > http://jakarta.apache.org/turbine
> > http://jakarta.apache.org/velocity
> > http://jakarta.apache.org/alexandria
> > http://jakarta.apache.org/commons
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

RE: Just the JARs

[Vincent Massol]

What would be nice would be to have a JJAR/CJAN project coupled with
GUMP. This application would have both an Ant task (for developers) to
retrieve versions of dependent jars (latest or specified version or
date) and a GUI/Applet in the download area so that end user could use
it to download dependent jars. What is needed is :
1/ a repository for the jars where GUMP would copy nightly builds and
where releases would be put
2/ dependency information (what Jason is building or what the Commons
JJAR project has) so that dependent jars can be easily downloaded

I think it might be a good idea for JJAR/CJAN to be a subproject of
Alexandria.

-Vincent

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 15:52
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> On 1/1/02 10:39 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> 
> > Does anyone have a page regarding how to make a Jakarta release? I'd
> > like to put one together and post it with the other guideline
materials.
> 
> I tried to make a dist target for helping with a release. The target
makes
> source and binary distributions and can be found in the BCEL, XmlRpc
and
> Fulcrum. I was going to add this target to the build file that Berin
> offered
> the Alexandria project.
> 
> With dependency information I've been adding to the gump descriptors
it
> would be possible to combine a standard target for building release
> bundles
> with that dependency information to produce whatever we felt was the
> desired
> result for a release.
> 
> Maybe we could take this over to the alexandria list?
> 
> > I've noticed that a few releases now include the JARs as a seperate
> > download. Personally, I think that's a good idea, since more and
more
> > products have inter-dependancies. Would we want to suggest that as a
> > standard practice?
> >
> > This could save a lot of effort and bandwidth, since now you often
have
> > to download a 3mb archive when all you want is a 150k JAR.
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Building Java web applications with Struts.
> > -- Tel +1 585 737-3463.
> > -- Web http://www.husted.com/struts/
> >
> > --
> > To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> > For additional commands, e-mail:  [EMAIL PROTECTED]>
> 
> --
> 
> jvz.
> 
> Jason van Zyl
> 
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
> 
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

> 




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

Re: Just the JARs

[Jason van Zyl]

On 1/1/02 10:39 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> Does anyone have a page regarding how to make a Jakarta release? I'd
> like to put one together and post it with the other guideline materials.

I tried to make a dist target for helping with a release. The target makes
source and binary distributions and can be found in the BCEL, XmlRpc and
Fulcrum. I was going to add this target to the build file that Berin offered
the Alexandria project.

With dependency information I've been adding to the gump descriptors it
would be possible to combine a standard target for building release bundles
with that dependency information to produce whatever we felt was the desired
result for a release.

Maybe we could take this over to the alexandria list?
 
> I've noticed that a few releases now include the JARs as a seperate
> download. Personally, I think that's a good idea, since more and more
> products have inter-dependancies. Would we want to suggest that as a
> standard practice?
> 
> This could save a lot of effort and bandwidth, since now you often have
> to download a 3mb archive when all you want is a 150k JAR.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



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

Just the JARs

[Ted Husted]

Does anyone have a page regarding how to make a Jakarta release? I'd
like to put one together and post it with the other guideline materials.

I've noticed that a few releases now include the JARs as a seperate
download. Personally, I think that's a good idea, since more and more
products have inter-dependancies. Would we want to suggest that as a
standard practice? 

This could save a lot of effort and bandwidth, since now you often have
to download a 3mb archive when all you want is a 150k JAR.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

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

Re: [Request For Comment] POI @ apache

[Andrew C. Oliver]

Hi,
 
I'm writing, at the recommendation of Stefano Mazzocchi, in hopes of
drawing discussion and perhaps later a vote on the creation of a new
Jakarta subproject based on the POI project (http://poi.sourceforge.net
& http://sourcefoge.net/projects/poi).

The POI project consists of an API for reading and writing Microsoft's
OLE2 Compound Document Format, the format used in Microsoft Office for
Word and Excel documents, as well as ports of file formats based on
it.

Currently the project is composed into the following parts:
 
POIFS - the pure java port of OLE 2 Compound Document format and the
APIs for manipulating it.
 
HSSF - the pure java port of Microsoft's Excel 97 File format (BIFF8)
which is shared by all newer version of Excel as well.
 
HSSFSerializer - Cocoon2 Serializer for HSSF.  It uses the same XML tag
language as Gnumeric. [this will be donated and hosted in Cocoon]
 
HSSFGenerator - commencing. [this will be part of Cocoon as well]
 
HDF - commencing. A pure java port of Microsoft's Word 97 File Format
which is shared by newer versions of Word as well.
 
The POI project has been in development for just over 6 months.  The POI
project has gained a reasonably large user base and currently has four
listed developers and a few occasional contributers.  On any given day
it makes the front page on Sourceforge's most active projects. The POI
project will attract a larger development community once the Word port
begins.  However, the project admins (myself and Marc) will continue to
develop it until pried from our cold dead fingertips regardless of
anything.  We released a beta over the holidays and our 1.0 release
yesterday.

We started the project in order to provide the ability for Cocoon to
present information directly in Office formats and wanted to donate it
to Cocoon directly, but the potential benefits of POI encompass those of
Cocoon or xml.apache.org and we believe that many Jakarta subprojects
could potentially benefit from POI and it makes good "business sense"
for Apache as a whole.

Possible collaboration scenarios are Lucene indexing large quantities
of data in .doc and .xls files, Slide doing content management in a
corporate environment that necessitates DOC and XLS support, Turbine
doing content delivery in DOC XLS and content editing in DOC, XLS). 

>From a personal standpoint, its the most fun thing I've worked on in a
great while.  Microsoft creates great brain teasers!  While I don't
think the project will ever be "finished" (there will always be a minor
enhancement or detail to be worked out), it is already very useful.

Thoughts?

Happy New Year,

-Andy
-- 
www.sourceforge.net/projects/poi - port of Excel format to java

The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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