Re: [Ant nudge STATUS] Better than we thought...

2002-10-26 Thread dion
What would this mean for the Jakarta PMC as many of them are part of Ant? 
Do these PMC'ers do double duty?
--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote on 26/10/2002 10:04:43 PM:

> >
> >
> >> The idea:
> >>
> >> ant.apache.org would become a valid url 
> >
> >
> >
> > Good move - presumably could be indendent of the rest of the points ?
> 
> 
> This has been asked but not answered.  I think the answer is probably no 

> as those are reserved for top level projects.  (I prefer the answer to 
> be yes...but I don't think it is)
> 
> >
> >>
> >> ant would have its own PMC composed of whomever the committers decide 

> >> (I guess)
> >> ant would report directly to the board
> >
> >
> >
> > Pros and cons - appears to me that the main issue is general 
> > discontinuity of the value perception - committers look at a PMC and 
> > see it as an overhead and something to push into the furthests reaches 

> > of their minds - board members see this is the accountability 
> > mechanisms - I'm still thinging about this one - I know there is 
> > something wrong with the model but I don't have througts together yet.
> 
> Understandable.  Another benefit:  greater self determination.  Although 

> its in a less tangible way as Jakarta committers have great deal of 
> this.  But you need to think not only about ant but in a global kind of 
> manner (the ASF as a whole)
> 
> >
> >>
> >> unresolved (but I think open...or maybe I'm wrong)
> >> relationship between ant and Jakarta (I'm assuming it would answer to 

> >> Jakarta only in name/branding) 
> >
> >
> >
> > Good move - leverage Jakarta (brand etc.).
> 
> agreed.
> 
> >
> >>
> >> jakarta.apache.org/ant still valid url?
> >
> >
> >
> > Should be.
> 
> agreed
> 
> >>
> >> greater access to the members/board
> >
> >
> >
> > Questionable given the PMC concept verus community disconnect I'm 
seeing.
> 
> well principally you should be interested in this communication. 
>  Another PRO...
> more opportunity for ant committers to become recognized and achieve 
> membership.
> 
> >
> >>
> >> Disadvantage
> >> reporting directly to the board (from a laziness perspective...I 
> >> think you have to actually "report" though I could be wrong)
> >> you'd be the first to make the transition
> >
> >
> >
> > My impression is that this something comming (which I happen to think 
> > is long overdue).
> 
> which this would help achieve..
> 
> >
> >>
> >> Ant is the project I personally would like to see be top level most. 
> >> Suggestion:
> >> Someone who understands the proposed process of this happening draft 
> >> a formal proposal to be voted on..
> >
> >
> >
> > I'm not on the ant list but I would be definaterly keen to see such a 
> > proposal cross posted to community@
> 
> yes.  or just moved there.
> 
> >
> > Cheers, Steve.
> >
> >>
> >> -Andy
> >>
> >>
> >>
> >
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

> ForwardSourceID:NT00086AEA 


Re: [PROPOSAL] Tapestry joins Jakarta

2002-10-26 Thread dion
"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote on 27/10/2002 12:20:26 AM:

> Mr Ship,
> 
> I totally disagree with Pier's statement (and you'll find many here will 

> feel the same as I on this). 
> The opinion of Tapestry joining is very good.
> Realize Apache is more like a confederation than anything.  So different 

> people feel
> differently.  We're still ironing out a new process as Pier said, 
> however most folks I've
> spoken to have felt that the Apache voting rules must be adopted as a 
> first step not
> later.  Dion and I have both committed to helping you with this 
> transition (though I don't
> think he ever stated so publically...Dion?).  And I'll be happy to 

This counts as publicly volunteering :)

> subscribe to the tapestry
> list if you desire and help you build the structure.
> 
> The steps as I see them:
> 
> 1. Adopt apache voting rules
> 2. Vote to join and relicense (in one swoop)
> 3. Submit a formal proposal
3a. PMC confers
> 4. You're in

[snip]
> Me & Dion
> 1. Find a sponsoring member
> 2. Assist you in reorganizing
> 3. Assist you in your propoasal
> 4. Make our case
> 5. Assist you in getting your sources/structures here.
6. Assist in liaising with incubator
7. Assist in 'The Apache Way' details.

> Thats as clearly as i can lay it out.  Hopefully others will chime in 
> constructively and clear up anything I got wrong or is fuzzy ;-)
--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers




Re: Dear incubator

2002-10-27 Thread dion
Since the discussion was initiated here on [EMAIL PROTECTED], I'd prefer we 
kept it here until there is a way forward via incubator, rather than move 
it off to yet another list.


--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote on 27/10/2002 11:30:10 AM:

