Re: Maven Repository Status

[Jason van Zyl]

On Fri, 2004-04-23 at 10:37, Mark R. Diggory wrote:
> I just wanted to drop everyone a note to let you know that I made the 
> rsync of the java-repository between Apache and Ibiblio much more stable 
> this week. It now occurs every 4 hours (EST 12am, 4am, 8am ...). If you 
> ever encounter issues with your jars not getting synced into ibiblio, 
> please contact me.

Awesome! Thanks very much for seeing this through from beginning to end,
it definitely makes admin much easier. In addition the artifacts are now
distributed in a fashion in accordance with what the board originally
requested. Kudos! Everyone should be happy all around.

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

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 


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

RE: so many jars

[Jason van Zyl]

On Fri, 2003-03-14 at 18:17, Dominique Devienne wrote:
> Could you please provide a link where to start looking to try to understand
> how you are doing it? Like maybe a ViewCVS link? Thanks, --DD

Right now we use three approaches we have a WerkzResolver for
short-lived graphs which we use for the CLI and a resolver based on the
graph package in the commons-sandbox which will be used for long-lived
graphs:

http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/java/org/apache/maven/jelly/tags/maven/

What's in the Plexus plugin is just brute-force walking through POMs. I
will eventually incorporate the use of the commons-graph package.


> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 14, 2003 5:08 PM
> To: Jakarta General List
> Subject: RE: so many jars
> 
> On Fri, 2003-03-14 at 18:07, Dominique Devienne wrote:
> > Why can't the POM be stored in the artifact itself? 
> 
> That certainly can be done and has been suggested, but the POM can be
> uesd for so many other things. It's certainly one of the routes we could
> go.
> 
> > Assuming most Maven
> > projects generate JAR artifacts, couldn't you store the POM in the JAR,
> like
> > in META-INF/maven/project.xml, and then use that info at runtime? Seems
> like
> > all you would need is some bootstrap class (a modified forehead?) that
> knows
> > where to find JAR artifacts (the runtime equivalent to the current
> > maven.repository); When requested to start a main class from a given JAR,
> it
> > would read the POM from the JAR, and start looking up the necessary
> runtime
> > JARs dependencies (declared in the POM) in the repository(ies). If these
> JAR
> > dependencies in turn also contain their own POM, you can fully resolve the
> > dependencies (transitive closure).
> > 
> > Or am I completely in left field? --DD
> 
> Nope, that's what I'm doing to create avalon runtimes.
> 
> > -Original Message-
> > From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
> > Sent: Friday, March 14, 2003 4:53 PM
> > To: Jakarta General List
> > Subject: RE: so many jars
> > 
> > On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote:
> > > On Fri, 2003-03-14 at 11:14, Henri Yandell wrote:
> > > > at compile-time maybe :)
> > > > 
> > > > But you still end up with jar duplication, you just get to avoid
> having
> > to
> > > > think about it too much when compiling.
> > > > 
> > > 
> > > I agree that maven has an excellent jar dependency solution for
> > > compile-time, but I don't think there exists any (standard) solution for
> > > run-time dependencies in java.  
> > 
> > This is technically not a hard problem. For maven it's more an
> > admistrative problem. Eventually only the compile time needs will be
> > required in the Maven POM but in order to find the runtime dependencies
> > you need all the POMs of the compile time dependencies of the target
> > project. And there exist most of the POMs to do this it's just creating
> > a mechanism where the POMs are stored safely, sync'd properly and a
> > mechanism for retrieving them.
> > 
> > There are glimpses of this already in some of the maven plugins where a
> > single POM is used as the target and then all dependencies are traced
> > and gathered. I'm doing this to produce avalon runtimes with great
> > success and the method will eventually make it's way into Maven proper
> > after more field testing. 
> > 
> > > Using a system level $CLASSPATH variable
> > > becomes painful (as was mentioned).  The general solution seems to be a
> > > hierarchal set of /lib directories.  
> > > 
> > > To have a true run-time jar dependency solution you would need a
> > > standard installation and launch mechanism.  I suppose something based
> > > on JNLP (WebStart) plus some sort of "ports" or "emerge" system could do
> > > this, but I don't think it exists yet.  Interesting idea though. 
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

RE: so many jars

[Jason van Zyl]

On Fri, 2003-03-14 at 18:07, Dominique Devienne wrote:
> Why can't the POM be stored in the artifact itself? 

That certainly can be done and has been suggested, but the POM can be
uesd for so many other things. It's certainly one of the routes we could
go.

> Assuming most Maven
> projects generate JAR artifacts, couldn't you store the POM in the JAR, like
> in META-INF/maven/project.xml, and then use that info at runtime? Seems like
> all you would need is some bootstrap class (a modified forehead?) that knows
> where to find JAR artifacts (the runtime equivalent to the current
> maven.repository); When requested to start a main class from a given JAR, it
> would read the POM from the JAR, and start looking up the necessary runtime
> JARs dependencies (declared in the POM) in the repository(ies). If these JAR
> dependencies in turn also contain their own POM, you can fully resolve the
> dependencies (transitive closure).
> 
> Or am I completely in left field? --DD

Nope, that's what I'm doing to create avalon runtimes.

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 14, 2003 4:53 PM
> To: Jakarta General List
> Subject: RE: so many jars
> 
> On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote:
> > On Fri, 2003-03-14 at 11:14, Henri Yandell wrote:
> > > at compile-time maybe :)
> > > 
> > > But you still end up with jar duplication, you just get to avoid having
> to
> > > think about it too much when compiling.
> > > 
> > 
> > I agree that maven has an excellent jar dependency solution for
> > compile-time, but I don't think there exists any (standard) solution for
> > run-time dependencies in java.  
> 
> This is technically not a hard problem. For maven it's more an
> admistrative problem. Eventually only the compile time needs will be
> required in the Maven POM but in order to find the runtime dependencies
> you need all the POMs of the compile time dependencies of the target
> project. And there exist most of the POMs to do this it's just creating
> a mechanism where the POMs are stored safely, sync'd properly and a
> mechanism for retrieving them.
> 
> There are glimpses of this already in some of the maven plugins where a
> single POM is used as the target and then all dependencies are traced
> and gathered. I'm doing this to produce avalon runtimes with great
> success and the method will eventually make it's way into Maven proper
> after more field testing. 
> 
> > Using a system level $CLASSPATH variable
> > becomes painful (as was mentioned).  The general solution seems to be a
> > hierarchal set of /lib directories.  
> > 
> > To have a true run-time jar dependency solution you would need a
> > standard installation and launch mechanism.  I suppose something based
> > on JNLP (WebStart) plus some sort of "ports" or "emerge" system could do
> > this, but I don't think it exists yet.  Interesting idea though. 
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

RE: so many jars

[Jason van Zyl]

On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote:
> On Fri, 2003-03-14 at 11:14, Henri Yandell wrote:
> > at compile-time maybe :)
> > 
> > But you still end up with jar duplication, you just get to avoid having to
> > think about it too much when compiling.
> > 
> 
> I agree that maven has an excellent jar dependency solution for
> compile-time, but I don't think there exists any (standard) solution for
> run-time dependencies in java.  

This is technically not a hard problem. For maven it's more an
admistrative problem. Eventually only the compile time needs will be
required in the Maven POM but in order to find the runtime dependencies
you need all the POMs of the compile time dependencies of the target
project. And there exist most of the POMs to do this it's just creating
a mechanism where the POMs are stored safely, sync'd properly and a
mechanism for retrieving them.

There are glimpses of this already in some of the maven plugins where a
single POM is used as the target and then all dependencies are traced
and gathered. I'm doing this to produce avalon runtimes with great
success and the method will eventually make it's way into Maven proper
after more field testing. 

> Using a system level $CLASSPATH variable
> becomes painful (as was mentioned).  The general solution seems to be a
> hierarchal set of /lib directories.  
> 
> To have a true run-time jar dependency solution you would need a
> standard installation and launch mechanism.  I suppose something based
> on JNLP (WebStart) plus some sort of "ports" or "emerge" system could do
> this, but I don't think it exists yet.  Interesting idea though. 
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Current roster of the Jakarta PMC

[Jason van Zyl]

On Mon, 2003-03-03 at 18:33, Nick Chalko wrote:
> Jason van Zyl wrote:
> 
> >On Sun, 2003-03-02 at 05:12, Sam Ruby wrote:
> >  
> >
> >>
> >>
> >>
> >
> >I ask because I have an essay to present and I would like to run for the
> >chair position as I feel it's time for some changes around here.
> >  
> >
> 
> Jason,
> In light of your comments in 
> http://marc.theaimsgroup.com/?l=jakarta-general&m=104448400328715&w=2
> can you, if you become the Jakarta PMC chair, collaborate with Nicola 
> Ken Barozzi.

I'm sure I could find a way but it's not likely that I will ever be the
chair of Jakarta.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Current roster of the Jakarta PMC

[Jason van Zyl]

On Sun, 2003-03-02 at 05:12, Sam Ruby wrote:
> Pete Kazmier wrote:
> > I believe you have omitted an individual from this list.  Jason Van
> > Zyl was included among the nominated that passed the nomination vote:
> > 
> > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=14489
> 
> OUCH!
> 
> I stand corrected.  Thanks Pete.
> 
> When updating the official list (in the committers repository, directory 
>   board/committee-info.txt), it occurred to me that a three column 
> format might be easier to read, so I wrote a little script. 
> Unfortunately, a roundoff error made *two* people not appear on the list 
> as 35 is not evenly divisible by three).
> 
> Sorry Rob Oxspring and Jason van Zyl.
> 

Also, how is the chair position being selected now? By peer PMC members
or by the entire body of Jakarta committers?

I ask because I have an essay to present and I would like to run for the
chair position as I feel it's time for some changes around here.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: [Fwd: Maven as a top-level apache project]

[Jason van Zyl]

On Fri, 2003-02-07 at 12:50, Rodent of Unusual Size wrote:
> Jason van Zyl wrote:
> > 
> > The second I feel that the environment here at Apache has eroded to
> > the point where this is not possible I will not hesitate to propose 
> > movement of the code to an environment conducive to the production of
> > outstanding software. I believe the environment here has the
> > potential of becoming seriously eroded by recent policies of heavy
> > handed top-down control and the philosophical visions of a few being
> > forced on to the entire committer base.
> 
> whoa, hang on there, tex!  as potentially one of those top-down
> heavy handers, i'd like a bit of clarification on that last
> sentence.  

The projects are no longer allowed to determine which external projects
they wish to bring into the fold. I brought OJB, BCEL, XmlRpc and
various other bits and pieces here to Apache without having to go
through an incubation process. That projects are no longer autonomous is
what I don't really like.

> i'd like to make sure that the term 'philosophical
> visions' isn't being mistakenly applied to things motivated by
> legally-required oversight.  

Not at all. I take the blame for violating the licenses and I never
intended to cause the ASF any harm by the inclusion of various JARs in
the repository. I was fully willing to take the brunt of any
repercussions as I was fully expecting them from Sun. I didn't know that
the ASF would be liable and I have no problem respecting what we talked
about on the phone.

What I'm referring to by philosophical vision is Sam's notion of opening
up everything to everybody and trying to create one big community. I'm
not interested in that and don't want to be forced into that practice.
In Maven for example there is no way on earth I would be comfortable
opening up the committer pool to anyone. Sam feels differently and is
willing to open up the committer pool on Gump to anyone. If he wants to
do that great but I don't and neither do any of the other Maven
committers. The same goes with the jakarta commons. I don't think it is
that much of a burden to request access to a project from the people who
have made it come into being. I don't know how the apache commons
project works but I'm just not into the free-for-all.

> that is, making sure that apache
> stays legal is part of the board's *job*; it's not a matter of
> philosophy.  and in many cases it isn't negociable; if the entire
> committer base voted unanimously to violate sun's licence, or
> the gpl, it wouldn't make it legal or right and the board would
> rightfully not permit the action to take place -- despite being
> overwhelmingly popular.

I have absolutely no problem with the legal oversight. I assume I had
kept the ASF in the clear and I assume repsonsibility for being
incorrect and am glad you made the call you did.

> so please, can you explain your last sentence in more detail, with
> circles and arrows so i know specifically what you think is heavy-
> handed, whose hands you mean, and what you think is an imposed
> minority philosophy?  maybe you're right and that's all really
> happening.. or maybe there's just another communication glitch.
> email is really good at getting the words across; less so at
> making sure the *meaning* is correctly conveyed. :-)  i want to
> understand so i can respond (or not) correctly.
> 
> thanks!
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: [Fwd: Maven as a top-level apache project]

[Jason van Zyl]

On Fri, 2003-02-07 at 10:40, Jason van Zyl wrote:
> On Fri, 2003-02-07 at 10:18, Sam Ruby wrote:
> > Jason van Zyl wrote:
> > > 
> > >>and can't or won't comply with Apache 
> > >>policies, 
> > > 
> > > I started removing the Sun violations and I just sent you another
> > > message asking you to take on a maven repository admin role. Feel free
> > > to find the violations and remove them with a notification on the
> > > maven-user list. You are more license aware and can remove any problems
> > > faster then any of us can.
> > 
> > I am willing to take on the maven repository admin role on one condition 
> > - every other admin is removed.  In short, I am willing to take on 
> > responsibility for removing piss from the pool if and only if the 
> > sources of this contamination are eliminated first.
> 
> Then Dion will just keep working with you. I'm not removing the other
> Maven admins. I think they're pretty aware of the licensing issues now
> and I take responsibility for the majority of the violations. I'll also
> add something to the admin app to help as well.

In addition I don't think it's very wise having one person be
responsible for the repository. Having people in different timezones
being able to push artifacts up is helpful. As you're as fallible as
anyone else. Maybe you could initiate a sort of moderating mechanism for
pushing up artifacts until the admin app is finished.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: [Fwd: Maven as a top-level apache project]

[Jason van Zyl]

On Fri, 2003-02-07 at 10:18, Sam Ruby wrote:
> Jason van Zyl wrote:
> > 
> >>and can't or won't comply with Apache 
> >>policies, 
> > 
> > I started removing the Sun violations and I just sent you another
> > message asking you to take on a maven repository admin role. Feel free
> > to find the violations and remove them with a notification on the
> > maven-user list. You are more license aware and can remove any problems
> > faster then any of us can.
> 
> I am willing to take on the maven repository admin role on one condition 
> - every other admin is removed.  In short, I am willing to take on 
> responsibility for removing piss from the pool if and only if the 
> sources of this contamination are eliminated first.

Then Dion will just keep working with you. I'm not removing the other
Maven admins. I think they're pretty aware of the licensing issues now
and I take responsibility for the majority of the violations. I'll also
add something to the admin app to help as well.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: [Fwd: Maven as a top-level apache project]

[Jason van Zyl]

On Thu, 2003-02-06 at 22:06, Sam Ruby wrote:
>  
> > It is your responsibility to enforce that policy.  Not maven and not the 
> > ASF's.  When you integrate JAR or any resource into your project you are 
> > doing so delibrately.  You should know where that jar originally comes 
> > from.  If you don't, ask on the developers or user's list.  Someone will 
> > gladly help.  Even better, search google, I'm sure something will turn up.
> > 
> > - Dan Diephouse
> 
> People should have a resonable expectation that building an ASF project 
> should not involve the download of materials in violation of their 
> licenses or the incurring of any additional obligations.  Enforcement of 
> this policy via Maven or simply by peer review of POMs are acceptable 
> way of achieving this goal.

+1

> - Sam Ruby
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: [Fwd: Maven as a top-level apache project]