> Dear incubator,
> 
> I feel like I'm speaking to the wizard of Oz posting to a list I can't 
> see ;-)
> 
> Tapestry (tapestry.sourceforge.net) is a web app framework similar in 
> use and scope to Velocity/turbine and JSP/Struts, but certainly very 
> different in approach.
> 
> dIon Gillard and I have both agreed to help with the transition. 
> However we both feel the first step is for the tapestry community 
> (to whom's mail list I am now subscribed) to adopt apache voting rules (
> http://httpd.apache.org/dev/guidelines.html) before joining.  once 
> they've demonstrated this transition and identified 3 core 
> committers, we should identify whether they go through some new 
> process or identify the new incubator process.  Whatever the case 
> they should not be unduely lubricated through the guidelines, nor 
> unduely inhibited by the transition.  I think we're all up to this 
> challenge and this could (hopefully) set a very nice precident.
> 
> To this end and to the ends of providing more interaction between 
> the various elements here at apache, I would like to suggest Ken 
> Coar whom I have approached as the "member sponsor" and "advisor" of
> the project and has stated his interest.  His experience and 
> abillities will be an asset to this transition as well as provide 
> greater insight to the rest of the Apache community on the goings on
> of a Java/Jakarta project.
> 
> I'd like to start a conversation on what the process/guidelines for 
> accepting Tapestry should be at the same time and what its path for 
> acceptance as either a Jakarta project or top level apache project 
should be.
> 
> I would suggest that this discussion happen on the community at 
> apache list and move to the general at jakarta list if deemed 
> appropriate as dion and I cannot participate in the [EMAIL PROTECTED] 
> list nor can the project principals.
> 
> Thanks for your support,
> 
> Andrew C. Oliver
> committer POI, Lucene
> contributer Cocoon, JAMES
> 
> 
> 
> 
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
<mailto:[EMAIL PROTECTED]>
> 

> ForwardSourceID:NT0008711E 


Ant PMC Issue (was: RE: [proposal] daedalus jar repository (was: primary distribution location))

2003-02-26 Thread dion
Noel Bergman writes:
> I like the idea of a central repository.  It would simplify the issue by
> centralizing maintenance of jars and licenses.  I just want to know how 
it
> is going to operate.  A joint operation between Ant and Maven?
> Infrastructure?
> 
> [I won't even get into the question of why those two can't be related
> projects under a single PMC]
Read the Ant missionit specifically states the Ant build system as 
it's scope.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository (was: primary distribution

2003-02-26 Thread dion
Now I've gone from digest to individual emails, keeping up might be 
easier...

[EMAIL PROTECTED] wrote on 27/02/2003 03:08:17 AM:
> --
> From: Leo Simons <[EMAIL PROTECTED]>
> yep. So don't drop the binary until you have a) policy, b) desire and c) 

> an ok to make apache into
> a redistribution point of third-party software. Just b) doesn't cut it.

The issue for the ASF is that we already *are* distributing third-party 
software via cvs and viewcvs.

jdom, w3c stuff like dom2, jaxp, JLex, tidy etc


> Licensing policy is quite tricky and lots of things need to be done 
> before the ASF should even consider
Now there's an understatement.

> For example, the docs started at
> http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should be made 
> into an authoritive source on
> www.apache.org that unambiguously answers "yes" or "no" with regard to
> 
> "can we link to software under license X?",
And what does 'linking' mean for languages used by the ASF, e.g. Java, 
PHP, Perl, scripting languages like Javascript?

> "can we redistribute software under license X in source form and/or 
> binary form?",
> "how do we provide these licenses when we redistribute or link to 
> software under license X?",
> "what other steps doe we take when we redistribute or link to software 
> under license X?"
e.g. credits, details in documentation, etc.

> Not sure if your project can distribute JUnit? Then don't, even if that 
> makes life terribly inconvenient.
That seems to be the opposite of most projects current stance.

> sourcecode under its own license. Yes, binary, but it is the best first 
> step and it solves a real need.
Just to play devils advocate, what is that need, Given that there current 
is a repository distributing ASF binaries with their license.

This is not a facetious comment, but a desire to explore what the need is 
for an ASF-blessed repository.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [off-topic-just for fun] - Maps and zoom-in

2003-02-27 Thread dion
From: Rodent of Unusual Size <[EMAIL PROTECTED]>
> 
> Dirk-Willem van Gulik wrote:
> > The map on:
> > 
> >http://cvs.apache.org/~dirkx/sgala.html
> > 
> > has had a wee enhancement; if you zoom in far enough; the boring 
digital
> > terrain map of etoto5 gets replaced by mapblast. Depending on which 
part
> > of the world you're in, the projection is about right :-)

That map shows only one person in Australia...how are the people 
determined?
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository (was:primary

2003-02-27 Thread dion
From: Conor MacNeill <[EMAIL PROTECTED]>

> [EMAIL PROTECTED] wrote:
> > 
> > Read the Ant missionit specifically states the Ant build system as 


> > it's scope.
> 
> Hi Dion,
> 
> Your subject got my attention :-) Is there an Ant PMC issue here? We're 
Nope, no ant pmc issue from me.

> certainly open to working with other projects within Apache and beyond. 
Is 
> Ant's scope statement preventing the Maven developers from working on an 


> Apache jar repository with Ant? Am I missing something?
Nope, you're not missing something. Noel just asked in passing why Maven 
and Ant aren't under the same PMC.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [off-topic-just for fun] - Maps and zoom-in

2003-02-27 Thread dion
From: Rodent of Unusual Size <[EMAIL PROTECTED]>
> 
> Dirk-Willem van Gulik wrote:
> > The map on:
> > 
> >http://cvs.apache.org/~dirkx/sgala.html
> > 
> > has had a wee enhancement; if you zoom in far enough; the boring 
digital
> > terrain map of etoto5 gets replaced by mapblast. Depending on which 
part
> > of the world you're in, the projection is about right :-)

That map shows only one person in Australia...how are the people 
determined?
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository (was: primary distribution location)

2003-02-27 Thread dion
Costin Manolache <[EMAIL PROTECTED]> writes:

> Few simple questions:
> 
> Should we use 2 different dirs for src and binary distribution ? Or 
> maybe 3 dirs ( src, bin, doc ) ? 

Why duplicate the existing distributions? They're available, mirrored and 
well understood.

> Are "milestone" builds acceptable ? Should we get some weekly gump 
> builds from HEAD into the repository ? 
FWIW, Milestone and even 'snapshot' builds have proven necessary for 
projects using Maven.

> What policy should we use for removing older versions ( or we just keep 
> everything ) ? 
It needs to be driven by usage. If someone is still using ant 1.1, fine 
keep it available. There's nothing worse than a build failing because the 
repository has changed.

> Since the versioned jar/unversioned dir format is used - I think various 

> PMCs should try to get the various projects to use the same format 
> internally. 
That's a project decision. I don't see anyone should be forcing the 
projects to change their build process to match the repository. That's why 

the ibiblio repository has manual admin as an option (at the moment it's 
the only one).

> I would prefer the reverse ( versioned dirs / unversioned jars ) - but I 

> can live with the reverse if it does have a "majority" support. 
So asking the projects which format they would like for a repository they 
don't currently use? Sounds like asking for uninformed opinions. I'd be 
happier to come ask them to participate in a discussion here.

> Could we put at least this option to a vote, just to have a record that 
> it isn't just a random decision but what the committers really want ?
Why not ask the users of the repository. The committers wont be the main 
users.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository (was: primary distribution

2003-02-27 Thread dion
Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote on 27/02/2003 10:18:26 
AM:

> 
> On Thu, 27 Feb 2003 [EMAIL PROTECTED] wrote:
> 
> > > "can we link to software under license X?",
> 
> > And what does 'linking' mean for languages used by the ASF, e.g. Java,
> > PHP, Perl, scripting languages like Javascript?
> 
> Actually - in a lot of cases - that is not 'our' problem. Best we can do
> is ask the owner/author of the IP/License for which resolving such is
> important for his-or-her take on that; and then make sure the answer is
> filed properly in the ASF books.

Yep. If the ASF wants to use third-party code, it must verify the license 
usage is legal.

Given the discussions lately re: LGPL, this sort of issue is extremely 
important.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: can Apache distribute third party libraries?

2003-02-27 Thread dion
Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote on 27/02/2003 10:08:20 
AM:

> 
> On Thu, 27 Feb 2003, Leo Simons wrote:
> 
> > there exists some confusion within the apache community about the
> > redistribution of library sources and binaries by apache. The question
> 
> I took an action on the last board meeting to start making an initial 
list
> of those licenses and a procedure to keep that list up to date/extend 
it.
> 
> Expect some action on that in the next days/week.
Cool. I've done a lot of reading of licenses lately, and would appreciate 
any info you've got.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Maven and community

2003-02-27 Thread dion


-Sam Ruby <[EMAIL PROTECTED]> wrote: -

> Now that the initial board discussion on the Maven resolution has been
> held, a few thoughts...

> 1) It was made quite clear to me by a number of directors that it is
> expected that I have an interest and opinion on topics that come before
> the board.  I received repeated requests not to abstain on this vote,
> but I held my ground.  I believe that over the years I have amply
> demonstrated a preference to "let a thousand flowers bloom", but in this
> case my integrity was called into question in a way that I very much did
> not appreciate.
>
> 2) The question that is foremost in my mind on the Maven proposal is as
> follows: what does the ASF as a whole gain by yielding a specific scope
> and responsibility to the set of five developers mentioned in the
> proposed Maven resolution?  If these people want to work together, they

There are more than five members of the Maven team. Please see
http://jakarta.apache.org/turbine/maven/team-list.html for a full list of
committers
and contributors. There are around 30 contributors to the effort overall.

The ASF gains nothing new from these people, as they are mostly existing
committers.
The code is (c) ASF, so they gain no code from the proposal.
The ASF would gain more assurance that the code being created is overseen
by
people directly responsible and involved in its creation, rather than the
responsibility falling to the Jakarta PMC, who I'm sure haven't got the
time
and energy to cover it. They would also gain a focussed community of
software developers
with a passionate group of users.

> can certainly do so in a number of venues, so what do they or the ASF
> benefit from doing so here?
There are quite a few projects here (ASF) using Maven as a build tool.
Maven heavily relies
on other ASF code (Ant, Jakarta's Jelly, Jexl, Commons etc). There are
obvious benefits to
those projects in Maven's continued working with them, as we have done in
the past.

> 3) A challenge to the Maven developers: what would it take to convert
> Xalan to use Maven?  The reason for this challenge is simple: to
> demonstrate the the antipathy towards other ASF efforts is damaging not
> only to the ASF, but to Maven itself.
Last things first:

'antipathy' == 'A strong feeling of aversion or repugnance'.

I'm not very happy that you feel the 'Maven developers', all 30 or so
people
involved in a significant way, feel this way about 'other ASF efforts'.

Given the involvement of most of the proposed PMC members in other ASF
efforts
I'm having trouble seeing how it is justified. I'm trying not to take it
personally.

As for the challenge, I, personally, don't think that Maven needs to
'convert'
other projects to use it. Other projects should use Maven if they feel it
fits their needs.
I personally don't feel that other projects (Forrest, Gump, Centipede, Ant,
Make, Nant etc)
should try to convert people. I'd rather people experimented and made up
their
own mind. I'd hate for someone to force a build tool on me.

That said, Xalan could quite easily start using Maven as a build
or site generation tool, but,  Maven doesn't currently cover as much of
Xalan's build
process as a pure java project, and hence there would be work to determine
how this
would be best achieved. I see no problem or issue there. If the Xalan team
would like help
I'm offering.

> P.S., and this is primarily to Jason: please don't try to twist any of
> this into coersion.  #2 and #3 above are simply a question and a
> challenge.  They are not a prerequisite for board approval, or even
> necessarily for my one vote out of nine directors on the subject when it
> comes up again.  It is my belief that a number of efforts made by the
> Maven community can, will, and do benefit the ASF.  I simply want to
> maximize the potential for this to occur.  That is my interest.
Just so I understand that last bit, you'd like to 'maximize the potential'
for the 'efforts made by the Maven community' to 'benefit the ASF'. Right?

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
 Work:  http://www.multitask.com.au


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Maven and community

2003-02-27 Thread dion
Sam Ruby <[EMAIL PROTECTED]> wrote on 27/02/2003 11:39:47 PM:

> [EMAIL PROTECTED] wrote:
>  >
>  > The ASF gains nothing new from these people, as they are mostly
>  > existing committers. The code is (c) ASF, so they gain no code from
>  > the proposal. The ASF would gain more assurance that the code being
>  > created is overseen by people directly responsible and involved in
>  > its creation, rather than the responsibility falling to the Jakarta
>  > PMC, who I'm sure haven't got the time and energy to cover it. They
>  > would also gain a focussed community of software developers with a
>  > passionate group of users.
> 
> The proposed resolution is not the only organization which would achieve 