[Jason van Zyl]

On Thu, 2003-02-06 at 16:45, Sam Ruby wrote:

> Jason, now let me ask you a direct question: 

> if you don't want to work 
> with the Apache infrastructure 

I am first concerned with setting up the infrastructure that Maven
requires in order to satisfy the needs of people building projects. 

L/GPL jars cannot be stored within the Apache infrastructure so right
now there is a mismatch. It would mean that anyone requiring L/GPL jars
would be hosed.

Ted Leung suggested a solution at ApacheCon that could be viable
solution which uses the PORTs methodology where the repository becomes a
set of pointers. This allows the storage of artifcacts anywhere but also
causes another problem for users where one bad pointer, or one bad
connection could fubar everything.

I would prefer to have the entire Maven repository mirrored in its
entirety in several places in the world. Right now ibiblio on its own
does not go down very often but other whole mirrors would be nice.

Ibiblio also doesn't have a problem storing commercial artifacts either.
I want the repository to become a whole repository. I want it primarily
for building projects but I would also like it be a place where people
can find any Java artifacts commercial or otherwise. Ibiblio doesn't
have a problem storing the Clover JAR for example.

So if Apache would let me store L/GPL jars, commercial artifacts and the
whole repository on their infrastructure then I'm all for using the
Apache infrastructure. I assumed this would not be possible but would be
willing to move the repository back to Apache hardware if this is
possible.

The infrastructure policies as far as I thought were incompatible with
the requirements of the Maven repository.

> and can't or won't comply with Apache 
> policies, 

I started removing the Sun violations and I just sent you another
message asking you to take on a maven repository admin role. Feel free
to find the violations and remove them with a notification on the
maven-user list. You are more license aware and can remove any problems
faster then any of us can.

As far as L/GPL jars go that's not something Maven controls. Projects
state their own dependencies and if an Apache project is violating
Apache policies how is that Maven's problem? If it was an Ant build that
used the  task to link in an L/GPL jar is that Ant's problem?
Obviously not.

Maven can help identify license violations but it can't enforce them by
default without some additional checks added by individual projects. I
proposed a license element in the Maven POM so that tools can be made to
help identify problems.

> then why do you want Maven to be an Apache project?

The same reason I wrote Velocity, the same reason I whipped Turbine into
shape for its first release, the same reason I brought BCEL here, the
same reason I brought OJB here, the same reason I helped bring Lucene
here, the same reason I moderate 8 mailing lists, and the same reason I
am a cvs admin. I believe that Apache is a place where some of the best
software in the world can be created and I will put forth as much spare
time and energy as I can do help make good software.

The second I feel that the environment here at Apache has eroded to the
point where this is not possible I will not hesitate to propose movement
of the code to an environment conducive to the production of outstanding
software. I believe the environment here has the potential of becoming
seriously eroded by recent policies of heavy handed top-down control and
the philosophical visions of a few being forced on to the entire
committer base.

> - Sam Ruby
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: [Fwd: Maven as a top-level apache project]

[Jason van Zyl]

On Thu, 2003-02-06 at 15:39, Nicola Ken Barozzi wrote:
> I'm moving this to PMC.
> 
> Jason van Zyl wrote, On 06/02/2003 19.15:
> > On Thu, 2003-02-06 at 12:53, Costin Manolache wrote:
> ...
> > I'm not stopping anyone from participating. Nicola jumps out of nowhere,
> > starts a project that completely replicates what's already been done and
> > I'm supposed to jump for joy and clamour to be a part of?
> 
> You are saying false things.
> 
> Maven started out of Gump. It duplicated Gump, Ant, Alexandria... who is 
> duplicating who?

Gump _never_ used an object model, never. Gump was targeted at overall
control by a small set of people (and it's still that way, no one
outside of Jakarta/XML barely knows what it is) to build sources against
CVS. That's not what Maven was ever targeted at, ever. Maven uses Ant
but Ant has no concept of an object model either. I definitely admit to
not wanting to use the Gump descriptor and that's proven to be a good
thing. If you call Maven a duplicate of a tool that generates 30k line
shell scripts then do as you please.

> I have started the project way before I ever knew of Maven. 

_before I ever knew of Maven_ That's fine. Don't presume to know how
long I've been thinking of Maven before the first line of code landed
anywhere.

> And I also 
> asked to merge efforts, at a point when we were downloading plugins, and 
> Maven didn't even have a single plugin because it haven't even decided 
> to have them.

Give me a break. Again like a pluggable functionality is a radical new
idea. Your plugins are ant build files. So you came out first with a way
to pull in ant build files. Woo hoo! So you're saying we stole your idea
to have pluggable capabilities because you could import and an Ant file.
Again, please spare me the laughable nature of what you're saying.

> All these are in the mailing lists, and in CVS history, as well as 
> comments in public IRC channels on werken, where you and others clearly 
> deride me. This is not what I would expect from Apache members, and 
> certainly it's not what you have gotten from me.

No, we only got from you initially the accusation that we stole your
miraculous ideas. That's where it started and that's why I refuse to
cooperate with you. You act like the Pontiff of Opensource sprouting up
little projects here and there and then when people don't want to
'merge' or 'cooperate' you have little hissy fits. JCharts (or
JFreeCharts or whatever) ring any bells? That you went and started
another graph package because the author of the package didn't want any
part of krysalis. I feel that's what you do with everything, start some
project under the guise of community because no one really wants to work
with you.

> I have worked with all these projects so that we did not duplicate. The 
> *only* project that rejected me was Maven. And rejected me badly.

I don't care what you do or do not do. I didn't want any part of Gump
code, 30k lines shells scripts, a DOM model or a big heap of ant build
files. So yes, I am the one who advocated not working together but I
certainly wasn't the only one who felt like that. 

> > I am not stopping anyone from participating. Nicola once argued to keep
> > JARs in CVS and now all of a sudden it's a fabulous idea not to store
> > the JARs in CVS. What a revelation! 
> 
> In fact Centipede can be easily used by keeping jars in CVS. I still 
> think that in many cases it's a necessity. 

Of course it is. I'm not arguing the fact that this is sometimes
necessary what is that it probably didn't even occur to you (and seemed
like that to me with the mountain of JARs in the krysalis repository at
one point in time) until it was a function of Maven. Of course this is
not a new and radical idea either. I just dislike the up and starting of
a new project. We rejected a merger with your code, we didn't reject
your input or your ideas. You've never been able to distinguish those
two things.

> I haven't changed my mind on 
> this, although I *do* change my mind when I see compelling reasons, as 
> any reasonable person does.
> 
> ...
> > It's not a Maven only repository. We built the whole infrastructure and
> > did _all_ the work but anyone can use it if they so desire. I choose not
> > to participate with certain people and they choose not to pariticipate
> > where every last single stroke of effort has been made to set up the
> > repository. Don't start twisting reality.
> 
> You are the one twisting reality, Jason.
> 
> I have sent you more than a mail privately telling you to partecipate in 
> the discussions on infrastructure about mirroring, so that the Maven 
> rep

Re: [Fwd: Maven as a top-level apache project]

[Jason van Zyl]

On Thu, 2003-02-06 at 14:00, Costin Manolache wrote:
> James Taylor wrote:
> 
> >> Maven is a nice tool - and I wish it good luck wherever it goes.
> >> But if Maven charter will include the creation of a maven-only repository
> >> - I hope at least some board members will vote -1.
> > 
> > Hopefully we can keep these as seperate issues. Maven already has a
> > repository which can be used by any project, but might be considered
> > Maven (the project) only since access for uploading jars is currently
> > restricted. This is the case only because we are still developing the
> > administration application to open the repository up. The repository we
> > have now is neccesary to continue development of maven (the tool), but
> > nobody expects it to be the final solution.
> > 
> > I would hate for this to prevent Maven's promotion to a top level
> > project, which I think is a step in the right direction for the project,
> > even if we still have a way to go, particularly with regard to a common
> > repository.
> 
> I am talking about this in the context of the other discussions on 
> having an apache repository ( and use the apache mirroring system, etc).
> Also in the context of having a common policy on how releases will
> be distributed and structured - to fit well in such a repository. And 
> the set of tools and conventions that are needed to access the repository.
> 
> I agree moving maven to a top level ( apache or jakarta ) is the best step,
> but the common repository must be common to apache, and not maven specific.

I want it to be common for all Java projects not just Apache. The
repository is for _all_ Java projects and the needs of majority of Java
developers outweighs the needs of simply Apache. I think you should take
a little more time and actually ask some questions. I don't think you
really understand what we're trying to do. Everything you outline above
is _exactly_ what we've been trying to do. But now that everyone has
figured out that this is indeed a good idea it's somehow bad that it's
all in the Maven repository? Why?

> ( I know that everyone can use maven repository already )
> 
> 
> BTW, given the license discussions it seems unlikely a solution that
> includes all the jars in the same place will work. So the "repository"
> will be not only a storage for jars, but a set of tools to deal with
> downloading from different locations with different methods ( and mirror
> lists, etc ). Again - I think this part can only be apache-wide.

For God's sake Costin please ask some questions before assuming what
capabilities are in Maven. We have multiple repositories, to deal with
most situations that arise. Kurt also had discussions with Ted about
using a PORTS like system. We've discussed many of these things. Just
because you're getting involved now please don't presume to know what we
have planned or what we have implemented. To toss out the -1, even
though not binding, without much backgroud information is shows heavy
bias. And that's fine, just be honest about it.

> 
> Costin
> 
> 
> 
> 
>  
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: [Fwd: Maven as a top-level apache project]

[Jason van Zyl]

On Thu, 2003-02-06 at 12:53, Costin Manolache wrote:
> Sam Ruby wrote:
> 
> > Those that care to participate, please indicate your interest by posting
> > to the [EMAIL PROTECTED] mailing list.
> 
> It's up to the board members to decide - but as with Nicola's proposal, I'll
> strongly opose ( by not participating :-) a repository/CJAN/etc project that
> is not open to all apache committers ( like gump for example ).

Who said I was stopping anyone from participating in how the Maven
repository is structured, or used or otherwise administered?

I'm not stopping anyone from participating. Nicola jumps out of nowhere,
starts a project that completely replicates what's already been done and
I'm supposed to jump for joy and clamour to be a part of?

I am not stopping anyone from participating. Nicola once argued to keep
JARs in CVS and now all of a sudden it's a fabulous idea not to store
the JARs in CVS. What a revelation! 

The repository is accessible via HTTP, no one is being barred. The
design and structure of the repository is discussed on maven-dev but
that doesn't mean the repository can only be used by Maven to build.
Nicola has already stated they are using the repository.

> Maven is a nice tool - and I wish it good luck wherever it goes. 
> But if Maven charter will include the creation of a maven-only repository -
> I hope at least some board members will vote -1. 

It's not a Maven only repository. We built the whole infrastructure and
did _all_ the work but anyone can use it if they so desire. I choose not
to participate with certain people and they choose not to pariticipate
where every last single stroke of effort has been made to set up the
repository. Don't start twisting reality.

Didn't Nicola say they were already using the Maven repository. What is
stopping anyone from using the repository? It's not like we're using a
client to download the artifacts and blocking non-maven clients.

> Costin
> 
> 
> > 
> > ---- Original Message 
> > Subject: Maven as a top-level apache project
> > Date: 06 Feb 2003 12:20:32 -0500
> > From: Jason van Zyl <[EMAIL PROTECTED]>
> > Reply-To: "Turbine Maven Developers List"
> > <[EMAIL PROTECTED]>
> > Organization: Zenplex
> > Newsgroups: gmane.comp.jakarta.turbine.maven.devel
> > 
> > Hi,
> > 
> > As I've just gone through the process of getting db.apache.org of the
> > ground I would now like to attempt to do the same for Maven. A top-level
> > project could house Maven and ancillary tools like Continuum and an SCM
> > package and various IDE integration that are popping up.
> > 
> > I can easily mock up a site as I'll just borrow the tools I made for
> > db.apache.org.
> > 
> > There is a board meeting in two weeks so if the developers are in
> > agreement we'll try and go straight to the top.
> > 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Proposal

[Jason van Zyl]

On Wed, 2003-02-05 at 17:26, Jason van Zyl wrote:
> On Wed, 2003-02-05 at 16:08, Andrew C. Oliver wrote:
> > Jason,
> > 
> > Can you please add your name to this as a committer and/or a sponsoring 
> > member: http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
> > Also other maven folks? 
> > 
> > I value your previous experience and existing source code.
> 
> Can't do it. I will never collaborate on anything with Nicola Ken
> Barozzi. And if I have to say it in public I will. I would probably
> participate in anything but not with him.

Ah damn, when it rains it pours. The old man is in a coma, I haven't
slept in days and I can't read reply-to headers. That was not meant for
public consumption.

> > -Andy
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Proposal

[Jason van Zyl]

On Wed, 2003-02-05 at 16:08, Andrew C. Oliver wrote:
> Jason,
> 
> Can you please add your name to this as a committer and/or a sponsoring 
> member: http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
> Also other maven folks? 
> 
> I value your previous experience and existing source code.

Can't do it. I will never collaborate on anything with Nicola Ken
Barozzi. And if I have to say it in public I will. I would probably
participate in anything but not with him.

> -Andy
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: [Proposal] Jakarta Ruper

[Jason van Zyl]

On Wed, 2003-02-05 at 15:38, Nicola Ken Barozzi wrote:
> http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
> 
> I've set up a proposal about a Jakarta project for a Repository Project 
> on the wiki. Below is the current content.
> 
> Maven developers are invited to partecipate in the effort :-)

Great, so you're inviting us to develop something we've already thought
about intensely and implemented. Do you ever wonder why we as Maven
developers have never felt compelled to work with you?


-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Clear the air Re: ATTN: Maven developers [was: primarydistribution location]

[Jason van Zyl]

On Wed, 2003-02-05 at 14:50, Ted Leung wrote:
> I'd like to see this broken out of Maven / Centipede whatever, and put into
> libraries that can be used independent of the build tools.
> 
> I also think that we need to plan for multiple repositories, whether they be
> ASF, ibiblio, what have you.

That's dealt with in Maven.

> There are two ideas going on in this thread.  One is about the mechanism --
> the repository, version management, dependency tracing, resource retreival
> etc.  

All dealt with in Maven.

> The other is about policy -- what kind of stuff can be in a particular
> repository.   If the ASF ultimately decides to run its own repository with
> ASF policy that's fine.  That shouldn't prevent the iBiblio repository (with
> a different policy) from continuing to exist.

Right. We can probably also assist people in knowing about violations as
well. If for example a dependency could have a license type associated
with someone trying to assemble a set of JARs could be notified of
meaning of doing so.

> I'd hate to see us build mechanism that enforced policy.

Definitely not enforce but certainly warnings. People can do what they
like. We can provide information vis-a-vis possible license violations
but ultimately individual projects are responsible for watching their
own asses.

> I'd like to lend a hand if this gets broken out into a separate project.

I can certainly strip out the dependency resolution code in Maven.

> Ted
> - Original Message -
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: "Jakarta General List" <[EMAIL PROTECTED]>
> Sent: Wednesday, February 05, 2003 11:40 AM
> Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary
> distribution location]
> 
> 
> > On Wed, 2003-02-05 at 14:35, Geir Magnusson Jr. wrote:
> > > On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote:
> > > >
> > > > I hope to have a proposal started on the Wiki tonight (PST).  The
> Maven
> > > > repository
> > > > has been an essential tool for me for me.
> > > > The next step is to play nice with gump.
> > > > Then do help with dependencies
> > > > Also to make it easy for projects to "brand" themselves with version
> > > > and
> > > > dependency information.
> > > >
> > >
> > > JJAR in commons sandbox had some of these ideas in there...  But can
> > > you build this into maven rather than in parallel?
> >
> > The stuff in Maven can certainly be split out. As I said to Nick, it can
> > already handle generation changes, evolution and the dependency
> > mechanism in Maven already deals with non-JAR artifacts like WAR files,
> > maven POMs, docs or whatever you want.
> >
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > [EMAIL PROTECTED]
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> >   -- Jacques Ellul, The Technological Society
> >
> >
> > -
> > 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]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