> that goal.  It might happen to be the best one, but it certainly isn't 
> the only one.
I'm not suggesting it is. I'd be interested to hear others.

> I do believe that a number of potentially fruitful discussions about 
> potential synergies have been shut down during this process.  This 
> troubles me.
I haven't seen that from my side, so I can't comment.

> I do not believe that all Maven developers feel the same way.  Need I 
> cite a few IRC logs to show that that a number of them, particularly 
> some of those listed as the proposed PMC, do?  Or at the very least, 
> look the other way when such sentiments are expressed?
I'm sure you could find lots of things on IRC logs that don't quote very 
well.

That's the nature of IRC; casual conversation. Reading an IRC log is like 
eavesdropping.

>  > Given the involvement of most of the proposed PMC members in other
>  > ASF efforts I'm having trouble seeing how it is justified. I'm trying
>  > not to take it personally.
> 
> As I have tried not to take the numerous and repeated comments that Gump 

> sucks or is an embarrasment to the ASF personally.
There's a difference here. Gump is a piece of software. 'Maven developers' 
are
people, myself included. And I'll ignore those blog entries about Jelly 
sucking too :)

>  > As for the challenge, I, personally, don't think that Maven needs to
>  > 'convert' other projects to use it. Other projects should use Maven
>  > if they feel it fits their needs. I personally don't feel that other
>  > projects (Forrest, Gump, Centipede, Ant, Make, Nant etc) should try
>  > to convert people. I'd rather people experimented and made up their
>  > own mind. I'd hate for someone to force a build tool on me.
> 
> Here we strongly agree.
> 
> That's why I am concerned when I see statements to the effect that 
> threre is no need for certain other efforts (for example, an ASF jar 
> repository).

I'm happy for the ASF to have a jar repository. I personally haven't seen 
a need
clearly expressed about why we need an ASF only repository. Desire, sure. 
Need?
That hasn't been clearly articulated, and we seem to be discussing low 
level details
without working out/discussing the reasons first.

I've had several discussions with Noel Bergman offline about the idea, and 
posted
recently to this list about it.

Other developers can get as involved as they would like, but I don't think 
I've been
forcing things on people.

>  > Just so I understand that last bit, you'd like to 'maximize the
>  > potential' for the 'efforts made by the Maven community' to 'benefit
>  > the ASF'. Right?
> 
> I certainly would like to see that.  To be clear, I wouldn't pursue that 

> to the expense of the self determination of people who have contributed 
> to Maven.  Nor to the expense of the self determination of those that 
> wish to pursue "competing" efforts.

A lot of things could come out of projects, such as Maven, that would be 
of
wider benefit to the ASF. When this happens, I hope people step up and 
offer 
to get involved and suggest ways of working together.

As an example, take the jar repository. Leo has cross-posted to 
turbine-maven-dev
to solicit feedback, and I've had emails from Noel Bergman as well. 
Whether
anything comes of it, who knows, but from my angle all the right noises 
are
being made.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [proposal] daedalus jar repository (was: primary distribution location)

2003-02-27 Thread dion
Costin Manolache <[EMAIL PROTECTED]> wrote on 27/02/2003 08:28:05 AM:

> On Wed, 26 Feb 2003, Noel J. Bergman wrote:
> 
> > differing views on how to make use of the repository.  Costin and I 
seem to
> > be of the option that a significant portion of the value of the 
repository
> > comes from sharing and centralizing the managment of ASF-acceptable 
third
> > party jars.
> 
> Not entirely true, but close. 
> 
> I think third party jars that are found compatible with ASF license - 
i.e. 
> freely redistributable - are very valuable as they will allow projects 
> to better manage their dependencies. 

You know that ASF jars aren't 'freely' distributable, right? The license 
specifies some conditions on binary distribution.

> I don't believe in a single repository or a single policy - the download 

> tools must be smart and be able to deal with different kinds of 
> repositories ( apache, sourceforge, maven, etc ). Heck - if the tool can 

> display the license and ask for an "I agree" and if this satisfies the 
> requirements of some licenses - it should be supported. That's what 
> makes a good tool - flexibility and ability to accept multiple inputs. 
Sure, that's a tool that can handle lots of repositories. But what about 
the apache repo?

> Well, Maven doesn't seem to be that concerned with duplication, and 
values 
> the competition :-) To paraphrase Jason - what's wrong with multiple 
> competing repositories ? A smart tool should be able to support multiple
> policies - or choose to restrict the users to a particular set.
Sure, feel free.

> To take one example - the jar naming - I understand very well that Maven 

> people decided on this thing. And I understand that a lot of people 
> consider this a good decision - and a lot of other people don't. If this 

> becomes an apache-wide policy, I strongly disagree that Maven can decide 

> for apache policies. 
I don't think we've tried to.

> In other words - as long as maven decisions affect only maven - I don't 
> care. But if it affects other projects, and the repository certainly 
does 
> - then the PMCs of those projects or the apache community are the ones 
> that decide.
Sure, but please take into account the work we've already done.

> +1 on the oversight committee for non-apache jars. 
Believe me, the oversight bit is the hardest part.

> A strong -1 on oversight for apache jars. We already have PMCs for each 
> project, and those should oversee the distribution of their own files.
Even by other projects?

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository

2003-02-27 Thread dion
Greg Stein <[EMAIL PROTECTED]> wrote on 27/02/2003 11:33:28 AM:

> On Thu, Feb 27, 2003 at 10:12:35AM +1100, [EMAIL PROTECTED] wrote:
> >...
> > > sourcecode under its own license. Yes, binary, but it is the best 
first 
> > > step and it solves a real need.
> >
> > Just to play devils advocate, what is that need, Given that there 
current 
> > is a repository distributing ASF binaries with their license.
> > 
> > This is not a facetious comment, but a desire to explore what the need 
is 
> > for an ASF-blessed repository.
> 
> The ASF doesn't "need" to have a repository. But it cannot operate or
> condone a repository that has or allows license violations.
Sure. I don't think anyone was suggesting that such a repository be 
created.