RE: Clear the air Re: ATTN: Maven developers [was: primary distribution location]

[Jason van Zyl]

On Wed, 2003-02-05 at 14:45, Henri Yandell wrote:

> The Sun licence stuff on there is more quesitonable. I figure as long as
> ibiblio are aware they are liable, and that they have happily accepted
> that liability, then it doesn't matter. Or do they pass the liability on
> to the individual who set it up, [Jason?] ?

I removed them this morning and will remove any other JARs that are
brought to my attention. Sam named JAF, JavaMail and EJBs so I removed
those. I just got off the phone and I got a clear answer as to what
Apache could be liable for. If Maven, being an ASF piece of software, is
party to illegal assembly then the ASF could be liable. This I did not
think was the case as the JARs were not on ASF hardware but that doesn't
seem to matter. So the Sun violations can't happen anymore. Now we just
have to deal with LGPL and GPL issues.

> Hen
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

RE: Clear the air

[Jason van Zyl]

On Wed, 2003-02-05 at 14:38, Nick Chalko wrote:
> JJAR has stalled.  but maybe restarting that is a good solution.

It's not a good idea. Again, it was started at my behest and I've
absorbed everything in JJAR into Maven's mechanism. Which can be split
out.

> I think building outside of maven is a worthwhile because not every one uses
> maven.  
> I would like to see the tools and standards developed be independent of the
> build tool.

It can be a separate tiny build and then anyone can use it.

> 
> 
> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 05, 2003 11:36 AM
> To: Jakarta General List
> Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary
> distri bution location]
> 
> 
> JJAR in commons sandbox had some of these ideas in there...  But can 
> you build this into maven rather than in parallel?
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]

[Jason van Zyl]

On Wed, 2003-02-05 at 14:35, Geir Magnusson Jr. wrote:
> On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote:
> >
> > I hope to have a proposal started on the Wiki tonight (PST).  The Maven
> > repository
> > has been an essential tool for me for me.
> > The next step is to play nice with gump.
> > Then do help with dependencies
> > Also to make it easy for projects to "brand" themselves with version 
> > and
> > dependency information.
> >
> 
> JJAR in commons sandbox had some of these ideas in there...  But can 
> you build this into maven rather than in parallel?

The stuff in Maven can certainly be split out. As I said to Nick, it can
already handle generation changes, evolution and the dependency
mechanism in Maven already deals with non-JAR artifacts like WAR files,
maven POMs, docs or whatever you want.


-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

RE: Clear the air Re: ATTN: Maven developers [was: primary distribution location]

[Jason van Zyl]

On Wed, 2003-02-05 at 14:29, Nick Chalko wrote:

> 
> 
> 
> I hope to have a proposal started on the Wiki tonight (PST).  The Maven
> repository 
> has been an essential tool for me for me.  
> The next step is to play nice with gump.
> Then do help with dependencies
> Also to make it easy for projects to "brand" themselves with version and
> dependency information.

This can be done with Maven already. We have got a grip on generational
transition, transitive dependencies and evolution. The non-trivial part
is the collection of the information. The tools are present and I don't
mind splitting them out if they want to be used elsewhere.

> I think Apache can grow a world class solution from the seed of the Maven
> Repository.
>   

I don't actually see why any project can't use the Maven repository
right now.

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

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: ATTN: Maven developers [was: primary distribution location]

[Jason van Zyl]

On Wed, 2003-02-05 at 13:16, Sam Ruby wrote: 

> 
> I am requesting that the people contributing to Maven perform an audit. 
>   I would like to see that audit complete within two weeks.
> 
> It is not difficult to find more license violations.  Quite a number of 
> the packages starting with the letter 'J' alone look suspicious.

If this is a board mandate, or Roy feels it is necessary then I will do
so if it is a legal imperitive to keep the ASF safe. I, at this point,
don't care about what you personally want or think. I think you've gone
off the deep end. Making a morass out of something that does not need to
be.

> - Sam Ruby
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: ATTN: Maven developers [was: primary distribution location]

[Jason van Zyl]

On Wed, 2003-02-05 at 13:16, Sam Ruby wrote:
> Jason van Zyl wrote:
> > 
> > The Sun Binary Code License issue I am looking into personally and will
> > either 1) add a click through license handler 2) Add the
> > non-distributable JARs feature back in or 3) remove them. These are a
> > problem.
> 
> I don't see anything in the license that permits others to redistribute 
> this with a click through license.

Netbeans does it so I don't see why we can't.

> > As for the LGPL and GPL jars what is the problem exactly. Ibiblio is not
> > ASF hardware what jurisdiction does the ASF have?. What juridiction do
> > you have at all? I put the repository there to avoid these problems. Why
> > are you trying to make it so difficult for people to build projects?
> > What are users supposed to do who need GPL and LGPL JARs. The Maven
> > repository is not for ASF code only, it's for all Java projects.
> 
> Ibiblio can do whatever it wants.  I don't want the ASF to be complicit 
> with license violations.  Sever the connection to ibiblio or correct the 
> problem.

How is the ASF complicit. IT'S NOT ON ASF HARDWARE!

> > I've removed the JAF, JavaMail and EJB jars from the repository.
> > 
> > Sam, just let know if there are others JARs I can remove to make it more
> > difficult for people to build their projects. 
> 
> I realize that you are not happy with the terms of the Sun license. 
> Please do not direct that at me.

Yes, I'm directing it at you because you're the only person who seems to
making this as issue. Obviously Sun is implicitly ignoring the
redistribution of these JARs because it's happening all over the place.
You bringing this to a head is not going to allow Sun to whistle in the
dark and let it go. They probably don't care and they probably don't
want to spend any money changing the license because things just
generally work. You making a big stink about it and then doing zilch
insofar as contacting anyone at Sun to try and help with all your
purported clout absolutely sucks.

> - Sam Ruby
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: ATTN: Maven developers [was: primary distribution location]

[Jason van Zyl]

On Wed, 2003-02-05 at 12:30, Jason van Zyl wrote:
> On Wed, 2003-02-05 at 11:57, Sam Ruby wrote:
> 
> > This issue has come up before.  This time, let's flatten it.
> > 
> > In two weeks, there is a board meeting.  At that time, I would like to
> > be able to report that the contents of the Maven repository conforms to
> > the policies of the Apache Software Foundation.
> > 
> > Code under the ASF License is clearly OK.  As is the IBM Public License
> > (the pre-Jakarta BSF, for example) and the MPL (Rhino).  The following
> > public domain components are also approved: Antlr and Doug Lea's
> > concurrency package.
> > 
> > Licenses clearly not conforming to the ASF's policies for distribution:
> > LGPL, GPL, Sun's Binary Code License.
> 
> The Sun Binary Code License issue I am looking into personally and will
> either 1) add a click through license handler 2) Add the
> non-distributable JARs feature back in or 3) remove them. These are a
> problem.
> 

I've removed the JAF, JavaMail and EJB jars from the repository.

Sam, just let know if there are others JARs I can remove to make it more
difficult for people to build their projects. 

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: ATTN: Maven developers [was: primary distribution location]

[Jason van Zyl]

On Wed, 2003-02-05 at 11:57, Sam Ruby wrote:

> This issue has come up before.  This time, let's flatten it.
> 
> In two weeks, there is a board meeting.  At that time, I would like to
> be able to report that the contents of the Maven repository conforms to
> the policies of the Apache Software Foundation.
> 
> Code under the ASF License is clearly OK.  As is the IBM Public License
> (the pre-Jakarta BSF, for example) and the MPL (Rhino).  The following
> public domain components are also approved: Antlr and Doug Lea's
> concurrency package.
> 
> Licenses clearly not conforming to the ASF's policies for distribution:
> LGPL, GPL, Sun's Binary Code License.

The Sun Binary Code License issue I am looking into personally and will
either 1) add a click through license handler 2) Add the
non-distributable JARs feature back in or 3) remove them. These are a
problem.

As for the LGPL and GPL jars what is the problem exactly. Ibiblio is not
ASF hardware what jurisdiction does the ASF have?. What juridiction do
you have at all? I put the repository there to avoid these problems. Why
are you trying to make it so difficult for people to build projects?
What are users supposed to do who need GPL and LGPL JARs. The Maven
repository is not for ASF code only, it's for all Java projects.

The Maven repository is not Maven. Ted Leung had the idea of using a
PORTs type system where the repository had pointers to the actual
artifacts but what you are saying is that we wouldn't even be allowed to
provide pointers to LGPL and GPL software because it's associated with
Maven which is a project at the ASF. That's just ridiculous? How is the
ASF at all liable for anything not on ASF hardware?

On what legal grounds could anyone make the ASF liable? I don't see how
this is possible? And given that is not the ASF's problem which is again
why I put the repository on ibiblio because I didn't want it to be a
problem for the ASF.

I assume that Roy is the most versed in the legal issues so I've cc'd
him here as I would like to know if there are any legal grounds under
which the ASF would be liable for anything done at ibiblio?

> Please direct any questions or comments (including new licenses to be
> considered) to [EMAIL PROTECTED]  Some we can resolve for
> ourselves (e.g., the specific public domain packages above).  Others
> I'll batch up and forward to the board and/or licensing folk.
> 
> By the board meeting after that (3rd week in March), I'd like to have
> the infrastructure issues resolved (where should this data should be
> hosted, mirrored, etc).
> 
> - Sam Ruby
> 
> 
> -
> 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]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Jakarta Charter

[Jason van Zyl]

Hi,

I was poking around looking for the Jakarta Charter, is it kicking
around somewhere. I couldn't find it on the site and I want to use it as
a template for the db.apache.org charter.
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

[ANN] Maven 1.0 Beta 7 Released!

[Jason van Zyl]

The Maven team is pleased to announce the Beta 7 release!

http://jakarta.apache.org/turbine/maven/

Maven is a Java project management and project comprehension tool. Maven
is based on the concept of a project object model (POM) in that all the
artifacts produced by Maven are a result of consulting a well defined
model for your project. Builds, documentation, source metrics, and
source cross-references are all controlled by your POM.

Maven has many goals, but in a nutshell Maven aims to make the
developer's life easier by providing a well defined project structure,
well defined development processes to follow, and a coherent body of
documentation that keeps your developers and clients apprised of what's
happening with your project. Maven alleviates a lot of what most
developers consider drudgery and lets them get on with the task at hand.
This is essential in OSS projects where there aren't many people
dedicated to the task of documenting and propagating the critical
information about your project which is necessary in order to attract
potential new developers and clients.

This version is primarily a bugfix release. Changes in this version
include:

o Codeswitcher plug-in has been added. This is a Java preprocessor
  plug-in.
  
o Examples plug-in has been added. This provides basic working
  Maven example projects.
  
o IDEA plug-in has been added.
  
o Jalopy plug-in has been added.
  
o JBuilder plug-in has been added.
  
o Perforce plug-in has been added.
  
o StatCVS plug-in has been added. This provides some visuals of the
  state of your CVS repository.
  
o Word2Html plug-in has been added.
  
You can find the Maven distributions here:
http://www.ibiblio.org/maven/maven/distributions/

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Issue tracking

[Jason van Zyl]

On Thu, 2002-09-26 at 12:09, Pier Fumagalli wrote:

> Fine... Less work for me... Want to get also BugZilla and Eyebrowse on
> there?

I'm not interested in looking at Bugzilla so if that can stay at Nagoya
that would be appreciated. Daniel is the Eyebrowse kingpin so if he
wants access to the rackspace box he's welcome to setup Eyebrowse there.

> Pier
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Issue tracking

[Jason van Zyl]

On Thu, 2002-09-26 at 05:16, Pier Fumagalli wrote:
> On 26/9/02 3:04, "Scott Eade" <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> > I am in the process of tidying up the issue tracking systems used by the
> > turbine projects.  The biggest change is that we are predominantly going to
> > use an instance of the turbine based Scarab issue tracking system (from
> > tigris.org) that is installed at werken.com (Bob McWhirter's site on a box
> > belonging to Bob and Jason van Zyl - thanks guys).  This instance was set up
> > as it apparently proved difficult to gain the necessary access to maintain
> > the Scarab instance at issues.apache.org/scarab.
> > 
> > Bob has suggested that we set up an apache.org hostname for the box to make
> > it easier if it becomes necessary to migrate to another system in the
> > future.  I thought it would be a good idea to run this past the general
> > Jakarta list prior to making a request to [EMAIL PROTECTED]
> > 
> > In summary here is what we want to do:
> > 
> > 1. Request the host name scarab.apache.org be set up to point to the same
> > address as scarab.werken.com
> > 2. Update http://issues.apache.org/ to de-emphasise the
> > issues.apache.org/scarab install (now used only by OJB) and to include a
> > reference to the new scarab.apache.org instance (note that OBJ guys are
> > being invited to migrate over to the maintained Scarab instance).
> > 3. Organize for bugzilla to no longer accept turbine issues.
> > 
> > Please speak up if you have any comments or concerns about this.  It has
> > been discussed on the turbine-dev list with no objections.
> 
> We already have a setup of Scarab on nagoya.apache.org, which of course is
> _already_ has an alias as issues.apache.org
> 
> If you want to use scarab, use nagoya and update that installation, let's
> not redo the whole thing again and again and again...

We're not doing it again and again. We're doing it once more in a place
where we know that we can get hold of people taking care of the box and
don't have to deal with a Sun box. There are a group of us taking care
of that machine and we would prefer to do it there than have it on
nagoya. I am personally against putting anything on Nagoya as getting
hold of you has proved difficult at times (I'm well aware you're
volunteering your time) and I hate Sun boxes and find them amazingly
annoying to work on. I would like to dump the scarab install on nagoya
and use the rackspace managed box that we have. It's just less work for
everyone and we are more comfortable hosting Scarab there. 
 
> Pier
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: process of OSS development at jakarta

[Jason van Zyl]

On Tue, 2002-07-02 at 11:36, Leo Simons wrote:
> that's the idea.
> 
> can someone get me karma to site2?

Done.
 
> thanks!
> 
> On Tue, 2002-07-02 at 13:20, Ted Husted wrote:
> > Leo Simons wrote:
> > > 
> > > If y'all could comment and perhaps expand a bit, I'll put a webpage somewhere.
> > > Or, if I missed the mark completely, I'll do nothing =)
> > 
> > How about tieing that page in with the outline we started here:
> > 
> > http://jakarta.apache.org/site/guides
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: XMLRPC in Jakarta???

[Jason van Zyl]

On Sat, 2002-06-22 at 20:32, Pier Fumagalli wrote:
> Jason,
>   what is xmlrpc doing in the Jakarta distribution directory? That's an XML
> project, and it should be distributed from there...
> 
> I notice the files are owned by you...

If I remember I put them in there because I was waiting around for some
perms to be fixed and needed to make a drop. I drop the next release in
the xml zone.
 
> Pier
> 
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of different
> sublanguages in  one monolithic executable.  It combines the power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Scarab

[Jason van Zyl]