> The ASF is primarily concerned with the original, authoritative 
distribution
> of its code. For proper authenticity, security, mirroring, etc, that
> distribution has a set of requirements and policy which has been defined 
by
> the infrastructure team.
The current 'distributions' are mainly in zipped source or binary form, 
right? 
Is there a precedent for non-zipped binaries?

> Beyond the original distribution, then it's all gravy. What facilities 
do we
> want to provide our users and downstream developers? How can we simplify
> their lives? Ted points out that it is reasonable to state that the ASF 
is
> creating problems (classpath and whatnot), so maybe you could even say 
we
> "must" create a repos simply as a way to help recover from the mess that 
we
> have made.  *shrug*
> 
> 
> It does seem like people are narrowing in on some proposals, designs, 
etc. I
> might suggest it is about time to Wiki-ize the current thoughts so that 
you
> have something concrete to reference in further mailing list discussion. 
And
> to iterate on or to provide some alternatives.
Sounds like a plan.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository (was: primary distribution location)

2003-02-27 Thread dion
Ben Hyde <[EMAIL PROTECTED]> wrote on 28/02/2003 01:46:43 AM:

> [EMAIL PROTECTED] wrote:
> > You know that ASF jars aren't 'freely' distributable, right? The 
> > license
> > specifies some conditions on binary distribution.
> 
[snip good stuff]
> Are you arguing that the ASF should stop striving to keep licenses 
> compatible?

No. Where did you get that idea?
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Scrambling jar files?

2003-02-28 Thread dion
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote on 28/02/2003 11:06:51 AM:

> I just ran into this and found that might be worth injecting into the 
> jar repositories discussions.
> 
>  http://nbbuild.netbeans.org/scrambler.html

That one is listed up @ 
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Scrambling jar files?

2003-02-28 Thread dion
FWIW,

Maven has been following up with Sun on a click-through approach to 
allowing BCL code to be distributed. Geir is the man on the ground for us.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


"Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 28/02/2003 12:06:04 PM:

> > I just ran into this and found that might be worth injecting into the
> > jar repositories discussions.
> >  http://nbbuild.netbeans.org/scrambler.html
> 
> Yes.  That is what I was referring to when I mentioned click-through
> licenses on netbeans.org, and Costin seems to be aware of it as well.
> 
>--- Noel
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Maven and community

2003-02-28 Thread dion








-"Noel J. Bergman" <[EMAIL PROTECTED]> wrote: -
> Dion,

> > > The reason for this challenge is simple: to
> > > demonstrate the the antipathy towards other
> > > ASF efforts is damaging not only to the ASF,
> > > but to Maven itself.

> > 'antipathy' == 'A strong feeling of aversion or repugnance'.

> However you want to label it, Jason's harshly phrased statements
yesterday
> regarding collaboration with other ASF projects (and people) expressed an
> attitude that some people, including myself, obviously didn't view
> positively.  In fairness, my reaction is influenced as much by my views
on
> software development as by his words.  Nor did I miss his somewhat
contrite
> reply to Ken Coar.  I would hope that his comments are not representative
of
> Maven.  I would prefer to believe that his comments are not even
> representative of himself.

You don't like Jason's attitude, fine, take that up with Jason. Personality
conflicts are
a natural part of life. Representing Jason as all Maven developers is a
leap beyond that
I can't fathom.

[snip]
> A development tool exists for the purpose of servicing other projects.  I
> viewed Sam's comments as expressing the concern that if personalities
were
> to get in the way of collaborating to produce something that better
serves
> other projects, then that would be damaging.  With Ant, the ASF set the
So if/when it happens I expect people to get involved. Preempting it seems
a little premature.

> standard (for better or worse) for Java build tools.  With Maven, that is
> extended, enhanced, embedded to handle web-based project management.  You
> said that there is a great deal of synergy between Ant and Maven.  It is
> natural to feel that these are related projects, and that collaboration
> would not only be beneficial, but highly desired by all parties.  The
Collaboration does happen, now. It's not a future waiting to happen.
Is there something that's not happening that specifically needs to be
looked
at?

> antagonistic response, with neither provocation nor justification, was
> disconcerting to say the least.  It is unsurprising then to have concerns
> regarding a productive relationship with an entity exhibiting that
attitude.

Jason is an 'entity'? I figured he was a person with all the usual good and
bad
points, much like you and I.

It seems you are confusing your view of Jason, which you admit is limited
to a short exchange here, with the team of people developing Maven. I've
worked
with Jason for quite a while now and he speaks his mind, and when he's
wrong,
he's the first to admit it.

If you're interested in the Maven community and what it is, please join us
on turbine-maven-user@jakarta.apache.org and
turbine-maven-dev@jakarta.apache.org

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository

2003-03-01 Thread dion
As an aside, one of the issues we had when coming up with Maven's repository format, is that often artifacts (jars, wars, ears etc), willget left on the filesystem outside of a repository.  Think rpms for example. Having a file encode --.type has been very useful for us. Yes, it's often different from what the project creates and distributes, but I (and others) have been bitten bycommons-logging.jar, struts.jar, junit.jar so many times, that seeing log4j-1.2.5.jar is a godsend.--dIon Gillard, Multitask ConsultingBlog:  http://www.freeroller.net/page/dion/WeblogWork:  http://www.multitask.com.au-Nick Chalko <[EMAIL PROTECTED]> wrote: -To: community@apache.orgFrom: Nick Chalko <[EMAIL PROTECTED]>Date: 03/01/2003 06:54AMSubject: Re: [proposal] daedalus jar repositoryNoel J. Bergman wrote:>Nick,>>As long as you want to start with first principles ...>>  >>>project/[subproject]/version/(jar|zip|gz|docs|liscenses)>>is very good.>>>>>>How much should be encoded in a URI, and how much in data associated with>the URI?  You seem to be trying to encode all of the data into the URI>naming space.  Why not have a single URI for the target, and then trigger>behavior based upon the content?  That would seem more extensible and less>fragile.>  >>This would also unify with Costin's thoughts regarding tool-neutral>standards for the repository and project descriptors.  The URI tells the>repository what you want, and it responds with the information known about>it, such as the locations of its parts, dependency information, build>instructions, etc.  The URI could encode optional filter information about>what we want in the response.  Depending upon whether the resource were>dynamic or static, the filter might or might not be honored.>>Seems to me that some of the prior art associated with JNLP should be>brought into the picture, as well as everything that Maven has learned about>repositories.  And REST in terms of the web interaction.>  >>Also, shouldn't URIs also support movement of the resource, e.g., when a>sub-project moves from underneath a project?  For that matter, is the>project hierarchy really useful in the URI, or just a unique name?>  >>Thoughts?>  >Your approach seems very powerfull,  I like it.I was trying for a  "Valid" repositry being just a filesystem.   I think we can add the rest later as optionl support elements.A filesystem only approach lets other people build "compatible" repositories without tools or keeping a catalog.xml or whatever uptodate.>	--- Noel>>>->To unsubscribe, e-mail: [EMAIL PROTECTED]>For additional commands, e-mail: [EMAIL PROTECTED]>  >-- Nick Chalko Show me the code.  Centipede  Ant + autodownloadable build plugins + needed jars autodownload.  http://krysalis.org/centipede--To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]

Re: ASF repository URI syntax

2003-03-01 Thread dion
Nick, can you explain why there is a need for a subproject and not a sub-subproject etc?--dIon Gillard, Multitask ConsultingBlog:  http://www.freeroller.net/page/dion/WeblogWork:  http://www.multitask.com.au-Nick Chalko <[EMAIL PROTECTED]> wrote: -To: community@apache.orgFrom: Nick Chalko <[EMAIL PROTECTED]>Date: 03/01/2003 09:38AMSubject: ASF repository URI syntaxI think in general  ./ or  ./index.html should return a human readable form and ./index.xml should give machine readable form of the following* /  o list of projects in the repository* /project  o list of subprojects  o  list of versions available if there is no subprojects* /project/[subproject]/  o list of versions available* /project/[subproject]/version/  o list of artifacts available.* /project/[subproject]/version/artifact.  o downloads the actual artifact.I think this a reasonable base set that support both a simple   filesystem or an smart server.These are just ideas to get the discussion of the protocol started.Comments.R,Nick-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]

RE: ASF repository URI syntax

2003-03-02 Thread dion






Yes. Stable URIs are a must.

Hence the subproject piece of the directory structure was left out of
the maven repository and we went with  only.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au



-"Noel J. Bergman" <[EMAIL PROTECTED]> wrote: -

To: 
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
Date: 03/02/2003 09:05AM
Subject: RE: ASF repository URI syntax

> i think that maybe organization / project would be better that
> /project/[subproject/..].

More stable, less fragile.  Still provides for qualified the naming space,
and is more in keeping with how we've been doing package naming.

I don't know if it needs to be a directory hierarchy, though.  The naming
separator could be anything.

--- Noel


-
 To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository (was: primary distribution location)

2003-03-02 Thread dion
Nick Chalko <[EMAIL PROTECTED]> wrote on 01/03/2003 05:09:50 AM:

> A somewhat standard layout is the important part.
> 
> If we are changing current practice  I think
> 
> project/[subproject]/version/(jar|zip|gz|docs|liscenses)
> is very good.

Sub project is, IMHO, way too fragile to be part of the URI. This is why 
we left it out of maven. Same for cvs name.

Projects often move 'up' and change their cvs repo.

> All kinds of artifacts for a particular version in one dir.  Seems the 
> easiest to me.
My personal preference is to have the version in the artifact name for use 
later on.

This is, I know, an unpopular view, but one that has saved many people 
time in the long run.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Maven and community

2003-03-02 Thread dion
Hey Costin, tell me if I'm reading this right:

Costin Manolache <[EMAIL PROTECTED]> wrote on 01/03/2003 05:59:56 AM:

> On Fri, 28 Feb 2003, Noel J. Bergman wrote:
> 
> > > Collaboration does happen, now.  It's not a future waiting to 
happen.
> > > Is there something that's not happening that specifically needs to 
be
> > > looked at?
> > 
> > That's the irony.  As far as I can see, most of the build processes 
could
> > converge around Ant and Maven.  It isn't hard to see how the domains 
served
> > by Gump and Centipede could be subsumed by Ant and Maven, given the
> > additional development that you've told me is already happening.  The
> > thought behind my earlier question about the PMC, which initiated this
> > spiral, was that having Ant and Maven under a PMC would help that 
effort.
> 
> I tried to stay out of this discussion. 
> 
> The points that I care about is where Maven tries to set a standard 
> that will affect the other build tools. The repository is one example,
> the descriptors is the other. 
> 
> If the apache community can reach an agreement on base standards - 
> with the participation of all projects and people who are involved or 
> care about the build process - then we're fine. And it is even better
> if we have multiple tools to support the repo and descriptors and try 
> to make the build process easy.

If one project sets a 'standard' that's a bad thing. If we design by 
committee, that's ok.

> I am worried that Maven will use agressive propaganda and the ASF brand
> to compete against Ant. All I've seen so far suggest that. And I think 
> that would be bad. However - agressive propaganda has a tendency to 
> backfire, and smart people usually see beyond it.

So what is there to worry about? If Maven hypes itself and then falls 
short of expectations, what the heck, it looks like it's only hurt itself.

> I'm talking about all the "landslide move", "all others are crap", 
> "convert all your projects to maven", the removal of ant build files in
> projects to force people to use maven, attacks to persons who are 
> involved with competing projects, etc ( I know that people learned that
> some of those tactics don't work well - and I'm sure I'll see more ) 

The fact that Maven generates ant build files for use without Maven 
doesn't help any?

> One problem may be that this kind of propaganda may hurt the 
> ASF brand and all projects involved - competition on "easy to use"
> or features or speed is good in itself. 

If people start hype'ing Maven to the detriment of the ASF, I'm sure 
someone will step in.

FWIW, most of the Maven developers don't want to push Maven onto other 
developers, and we've actively stayed out of the 'Please give us a 
proposal as to why we should adopt Maven' discussions. People will either 
want it or not.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [proposal] daedalus jar repository (was: primary distribution location)

2003-03-02 Thread dion
"Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 01/03/2003 06:45:42 AM:

[snip]
> How much should be encoded in a URI, and how much in data associated 
with
> the URI?  You seem to be trying to encode all of the data into the URI
> naming space.  Why not have a single URI for the target, and then 
trigger
> behavior based upon the content?  That would seem more extensible and 
less
> fragile.
It would also seem to rule out any consistency of naming across projects, 
and make the user browsing of a repository a logistical nightmare.

> This would also unify with Costin's thoughts regarding tool-neutral
> standards for the repository and project descriptors.  The URI tells the
> repository what you want, and it responds with the information known 
about
> it, such as the locations of its parts, dependency information, build
> instructions, etc.  The URI could encode optional filter information 
about
> what we want in the response.  Depending upon whether the resource were
> dynamic or static, the filter might or might not be honored.
Sounds like that rules out the simple filesystem mirroring that works so 
well everywhere.

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository

2003-03-02 Thread dion
Costin Manolache <[EMAIL PROTECTED]> wrote on 02/03/2003 03:12:55 AM:

> On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote:
> 
> > Having a file encode --.type has been 
> very useful for us.
> >  
> > Yes, it's often different from what the project creates and 
> distributes, but I (and others)
> > have been bitten by
> > commons-logging.jar, struts.jar, junit.jar so many times, that 
> seeing log4j-1.2.5.jar is a
> > godsend.
> 
> Yes, but I already mentioned that it can easily break features that 
work: 
> if a project uses Classpath attributes in the manifest ( a legal option 
> that simplifies setup - you may like it or not ) - then some things will 

> stop working.
Having a versioned copy of the jar file around doesn't break anything that 
already exists.

No-one is saying that people should remove their old stuff.

> It will also break any script or program that creates classpaths by 
using
> jar names. 
As will changing the directory it's in, the file extension etc.

> And it will break the explicit CLASSPATH env variables and manifest 
> attributes once again every time you upgrade - since the jar name will 
> change. 
You mean people still specify CLASSPATH env variables. Yick.
But, again, if you 'upgrade' you don't have to remove the old files.

> It'll also break Ant build files that use the jar name - just do a grep 
> on jakarta and you'll find how many they are.
And many of those are the ones people can't be bothered setting up. Most 
of commons for example is a PITA to build.
I tried recently to quickly get commons-modeler going for a Tomcat 
connector, and it was a joke. Try building struts from source, the setup 
is a bitch.

> All those problems can only be solved with the active participation
> of the projects - by implementing whatever code is needed to support
> filenames that change. For Classpath attributes - that's not possible,
> so project will have to agree to stop using this (nice IMO ) feature.
Not necessarily. If the manifest is built by a tool, it can automatically 
place the correct names in the classpath entry for you.

> It doesn't matter how nice the versioned filename may look or 
> how much it can simplify maven code - if it breaks the code of the 
Costin, I'm not speaking about maven code here. In fact, I'm not talking 
about any code at all.

> project ( sometimes in subtle ways - if ant or a project won't find a 
jar, 
> it may disable a feature )
> 
> It is also redundant information - each jar has a well-defined Manifest 
> that should include version. 
Really. Go read all the manifests on www.ibiblio.org/maven/*.jar and tell 
me how many:
a) Have a valid manifest
b) Have a license in the jar
c) Have code from other projects contained within

Believe me, the actual jars that are distributed by most projects do not 
come packaged ready for binary distribution. Take for example 
commons-logging 1.0.2 and the manifest in it's jar, which has:

Class-Path: log4j.jar log4j-core.jar

in it.

> .so files are versioned - that would be the perfect argument to convince 

> people to adopt this naming scheme. But think what happens if someone
> takes a .so file that was shiped with an application, and renames it to
> something he feels is nicer. The app will just stop working. You can't 
> mess with a project distribution files without the risk of breaking 
> something. 

Nor should you just 'mess with a project distribution files' and expect 
things to still work.

> Many people like this naming convention - but they can't impose it
> to everyone. I'm more then willing to accept and support this naming 
Call your jars what you like. Noone is 'imposing' it on you.

> scheme - my only condition is to be the result of an informed decision 
> by the apache developer community. ( the breakages are just 2 simple
> examples - there are many other arguments in both sides )
> 
> BTW - an important thing to keep in mind is that in many cases the
> latest version of a .jar may fix security bugs - so it shouldn't
> just pick the buggy jar. Having multiple versions of the same 
What are you talking about here? What 'shouldn't just pick the buggy jar'? 
If something goes about picking new versions of jars, that I've gone to 
the trouble to specify,  I'm going to be very upset. If I've asked for 
'the latest', fair enough.

> jar in a system creates huge problems.
Having multiple versions of the same jar in many 'systems' is not an 
issue. Classloader isolation exists for a reason. Imagine a servlet engine 
where you can only have one copy of struts.jar.

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [proposal] daedalus jar repository

2003-03-02 Thread dion
"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote on 02/03/2003 05:36:38 
AM:

[snip]
> I've gotten bit by the opposite problem (changing version number in a 
JAR
> filename causing broken build scripts) just as often.
> 
> Wouldn't a reasonable approach to this problem be to make searches for
> "commons-foo.jar" return the latest released version, while searches for
> "commons-foo-x.y.jar" would return that particular version?  Then, you 
can
> have it either way.  On the former, one might also support a mode that
> grabs the latest nightly instead of the latest reslease.
Maven has the concept of a 'SNAPSHOT' jar, which is the latest 
date-timestamped version of an artifact available.

If tell Maven you depend on a SNAPSHOT, at each build it checks to make 
sure you have the latest available, and downloads the new one if needed.

This however doesn't fix the problem, as people can change version numbers 
on jars to anything they want, possibly a fictitious release.

'LATEST' builds are often not reproducible as well.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: ASF repository URI syntax

2003-03-02 Thread dion
Nick Chalko <[EMAIL PROTECTED]> wrote on 02/03/2003 05:56:32 AM:

> [EMAIL PROTECTED] wrote:
> 
> > Nick,
> > 
> > can you explain why there is a need for a subproject and not a 
> > sub-subproject etc?
> 
> Good question. 
> 
> This also releates to "what is a project" .  Jakarta , avalon,  turbine. 

>  poi, poi-contrib. 
> On the one hand we could allow  unlimited subprojects.   specify that 
> projects must start with a letter, and version must start with a number.
> 
> Or the other aproach is only one level of projects then you have
> jakarta-avalon-fulcrum.
> 
> This is a namespace problem, how do we avoid naming collitions at Apache
>  I suppose we could say that  a  "project"="cvs module" 
In the interest of a URI that's not going to change too much, cvs module 
is as fragile as subproject in my experience, and whilst a good idea, 
still leaves the URI too fragile for my liking.

> My preference would be for /project/[subproject/..]/version/artifact.
Version being in the directory I've already mentioned.

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: anyone know the progress of the Maven top level proposal?

2003-03-05 Thread dion





I posted to [EMAIL PROTECTED] yesterday asking about the updated scope but
have yet to hear a reply.

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au



-Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: -

To: community@apache.org
From: Rodent of Unusual Size <[EMAIL PROTECTED]>
Date: 03/06/2003 05:23AM
Subject: Re: anyone know the progress of the Maven top level proposal?

James Strachan wrote:
> Just wondered if anyone knew the boards latest view of the 'Maven as top
> level project' proposal? Its been a bit quiet lately - have I missed
> anything?

afaik, jason, dIon, and the board are refining the charter.  i think
that's the only thing.
--
#ken P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millennium hand and shrimp!"


-
 To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: open software for testing

2003-03-29 Thread dion
For webapps, we have a combo used in Maven of:

a) JMeter ( http://jakarta.apache.org/jmeter/ )
and
b) Latka ( http://jakarta.apache.org/commons/latka )

- Using JMeter's proxy server you can record a web 'session' .
- The Maven Latka plugin can then convert the JMeter output to a latka 
test case
- The Maven Latka plugin can the run those generated test cases.

See http://maven.apache.org/reference/plugins/latka/ for more detail.
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


Apache Software Foundation <[EMAIL PROTECTED]> wrote on 30/03/2003 
12:30:50 AM:

> acked; anyone in apache-land know of anything of ours, or
> anyone elses', that does this sort of thing?  maybe the
> CPAN Test::* modules?  please respond to the original author
> with a bcc to community@ so we can all learn..
> -- 
> The Apache Software Foundation
> 
> If you have not looked at http://www.apache.org/foundation/preFAQ.html
> PLEASE DO SO NOW.  There's an excellent chance your question/concern
> is addressed therein.  If your question concerns licensing, please see
> http://www.apache.org/foundation/licence-FAQ.html
> 
> - Message from Kenzo Saito <[EMAIL PROTECTED]> on Mon, 24 
> Mar 2003 17:39:02 -0500 -
> 
> To:
> 
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> 
> Hi,
> 
> I'm not sure if you are able to answer my question or not (I hope you 
are
> though). I work for a software company in Toronto and I am currently 
trying
> to investigate if the exists any sort of open source programs that do
> automated testing. Previously we have been using a program called
> TestPartner from NuMega. It basically allowed us to test out our GUI, by
> recording and playing back scripts. It also allowed us to edit the 
scripts
> using VB for Applications. Since you guys at Apache are experts in the 
open
> source community, I was wondering if you knew of any open source program
> that perform automated testing? Any information would be extremely 
useful. 
> 
> Thanks,
> Kenzo
> 
> Gregory Kenzo Saito, Product Development Co-op
> Cast Software, 35 Ripley Avenue, Unit 1
> Toronto, Ontario Canada M6S 3P2 
> Tel: (416) 597 2278 x254   Fax: (416) 597-9594 
> [EMAIL PROTECTED], http://www.cast-soft.com
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Follow the example

2003-09-18 Thread dion
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 18/09/2003 11:55:43 PM:
> Everyone would agree that spreading the good word on ApacheCon US 2003
> will contribute significantly to its success.
> 
> Some projects have begun to do just that. See for example,
> 
>http://www.apache.org
>http://jakarta.apache.org
>http://jakarta.apache.org/tomcat/index.html
> 
> Thus, I urge all ASF projects (and subprojects) follow their example
> and add a prominent icon to their project pages. Please do not wait
> until the conference starts. We really need to properly market
> ApacheCon US 2003. As an important source of revenue for the
> foundation, the success of AC 2003 matters to us all.
> 
> As far as I can tell, the following projects have *not* updated their
> web pages.
> 
>Ant
>Apr
>Avalon
>Cocoon
>DB
>Incubator
>James
>Maven
>mod_perl
>PHP
>TCL
>Web Services
>XML
> 
> What can be done to fix this? Many thanks in advance,

There's no coverage on some of the top level projects you mention, e.g. no 
sessions on Ant, Avalon, James & Maven.


--
dIon Gillard, Multitask Consulting
Blog:  http://blogs.codehaus.org/people/dion/




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: EarthQuake near Sumatra

2004-12-27 Thread Dion Gillard
Has anyone heard from dims?
-- 
http://www.multitask.com.au/people/dion/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]