On Thu, 2002-06-20 at 12:03, Jon Scott Stevens wrote:
> Jason, since you started with a clean database, I suggest that you also not
> load the sample data. To do this:
> 
> cd scarab/src/sql
> cp LoadOrder.lst Jason.lst
> (edit the .lst file and remove the sample-data.sql line)
> ./create-db.sh -l Jason.lst
> 
> That will wipe the database again and not load the sample data. You can then
> login using the [EMAIL PROTECTED] account (or whatever root account you
> defined when you built scarab).

Cool, will do.
 
> -jon
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: Scarab

[Jason van Zyl]

On Wed, 2002-06-12 at 22:08, Peter Donald wrote:
> Yea for scarab!
> 
> BTW are all the bugs and bug histories from bugzilla going to be moved 
> across auotmagically?

I will attempt, but I don't know what the conversion process is like. I
think we should let both run for a while. Let new issues go to Scarab,
if a project decides they are ready to try, and use Bugzilla until the
issues are dealt with. I don't think we want to mandate switching. Not
until everyone gets a feel for Scarab.

If the bugzilla/scarab migration is relatively easy and people like
Scarab and are satisfied it is ready to replace Bugzilla then we can try
to cull the Bugzilla installation.
 
> At 06:12 PM 6/12/2002 -0400, you wrote:
> >Does anyone have anything critical they want saved in the old Scarab
> >installation on nagoya?
> >
> >I'm ready to install a new version of Scarab so that it's available for
> >everyone but just wanted to check before blowing the old install away.
> >
> >--
> >jvz.
> >
> >Jason van Zyl
> >[EMAIL PROTECTED]
> >
> >http://tambora.zenplex.org
> >
> >
> >--
> >To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> Cheers,
> 
> Peter Donald
> ~~~
> "Faced with the choice between changing one's mind,
> and proving that there is no need to do so - almost
> everyone gets busy on the proof."
>   - John Kenneth Galbraith
> ~~~
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: Scarab

[Jason van Zyl]

On Wed, 2002-06-12 at 18:14, Martin van den Bemt wrote:
> I understood there wasn't any issue data in there anyway..

There are modules there that I didn't add so I'm just checking.
 
> Mvgr,
> Martin
> 
> On Thu, 2002-06-13 at 00:12, Jason van Zyl wrote:
> > Hi,
> > 
> > Does anyone have anything critical they want saved in the old Scarab
> > installation on nagoya?
> > 
> > I'm ready to install a new version of Scarab so that it's available for
> > everyone but just wanted to check before blowing the old install away.
> > 
> > -- 
> > jvz.
> > 
> > Jason van Zyl
> > [EMAIL PROTECTED]
> > 
> > http://tambora.zenplex.org
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Scarab

[Jason van Zyl]

Hi,

Does anyone have anything critical they want saved in the old Scarab
installation on nagoya?

I'm ready to install a new version of Scarab so that it's available for
everyone but just wanted to check before blowing the old install away.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: status

[Jason van Zyl]

On Sun, 2002-06-09 at 13:11, Andrew C. Oliver wrote:
> >
> >
> >There is an installation of Scarab on nagoya which is where I've been
> >working on upgrading what's there. A mailing list for the admin has also
> >been setup [EMAIL PROTECTED] 
> >
> Cool I'll subscribe.

We'll just add you to the list, nothing to subscribe to.
 
> >  
> >
> >I was gone for about six weeks so I didn't know there was discussion of
> >Scarab but nagoya is where it will live as it's well maintained (that's
> >not to say your colo box wouldn't be), backed up regularly and well
> >connected.
> >  
> >
> Oh no, I am practicing on my colo box.  I've never installed scarab 
> before so *shrug* its called
> paranoia (my preferred mode of system adminstration).  I intended to 
> install it on nagoya.  I've no
> desire to assume that kinda traffic on my box ;-)
> 
> Sorry for the confusion, this was intended as a status update for a 
> previous mail.
> 
> >Currently Daniel Rall and I get the scarab-admin mail but I know that
> >Dan is super busy and probably wouldn't mind you taking his place if
> >you're keen on helping with Scarab. Or we can simply add you to the list
> >of admins.
> > 
> >
> Cool, Pier gave me access to the box.  Is there any data in that scarab 
> install?  

Yes, but we can dump it pretty easily. There is a #scarab chatroom on
irc.whichever.com:6667 if you want to chat about the details. Dan is
usually there too.

> -Andy
> 
> >  
> >
> >>-Andy
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >>
> >>
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: status

[Jason van Zyl]

On Sun, 2002-06-09 at 12:41, Andrew C. Oliver wrote:
> FYI, I've gotten my server back to its co-location and I'm working on 
> learning how to install scarab.
> Running out of weekend, so it will probably be another week. (I haven't 
> forgotten)

There is an installation of Scarab on nagoya which is where I've been
working on upgrading what's there. A mailing list for the admin has also
been setup [EMAIL PROTECTED] 

I was gone for about six weeks so I didn't know there was discussion of
Scarab but nagoya is where it will live as it's well maintained (that's
not to say your colo box wouldn't be), backed up regularly and well
connected.

Currently Daniel Rall and I get the scarab-admin mail but I know that
Dan is super busy and probably wouldn't mind you taking his place if
you're keen on helping with Scarab. Or we can simply add you to the list
of admins.
 
> -Andy
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: [PATCH] Added new turbine mailing lists to site

[Jason van Zyl]

On Fri, 2002-06-07 at 12:54, robert burrell donkin wrote:
> 
> On Thursday, June 6, 2002, at 11:02 PM, Jason van Zyl wrote:
> 
> > On Thu, 2002-06-06 at 17:59, robert burrell donkin wrote:
> >> the existing list of mailing lists doesn't include some of the newer
> >> turbine lists.
> >>
> >> this patch for jakarta-site2/xdocs/site/mail2.xml adds them.
> >
> > Would you like access to the jakarta-site2 module?
> 
> ok

Done.
 
> - robert
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: [PATCH] Added new turbine mailing lists to site

[Jason van Zyl]

On Thu, 2002-06-06 at 17:59, robert burrell donkin wrote:
> the existing list of mailing lists doesn't include some of the newer 
> turbine lists.
> 
> this patch for jakarta-site2/xdocs/site/mail2.xml adds them.

Would you like access to the jakarta-site2 module?


 
> - robert
> 
> 
> 

> Index: xdocs/site/mail2.xml
> ===
> RCS file: /home/cvs/jakarta-site2/xdocs/site/mail2.xml,v
> retrieving revision 1.44
> diff -u -r1.44 mail2.xml
> --- xdocs/site/mail2.xml  9 May 2002 22:11:20 -   1.44
> +++ xdocs/site/mail2.xml  6 Jun 2002 21:54:27 -
> @@ -745,6 +745,69 @@
>  
>  This list is where discussion of the Turbine TDK development occurs.
>  
> +
> +The Torque User List
> +Medium Traffic 
> +mailto:[EMAIL PROTECTED]";>Subscribe  
> +mailto:[EMAIL PROTECTED]";>Unsubscribe 
> +href="http://www.mail-archive.com/turbine-torque-user@jakarta.apache.org/";>Archive
> 
> +
> +
> +List for Torque users to meet, discuss and solve problems. 
> +Developers will also be lurking around.
> +
> +
> +The Torque Developer List
> +Medium Traffic 
> +mailto:[EMAIL PROTECTED]";>Subscribe  
> +mailto:[EMAIL PROTECTED]";>Unsubscribe 
> +href="http://www.mail-archive.com/turbine-torque-dev@jakarta.apache.org/";>Archive 
> +
> +
> +This list is where discussion of Torque development occurs.
> +
> +
> +The Maven User List
> +Medium Traffic 
> +mailto:[EMAIL PROTECTED]";>Subscribe  
> +mailto:[EMAIL PROTECTED]";>Unsubscribe 
> +href="http://www.mail-archive.com/turbine-maven-user@jakarta.apache.org/";>Archive 
> +
> +
> +List for Maven users to meet, discuss and solve problems. 
> +Developers will also be lurking around.
> +
> +
> +The Maven Developer List
> +Medium Traffic 
> +mailto:[EMAIL PROTECTED]";>Subscribe  
> +mailto:[EMAIL PROTECTED]";>Unsubscribe 
> +href="http://www.mail-archive.com/turbine-maven-dev@jakarta.apache.org/";>Archive 
> +
> +
> +This list is where discussion of Maven development occurs.
> +
> +
> +The JCS User List
> +Medium Traffic 
> +mailto:[EMAIL PROTECTED]";>Subscribe  
> +mailto:[EMAIL PROTECTED]";>Unsubscribe 
> +href="http://www.mail-archive.com/turbine-jcs-user@jakarta.apache.org/";>Archive 
> +
> +
> +List for JCS users to meet, discuss and solve problems. 
> +Developers will also be lurking around.
> +
> +
> +The JCS Developer List
> +Medium Traffic 
> +mailto:[EMAIL PROTECTED]";>Subscribe  
> +mailto:[EMAIL PROTECTED]";>Unsubscribe 
> +href="http://www.mail-archive.com/turbine-jcs-dev@jakarta.apache.org/";>Archive 
> +
> +
> +This list is where discussion of JCS development occurs.
> +
>  
>  
>  
> 
> 
> 

> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Maven 1.0 B4 Released!

[Jason van Zyl]

The Maven team is pleased to announce the Beta 4 release!

http://jakarta.apache.org/turbine/maven/

Maven is a Java project management and project comprehension tool. Maven
is based on the concept of a project object model (POM) in that all the
artifacts produced by Maven are a result of consulting a well defined
model for your project. Builds, documentation, source metrics, and
source cross-references are all controlled by your POM.

Maven has many goals, but in a nutshell Maven aims to make the
developer's life easier by providing a well defined project structure,
well defined development processes to follow, and a coherent body of
documentation that keeps your developers and clients apprised of what's
happening with your project. Maven alleviates a lot of what most
developers consider drudgery and lets them get on with the task at hand.
This is essential in OSS projects where there aren't many people
dedicated to the task of documenting and propagating the critical
information about your project which is necessary in order to attract
potential new developers and clients.

Changes in this version include:

o Configurable color scheme for the generated web site.  By default,
Maven uses its own color scheme for generated web sites; however,
users now have the option of overriding some or all of the color
selections.

o Support for J2EE (tm) WAR and EAR files being generated as part of the
build process.

o WAR file validation has been added, such that a war is verified to be
consistent with the web.xml it provides describing its contents

o Extra reporting on project activity has been added. The reports
include activity by file and developer.

o Nag email address and package were added to the gump descriptor

o The LICENSE.txt file is now added to JARs, WARs and EARs built with
Maven

o JUnit tests can be configured to display their output at the console,
rather than placed into a file, for easier debugging.

o Maven will now create a separate classpath for unit tests and
integration unit tests

o All properties used by maven are now prefixed with 'maven.'

o The source code directories were restructured to allow easier
development of plugins

o Work on validating Struts 1.0 war files was started

o Eclipse plugin for Maven started

o Maven GUI started

o POM updated to allow multiple and various SCMs

o POM simplified to aid in the development of discrete components

Maven is going strong! 15 developers, 114 unit tests, and a staggering
amount of documentation!


-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: OJB & Jakarta

[Jason van Zyl]

On Sat, 2002-06-01 at 13:37, Geir Magnusson Jr. wrote:
> On 5/31/02 11:04 PM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> > I am assuming that the formation of db.apache.org may still happen but
> > for appears that this will take a bit of time.
> > 
> > I would like to move over the OJB code into our repositories now under
> > the proviso that code is moved to db.apache.org when it forms.
> > 
> > Does anyone object to this?
> 
> Seems perfectly reasonable as long as you don't mind the admin slog if it
> happens...

I don't mind helping with the admin slog of getting db.apache.org up and
running. When OJB moves the package names won't change and neither will
any of the CVS info I imagine so it won't be a problem.
 
> -- 
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> [EMAIL PROTECTED]
> +1-203-247-1713
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

OJB & Jakarta

[Jason van Zyl]

Hi,

I am assuming that the formation of db.apache.org may still happen but
for appears that this will take a bit of time.

I would like to move over the OJB code into our repositories now under
the proviso that code is moved to db.apache.org when it forms.

Does anyone object to this?

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

RE: [PATCH] new James version numbers for binindex and srcindex

[Jason van Zyl]

On Thu, 2002-05-30 at 12:20, Danny Angus wrote:
> > Is there some reason why you can't apply the patch yourself (or request
> > commit access)?
> 
> No Karma, and I asked a while a go but got not. :-(

There you go :-) You should be able to commit to jakarta-site-2
 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: Quick! convert all your projects to maven!

[Jason van Zyl]

On Tue, 2002-04-30 at 17:26, Jon Scott Stevens wrote:
> Quick! convert all your projects build.xml files to being controlled by
> maven!
> 
> <http://jakarta.apache.org/turbine/maven/>
> 
> The faster we get a centralized build system in Jakarta the better off we
> will all be.
> 
> Forget the days where you have to edit silly properties files to locate
> dependency .jar files...now, maven will do all of that for you!
> 
> Maven is the next killer build tool like Ant was.
> 
> Everyone should install and use it.

I am very thankful for your praise, really. 

I encourage people to look at Maven and try to use it but there are some
definite kinks to work out. When Maven hits 1.0 I will be as
enthusiastic as you are! 

If people want to try Maven and and give your feedback that would be
great, and would help Maven move along faster to a 1.0 but it is not an
entirely seamless process, as it will be in 1.0, and I don't want people
getting frustrated needlessly. It is highly functional but at the same
time displays certain limitations (like deployment flexibility) that are
highly annoying.

So play if you wish but please be patient :-) 

> -jon
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: [New Subproject Proposal] ObjectBridge

[Jason van Zyl]

On Tue, 2002-04-30 at 15:15, [EMAIL PROTECTED] wrote:
> Given the votes expressed so far by other jakarta commiters - I can
> only vote +1.

You should put your name in the PMC section on the "who we are" page. I
know you're on the PMC but I can't remember who the 7th is.
 
> This seems like a usefull tool ( I spent few years working on OODBs and
> OQL ), with a modular design.
> 
> My only comment:
> 
> I would be much happier with a wider top-level project, where the 
> various db-related technologies could find the expertise and community 
> that is needed ( instead of ending up with 3-4 smaller projects ).

I'm hoping this comes to pass given at least for the various persistence
layer options. OJB design is flexible enough to allow the core to be
used with different usage APIs (ODMG, JDO, ...) and different query
APIs. 

> We do not have ( AFAIK ) any top level project with the primary 
> goal of doing database-related stuff.
> 
> In time ( and if we are lucky ) this project can incorporate various
> other db-related components - like the various connection pools, 
> portions of torque, etc. Of course, the internal organization is
> your choice, but I think it would be good if various database related 
> proposals and technologies share the same top level porject

I would like to see that too.

> You have my +1 on the proposal anyway.

Cool :-)
 
> Costin
> 
> 
> 
> On 29 Apr 2002, Jason van Zyl wrote:
> 
> > Hi,
> > 
> > I would like to propose ObjectRelationalBridge
> > (http://objectbridge.sourceforge.net/) as a top level subproject of
> > Jakarta.
> > 
> > For those not familiar with ObjectBridge it is arguably one of the most
> > advanced persistence layers available, commercial or otherwise. It is
> > accompanied by an extensive, current documentation set which includes a
> > quick start guide, tutorials, a FAQ, design documentation describing how
> > certain features of OJB have been implemented, and deployment guides.
> > 
> > The developer community is incredibly strong and currently consists of
> > 17 inviduals: three of whom are Jakarta committers, and one of the core
> > Castor developers. So the project has the numbers and has displayed some
> > collaboration with other projects. There are developers from the Torque
> > team (the simple table->object persistence tool within the turbine
> > subproject) too so there is obvious interest in OJB. The current list of
> > developers can be found here:
> > 
> > http://sourceforge.net/project/memberlist.php?group_id=13647
> > 
> > I would also like to note that David Taylor, a Jetspeed fellow, also
> > contributed to the internal transaction mechanism. So again, another
> > point of interest within Jakarta.
> > 
> > OJB is currently being used in the Jetspeed project, and integration is
> > well underway in the Turbine project and Thomas Mahler, the author of
> > OJB, uses OJB in conjunction with Struts as part of some of the
> > solutions his company provides for clients. Thomas is also a user of
> > TopLink, which is the only product that is even remotely comparable with
> > OJB, so he is very familiar with both and reports that OJB is on par
> > with TopLink with to respect to performance and available features.
> > 
> > I won't go into a complete list of features, but here are some of the
> > features that set OJB apart:
> > 
> > o Pluggable APIs: Currently there is the native PersistenceBroker API, a
> > full ODMG API (which provides enhanced transaction isolation) and a JDO
> > implementation is in the works. OJB has been designed to allow different
> > front-end APIs for maximum flexibility. The ODMG API, for example, is a
> > small set of classes layered over top the core of OJB. The JDO
> > implementation will be very similiar in nature.
> > 
> > o Pluggable query APIs: currently supported are a criteria based API
> > (AST based mechansism), OQL and SODA. But again they are pluggable, so
> > for example the query mechanism in Torque could easily be made to work
> > with OJB.
> > 
> > These two features alone make OJB attractive as different APIs can be
> > made so that existing users of different systems can use OJB without
> > forcing clients to change code. Trying this with Torque is going to be
> > one of my first exercises to see how well this mechanism works. There
> > are many tools like Torque and OJB can be made to work with the APIs of
> > these projects so that greater collaboration can occur within OJB
> > itself. One can take a look at the source and design of OJB and quickly
> > det

[New Subproject Proposal] ObjectBridge

[Jason van Zyl]

Hi,

I would like to propose ObjectRelationalBridge
(http://objectbridge.sourceforge.net/) as a top level subproject of
Jakarta.

For those not familiar with ObjectBridge it is arguably one of the most
advanced persistence layers available, commercial or otherwise. It is
accompanied by an extensive, current documentation set which includes a
quick start guide, tutorials, a FAQ, design documentation describing how
certain features of OJB have been implemented, and deployment guides.

The developer community is incredibly strong and currently consists of
17 inviduals: three of whom are Jakarta committers, and one of the core
Castor developers. So the project has the numbers and has displayed some
collaboration with other projects. There are developers from the Torque
team (the simple table->object persistence tool within the turbine
subproject) too so there is obvious interest in OJB. The current list of
developers can be found here:

http://sourceforge.net/project/memberlist.php?group_id=13647

I would also like to note that David Taylor, a Jetspeed fellow, also
contributed to the internal transaction mechanism. So again, another
point of interest within Jakarta.

OJB is currently being used in the Jetspeed project, and integration is
well underway in the Turbine project and Thomas Mahler, the author of
OJB, uses OJB in conjunction with Struts as part of some of the
solutions his company provides for clients. Thomas is also a user of
TopLink, which is the only product that is even remotely comparable with
OJB, so he is very familiar with both and reports that OJB is on par
with TopLink with to respect to performance and available features.

I won't go into a complete list of features, but here are some of the
features that set OJB apart:

o Pluggable APIs: Currently there is the native PersistenceBroker API, a
full ODMG API (which provides enhanced transaction isolation) and a JDO
implementation is in the works. OJB has been designed to allow different
front-end APIs for maximum flexibility. The ODMG API, for example, is a
small set of classes layered over top the core of OJB. The JDO
implementation will be very similiar in nature.

o Pluggable query APIs: currently supported are a criteria based API
(AST based mechansism), OQL and SODA. But again they are pluggable, so
for example the query mechanism in Torque could easily be made to work
with OJB.

These two features alone make OJB attractive as different APIs can be
made so that existing users of different systems can use OJB without
forcing clients to change code. Trying this with Torque is going to be
one of my first exercises to see how well this mechanism works. There
are many tools like Torque and OJB can be made to work with the APIs of
these projects so that greater collaboration can occur within OJB
itself. One can take a look at the source and design of OJB and quickly
determine that OJB stands in a class of its own, is very reliable, very
flexible and very performant.

The greatest feature with respect to development is the extensive
regression testing features and the testbed. There are currently 130+
test cases and a regression test that compares the performance of OJB
with native JDBC calls.

A full list of features can be found here:

http://objectbridge.sourceforge.net/features.html

OJB also makes use of many Jakarta packages: Ant, Maven, Crimson, and
Log4j. There are also plans to use more of the commons utilities where
possible so the project is already Jakarta friendly :-)

Another interesting note is that OJB is one of the top 100 projects on
SourceForge (rank 89) with about 15,000 hits and 3,500 downloads per
month. So there is a very healthy user community that complements the
strong developer community.

Currently the license of OJB is LGPL but in discussion with Thomas he
feels that a BSD style license like Apache's is actually a better model
and has no problem with changing the license if the donation of OJB is
accepted by the Jakarta PMC.

This is really a one-of-a-kind project, and is definitely one of the
cases where an OSS implementation is close, if not better than its
commercial counterpart. The developer community is keen, there are great
number of users and we think that OJB would be a fabulous addition to
the set of projects that are currently housed at Jakarta.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: New Subproject proposal Config4J

[Jason van Zyl]

On Thu, 2002-04-25 at 15:46, Sam wrote:
> I looked at the CVS repository for this component.
> 
> This seems to be in a very early statge. Eg theres
> nothing in the XML config part. There are just 2 basic
> classes Eg BaseConfiguration.java that really doesnt
> do much.

You are right, it doesn't do much other then using properties like
files. That's why it's in the sandbox. If you've got some code bring it
on down. I was planning on using betwixt for the xml configuration stuff
and some changes need to be made to betwixt before I was going to
attempt that.
 
> I dont mean to sound like I m undermining your effort,
> but I would expect a configuration component to do
> more than that.

Definitely :-)

> Over the weekend, I ll putup what I have on a URL so
> you can look at it and use it as you feel necessary or
> incorporate whatevery you need.

Cool, I'll definitely take a look at it.

> Cheers
> ./s
> 
> Sam
> 
> 
> 
> --- Daniel Rall <[EMAIL PROTECTED]> wrote:
> > "Michael A. Smith" <[EMAIL PROTECTED]> writes:
> > 
> > > On Wed, 24 Apr 2002, Sam wrote:
> > > > Where is this
> > jakarta-commons-sandbox/configuration that you
> > mentioned
> > >> below.
> > >> 
> > >> Its not listed anywhere on
> > >> http://jakarta.apache.org/commons/components.html
> > >
> > > The component doesn't have a website yet.  You can
> > get to the files via
> > > viewcvs:
> > >
> > >
> >
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/configuration/
> > 
> > Indeed, it's brand new.  All the better for you help
> > influence its
> > direction, eh?  :)
> > 
> > - Dan
> > 
> > --
> > To unsubscribe, e-mail:  
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > 
> 
> 
> __
> Do You Yahoo!?
> Yahoo! Games - play chess, backgammon, pool and more
> http://games.yahoo.com/
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

[ANN] Maven b3 released!

[Jason van Zyl]

The Maven team is pleased to announce the Beta 3 release!

http://jakarta.apache.org/turbine/maven/

Maven is a Java project management and project comprehension tool. Maven is
based on the concept of a project object model (POM) in that all the
artifacts produced by Maven are a result of consulting a well defined model
for your project. Builds, documentation, source metrics, and source
cross-references are all controlled by your POM. 

Maven has many goals, but in a nutshell Maven aims to make the developer's
life easier by providing a well defined project structure, well defined
development processes to follow, and a coherent body of documentation that
keeps your developers and clients apprised of what's happening with your
project. Maven alleviates a lot of what most developers consider drudgery
and lets them get on with the task at hand. This is essential in OSS
projects where there aren't many people dedicated to the task of documenting
and propagating the critical information about your project which is
necessary in order to attract potential new developers and clients.

Changes in this version include:

o Integration of Checkstyle

o Maven installation update mechanism that allows you to easily
  update your Maven installation.

o POM update mechanism that will move your Maven projects forward easily
  as Maven improves. The updater will transform your project descriptor,
  properties files and the project structure itself if required.

o Testing has been simplified and made safer.

o An XML Schema and validation mechanism have been added.

o Documentation changes include fully documented Maven properties, the
  start of an FAQ, and several modifications to help unify the
  documentation so its more coherent for new users.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

[Fwd: Re: The Comprehensive Java Archive Network]

[Jason van Zyl]

I meant this for public consumption and sent it privately by mistake.
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org

--- Begin Message ---

On Tue, 2002-04-02 at 12:03, Michael Davey - Sun UK Support Engineer
wrote:
> Henri Yandell wrote:
> 
>  > I noticed this yesterday Michael after wondering 'who really does own cjan.org'.
>  >  Have you investigated the JJAR component with respect to cjan?
> 
> Yes.  It is my personal hope that the CJAN developers will enhance JJAR such 
> that it becomes the reference implementation for a CJAN client, with JJAR 
> continuing to be hosted by Apache, and the server-side being developed on 
> SourceForge.  This would of course require the backing of the Jakarta
> community ;)

I took a peek at the cjan repository and there wasn't much there other
than logos and some php scripts? And the download section doesn't go
anywhere.

CPAN also deals with distributions and not JARs. CPAN and generally the
tools that are used to make CPAN work are based on the principle of a
common descriptor for a perl project. These issues are being looked at
by two projects here: Gump and Maven. Gump has a project descriptor and
so does Maven and something will fall out of these two projects. And
Maven deals with building projects in a reliable manner with a common
format (much the same way perl packages are structured) which I think is
a critical part of making something like a CJAN work.

Right there is a primitive archive here that Maven-based projects use to
build but some critical things like project naming and versioning need
to be dealt with. Then there is the whole infrastructure: I have tried
to contact some of the CPAN people to get an overview of what they are
doing and I think the Avalon group have the tools to build the
distribution layer. IMO, JJAR is not adequate to deal with something on
the scale of CPAN, you need the project information to generate useful
indices, links to resources and all the other things that make
cross-project navigation/building easy for users.

I couldn't find much in the way of documentation on the cjan site, and
I'm writing up a CJAN type plan as part of Maven and I'm very interested
in hearing how you think the infrastructure would work.
 
> -- 
> Michael
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


--- End Message ---

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

Re: Open Source JDO Implementation??

[Jason van Zyl]

On Tue, 2002-04-02 at 11:46, Bruce Buttles wrote:
> Does anyone know of an open source JDO (Java Data Objects)
> implementation?
> 
> I know of a number of great Object-Relational mapping tools but
> none that are JDO compliant.
> I know JDO is still pretty new ... but the spec looks pretty
> cool.
> Also, I haven't seen any Apache activity around this yet.
> 
> All the JDO Implementations I've found (except that in Sun's Forte)
> are either NOT free ... or free for "Non-Commercial" use.
> 
> Anyone have some insight for me on this?
> Is there an Apache project out there for JDO that maybe I've
> overlooked?

You might want to look at OJB (objectbridge.sourceforge.net) which is
similar in architecture to JDO and a JDO adapter/wrapper is planned.
Thomas Mahler (lead dev on OJB) doesn't feel it will be a problem
technically, there is also a proposal for making the JDO layer that will
work over top the OJB core.
 
> Thanks!
> -Bruce
> 
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: Maven Beta 2 Released

[Jason van Zyl]

On Sat, 2002-03-30 at 03:20, Mike Hogan wrote:
> Maven looks very useful and I like the direction its going.  Please take a
> look at
> http://sourceforge.net/tracker/?atid=387260&group_id=26444&func=browse for
> other and similar ideas.

Cool, feel free to submit those ideas to the Maven mailing list and I
will add them if you want to participate. I see iContract in the list
and I'm very interested in iDoc and iDarwin as well. I actually know
Reto Kramer (met him at an aspectj conference) and hope to get his stuff
in sooner rather then later. Hope you join in!
 
> Cheers,
> Mike.
> - Original Message -
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Saturday, March 30, 2002 3:37 AM
> Subject: Maven Beta 2 Released
> 
> 
> > The Maven team is pleased to announce the Beta 2 release!
> >
> > http://jakarta.apache.org/turbine/maven/
> >
> > Maven is a Java project management and project comprehension tool. Maven
> > is based on the concept of a project object model (POM) in that all the
> > artifacts produced by Maven are a result of consulting a well defined
> > model for your project. Builds, documentation, source metrics, and
> > source cross-references are all controlled by your POM.
> >
> > Maven has many goals, but in a nutshell Maven aims to make the
> > developer's life easier by providing a well defined project structure,
> > well defined development processes to follow, and a coherent body of
> > documentation that keeps your developers and clients apprised of what's
> > happening with your project. Maven alleviates a lot of what most
> > developers consider drudgery and lets them get on with the task at hand.
> > This is essential in OSS projects where there aren't many people
> > dedicated to the task of documenting and propagating the critical
> > information about your project which is necessary in order to attract
> > potential new developers and clients.
> > [EOB]
> >
> >
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > [EMAIL PROTECTED]
> >
> > http://tambora.zenplex.org
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
> >
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Maven Beta 2 Released

[Jason van Zyl]

The Maven team is pleased to announce the Beta 2 release!

http://jakarta.apache.org/turbine/maven/

Maven is a Java project management and project comprehension tool. Maven
is based on the concept of a project object model (POM) in that all the
artifacts produced by Maven are a result of consulting a well defined
model for your project. Builds, documentation, source metrics, and
source cross-references are all controlled by your POM.

Maven has many goals, but in a nutshell Maven aims to make the
developer's life easier by providing a well defined project structure,
well defined development processes to follow, and a coherent body of
documentation that keeps your developers and clients apprised of what's
happening with your project. Maven alleviates a lot of what most
developers consider drudgery and lets them get on with the task at hand.
This is essential in OSS projects where there aren't many people
dedicated to the task of documenting and propagating the critical
information about your project which is necessary in order to attract
potential new developers and clients.
[EOB]



-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

RE: subproject layout conventions

[Jason van Zyl]

On Thu, 2002-03-28 at 09:53, Berin Loritsch wrote:

> 
> The only thing I would want to customize are:
> 
> 1) Project Logo
> 2) Project color-scheme

No problem :-) 
 
> That's it.  I really don't think that is too much to ask.  The
> layout should remain constant without a doubt.

We are in agreement then :-) Wow a new era for Avalon and Turbine
developers ;-) We did you avalon in part to produce PDFs :-)

> 
> > I'm not trying to stifle anyone's creative urges, I just feel 
> > that in the matter of project comprehension that it is 
> > pragmatic to have everything look the same. Some don't agree 
> > with me but what I'm really trying to avoid is the infinite 
> > configuration quagmire where everyone adds things to make 
> > things look the way they like and thus you loose all cross 
> > project cohesion.
> 
> Everything should definitely feel the same.  However, color is
> a definite clue that you have changed contexts.  By drilling
> down a Project's heirarchy, it helps to have a visual clue that
> you are not at the same level you used to be.
> 
> Color customization is not just a cosmetic tool, it does help
> to understand a project's hierarchy.  Logo changes can be missed,
> but a different background or header color is hard to ignore.

I'm definitely flexible on the color thing.

> As a side note, it would be cool if we could include the Jakarta
> and project logos as a header in the printed documentation, but
> that is a stylesheet change.
> 
> > 
> > > I just wish I new about Maven a lot earlier--it delivers on 
> > a lot of 
> > > promises, and in my book that's golden.
> > 
> > It's been in the works for a long time but really it's only 
> > been in the last 3-4 weeks that others have worked on it and 
> > it's taken off primarily because of the interest people have 
> > in making their develop lives easier. There is definitely an 
> > interest there because people would rather focus on their 
> > apps then fart around trying to get a build system to work 
> > and have it produce useful information.
> 
> Absolutely.
> 
> 
> So what did you think about the two line navigation approach for
> Jakarta Site?

I like the idea and I've thought about how to aggregate the content of
many projects into an uber site but I haven't done much work on it as
I've focused on the project level. But I'm definitely thinking of the
aggregation of projects: for documentation and building.

> > > I see the line with the sub-projects able to be two lines tall. The 
> > > first line would be the parent level, and the second line 
> > would be the 
> > > current line.  That way we can have something like this at the root 
> > > level:
> > > 
> > >   Alexandria Avalon BCEL ...
> > > 
> > > And at the sub-project level, we would be able to have 
> > something like 
> > > this:
> > > 
> > > Jakarta|  Theory Framework LogKit *Excalibur* Cornerstone 
> > Phoenix Apps
> > >   CLI Collections Concurrent 
> > > 
> > > That way we can easily navigate the site, and drill down quickly to 
> > > the actual information we need.
> > >   
> > > 
> > > 
> > 
> > > --
> > > To unsubscribe, e-mail:   
> > <mailto:general-> [EMAIL PROTECTED]>
> > > For 
> > additional commands, 
> > e-mail: 
> > > <mailto:[EMAIL PROTECTED]>
> > -- 
> > jvz.
> > 
> > Jason van Zyl
> > [EMAIL PROTECTED]
> > 
> http://tambora.zenplex.org
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

RE: subproject layout conventions

[Jason van Zyl]

 reference.
> 
> I see the line with the sub-projects able to be two lines tall.
> The first line would be the parent level, and the second line
> would be the current line.  That way we can have something like
> this at the root level:
> 
>   Alexandria Avalon BCEL ...
> 
> And at the sub-project level, we would be able to have something
> like this:
> 
> Jakarta|  Theory Framework LogKit *Excalibur* Cornerstone Phoenix Apps
>   CLI Collections Concurrent 
> 
> That way we can easily navigate the site, and drill down quickly to
> the actual information we need.
>   
> 
> 

> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: subproject layout conventions

[Jason van Zyl]

On Thu, 2002-03-28 at 01:14, [EMAIL PROTECTED] wrote:
> Jason van Zyl <[EMAIL PROTECTED]> wrote on 28/03/2002 08:15:53 AM:
> 
> > On Wed, 2002-03-27 at 17:13, Leo Simons wrote:
> > > It has been brought up by many people that there
> > > is no common way of organising subproject websites.
> > > I propose we draft a set of guidelines (_not_
> > > rules) on a general structure.
> > 
> > http://jakarta.apache.org/turbine/maven/
> > 
> > There's a sample structure there, with lots of documentation and the
> > printable pages issue is dealt with.
> 
> Hey Jason, don't undersell Maven :) It's a godsend for projects.

I will undersell it until it is at a point where it not only works (it
works fine now) but when it is transparent for clients to absorb changes
that are made. If the project descriptor changes, or the way the process
works, or stylesheets change, or additional documents are added then I
want automatic transformations to upgrade the project descriptor and a
mechanism to allow clients to take advantage of the change immediately
with no hassle. Right now I know of 33 projects using Maven and it is
still a PITA when a change is made and this has to be dealt with before
I would push anything. There are tools in Maven that can deal with XML
xformation (using dvsl) and non XML xformations (using ORO) but they
aren't integrated yet. So I'm still looking for the combination of easy
propagation (the InstallAnywhere installers are getting there) with easy
forward porting. But we're going to release a beta anyway :-)

It works great right now, but the process and mode of communication with
clients is just as important IMO, and the source of most problems. Most
people here could probably get Maven running pretty quickly but it's the
not no experienced developer that I'm targeting.
 
> Not only does Maven provide docs, pages but it also helps with jar file 
> downloading, dependencies, mailing lists, build file reuse, metrics, code 
> cross reference and more.
> 
> Bring it on!

We're getting there.

> > -- 
> > jvz.
> > 
> > Jason van Zyl
> > [EMAIL PROTECTED]
> > 
> > http://tambora.zenplex.org
> 
> --
> dIon Gillard, Multitask Consulting
> Work:  http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: BCEL?

[Jason van Zyl]

On Thu, 2002-03-28 at 09:00, Stefan Bodewig wrote:
> On 28 Mar 2002, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> 
> > I just looked, because I thought there was one, and there is a
> > category for BCEL.
> 
> I have created one with Pier's help just today, should have reported
> here, I guess ;-)

:-) So that was your handy work, I just assume it was there. It's magic!
 
> Stefan
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: BCEL?

[Jason van Zyl]

On Wed, 2002-03-27 at 14:27, Scott Vachalek wrote:
> Hello,
> 
> I have a BCEL bug to report but there doesn't seem to be a category for it in the 
>bug database.  Should it go somewhere else or can you create a category?  

I just looked, because I thought there was one, and there is a category
for BCEL.

-> Enter New Bug Report
-> BCEL (it is down the left column listed with the other components,
you might have missed it because there are so many components.

> Thanks,
> Scott
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: subproject layout conventions

[Jason van Zyl]

On Wed, 2002-03-27 at 17:13, Leo Simons wrote:
> It has been brought up by many people that there
> is no common way of organising subproject websites.
> I propose we draft a set of guidelines (_not_
> rules) on a general structure.

http://jakarta.apache.org/turbine/maven/

There's a sample structure there, with lots of documentation and the
printable pages issue is dealt with.


> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: The Complete Server Platform?

[Jason van Zyl]

On Fri, 2002-03-22 at 02:59, Stefan Bodewig wrote:
> On 21 Mar 2002, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> 
> > I assume that ant is not made to take advantage of a multi-processor
> > box,
> 
> Ant isn't doing too many things that could take advantage of multiple
> processors - it doesn't compile itself but uses your JDK's javac (you
> know that 8-) which won't take advantage of multiple processors for
> example.
> 
> If there are things in your build process that can be done in
> parallel, you can use Ant's  task (Ant >= 1.4) and run them
> in parallel.  This should take advantage of multiple processors if
> your JVM uses native threads.
> 
> If you put  inside , make sure you fork new processes
> though as Sun's javac code doesn't seem to be thread-safe.

Are there any solutions that would make a 4-way machine appear as a
machine with a single processor so that single threaded code can take
advantage of those extra processors transparently? I have a 4-way box
here that is sitting idle here @ zenplex and I may have access to 2
8-way machines but if running ant isn't going to be able to take
advantage of these machines (in some form, don't mind doing some work)
then I might as well run builds on my build box at home.

> Stefan
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: The Complete Server Platform?

[Jason van Zyl]

On Thu, 2002-03-21 at 15:48, Jon Scott Stevens wrote:
> on 3/21/02 8:41 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> 
> > I assume that ant is not made to take advantage of a multi-processor
> > box, (I compiled some code on a quad processor machine and ant didn't
> > really seem to move that much faster then on my laptop) but if I compile
> > ant using gjc would it take advantage of a multi-processor machine?
> 
> How would what is currently a shell script that sets some variables and
> executes a JVM be made to take advantage of a multi-processor box?

I assumed Costin compiled the java goods.
 
> Just because you have multiple processors, it doesn't mean that the load for
> one single process is going to be distributed across them.
> 
> It would take Ant to do all sorts of parallel threading to even get close to
> making that happen and since Ant is really a single threaded application, I
> doubt you will ever see a speed up (native code or JVM code).

I was looking for some magic :-)

> -jon
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Re: Printable pages

[Jason van Zyl]

On Thu, 2002-03-21 at 08:39, Berin Loritsch wrote:
 
> I tried looking at the BCEL manual, and while it looks nice on screen,
> when I
> tried to print it out it cut off almost two inches of text.  

Yup, that's my fault. I will remedy the situation with PDFs. A very long
time ago before Anakia we had PDFs being produced with stylebook. The
Turbine and Velocity docs were actually available in PDF format. Anakia
presented some problems that made it impossible to use the fop stuff we
created but that is different now with DVSL. Long story short: you will
have PDF docs for BCEL sooner rather than later.


> 
> "They that give up essential liberty to obtain a little temporary safety
>  deserve neither liberty nor safety."
> - Benjamin Franklin
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

RE: EJB = bad = MS.net

[Jason van Zyl]

; persistence,
> >
> >Got it: JDBC
> >
> > > transactional services,
> >
> >Got what I need in the JDBC.
> >
> > > security, etc.
> >
> >Got it:  RBAC
> >
> > >better than all those people?
> >
> >Most of this can be done fairly simply and most people just don't need
> >what the appserver vendors are selling.
> >
> >If you had said 2 phase commit, then I'd make concessions.
> >
> > >Wow,
> > > your the man.
> >
> >Thanks.
> >
> > >If I could create a product by myself better than all those
> > > people and create a billion dollar company I would. Seems stupid not
> >to?
> > > Kind of strange you call 'people' stupid
> >
> >Just to be clear.  I never called anyone stupid.  I never used the word.
> >That was in the subject line that I replied to.  I didn't notice it till
> >someone else replied.  I would have taken it out. (as I just did.)
> >
> >and claim you can do better than
> > > these teams at creating this monumental amount of complex code
> >
> >No.  I use a good amount of clear code.
> >
> >  yet you
> > > don't
> > > do it, even though it could bring you great wealth? Ok then, how about
> > > open
> > > source?
> >
> >Oh, I am a contributor to a couple of Jakarta projects but have no
> >intension of building an appserver.
> >
> >Cheers,
> >
> >Aaron
> >
> >
> >
> >--
> >To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
> 
> 
> 
> 
> _
> MSN Photos is the easiest way to share and print your photos: 
> http://photos.msn.com/support/worldwide.aspx
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


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

Non Distributable Jars

[Jason van Zyl]

Hi,

Did someone get that list together of JARs that we can't distribute?

I removed the JAF jar from turbine's projects and David Taylor did it for
Jetspeed. Is it correct that the JDBC jar can't be distributed via CVS as
well?

-- 

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

Re: PMC Nomination - Jason van Zyl

[Jason van Zyl]

On 1/31/02 5:00 PM, "Kurt Schrader" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I would like to nominate Jason Van Zyl for the PMC.  Jason is a current
> PMC member, is a (very) active Turbine developer, founded the Velocity
> project, has participated in any number of Jakarta projects, and strikes
> me as an overall a great guy.  He is also the type of person that
> lets his actions (with regards to consistently supporting users while
> still outputting a massive amount of code) speak louder than his words,
> and I think that we can always use a few more people like that around here.
> 

Thanks, but I have to decline. My commitment to Tambora takes precedence so
I honestly won't have much time for Jakarta.

Geir has also agreed to take over my current cvs admin responsibilities. So
anyone who has made requests from me for cvs access can now ask Geir.

-- 

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

Re: BCEL project bug database

[Jason van Zyl]

On 1/24/02 12:22 PM, "Stephen Cheng" <[EMAIL PROTECTED]> wrote:

> Hello comrades,
> 
> Is there a bug database for BCEL? I have found a bug in BCEL but
> unfortunately the project had not been added yet to
> http://nagoya.apache.org/bugzilla/.

You can post the bug here for now.

> Thanks,
> Stephen
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [PROPOSAL] POI @ Jakarta

[Jason van Zyl]

On 1/17/02 2:45 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> Proposal for "POI" - A Jakarta Subproject
> version 1.0 - 17 Jan 2002

+1

-- 

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

Re: [PROPOSAL] Jakarta PMC bylaws change

[Jason van Zyl]

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

> The number of PMC seats will be set at seven.  Annually, all seven seats
> will be up for renewal.  The ASF board will be asked to provide a person or
> persons to administer the nominations and a subsequent ballot. The
> administrator(s) will determine the mechanics of the voting procedures.
> Any committer to any Jakarta code base will be eligible to vote.  Once the
> new PMC is in place, the first order of business will be to determine a
> chairperson from amongst their ranks.
> 
> Once ratified, this proposal would be effective immediately, and an
> election would be initiated.

+1

> - Sam Ruby
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Re: Coding style addition

[Jason van Zyl]

On 12/15/01 4:41 PM, "Kevin A. Burton - burtonator" <[EMAIL PROTECTED]>
wrote:

> 
> Has this been accepted as psuedo standard across Jakarta?

No, each project has it's own coding style. There's no Jakarta wide
standard.
 
> http://jakarta.apache.org/turbine/common/code-standards.html
> 
> I agree with 90% of it.
> 
> Also... I have noticed that a lot of code isn't formated to column 80.  A lot
> of
> people aren't even trying!  :(
> 
> What do people think of this as an addition?

I think allowing each project to define what is acceptable is the way it's
working now and it's probably best to leave it that way.
 
> Kevin

-- 

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

Re: MY query regarding web.xml

[Jason van Zyl]

On 12/3/01 10:38 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Dear friends i had posted a problem with a web.xml file but havent received
> any response from the jakarta family .

Post the question to the tomcat users's list. You can find out about that
mailing list in this document:

http://jakarta.apache.org/site/mail2.html
 
> Whats wrong !!!

You posted to the wrong list. This mailing list is for general discussions
relating to Jakarta and Java, not for project specific questions.
 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

BCEL @ Jakarta

[Jason van Zyl]

Hi,

Here's a summary of the PMC voting with respect to moving BCEL
to Jakarta:

[+1] Peter Donald
[+1] Pierpaolo Fumagalli
[+1]Ted Husted
[ ] Ceki Gülcü
[+1] Geir Magnusson Jr.
[ ] Vincent Massol
[+1] Craig McClanahan
[+1] Sam Ruby
[+1] Daniel Savarese
[+1] Jon Stevens
[+1] Jason van Zyl

This gives us the 3/4 PMC approval rating so I believe BCEL will be moving
to Jakarta unless Ceki and/or Vincent express disapproval. We'll let this
float for another day or two to let anyone get their votes/concerns
registered.

-- 

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

Re: Distributing the JSSE

[Jason van Zyl]

On 10/23/01 2:38 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:

> on 10/23/01 10:40 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> 
>> I want to distribute the JSSE jars with the Turbine Development Kit but I'm
>> not entirely sure if it's legal. On the JSSE website it says that "the
>> binary implementation may be used royalty-free as part of commercial
>> applications", but in the license it says for internal use only?
> 
> It is not legal.

If that is indeed the case does anyone know of any JSSE implementations that
can be distributed?
 
> -jon
> 
> 
> -
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Distributing the JSSE

[Jason van Zyl]

Hi,

I want to distribute the JSSE jars with the Turbine Development Kit but I'm
not entirely sure if it's legal. On the JSSE website it says that "the
binary implementation may be used royalty-free as part of commercial
applications", but in the license it says for internal use only?

Here's the lic:

http://java.sun.com/products/jsse/LICENSE.txt

-- 

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

Re: ImportScrubberTask

[Jason van Zyl]

On 10/22/01 1:04 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:

> on 10/22/01 6:22 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> 
>> It works fine, but there is a problem with the imports being placed in the
>> wrong place when there is text right after the package declaration. I asked
>> Tom Copeland to fix this for me and he said he would get to it today. It
>> does the job correctly, it just doesn't put the imports in the right place.
> 
> Run the ant target that I pasted here against Scarab and you will see that
> it does NOT work fine at all. I pasted it here so that I wouldn't get a
> response like you just gave me.

I only ran it on a small body of source, but Scarab is a good test bed.
 
> Here is an example of some imports it f*cked up:
> 
> [196][ src/org/tigris/scarab/om ]% more Attachment.java
> package org.tigris.scarab.om;
> 
> import text.plain;
> import org.apache.fulcrum.upload.FileItem;
> import org.apache.torque.om.NumberKey;
> import org.apache.torque.om.Persistent;
> 
> I never knew that text.plain is a proper import. :-)
> 
> Here is another one:
> 
> [197][ src/org/tigris/scarab/om ]% more IssueTemplateInfo.java
> package org.tigris.scarab.om;
> 
> import email.RequireApproval.vm;
> import org.apache.turbine.Turbine;
> import org.apache.fulcrum.template.TemplateContext;
> import org.apache.torque.om.NumberKey;
> import org.apache.torque.om.UnsecurePersistent;
> import org.tigris.scarab.security.ScarabSecurity;
> import org.tigris.scarab.security.SecurityFactory;
> import org.tigris.scarab.tools.Email;
> import org.tigris.scarab.util.ScarabException;
> import org.tigris.scarab.services.module.ModuleEntity;
> 
> Wow. When did Velocity files become ok to import? :-)

But it did a pretty good job, I think after a couple rounds of fixes it will
be fine.
 
> It appears that in its search through files, it finds any mention of a
> "foo.bar" and sticks it into an import. That does not seem like a very good
> assumption.

Poking around in the constants pool isn't necessarily straight forward even
though BCEL makes it much easier.
 
> Another problem I noticed is that it imports java.util.Set when it doesn't
> need to as well.

I think that's a superclass problem. Same thing I ran into with the little
hack I whipped up.
 
> Yes, I compiled with debugging on.
> 
> I'm starting to think that post processing JAD (the java decompiler) output
> would be a better idea.

I think in a couple of days it will do the trick just fine. I ran it on the
Tambora source and it wasn't that bad. It doesn't work yet but it's pretty
close.
 
> -jon
> 
> 
> -
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Vote] BCEL @ Jakarta

[Jason van Zyl]

On 10/22/01 9:55 AM, "Pier Fumagalli" <[EMAIL PROTECTED]> wrote:

> Jason van Zyl at [EMAIL PROTECTED] wrote:
> 
>> Hi,
>> 
>> I now have a proposal for BCEL which can be found here:
>> 
>> http://www.apache.org/~jvanzyl/jakarta-bcel
>> 
>> +1
> 
> I like their project, the only thing I'm concerned about it is here:
> <http://bcel.sourceforge.net/licensing.html>

Markus has agreed to change the licensing strictly over to the AL.
 
> We can't really keep dual licensing with LGPL, do the folks over there know
> about it? Because on their page they wrote (quote) "I strongly encourage
> users to use the LGPL license and participate fully in the free software
> community."
> 
> That's doesn't sound very "ASF-like"... :) :) But I'm not subbed on their
> lists, and I don't know the folks over there... Any comment? (Would love to
> hear from them directly, too! Feel free to forward)
> 
>   Pier
> 
> 
> -------------
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ImportScrubberTask

[Jason van Zyl]

On 10/21/01 11:52 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:

> on 10/21/01 8:40 PM, "Pier Fumagalli" <[EMAIL PROTECTED]> wrote:
> 
>> Jon Stevens at [EMAIL PROTECTED] wrote:
>> 
>>> <http://importscrubber.sourceforge.net/ant.html>
>>> 
>>> org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrubberTask
>>> 
>>> Given that this isn't an official Jakarta project, shouldn't the tool choose
>>> another namespace?
>> 
>> Indeed...
>> 
>>   Pier
>> 
> 
> That said, I just tried running importscrubber against Scarab's code and it
> totally f*cked it up. I highly recommend not using it or at least being very
> careful with it.
> 

It works fine, but there is a problem with the imports being placed in the
wrong place when there is text right after the package declaration. I asked
Tom Copeland to fix this for me and he said he would get to it today. It
does the job correctly, it just doesn't put the imports in the right place.

-- 

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

[Vote] BCEL @ Jakarta

[Jason van Zyl]

Hi,

I now have a proposal for BCEL which can be found here:

http://www.apache.org/~jvanzyl/jakarta-bcel

+1

-- 

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

Re: BCEL @ Jakarta

[Jason van Zyl]

On 10/8/01 6:07 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> There wasn't one for Lucene, but I'd like to get back on track. My
> proposal for the Commons is here:
> 
> http://www.mail-archive.com/general@jakarta.apache.org/msg00626.html

Cool. Thanks Ted.
 
> Jason van Zyl wrote:
>> 
>> On 10/8/01 3:24 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
>> 
>>> Jason, could we have a proposal here?
>> 
>> Sure, not a problem. Do we archive the proposals somewhere? I'm trying to
>> find the lucene one so I can use it as a template.
>> 
>>> Creation of subprojects
>>> 
>>> PMC members may propose the creation of new subprojects. Proposals are
>>> to
>>> contain the scope of the project, identify the initial source from which
>>> the project is
>>> to be populated, identify the mailing list(s) if any which are to be
>>> created, and
>>> identify the initial set of committers. Creation of a new subproject
>>> requires approval
>>> by 3/4 vote of the PMC.
>>> 
>>> I agree that there seems to be support, but lacking a BCEL community we
>>> really need to address things like whow the 3+ committers will be.
>>> 
>>> We can then call for a [VOTE] on the proposal.
>>> 
>>> -- Ted Husted, Husted dot Com, Fairport NY USA.
>>> -- Custom Software ~ Technical Services.
>>> -- Tel +1 716 737-3463
>>> -- 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: BCEL @ Jakarta

[Jason van Zyl]

On 10/8/01 3:24 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> Jason, could we have a proposal here?

Sure, not a problem. Do we archive the proposals somewhere? I'm trying to
find the lucene one so I can use it as a template.
 
> Creation of subprojects
> 
> PMC members may propose the creation of new subprojects. Proposals are
> to
> contain the scope of the project, identify the initial source from which
> the project is
> to be populated, identify the mailing list(s) if any which are to be
> created, and
> identify the initial set of committers. Creation of a new subproject
> requires approval
> by 3/4 vote of the PMC.
> 
> I agree that there seems to be support, but lacking a BCEL community we
> really need to address things like whow the 3+ committers will be.
> 
> We can then call for a [VOTE] on the proposal.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
> 
> Jason van Zyl wrote:
>> 
>> Hi,
>> 
>> Markus has just informed me that he has removed the GNU regexp dependency
>> from the BCEL and is using the Jakarta Regexp package.
>> 
>> I think it was generally agreed that the package is complete, highly useful
>> and many people expressed an interested in having it be a Jakarta project.
>> Markus has already made a first pass at organizing the source in a Jakarta
>> like format and I have offered to help with the rest of work if we agree to
>> accept the package into Jakarta.
>> 
>> So, for the movement of BCEL to apache I would like to vote
>> 
>> +1
>> 
>> --
>> 
>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: BCEL's first Jakarta version

[Jason van Zyl]

On 10/8/01 11:22 AM, "Markus Dahm" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> this is my first "Jakarta" version of BCEL, please take a look at it. I'm
> using Jakarta's Regex now (I wanted something lightweight). I also took
> the chance to reorganize and clean up some things (see README).
> 
> You can download it at
> 
> ftp://ftp.inf.fu-berlin.de/pub/BCEL/jakarta/BCEL.tar.gz
> 
> Any help would be appreciated

Cool, I didn't see this until I responded to the message to sent to my
mailbox :-)

I think it's looking pretty good. I volunteer to help with any of the bits
that might still need to be done.

 
> Cheers
> Markus

-- 

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

BCEL @ Jakarta

[Jason van Zyl]

Hi,

Markus has just informed me that he has removed the GNU regexp dependency
from the BCEL and is using the Jakarta Regexp package.

I think it was generally agreed that the package is complete, highly useful
and many people expressed an interested in having it be a Jakarta project.
Markus has already made a first pass at organizing the source in a Jakarta
like format and I have offered to help with the rest of work if we agree to
accept the package into Jakarta.

So, for the movement of BCEL to apache I would like to vote

+1

-- 

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

Re: BCEL @ apache

[Jason van Zyl]

On 10/1/01 11:31 AM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:

> on 10/1/01 7:56 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> 
>> Hi,
>> 
>> Many months ago I asked Markus Dahm whether or not he would be interested in
>> BCEL (Byte Code Engineering tool) being a Jakarta project as I was using and
>> thought it a very cool package, and I believe Xalan uses it for their
>> compiler, but nothing resulted from the initial conversation.
>> 
>> Markus has approached me now stating that he would be interested in BCEL
>> becoming a Jakarta project so I thought I would see what others thought.
>> BCEL has many applications including compilers, analysis tools and who knows
>> what else.
>> 
>> Thoughts?
> 
> What is his developer/user community like?

I belong to the mailing list and there is never that much traffic but I
think that's due to the completeness of the tool. As it is based on the
language spec it is pretty much finished as a tool. Markus can correct me if
I'm wrong. Maybe there are changes in Merlin that will need to be
accomodated, I don't know.

I think it is primarily Markus who works on it which is why he wants to
consider giving it to Apache. He won't have time to maintain it.
 
> I'm leaning towards being conservative and saying that we don't need another
> project right now since we just added Lucene and moved Cactus to a TLP (top
> level project).

I don't think there is a rush, but I think BCEL is an amazingly powerful
tool with many possibilities. I don't think it would add a lot of overhead
as it is a very specialized tool and the mailing traffic is pretty minimal.

I would volunteer to help the move if it was decided to move it to jakarta.
 
> -jon
> 
> 
> ---------
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: BCEL @ apache

[Jason van Zyl]

On 10/1/01 11:50 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Jason van Zyl wrote:
>> 
>> Many months ago I asked Markus Dahm whether or not he would be interested in
>> BCEL (Byte Code Engineering tool) being a Jakarta project as I was using and
>> thought it a very cool package, and I believe Xalan uses it for their
>> compiler, but nothing resulted from the initial conversation.
>> 
>> Markus has approached me now stating that he would be interested in BCEL
>> becoming a Jakarta project so I thought I would see what others thought.
>> BCEL has many applications including compilers, analysis tools and who knows
>> what else.
> 
> Velocity depends on BCEL's predecessor - JavaClass.  Avalon's Excalibur
> includes a GNU licensed competitor named gnu.bytecode from a package named
> Kawa, but no longer seems to be depending on it.
> 
> I see this as an indication that there is an interest in such
> functionallity by Java based Apache projects, but I would prefer to
> understand the history behind Velocity and Excalibur's choices before
> proceeding.

I simply found the tool comprehensive, well documented and pretty easy to
use. In Velocity I have only ever played around trying to make a compiler,
only only place I've really used it is in making a simple import statement
qualifier.

As I said, I believe the tool is being used by Xalan for their compiler and
I think BCEL could be used to make compilers for tomcat. There is also some
dependency code in one of the optional Ant packages that uses byte code
analysis to check for dependencies and it could use BCEL.

The BCEL package comes with a pretty nifty example language and compiler.
For a tool that deals with fairly complex subject matter it is quite easy
to use.
 
> - Sam Rubyb
> 
> 
> -------------
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: BCEL @ apache

[Jason van Zyl]

On 10/1/01 11:13 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> 
> Hi Jason,
> 
> You should perhaps include a link to BCEL (http://bcel.sourceforge.net/)

Good idea! Thanks Ceki :-)

> Regards, Ceki
> 

-- 

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

BCEL @ apache

[Jason van Zyl]

Hi,

Many months ago I asked Markus Dahm whether or not he would be interested in
BCEL (Byte Code Engineering tool) being a Jakarta project as I was using and
thought it a very cool package, and I believe Xalan uses it for their
compiler, but nothing resulted from the initial conversation.

Markus has approached me now stating that he would be interested in BCEL
becoming a Jakarta project so I thought I would see what others thought.
BCEL has many applications including compilers, analysis tools and who knows
what else.

Thoughts?

-- 

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

Re: [VOTE] Making Commons-Cactus a top level projet

[Jason van Zyl]

+1

-- 

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

Re: [Lucene-dev] FW: Lucene Acceptance

[Jason van Zyl]

On 9/11/01 2:01 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:

> on 9/11/01 8:55 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> 
>> There's one
>> piece that someone of root authority needs to do, and I'll coordinate that
>> part.
> 
> Including getting a list of people who need commit access.

I'm getting the list together now. I've had a few responses so far so
hopefully the list will be complete soon. I will pass the info on to Sam
when I have all the pertinent info.
 
> -jon
> 
> 
> -
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Lucene-dev] FW: Lucene Acceptance

[Jason van Zyl]

On 9/11/01 11:17 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> Jason van Zyl wrote:
>> I will join the lucene mailing list and we can work together from there to
>> move down the list of things to get done. Hopefully we can encourage the
>> existing developers to pitch in some time too to move things along.
> 
> Jason, 
> 
> I see that zenplex has a NYC address, but don't know if that is where
> you are situate. So if I don't hear from you, I'll assume you're caught
> up in the turmoil.

I am in Canada, probably the safest place in the world, so I am fortunate to
say that I'm ok. 
 
> Meanwhile, I'd say we should get the site and CVS setup for them, but
> expect the committers to repackage Lucene, and upload it to the CVS.

Sounds good.
 
> If you are in a position to get the intial mailing lists and CVS setup
> up, and have Apache accounts created for the committers, with karma for
> the Lucene CVS, let me know.

I will gather the names of the committers and pass the info on the Sam or
Brian so they can make the accounts. I'll also make the request for the
mailing lists.

Do we know that all the current lucene committers have agreed to the switch?

> In the meantime, I'll continue work on the
> Web site part of it so that is ready to post.

Ok.
 
> (I hope no one minds keeping up with business-as-usual during these
> troubling times. But if the rest of us don't carry on, then the
> terrorists win. That we cannot have.)
 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/about/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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Lucene-dev] FW: Lucene Acceptance

[Jason van Zyl]

On 9/10/01 5:58 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> After being blind-sided by some other things, I'm actually ready to
> begin. 
> 
> Jason mentioned that he wanted to help, but hasn't gotten back.

Ted,

I'm now subscribed to the lucene developer's list. I'll send a quick note to
the list (if you haven't already) asking if any progress has been made on
the initial list Jon made.
 
> Just proceed down your list from the Lucene mailing list?
> 
> < http://www.geocrawler.com/archives/3/2626/2001/6/100/5924381/ >
> 


-- 

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

Re: [Lucene-dev] FW: Lucene Acceptance

[Jason van Zyl]

On 9/10/01 5:58 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> After being blind-sided by some other things, I'm actually ready to
> begin. 
> 
> Jason mentioned that he wanted to help, but hasn't gotten back.

I will join the lucene mailing list and we can work together from there to
move down the list of things to get done. Hopefully we can encourage the
existing developers to pitch in some time too to move things along.
 
> Just proceed down your list from the Lucene mailing list?
> 
> < http://www.geocrawler.com/archives/3/2626/2001/6/100/5924381/ >
> 
> -T.
> 

-- 

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

Re: Lucene Acceptance

[Jason van Zyl]

On 8/12/01 4:57 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> Jon Stevens wrote:
>> If you would like to take over and do the move, then that would be great. I
>> have sent several emails to the Lucene list with instructions on what needs
>> to be done. Check their list archives.
> 
> OK, I found this:
> 
> < http://www.geocrawler.com/archives/3/2626/2001/6/100/5924381/ >
> 
> I'm out of town most of this week, but will start stepping down the list
> if no one else is working on it.

I'm willing to help too, just back from a few days off but I use Lucene for
several things and would like to see the move happen sooner rather than
later :-)
 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/about/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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RFC] Re: Helma XML-RPC @ Jakarta

[Jason van Zyl]

On 7/11/01 12:29 PM, "Ted Leung" <[EMAIL PROTECTED]> wrote:

> The XML PMC has voted to accept Helma XML-RPC as an xml.apache.org project.
> 
> Unless somone from xml.apache.org voices a serious objection by the end of
> Thursday,
> we'll start the wheels turning to create the project.

Cool and the Gang :-) I will have everything ready for import by
Friday, so I'll coordinate with Sam as it looks like everything
is a go. 

I would like to use Anakia to generate the docs, is this acceptable?
I already have the docs converted to Anakia so I'd like to use
what I have.
 
> Ted
> - Original Message -
> From: "Ted Leung" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, July 06, 2001 10:12 AM
> Subject: [RFC] Re: Helma XML-RPC @ Jakarta
> 
> 
>> Does anyone else from xml.apache.org have any feedback on this proposal
>> one way or the other?
>> 
>> Ted
>> - Original Message -
>> From: "Sam Ruby" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>
>> Sent: Thursday, July 05, 2001 6:09 PM
>> Subject: Re: Helma XML-RPC @ Jakarta
>> 
>> 
>>> Jason van Zyl wrote:
>>>> 
>>>> Fair enough, I will no longer argue the point. My main concern is that
>>>> the project be granted full autonomy as a project initially as Hannes
>>>> and the rest of the committers become accustomed to xml.apache.org
> than
>>>> we can discuss the possible integration with Axis.
>>>> 
>>>> Does this sound reasonable?
>>> 
>>> +1
>>> 
>>> I'll even volunteer to set up the mailing lists, cvs trees,
> authorization,
>>> etc.  And, of course, integrate it into Gump.  ;-)
>>> 
>>> - Sam Ruby
>>> 
>>> 
>>> -
>>> In case of troubles, e-mail: [EMAIL PROTECTED]
>>> To unsubscribe, e-mail:  [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>> 
>> 
>> 
>> -
>> In case of troubles, e-mail: [EMAIL PROTECTED]
>> 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]

-- 

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

Re: Helma XML-RPC @ Jakarta

[Jason van Zyl]

On 7/6/01 1:08 PM, "Ted Leung" <[EMAIL PROTECTED]> wrote:

> One caveat.  Let the XML PMC have it's vote on this.  I'm sending the vote
> request in 2 minutes.

I'm a positive thinker :-)

> Ted
> ----- Original Message -
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, July 06, 2001 6:54 AM
> Subject: Re: Helma XML-RPC @ Jakarta
> 
> 
>> On 7/5/01 9:09 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>> 
>>> Jason van Zyl wrote:
>>>> 
>>>> Fair enough, I will no longer argue the point. My main concern is that
>>>> the project be granted full autonomy as a project initially as Hannes
>>>> and the rest of the committers become accustomed to xml.apache.org than
>>>> we can discuss the possible integration with Axis.
>>>> 
>>>> Does this sound reasonable?
>>> 
>>> +1
>>> 
>>> I'll even volunteer to set up the mailing lists, cvs trees,
> authorization,
>>> etc.  And, of course, integrate it into Gump.  ;-)
>> 
>> Cool, so can we coordinate next week sometime. Maybe toward the
>> end of the week we can populate the repository?
>> 
>>> - Sam Ruby
>>> 
>>> 
>>> -
>>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
> 
> 
> -
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Helma XML-RPC @ Jakarta

[Jason van Zyl]

On 7/5/01 9:09 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Jason van Zyl wrote:
>> 
>> Fair enough, I will no longer argue the point. My main concern is that
>> the project be granted full autonomy as a project initially as Hannes
>> and the rest of the committers become accustomed to xml.apache.org than
>> we can discuss the possible integration with Axis.
>> 
>> Does this sound reasonable?
> 
> +1
> 
> I'll even volunteer to set up the mailing lists, cvs trees, authorization,
> etc.  And, of course, integrate it into Gump.  ;-)

Cool, so can we coordinate next week sometime. Maybe toward the
end of the week we can populate the repository?

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

Re: Helma XML-RPC @ Jakarta

[Jason van Zyl]

On 7/5/01 1:08 PM, "Ted Leung" <[EMAIL PROTECTED]> wrote:

> Hello all,
> 
> It is not true that there is no interest in XML-RPC at xml.apache.org.  I
> would be
> amenable to / in-favor of XML RPC being an independent project under
> xml.apache.org.  I would prefer it if we could find a way to make this fit
> in with Axis,
> assuming that the respective committers can get along and make it work.

We would prefer that the project be independent at first. None of the
initial committers have much experience with xml.apache.org and would
like to gradually move toward collaborating. As I've said before this
is a self contained project and it is used that way. I have no doubt
that the code can be integrated into Axis in some form, but this
is not our primary motive for bringing the code to apache.
 
> The whole point of having a separate XML project is for XML related
> code-bases
> to go there.  With a name like XML-RPC, it is hard to argue that XML-RPC
> is not an XML related project.  Please don't try to circumvent the structure
> that the ASF
> has put in place.   As someone pointed out, If we were talking about a C or
> C++
> implementation of XML-RPC, then I don't think we would be arguing about
> where this
> particular code base belongs.

Fair enough, I will no longer argue the point. My main concern is that
the project be granted full autonomy as a project initially as Hannes
and the rest of the committers become accustomed to xml.apache.org than
we can discuss the possible integration with Axis.

Does this sound reasonable?

 
> Ted Leung
> Chair XML PMC
> 
> - Original Message -
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, July 05, 2001 7:18 AM
> Subject: Re: Helma XML-RPC @ Jakarta
> 
> 
>> On 7/5/01 7:55 AM, "Pier P. Fumagalli" <[EMAIL PROTECTED]> wrote:
>> 
>>> Hannes Wallnoefer at [EMAIL PROTECTED] wrote:
>>>> 
>>>> To put it right upfront, I don't think XML-RPC is a natural fit for
>>>> xml.apache.org, and I'd prefer to see it at Jakarta. Let me explain.
>>> 
>>> Even though I see your point, I'd still prefer seeing it over in XML
>>> alongside with the other technologies doing the same exact thing...
>>> 
>>> Jakarta has alrady a wide enough spectrum of problems covered (from
> build
>>> systems, to ioc frameworks). From what I can see, XML-RPC is based on
> XML
>>> (or a subset of it), is used to transmit objects and call methods over
> HTTP
>>> (same as SOAP), s, since it's an alternative to SOAP, it should go
>>> alongside with it.
>>> 
>>> -1 for XML-RPC on Jakarta...
>> 
>> So you would be amenable to the XML-RPC package being an independent
>> project under the xml.apache.org banner?
>> 
>>>   Pier
>>> 
>>> 
>>> -
>>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
> 
> 
> -
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Helma XML-RPC @ Jakarta

[Jason van Zyl]

On 7/5/01 7:55 AM, "Pier P. Fumagalli" <[EMAIL PROTECTED]> wrote:

> Hannes Wallnoefer at [EMAIL PROTECTED] wrote:
>> 
>> To put it right upfront, I don't think XML-RPC is a natural fit for
>> xml.apache.org, and I'd prefer to see it at Jakarta. Let me explain.
> 
> Even though I see your point, I'd still prefer seeing it over in XML
> alongside with the other technologies doing the same exact thing...
> 
> Jakarta has alrady a wide enough spectrum of problems covered (from build
> systems, to ioc frameworks). From what I can see, XML-RPC is based on XML
> (or a subset of it), is used to transmit objects and call methods over HTTP
> (same as SOAP), s, since it's an alternative to SOAP, it should go
> alongside with it.
> 
> -1 for XML-RPC on Jakarta...

Would anyone else on the Jakarta PMC care to vote?

I think there are 10 Jakarta PMC members can we get a quick
vote. So if anyone else has a -1 than that will put an end
to the proposal, right? We need 8/10 for the 3/4 minimum so
one more -1 and it's a goner.

So, this is for the inclusion the XML-RPC package in Jakarta

[  ]Peter Donald
[-1]Pier Fumagalli
[  ]Ted Husted
[  ]Ceki Gülcü
[  ]Geir Magnusson
[  ]Craig McClanahan
[-1]Sam Ruby
[  ]Dan Savarese
[  ]Jon Stevens
[+1]Jason van Zyl

I would like to try this avenue first as it's what the author wants.

-- 

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

Re: Helma XML-RPC @ Jakarta

[Jason van Zyl]

On 7/5/01 7:55 AM, "Pier P. Fumagalli" <[EMAIL PROTECTED]> wrote:

> Hannes Wallnoefer at [EMAIL PROTECTED] wrote:
>> 
>> To put it right upfront, I don't think XML-RPC is a natural fit for
>> xml.apache.org, and I'd prefer to see it at Jakarta. Let me explain.
> 
> Even though I see your point, I'd still prefer seeing it over in XML
> alongside with the other technologies doing the same exact thing...
> 
> Jakarta has alrady a wide enough spectrum of problems covered (from build
> systems, to ioc frameworks). From what I can see, XML-RPC is based on XML
> (or a subset of it), is used to transmit objects and call methods over HTTP
> (same as SOAP), s, since it's an alternative to SOAP, it should go
> alongside with it.
> 
> -1 for XML-RPC on Jakarta...

So you would be amenable to the XML-RPC package being an independent
project under the xml.apache.org banner?
 
>   Pier
> 
> 
> -
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Helma XML-RPC @ Jakarta

[Jason van Zyl]

On 7/4/01 10:04 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Hannes Wallnoefer wrote:
>> 
>> [snip]
> 
> Short and simple: -1.  Good luck getting 3/4 approval...
> 
> Want to change my vote?

I don't think there's anything to change. You decided what you what
you wanted very shortly after the proposal was made. That much is clear,
even if your answers are not.

I answered your questions as best I could, but you completely skirted
around answering any of my questions. I asked what you would do
with the code if it were brought into xml.apache.org and
I wanted to know what the interest is in xml-rpc, and why no one
has taken the steps to move toward an xml-rpc implementation in
axis?

Are these not valid questions and concerns? You are the one intimately
involved with xml.apache.org, so I assume you could answer these
questions quickly.

> Demonstrate some signs that you are willing to
> work with others,

I have been working with Hannes and the initial committers for the
last month to get to this point. I am interested in the xml-rpc package.
You are being unequivocally evasive. I don't think you're being very
cooperative. I asked what your proposal would be if the code was
to be donated to xml.apache.org and you didn't even bother to
answer. Is the answer supposed to be obvious? It's not obvious to me.
I think it's important that the code comes here, we have
our preferences as to the location but the code is used by
a lot of people and it would be a healthy project at apache.

> or are at least aware of related work.

I am aware of other xml-rpc packages, as I must emphasize that
is what I'm interested in.

> Criticize SOAP or
> the Apache implementation thereof if you like - I can take it.

I have absolutely nothing against SOAP, or your implementation of
it. I haven't looked that much at SOAP because none of the projects
I work on require it's use. To me, SOAP and xml-rpc are mutually
exclusive because that is the nature of my work. If xml-rpc is
to be a subset of axis than the real nature of the arrangement
is that you need xml-rpc but we don't need axis.

> Start with
> introducing yourself on the [EMAIL PROTECTED] mailing list.

I have zero interest in axis at the moment. Why is the onus on me
to participate in something in which I have no interest and no
requirement to be involved with. The xml-rpc package works fine
as a stand-alone piece of work. I am fully willing to work on the
xml-rpc package, but I'm certainly not going to stop you from integrating
the package into axis. I don't see why you see this as not cooperating,
it is simply not the domain I work in.

You can correct me if I'm wrong, but I think your proposal would
be the folding of the xml-rpc code into axis and forcing users currently
using xml-rpc by itself to use xml-rpc through axis instead. This is
expressly something we do not desire.

This is what I'm deducing from your emphasis on axis and lack of clear
answers to very direct questions.

What do you feel about the xml-rpc package being an independent project
at xml.apache.org? As a starting point for cooperation between the xml-rpc
package and axis. How is that for meeting half way? Then the the
collaboration would begin as two autonomous parties.

I would first like ask for votes from the Jakarta PMC members to see
if the package can be included within Jakarta as this is the express
desire of the author. I will make another short message with a voting
form.

If this fails than I will make a proposal to xml.apache.org if the
package could be accepted as an independent project (if this is acceptable
to Hannes). If the code is allowed to exist autonomously than I don't
have a real problem with where it lands. But I definitely don't like the
idea of the code being rolled into another package because right off the bat
we would probably be in a minority situation and the code could go in a
direction that we don't want. I don't believe that is right. But again Sam,
correct me if my assertions are in the wrong.

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

Re: Helma XML-RPC @ Jakarta

[Jason van Zyl]

On 7/3/01 8:56 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Jason van Zyl wrote:
>> 
>> You have totally side stepped the fact that no at xml.apache.org is
>> interested in XML-RPC. What exactly is the interest level in
>> XML-RPC? I honestly don't know a whole lot about SOAP, but I have
>> been using XML-RPC for a long while now and it's simple and works
>> great.
> 
> Hmmm.  I guess it is fair to say that Turbine is not interested in
> integrating with Cocoon.  If you ignore the recent warm welcome that Berin
> has seen, and focus just on the fact that this work has never bubbled to
> the top of any existing turbine committers todo list, then I guess it must
> be true.

I would definitely say that is a fair summation. No one is interested
or someone would be working on it. Berin is now, out of a requirement
and that¹s great if Turbine and Cocoon work together eventually
that's great. 
 
> XML-RPC has not bubbled to the top of my todo list at the moment.

That's because you have no real need for it I would say. It
fits in with the plans for axis but it seems xml-rpc hasn't
bubbled anywhere near the top of anyone's todo list. I might
eventually use axis, but integrating xml-rpc into axis isn't
on the top of my todo list either.

> But I
> will warmly welcome anybody who wishes to work on it.

But that's never happened though, has it? The presence
of an xml-rpc package at apache may cause someone to
pick up that torch but I don't see why the package
being at xml.apache.org would improve those odds.
 
>> If you are suggesting that the code be immediately be absorbed
>> into xml-soap than I definitely don't agree. Is that what you're
>> suggesting?
> 
> Can you honestly say that you have done your homework?

Again you are not answering the question. What homework do I have to
do Sam? I proposed a package that is self contained, self sustaining,
and completely independent of any other project at Apache. It may
certainly be related to other projects, I agree with that. But
my immediate concern is a home for the package, not trying to
integrate it with axis.
 
> All I ask is that if/when you do, you approach the problem with an open
> mind and a can do attitude, not simply look for reasons why it can't work.

I still don't know what you mean exactly by 'can't work' work because
so far it is entirely unclear what you would actually do with the code.

Let's say I'm Hannes and offer you the XML-RPC code, what exactly
is the proposal you would make on [EMAIL PROTECTED] A simple paragraph
stating what you would like to do with the code would help me a lot in
understanding your POV.

I have tried to contact Hannes to see what he thinks, I've asked
him to join the list and join the discussion.

> And I will promise to meet you more than half way.

I would be glad to meet you half way when I know what direction you're
walking in.
 
> - Sam Ruby
> 
> 
> -
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]