You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-dev@jakarta.apache.org by hc...@apache.org on 2005/01/19 12:01:15 UTC
cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE README
hchar 2005/01/19 03:01:15
Added: auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE
README
Log:
no message
Revision Changes Path
1.1 jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache/build.xml
Index: build.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!-- You may freely edit this file. See commented blocks below for -->
<!-- some examples of how to customize the build. -->
<!-- (If you delete it and reopen the project it will be recreated.) -->
<project name="cache" default="default" basedir=".">
<description>Builds, tests, and runs the project cache.</description>
<import file="nbproject/build-impl.xml"/>
<!--
There exist several targets which are by default empty and which can be
used for execution of your tasks. These targets are usually executed
before and after some main targets. They are:
-pre-init: called before initialization of project properties
-post-init: called after initialization of project properties
-pre-compile: called before javac compilation
-post-compile: called after javac compilation
-pre-compile-single: called before javac compilation of single file
-post-compile-single: called after javac compilation of single file
-pre-compile-test: called before javac compilation of JUnit tests
-post-compile-test: called after javac compilation of JUnit tests
-pre-compile-test-single: called before javac compilation of single JUnit test
-post-compile-test-single: called after javac compilation of single JUunit test
-pre-jar: called before JAR building
-post-jar: called after JAR building
-post-clean: called after cleaning build products
(Targets beginning with '-' are not intended to be called on their own.)
Example of inserting an obfuscator after compilation could look like this:
<target name="-post-compile">
<obfuscate>
<fileset dir="${build.classes.dir}"/>
</obfuscate>
</target>
For list of available properties check the imported
nbproject/build-impl.xml file.
Another way to customize the build is by overriding existing main targets.
The targets of interest are:
-init-macrodef-javac: defines macro for javac compilation
-init-macrodef-junit: defines macro for junit execution
-init-macrodef-debug: defines macro for class debugging
-init-macrodef-java: defines macro for class execution
-do-jar-with-manifest: JAR building (if you are using a manifest)
-do-jar-without-manifest: JAR building (if you are not using a manifest)
run: execution of project
-javadoc-build: Javadoc generation
test-report: JUnit report generation
An example of overriding the target for project execution could look like this:
<target name="run" depends="cache-impl.jar">
<exec dir="bin" executable="launcher.exe">
<arg file="${dist.jar}"/>
</exec>
</target>
Notice that the overridden target depends on the jar target and not only on
the compile target as the regular run target does. Again, for a list of available
properties which you can use, check the target you are overriding in the
nbproject/build-impl.xml file.
-->
</project>
1.1 jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache/LICENSE
Index: LICENSE
===================================================================
Copyright 2005 Hanson Char
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
1.1 jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache/README
Index: README
===================================================================
Pre-requisite
-------------
1) jdk 1.5.0_01+ installed
1) Ant 1.6.2+ installed
2) copy lib/junit-3.8.1.jar to your <ANT_HOME>/lib/
Build
-----
Simply type:
ant
Alternatively, if you've got NetBeans 4.0, life is even easier.
Simply open up the "cache" project folder, and build it.
Cheers,
Hanson
hanson.char@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE README
Posted by Hanson Char <ha...@gmail.com>.
I just started writing the yajcache code in the past few days for my
own amusement, and I don't know who else can claim the sole copyright
on it. joe_emporium is my login userid in sourceforge and I just
updated my display name from "Joe Emporium" to "Hanson Char".
Hopefully this resolves all the confusion about who Joe is.
ok, I'll fix up the copyright headers and package names shortly.
I suppose I can then keep yajcache under the current directory (with
the new package name structure).
H
On Fri, 21 Jan 2005 12:38:27 +0000 (UTC), Henning P. Schmiedehausen
<hp...@intermeta.de> wrote:
> Hanson Char <ha...@gmail.com> writes:
>
> >Is there a legal issue if yajcache is both kept on jcs and sourceforge
> >? Why do I need to remove the code from sourceforge ? I thought both
> >hosts open source projects, but maybe I didn't read the fine-print.
>
> Have you written the code and do you have the copyright on it
> (i.e. are you joe_emporium)? Or has it someone else written and
> donated it to the ASF?
>
> If you have written all the code and the sole copyright on it, then it
> is simple. Change all the copyright headers to ASF 2.0 and add author
> tags to the code if you wish. And _please_ change the packages from
> net.sf.yajcache to e.g. org.apache.jcs.yajcache.
>
> If someone else wrote the code, then you must get a CLA from this
> person and make sure that there are no other parties involved with the
> code.
>
> That's the whole point. It is not technical but legal. The ASF must be
> sure that code that gets donated to it (and especially if it is more
> than just a bunch of lines) is legally unencumbered. You don't seem to
> be on general@jakarta, are you? ;-)
>
> (Hm, maybe we can get Remy to rewrite it. <evil grin>)
>
> >So should I put the 1.5 code in a sandbox, or should I remove it from jcs ?
>
> >If we go the sandbox path, which directory is the sandbox ? Can I use
> >the @CopyRightApache annotation instead of copy-n-paste the copyright
>
> No. See Henri's comments
>
> >info at the beginning of every class ?
>
> All classes _must_ contain the copyright notice on top.
>
> Regards
> Henning
>
> >H
>
> >On Thu, 20 Jan 2005 19:35:30 -0800 (PST), Aaron Smuts <as...@yahoo.com> wrote:
> >> I'd prefer that experimental ideas be put into an
> >> experimental directory. We would do well to start
> >> playing around with what jdk 1.5 will do for us.
> >> Clearly this is nothing that we would release or jar.
> >> Other caches, such as jboss cache, which I heard a
> >> presentation on today (which is cool, but more like a
> >> database than a cache, and will probably never perform
> >> well), are using 1.4 features and are looking into 1.5
> >> features. . .
> >>
> >> If there are any legal issues, we should take the test
> >> 1.5 cache out of the repository. I wish it were not
> >> in the experimental build directory, had proper apache
> >> licenses, and was packaged appropriately. If these
> >> things were done and it was removed from sourceforge,
> >> then it seems fine.
> >>
> >> If Hanson would rather play on sourceforge with new
> >> ideas, then fine, but I don't want any problems if we
> >> decide to use something for a memory module. I'd
> >> prefer that we have some kind of sandbox in jcs
> >> though. I think log4j has something like this. The
> >> admin servlet was in it for a while (and may still be
> >> there). I'd like to see a new memory cache module
> >> come out of the 1.5 stuff he is working on. We have
> >> 1.4 extensions, but no 1.5 . . . I'd hope that this
> >> kind of work could happen within jcs.
> >>
> >> I lost the template for a project proposal. I'll just
> >> try to submit something that addresses all the
> >> concerns on the web site. Should I post a draft on
> >> the mailing list first?
> >>
> >> Aaron
>
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> What is more important to you...
> [ ] Product Security
> or [ ] Quality of Sales and Marketing Support
> -- actual question from a Microsoft customer survey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE README
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Hanson Char <ha...@gmail.com> writes:
>Is there a legal issue if yajcache is both kept on jcs and sourceforge
>? Why do I need to remove the code from sourceforge ? I thought both
>hosts open source projects, but maybe I didn't read the fine-print.
Have you written the code and do you have the copyright on it
(i.e. are you joe_emporium)? Or has it someone else written and
donated it to the ASF?
If you have written all the code and the sole copyright on it, then it
is simple. Change all the copyright headers to ASF 2.0 and add author
tags to the code if you wish. And _please_ change the packages from
net.sf.yajcache to e.g. org.apache.jcs.yajcache.
If someone else wrote the code, then you must get a CLA from this
person and make sure that there are no other parties involved with the
code.
That's the whole point. It is not technical but legal. The ASF must be
sure that code that gets donated to it (and especially if it is more
than just a bunch of lines) is legally unencumbered. You don't seem to
be on general@jakarta, are you? ;-)
(Hm, maybe we can get Remy to rewrite it. <evil grin>)
>So should I put the 1.5 code in a sandbox, or should I remove it from jcs ?
>If we go the sandbox path, which directory is the sandbox ? Can I use
>the @CopyRightApache annotation instead of copy-n-paste the copyright
No. See Henri's comments
>info at the beginning of every class ?
All classes _must_ contain the copyright notice on top.
Regards
Henning
>H
>On Thu, 20 Jan 2005 19:35:30 -0800 (PST), Aaron Smuts <as...@yahoo.com> wrote:
>> I'd prefer that experimental ideas be put into an
>> experimental directory. We would do well to start
>> playing around with what jdk 1.5 will do for us.
>> Clearly this is nothing that we would release or jar.
>> Other caches, such as jboss cache, which I heard a
>> presentation on today (which is cool, but more like a
>> database than a cache, and will probably never perform
>> well), are using 1.4 features and are looking into 1.5
>> features. . .
>>
>> If there are any legal issues, we should take the test
>> 1.5 cache out of the repository. I wish it were not
>> in the experimental build directory, had proper apache
>> licenses, and was packaged appropriately. If these
>> things were done and it was removed from sourceforge,
>> then it seems fine.
>>
>> If Hanson would rather play on sourceforge with new
>> ideas, then fine, but I don't want any problems if we
>> decide to use something for a memory module. I'd
>> prefer that we have some kind of sandbox in jcs
>> though. I think log4j has something like this. The
>> admin servlet was in it for a while (and may still be
>> there). I'd like to see a new memory cache module
>> come out of the 1.5 stuff he is working on. We have
>> 1.4 extensions, but no 1.5 . . . I'd hope that this
>> kind of work could happen within jcs.
>>
>> I lost the template for a project proposal. I'll just
>> try to submit something that addresses all the
>> concerns on the web site. Should I post a draft on
>> the mailing list first?
>>
>> Aaron
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: Copyright in JDK1.5
Posted by Henri Yandell <ba...@generationjava.com>.
It wouldn't be available at source time would it?
If I goto CVS, grab the TestOnly.java file and copy it, I'll have never
seen a copyright notice.
Hen
On Fri, 21 Jan 2005, Hanson Char wrote:
> Oops, the "TestOnly" annotation can be ommited. Otherwise, here is
> the definition:
>
> @CopyRightApache
> @Documented
> @Inherited
> @Retention(RetentionPolicy.RUNTIME)
> public @interface TestOnly {
> String value() default "";
> }
>
> H
>
> On Fri, 21 Jan 2005 16:23:03 +1100, Hanson Char <ha...@gmail.com> wrote:
>> Conceivably, this makes it unnecessary to copy and paste the Apache
>> Copyright at the top of every java source files.
>>
>> Instead, simply annotate:
>>
>> @CopyRightApache
>> public class Foo {...}
>>
>> This copyright info then becomes available both at source, class and
>> runtime level, plus the compiler will verify it for you in case of
>> typo.
>>
>> H
>>
>> On Fri, 21 Jan 2005 16:17:43 +1100, Hanson Char <ha...@gmail.com> wrote:
>>> An idea on preserving copyright on objects via jdk1.5 annotation and enum.
>>>
>>> 1) Creates a enum CopyRightType with one value APACHE, which has the
>>> toString method to return the Apache software license.
>>> 2) Creates an annotation CopyRightApache that has a value that returns
>>> the above CopyRightType, with the default set to CopyRightType.APACHE.
>>> 3) Annotates every class with @CopyRightApache.
>>>
>>> Now the copyright of any object can be accessed in the JVM during runtime by:
>>>
>>> object.getClass().getAnnotation(CopyRightApache.class).toString()
>>>
>>> Sample code:
>>>
>>> // Enum Definition for the Apache Copyright
>>> @CopyRightApache
>>> public enum CopyRightType {
>>> APACHE {
>>> @Override public String toString() {
>>> return "\n"
>>> + "/*
>>> ========================================================================\n"
>>> + " * Copyright 2004 The Apache Software Foundation\n"
>>> + " *\n"
>>> + " * Licensed under the Apache License, Version 2.0 (the
>>> \"License\");\n"
>>> + " * you may not use this file except in compliance with
>>> the License.\n"
>>> + " * You may obtain a copy of the License at\n"
>>> + " *\n"
>>> + " * http://www.apache.org/licenses/LICENSE-2.0\n"
>>> + " *\n"
>>> + " * Unless required by applicable law or agreed to in
>>> writing, software\n"
>>> + " * distributed under the License is distributed on an
>>> \"AS IS\" BASIS,\n"
>>> + " * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>> express or implied.\n"
>>> + " * See the License for the specific language governing
>>> permissions and\n"
>>> + " * limitations under the License.\n"
>>> + " *
>>> ========================================================================\n"
>>> + " */\n"
>>> ;
>>> }
>>> };
>>> }
>>>
>>> // Annotation Type Definition for the Apache Copyright
>>> @CopyRightApache
>>> @Documented
>>> @Retention(RetentionPolicy.RUNTIME)
>>> public @interface CopyRightApache {
>>> CopyRightType value() default CopyRightType.APACHE;
>>> }
>>>
>>> // JUnit test case for the Apache Copyright artifacts.
>>> import junit.framework.TestCase;
>>> import org.apache.commons.logging.Log;
>>> import org.apache.commons.logging.LogFactory;
>>>
>>> @CopyRightApache
>>> @TestOnly
>>> public class CopyRightApacheTest extends TestCase {
>>> private Log log = LogFactory.getLog(this.getClass());
>>>
>>> public void test() {
>>> log.debug(this.getClass().getAnnotation(CopyRightApache.class));
>>> }
>>> }
>>>
>>> An interesting result is that the enum and annotation are themselves
>>> recursively annotated by the same copyright they define.
>>>
>>> H
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: Copyright in JDK1.5
Posted by Hanson Char <ha...@gmail.com>.
Oops, the "TestOnly" annotation can be ommited. Otherwise, here is
the definition:
@CopyRightApache
@Documented
@Inherited
@Retention(RetentionPolicy.RUNTIME)
public @interface TestOnly {
String value() default "";
}
H
On Fri, 21 Jan 2005 16:23:03 +1100, Hanson Char <ha...@gmail.com> wrote:
> Conceivably, this makes it unnecessary to copy and paste the Apache
> Copyright at the top of every java source files.
>
> Instead, simply annotate:
>
> @CopyRightApache
> public class Foo {...}
>
> This copyright info then becomes available both at source, class and
> runtime level, plus the compiler will verify it for you in case of
> typo.
>
> H
>
> On Fri, 21 Jan 2005 16:17:43 +1100, Hanson Char <ha...@gmail.com> wrote:
> > An idea on preserving copyright on objects via jdk1.5 annotation and enum.
> >
> > 1) Creates a enum CopyRightType with one value APACHE, which has the
> > toString method to return the Apache software license.
> > 2) Creates an annotation CopyRightApache that has a value that returns
> > the above CopyRightType, with the default set to CopyRightType.APACHE.
> > 3) Annotates every class with @CopyRightApache.
> >
> > Now the copyright of any object can be accessed in the JVM during runtime by:
> >
> > object.getClass().getAnnotation(CopyRightApache.class).toString()
> >
> > Sample code:
> >
> > // Enum Definition for the Apache Copyright
> > @CopyRightApache
> > public enum CopyRightType {
> > APACHE {
> > @Override public String toString() {
> > return "\n"
> > + "/*
> > ========================================================================\n"
> > + " * Copyright 2004 The Apache Software Foundation\n"
> > + " *\n"
> > + " * Licensed under the Apache License, Version 2.0 (the
> > \"License\");\n"
> > + " * you may not use this file except in compliance with
> > the License.\n"
> > + " * You may obtain a copy of the License at\n"
> > + " *\n"
> > + " * http://www.apache.org/licenses/LICENSE-2.0\n"
> > + " *\n"
> > + " * Unless required by applicable law or agreed to in
> > writing, software\n"
> > + " * distributed under the License is distributed on an
> > \"AS IS\" BASIS,\n"
> > + " * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
> > express or implied.\n"
> > + " * See the License for the specific language governing
> > permissions and\n"
> > + " * limitations under the License.\n"
> > + " *
> > ========================================================================\n"
> > + " */\n"
> > ;
> > }
> > };
> > }
> >
> > // Annotation Type Definition for the Apache Copyright
> > @CopyRightApache
> > @Documented
> > @Retention(RetentionPolicy.RUNTIME)
> > public @interface CopyRightApache {
> > CopyRightType value() default CopyRightType.APACHE;
> > }
> >
> > // JUnit test case for the Apache Copyright artifacts.
> > import junit.framework.TestCase;
> > import org.apache.commons.logging.Log;
> > import org.apache.commons.logging.LogFactory;
> >
> > @CopyRightApache
> > @TestOnly
> > public class CopyRightApacheTest extends TestCase {
> > private Log log = LogFactory.getLog(this.getClass());
> >
> > public void test() {
> > log.debug(this.getClass().getAnnotation(CopyRightApache.class));
> > }
> > }
> >
> > An interesting result is that the enum and annotation are themselves
> > recursively annotated by the same copyright they define.
> >
> > H
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: Copyright in JDK1.5
Posted by Hanson Char <ha...@gmail.com>.
Conceivably, this makes it unnecessary to copy and paste the Apache
Copyright at the top of every java source files.
Instead, simply annotate:
@CopyRightApache
public class Foo {...}
This copyright info then becomes available both at source, class and
runtime level, plus the compiler will verify it for you in case of
typo.
H
On Fri, 21 Jan 2005 16:17:43 +1100, Hanson Char <ha...@gmail.com> wrote:
> An idea on preserving copyright on objects via jdk1.5 annotation and enum.
>
> 1) Creates a enum CopyRightType with one value APACHE, which has the
> toString method to return the Apache software license.
> 2) Creates an annotation CopyRightApache that has a value that returns
> the above CopyRightType, with the default set to CopyRightType.APACHE.
> 3) Annotates every class with @CopyRightApache.
>
> Now the copyright of any object can be accessed in the JVM during runtime by:
>
> object.getClass().getAnnotation(CopyRightApache.class).toString()
>
> Sample code:
>
> // Enum Definition for the Apache Copyright
> @CopyRightApache
> public enum CopyRightType {
> APACHE {
> @Override public String toString() {
> return "\n"
> + "/*
> ========================================================================\n"
> + " * Copyright 2004 The Apache Software Foundation\n"
> + " *\n"
> + " * Licensed under the Apache License, Version 2.0 (the
> \"License\");\n"
> + " * you may not use this file except in compliance with
> the License.\n"
> + " * You may obtain a copy of the License at\n"
> + " *\n"
> + " * http://www.apache.org/licenses/LICENSE-2.0\n"
> + " *\n"
> + " * Unless required by applicable law or agreed to in
> writing, software\n"
> + " * distributed under the License is distributed on an
> \"AS IS\" BASIS,\n"
> + " * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
> express or implied.\n"
> + " * See the License for the specific language governing
> permissions and\n"
> + " * limitations under the License.\n"
> + " *
> ========================================================================\n"
> + " */\n"
> ;
> }
> };
> }
>
> // Annotation Type Definition for the Apache Copyright
> @CopyRightApache
> @Documented
> @Retention(RetentionPolicy.RUNTIME)
> public @interface CopyRightApache {
> CopyRightType value() default CopyRightType.APACHE;
> }
>
> // JUnit test case for the Apache Copyright artifacts.
> import junit.framework.TestCase;
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> @CopyRightApache
> @TestOnly
> public class CopyRightApacheTest extends TestCase {
> private Log log = LogFactory.getLog(this.getClass());
>
> public void test() {
> log.debug(this.getClass().getAnnotation(CopyRightApache.class));
> }
> }
>
> An interesting result is that the enum and annotation are themselves
> recursively annotated by the same copyright they define.
>
> H
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Copyright in JDK1.5
Posted by Hanson Char <ha...@gmail.com>.
An idea on preserving copyright on objects via jdk1.5 annotation and enum.
1) Creates a enum CopyRightType with one value APACHE, which has the
toString method to return the Apache software license.
2) Creates an annotation CopyRightApache that has a value that returns
the above CopyRightType, with the default set to CopyRightType.APACHE.
3) Annotates every class with @CopyRightApache.
Now the copyright of any object can be accessed in the JVM during runtime by:
object.getClass().getAnnotation(CopyRightApache.class).toString()
Sample code:
// Enum Definition for the Apache Copyright
@CopyRightApache
public enum CopyRightType {
APACHE {
@Override public String toString() {
return "\n"
+ "/*
========================================================================\n"
+ " * Copyright 2004 The Apache Software Foundation\n"
+ " *\n"
+ " * Licensed under the Apache License, Version 2.0 (the
\"License\");\n"
+ " * you may not use this file except in compliance with
the License.\n"
+ " * You may obtain a copy of the License at\n"
+ " *\n"
+ " * http://www.apache.org/licenses/LICENSE-2.0\n"
+ " *\n"
+ " * Unless required by applicable law or agreed to in
writing, software\n"
+ " * distributed under the License is distributed on an
\"AS IS\" BASIS,\n"
+ " * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied.\n"
+ " * See the License for the specific language governing
permissions and\n"
+ " * limitations under the License.\n"
+ " *
========================================================================\n"
+ " */\n"
;
}
};
}
// Annotation Type Definition for the Apache Copyright
@CopyRightApache
@Documented
@Retention(RetentionPolicy.RUNTIME)
public @interface CopyRightApache {
CopyRightType value() default CopyRightType.APACHE;
}
// JUnit test case for the Apache Copyright artifacts.
import junit.framework.TestCase;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@CopyRightApache
@TestOnly
public class CopyRightApacheTest extends TestCase {
private Log log = LogFactory.getLog(this.getClass());
public void test() {
log.debug(this.getClass().getAnnotation(CopyRightApache.class));
}
}
An interesting result is that the enum and annotation are themselves
recursively annotated by the same copyright they define.
H
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: draft promotion proposal for JCS
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Aaron Smuts <as...@yahoo.com> writes:
Very good! Besides a very few small nits (which are more bean-counting
than real objections), I think that is it! We should have you on
Jakarta-Level in no time.
Regards
Henning
>Proposal for JCS Project Promotion
>I. Rational
>JCS (Java Caching System) was the first major
>open-source Java caching solution. After a few years
... is a major open-source Java caching solution. Or are you sure about "first" ?
>of incubation within the Turbine project, JCS is ready
>to become a top-level Jakarta project. The scope and
>maturity of JCS make it suitable for top level project
>status.
+1
>The JCS project is of the scope of a project such as
>log4j, which its sub project status does not indicate.
log4j is a bad example because it is no longer part of Jakarta. Make
this "Tapestry" or "Velocity" or "Turbine".
> Since JCS has no dependencies on Turbine, it would
>less confusing to users if it were its own top-level
>project. Given the size and coherence of the
>code-base it is not well suited in as a module of any
>other project, such as commons.
+1
>JCS is ready for a production release. Over the past
>year, we solved all major, known bugs. Although there
>are a growing number of competitors, JCS has a good
>number of users and is currently at a 1.2.1
>development version.
>JCS would be a good addition to the list of current
>top level Jakarta projects, and, perhaps more
>importantly, it would benefit from the input of a
>larger community that increased exposure would afford.
+1
>II. Scope of the Package
>JCS is a distributed caching system written in java
>for server-side java applications. The project is an
>attempt to build a system close to JCACHE , JSR-107, a
>description of the caching system used in Oracle9i.
>JCS is intended to speed up dynamic web applications
>by providing a means to manage cached data of various
>dynamic natures. Like any caching system, JCS is most
>useful for high read, low put applications.
+1
>JCS is essentially a cache hub and several production
>ready and experimental modules that can be plugged
>into the hub. In JCS, cached data is stored in a
>region. Each region can be configured independently
>of the others. JCS is modeled on log4j, where various
>appenders can be defined for specific regions.
>JCS defines four types of appenders, or what we call
>auxiliaries: memory, disk, lateral, and remote. A
>memory auxiliary manages items stored in memory. Disk
>auxiliaries manage memory overflow and persistence of
>cached data. Lateral auxiliaries communicate directly
>with other caches. Remote auxiliaries communicate
>with a remote server to which other caches are
>connected. At least one production ready
>implementation of each type of auxiliary is included
>in the core JCS jar. The LRU memory cache, indexed
>disk cache, TCP lateral cache, JGroups lateral cache,
>and RMI remote cache auxiliaries form the core suite
>of stable JCS auxiliaries.
>
>JCS is extremely configurable. Every auxiliary
>exposes detailed configuration options. For example,
>the indexed disk cache allows you to configure such
>things as the maximum number of keys in memory, the
>size of the recycle bin for reusing empty spots on
>disk, whether it should defragment and if so when, and
>the type of event queue to use. More information on
>the available disk cache configuration options can be
>found here:
>http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html
>One of the most important features of JCS is that you
>can plug in new auxiliaries. Each type of auxiliary
>has a defined interface, and the implementation class
>can be defined in the JCS configuration file.
>The cache hub and the core auxiliaries are contained
>in a JAR file that is JDK 1.3 compatible. Other JDK
>1.4 specific features are contained in another
>optional JAR.
>III. Interaction with other packages
>JCS has dependencies on several standard commons
>packages, including: commons-lang,
>commons-collections, and commons-logging. We also
>depend on Doug Lea's util concurrent JAR for some of
>our locking and thread pools. Some of the optional
>auxiliaries depend on other libraries. For instance,
>the JGroups jar depends on the JGroups release. The,
>JDK 1.4 optional, Berkeley DB auxiliary depends on the
>related project.
>The Cocoon project currently uses JCS as its caching
>mechanism.
>IV. Source of the package
>I contributed JCS to the Stratum project, a subproject
>of Turbine, over three years ago. It has been a sub
>project of Turbine for about 2 years.
>V. Base name for the package
>The JCS code is currently checked into CVS with the
>following root package name:
>org.apache.jcs
>VI. Coding conventions
>The code follows a modified version of Sun's standard
>coding conventions, with the following stylistic
>changes:
>� instance variables are prefixed with an underscore
>� a newline is inserted before all braces
* instance variables are prefixed with an underscore
* a newline is inserted before all braces
>VII. Jakarta resources to be created
>The current mailing lists are turbine-jcs-user@
>jakarta.apache.org and turbine-jcs-dev@
>jakarta.apache.org. We should forward these lists to,
>or just create, these two new lists:
>jcs-user@jakarta.apache.org -- User discussions
>jcs-dev@jakarta.apache.org -- Developer discussions
>and CVS update notifications
>VIII. Initial set of committers
>There are currently four committers on the JCS
>project, all of whom have licenses on file.
>Aaron Smuts <as...@apache.org>
>James Taylor <ja...@jamestaylor.org>
>Hanson Char <hc...@apache.org>
>Travis Savo <ts...@IFILM.com>
>VIII. Documentation
>You can find the current JCS documentation here:
>http://jakarta.apache.org/turbine/jcs/
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE README
Posted by Hanson Char <ha...@gmail.com>.
Is there a legal issue if yajcache is both kept on jcs and sourceforge
? Why do I need to remove the code from sourceforge ? I thought both
hosts open source projects, but maybe I didn't read the fine-print.
So should I put the 1.5 code in a sandbox, or should I remove it from jcs ?
If we go the sandbox path, which directory is the sandbox ? Can I use
the @CopyRightApache annotation instead of copy-n-paste the copyright
info at the beginning of every class ?
H
On Thu, 20 Jan 2005 19:35:30 -0800 (PST), Aaron Smuts <as...@yahoo.com> wrote:
> I'd prefer that experimental ideas be put into an
> experimental directory. We would do well to start
> playing around with what jdk 1.5 will do for us.
> Clearly this is nothing that we would release or jar.
> Other caches, such as jboss cache, which I heard a
> presentation on today (which is cool, but more like a
> database than a cache, and will probably never perform
> well), are using 1.4 features and are looking into 1.5
> features. . .
>
> If there are any legal issues, we should take the test
> 1.5 cache out of the repository. I wish it were not
> in the experimental build directory, had proper apache
> licenses, and was packaged appropriately. If these
> things were done and it was removed from sourceforge,
> then it seems fine.
>
> If Hanson would rather play on sourceforge with new
> ideas, then fine, but I don't want any problems if we
> decide to use something for a memory module. I'd
> prefer that we have some kind of sandbox in jcs
> though. I think log4j has something like this. The
> admin servlet was in it for a while (and may still be
> there). I'd like to see a new memory cache module
> come out of the 1.5 stuff he is working on. We have
> 1.4 extensions, but no 1.5 . . . I'd hope that this
> kind of work could happen within jcs.
>
> I lost the template for a project proposal. I'll just
> try to submit something that addresses all the
> concerns on the web site. Should I post a draft on
> the mailing list first?
>
> Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: draft promotion proposal for JCS
Posted by Hanson Char <ha...@gmail.com>.
Good work, Aaron.
+1
H
On Thu, 20 Jan 2005 21:48:44 -0800 (PST), Aaron Smuts <as...@yahoo.com> wrote:
> Proposal for JCS Project Promotion
>
> I. Rational
> JCS (Java Caching System) was the first major
> open-source Java caching solution. After a few years
> of incubation within the Turbine project, JCS is ready
> to become a top-level Jakarta project. The scope and
> maturity of JCS make it suitable for top level project
> status.
>
> The JCS project is of the scope of a project such as
> log4j, which its sub project status does not indicate.
> Since JCS has no dependencies on Turbine, it would
> less confusing to users if it were its own top-level
> project. Given the size and coherence of the
> code-base it is not well suited in as a module of any
> other project, such as commons.
>
> JCS is ready for a production release. Over the past
> year, we solved all major, known bugs. Although there
> are a growing number of competitors, JCS has a good
> number of users and is currently at a 1.2.1
> development version.
>
> JCS would be a good addition to the list of current
> top level Jakarta projects, and, perhaps more
> importantly, it would benefit from the input of a
> larger community that increased exposure would afford.
>
> II. Scope of the Package
> JCS is a distributed caching system written in java
> for server-side java applications. The project is an
> attempt to build a system close to JCACHE , JSR-107, a
> description of the caching system used in Oracle9i.
> JCS is intended to speed up dynamic web applications
> by providing a means to manage cached data of various
> dynamic natures. Like any caching system, JCS is most
> useful for high read, low put applications.
>
> JCS is essentially a cache hub and several production
> ready and experimental modules that can be plugged
> into the hub. In JCS, cached data is stored in a
> region. Each region can be configured independently
> of the others. JCS is modeled on log4j, where various
> appenders can be defined for specific regions.
>
> JCS defines four types of appenders, or what we call
> auxiliaries: memory, disk, lateral, and remote. A
> memory auxiliary manages items stored in memory. Disk
> auxiliaries manage memory overflow and persistence of
> cached data. Lateral auxiliaries communicate directly
> with other caches. Remote auxiliaries communicate
> with a remote server to which other caches are
> connected. At least one production ready
> implementation of each type of auxiliary is included
> in the core JCS jar. The LRU memory cache, indexed
> disk cache, TCP lateral cache, JGroups lateral cache,
> and RMI remote cache auxiliaries form the core suite
> of stable JCS auxiliaries.
>
> JCS is extremely configurable. Every auxiliary
> exposes detailed configuration options. For example,
> the indexed disk cache allows you to configure such
> things as the maximum number of keys in memory, the
> size of the recycle bin for reusing empty spots on
> disk, whether it should defragment and if so when, and
> the type of event queue to use. More information on
> the available disk cache configuration options can be
> found here:
> http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html
>
> One of the most important features of JCS is that you
> can plug in new auxiliaries. Each type of auxiliary
> has a defined interface, and the implementation class
> can be defined in the JCS configuration file.
>
> The cache hub and the core auxiliaries are contained
> in a JAR file that is JDK 1.3 compatible. Other JDK
> 1.4 specific features are contained in another
> optional JAR.
>
> III. Interaction with other packages
> JCS has dependencies on several standard commons
> packages, including: commons-lang,
> commons-collections, and commons-logging. We also
> depend on Doug Lea's util concurrent JAR for some of
> our locking and thread pools. Some of the optional
> auxiliaries depend on other libraries. For instance,
> the JGroups jar depends on the JGroups release. The,
> JDK 1.4 optional, Berkeley DB auxiliary depends on the
> related project.
> The Cocoon project currently uses JCS as its caching
> mechanism.
>
> IV. Source of the package
> I contributed JCS to the Stratum project, a subproject
> of Turbine, over three years ago. It has been a sub
> project of Turbine for about 2 years.
>
> V. Base name for the package
> The JCS code is currently checked into CVS with the
> following root package name:
> org.apache.jcs
>
> VI. Coding conventions
> The code follows a modified version of Sun's standard
> coding conventions, with the following stylistic
> changes:
> • instance variables are prefixed with an underscore
> • a newline is inserted before all braces
>
> VII. Jakarta resources to be created
> The current mailing lists are turbine-jcs-user@
> jakarta.apache.org and turbine-jcs-dev@
> jakarta.apache.org. We should forward these lists to,
> or just create, these two new lists:
> jcs-user@jakarta.apache.org -- User discussions
> jcs-dev@jakarta.apache.org -- Developer discussions
> and CVS update notifications
>
> VIII. Initial set of committers
> There are currently four committers on the JCS
> project, all of whom have licenses on file.
> Aaron Smuts <as...@apache.org>
> James Taylor <ja...@jamestaylor.org>
> Hanson Char <hc...@apache.org>
> Travis Savo <ts...@IFILM.com>
>
> VIII. Documentation
> You can find the current JCS documentation here:
> http://jakarta.apache.org/turbine/jcs/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE README
Posted by Hanson Char <ha...@gmail.com>.
Joe Emporium is me. Sourceforge Admin won't let me change it once
registered, so it remains (since long time ago). My original use of
it was to trash junk mail.
Hanson
On Fri, 21 Jan 2005 10:52:40 +1100, Scott Eade
<se...@backstagetech.com.au> wrote:
> Okay, but who is Joe Emporium (listed as the Project Developer and sole
> developer on SourceForge) and is there an ASF CLA on file for him?
>
> Have there been any other contributors to yajcache?
>
> Have you seen http://incubator.apache.org/index.html - this is the path
> by which projects must enter the ASF.
>
> It strikes me that there should have at least been some public
> discussion before this code is brought into the ASF.
>
> There have been a number of attempts at prodding Aaron to get his act
> together and propose that JCS move out from beneath Turbine to a direct
> subproject of Jakarta. Adding yajcache in this manner at this point in
> time may well complicate matters.
>
> Aaron: Would you mind please commenting on your progress with the
> proposal for JCS to become a direct Jakarta subproject. Do you have a
> handle at all on yajcache?
>
> Scott
>
>
> Hanson Char wrote:
>
> >The purpose is to have a jdk1.5 version of an experimental cache.
> >Details are explained in the README file . Will fix up the licenses
> >shortly.
> >
> >H
> >
> >
> >On Thu, 20 Jan 2005 22:59:04 +1100, Scott Eade <se...@apache.org> wrote:
> >
> >
> >>hchar@apache.org wrote:
> >>
> >>
> >>>hchar 2005/01/19 03:01:15
> >>>
> >>> Added: auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE
> >>> README
> >>> Log:
> >>> no message
> >>>
> >>>
> >>It would be great if you could describe what you are committing.
> >><snip />
> >>
> >>
> >>> 1.1 jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache/LICENSE
> >>>
> >>> Index: LICENSE
> >>> ===================================================================
> >>>
> >>> Copyright 2005 Hanson Char
> >>>
> >>>
> >>I believe the above line should actually be:
> >> Copyright 2005 The Apache Software Foundation
> >>
> >>
> >>> Licensed under the Apache License, Version 2.0 (the "License");
> >>> you may not use this file except in compliance with the License.
> >>> You may obtain a copy of the License at
> >>>
> >>> http://www.apache.org/licenses/LICENSE-2.0
> >>>
> >>> Unless required by applicable law or agreed to in writing, software
> >>> distributed under the License is distributed on an "AS IS" BASIS,
> >>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> >>> See the License for the specific language governing permissions and
> >>> limitations under the License.
> >>>
> >>>
> >><snip />
> >>
> >>In the LICENSE file you should include the full ASL 2.0 text. Pretty
> >>much every other file should include the short version from:
> >>http://wiki.apache.org/general/LicenseFormats
> >>
> >>Given that this appears to be the yajcache project from sf.net, what
> >>procedures are being followed to import this code into the ASF? Usualy
> >>there is some kind of incubation process. I haven't seen any mention of
> >>the impending import of this code on turbine-jcs-dev or any of the more
> >>generic jakarta mailing lists.
> >>
> >>I think you may have skipped a few important steps with getting this
> >>code into the ASF. Would you mind please explaining your intentions.
> >>
> >>Thanks,
> >>
> >>Scott
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: draft promotion proposal for JCS
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Scott Eade <se...@backstagetech.com.au> writes:
>Great Aaron. I'll bring this to Henning's attention and we will try and
>give you some feedback and advice on the path forwards.
Got it, thanks. I monitor jcs-dev and jcs-user
Regards
Henning
>Thanks,
>Scott
>Aaron Smuts wrote:
>>Proposal for JCS Project Promotion
>>
>>I. Rational
>>JCS (Java Caching System) was the first major
>>open-source Java caching solution. After a few years
>>of incubation within the Turbine project, JCS is ready
>>to become a top-level Jakarta project. The scope and
>>maturity of JCS make it suitable for top level project
>>status.
>>
>>The JCS project is of the scope of a project such as
>>log4j, which its sub project status does not indicate.
>> Since JCS has no dependencies on Turbine, it would
>>less confusing to users if it were its own top-level
>>project. Given the size and coherence of the
>>code-base it is not well suited in as a module of any
>>other project, such as commons.
>>
>>JCS is ready for a production release. Over the past
>>year, we solved all major, known bugs. Although there
>>are a growing number of competitors, JCS has a good
>>number of users and is currently at a 1.2.1
>>development version.
>>
>>JCS would be a good addition to the list of current
>>top level Jakarta projects, and, perhaps more
>>importantly, it would benefit from the input of a
>>larger community that increased exposure would afford.
>>
>>
>>II. Scope of the Package
>>JCS is a distributed caching system written in java
>>for server-side java applications. The project is an
>>attempt to build a system close to JCACHE , JSR-107, a
>>description of the caching system used in Oracle9i.
>>JCS is intended to speed up dynamic web applications
>>by providing a means to manage cached data of various
>>dynamic natures. Like any caching system, JCS is most
>>useful for high read, low put applications.
>>
>>JCS is essentially a cache hub and several production
>>ready and experimental modules that can be plugged
>>into the hub. In JCS, cached data is stored in a
>>region. Each region can be configured independently
>>of the others. JCS is modeled on log4j, where various
>>appenders can be defined for specific regions.
>>
>>JCS defines four types of appenders, or what we call
>>auxiliaries: memory, disk, lateral, and remote. A
>>memory auxiliary manages items stored in memory. Disk
>>auxiliaries manage memory overflow and persistence of
>>cached data. Lateral auxiliaries communicate directly
>>with other caches. Remote auxiliaries communicate
>>with a remote server to which other caches are
>>connected. At least one production ready
>>implementation of each type of auxiliary is included
>>in the core JCS jar. The LRU memory cache, indexed
>>disk cache, TCP lateral cache, JGroups lateral cache,
>>and RMI remote cache auxiliaries form the core suite
>>of stable JCS auxiliaries.
>>
>>JCS is extremely configurable. Every auxiliary
>>exposes detailed configuration options. For example,
>>the indexed disk cache allows you to configure such
>>things as the maximum number of keys in memory, the
>>size of the recycle bin for reusing empty spots on
>>disk, whether it should defragment and if so when, and
>>the type of event queue to use. More information on
>>the available disk cache configuration options can be
>>found here:
>>http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html
>>
>>One of the most important features of JCS is that you
>>can plug in new auxiliaries. Each type of auxiliary
>>has a defined interface, and the implementation class
>>can be defined in the JCS configuration file.
>>
>>The cache hub and the core auxiliaries are contained
>>in a JAR file that is JDK 1.3 compatible. Other JDK
>>1.4 specific features are contained in another
>>optional JAR.
>>
>>III. Interaction with other packages
>>JCS has dependencies on several standard commons
>>packages, including: commons-lang,
>>commons-collections, and commons-logging. We also
>>depend on Doug Lea's util concurrent JAR for some of
>>our locking and thread pools. Some of the optional
>>auxiliaries depend on other libraries. For instance,
>>the JGroups jar depends on the JGroups release. The,
>>JDK 1.4 optional, Berkeley DB auxiliary depends on the
>>related project.
>>The Cocoon project currently uses JCS as its caching
>>mechanism.
>>
>>IV. Source of the package
>>I contributed JCS to the Stratum project, a subproject
>>of Turbine, over three years ago. It has been a sub
>>project of Turbine for about 2 years.
>>
>>V. Base name for the package
>>The JCS code is currently checked into CVS with the
>>following root package name:
>>org.apache.jcs
>>
>>VI. Coding conventions
>>The code follows a modified version of Sun's standard
>>coding conventions, with the following stylistic
>>changes:
>>� instance variables are prefixed with an underscore
>>� a newline is inserted before all braces
>>
>>VII. Jakarta resources to be created
>>The current mailing lists are turbine-jcs-user@
>>jakarta.apache.org and turbine-jcs-dev@
>>jakarta.apache.org. We should forward these lists to,
>>or just create, these two new lists:
>>jcs-user@jakarta.apache.org -- User discussions
>>jcs-dev@jakarta.apache.org -- Developer discussions
>>and CVS update notifications
>>
>>VIII. Initial set of committers
>>There are currently four committers on the JCS
>>project, all of whom have licenses on file.
>>Aaron Smuts <as...@apache.org>
>>James Taylor <ja...@jamestaylor.org>
>>Hanson Char <hc...@apache.org>
>>Travis Savo <ts...@IFILM.com>
>>
>>VIII. Documentation
>>You can find the current JCS documentation here:
>>http://jakarta.apache.org/turbine/jcs/
>>
>>
>>
>>
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: draft promotion proposal for JCS
Posted by Scott Eade <se...@backstagetech.com.au>.
Great Aaron. I'll bring this to Henning's attention and we will try and
give you some feedback and advice on the path forwards.
Thanks,
Scott
Aaron Smuts wrote:
>Proposal for JCS Project Promotion
>
>I. Rational
>JCS (Java Caching System) was the first major
>open-source Java caching solution. After a few years
>of incubation within the Turbine project, JCS is ready
>to become a top-level Jakarta project. The scope and
>maturity of JCS make it suitable for top level project
>status.
>
>The JCS project is of the scope of a project such as
>log4j, which its sub project status does not indicate.
> Since JCS has no dependencies on Turbine, it would
>less confusing to users if it were its own top-level
>project. Given the size and coherence of the
>code-base it is not well suited in as a module of any
>other project, such as commons.
>
>JCS is ready for a production release. Over the past
>year, we solved all major, known bugs. Although there
>are a growing number of competitors, JCS has a good
>number of users and is currently at a 1.2.1
>development version.
>
>JCS would be a good addition to the list of current
>top level Jakarta projects, and, perhaps more
>importantly, it would benefit from the input of a
>larger community that increased exposure would afford.
>
>
>II. Scope of the Package
>JCS is a distributed caching system written in java
>for server-side java applications. The project is an
>attempt to build a system close to JCACHE , JSR-107, a
>description of the caching system used in Oracle9i.
>JCS is intended to speed up dynamic web applications
>by providing a means to manage cached data of various
>dynamic natures. Like any caching system, JCS is most
>useful for high read, low put applications.
>
>JCS is essentially a cache hub and several production
>ready and experimental modules that can be plugged
>into the hub. In JCS, cached data is stored in a
>region. Each region can be configured independently
>of the others. JCS is modeled on log4j, where various
>appenders can be defined for specific regions.
>
>JCS defines four types of appenders, or what we call
>auxiliaries: memory, disk, lateral, and remote. A
>memory auxiliary manages items stored in memory. Disk
>auxiliaries manage memory overflow and persistence of
>cached data. Lateral auxiliaries communicate directly
>with other caches. Remote auxiliaries communicate
>with a remote server to which other caches are
>connected. At least one production ready
>implementation of each type of auxiliary is included
>in the core JCS jar. The LRU memory cache, indexed
>disk cache, TCP lateral cache, JGroups lateral cache,
>and RMI remote cache auxiliaries form the core suite
>of stable JCS auxiliaries.
>
>JCS is extremely configurable. Every auxiliary
>exposes detailed configuration options. For example,
>the indexed disk cache allows you to configure such
>things as the maximum number of keys in memory, the
>size of the recycle bin for reusing empty spots on
>disk, whether it should defragment and if so when, and
>the type of event queue to use. More information on
>the available disk cache configuration options can be
>found here:
>http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html
>
>One of the most important features of JCS is that you
>can plug in new auxiliaries. Each type of auxiliary
>has a defined interface, and the implementation class
>can be defined in the JCS configuration file.
>
>The cache hub and the core auxiliaries are contained
>in a JAR file that is JDK 1.3 compatible. Other JDK
>1.4 specific features are contained in another
>optional JAR.
>
>III. Interaction with other packages
>JCS has dependencies on several standard commons
>packages, including: commons-lang,
>commons-collections, and commons-logging. We also
>depend on Doug Lea's util concurrent JAR for some of
>our locking and thread pools. Some of the optional
>auxiliaries depend on other libraries. For instance,
>the JGroups jar depends on the JGroups release. The,
>JDK 1.4 optional, Berkeley DB auxiliary depends on the
>related project.
>The Cocoon project currently uses JCS as its caching
>mechanism.
>
>IV. Source of the package
>I contributed JCS to the Stratum project, a subproject
>of Turbine, over three years ago. It has been a sub
>project of Turbine for about 2 years.
>
>V. Base name for the package
>The JCS code is currently checked into CVS with the
>following root package name:
>org.apache.jcs
>
>VI. Coding conventions
>The code follows a modified version of Sun's standard
>coding conventions, with the following stylistic
>changes:
>• instance variables are prefixed with an underscore
>• a newline is inserted before all braces
>
>VII. Jakarta resources to be created
>The current mailing lists are turbine-jcs-user@
>jakarta.apache.org and turbine-jcs-dev@
>jakarta.apache.org. We should forward these lists to,
>or just create, these two new lists:
>jcs-user@jakarta.apache.org -- User discussions
>jcs-dev@jakarta.apache.org -- Developer discussions
>and CVS update notifications
>
>VIII. Initial set of committers
>There are currently four committers on the JCS
>project, all of whom have licenses on file.
>Aaron Smuts <as...@apache.org>
>James Taylor <ja...@jamestaylor.org>
>Hanson Char <hc...@apache.org>
>Travis Savo <ts...@IFILM.com>
>
>VIII. Documentation
>You can find the current JCS documentation here:
>http://jakarta.apache.org/turbine/jcs/
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
draft promotion proposal for JCS
Posted by Aaron Smuts <as...@yahoo.com>.
Proposal for JCS Project Promotion
I. Rational
JCS (Java Caching System) was the first major
open-source Java caching solution. After a few years
of incubation within the Turbine project, JCS is ready
to become a top-level Jakarta project. The scope and
maturity of JCS make it suitable for top level project
status.
The JCS project is of the scope of a project such as
log4j, which its sub project status does not indicate.
Since JCS has no dependencies on Turbine, it would
less confusing to users if it were its own top-level
project. Given the size and coherence of the
code-base it is not well suited in as a module of any
other project, such as commons.
JCS is ready for a production release. Over the past
year, we solved all major, known bugs. Although there
are a growing number of competitors, JCS has a good
number of users and is currently at a 1.2.1
development version.
JCS would be a good addition to the list of current
top level Jakarta projects, and, perhaps more
importantly, it would benefit from the input of a
larger community that increased exposure would afford.
II. Scope of the Package
JCS is a distributed caching system written in java
for server-side java applications. The project is an
attempt to build a system close to JCACHE , JSR-107, a
description of the caching system used in Oracle9i.
JCS is intended to speed up dynamic web applications
by providing a means to manage cached data of various
dynamic natures. Like any caching system, JCS is most
useful for high read, low put applications.
JCS is essentially a cache hub and several production
ready and experimental modules that can be plugged
into the hub. In JCS, cached data is stored in a
region. Each region can be configured independently
of the others. JCS is modeled on log4j, where various
appenders can be defined for specific regions.
JCS defines four types of appenders, or what we call
auxiliaries: memory, disk, lateral, and remote. A
memory auxiliary manages items stored in memory. Disk
auxiliaries manage memory overflow and persistence of
cached data. Lateral auxiliaries communicate directly
with other caches. Remote auxiliaries communicate
with a remote server to which other caches are
connected. At least one production ready
implementation of each type of auxiliary is included
in the core JCS jar. The LRU memory cache, indexed
disk cache, TCP lateral cache, JGroups lateral cache,
and RMI remote cache auxiliaries form the core suite
of stable JCS auxiliaries.
JCS is extremely configurable. Every auxiliary
exposes detailed configuration options. For example,
the indexed disk cache allows you to configure such
things as the maximum number of keys in memory, the
size of the recycle bin for reusing empty spots on
disk, whether it should defragment and if so when, and
the type of event queue to use. More information on
the available disk cache configuration options can be
found here:
http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html
One of the most important features of JCS is that you
can plug in new auxiliaries. Each type of auxiliary
has a defined interface, and the implementation class
can be defined in the JCS configuration file.
The cache hub and the core auxiliaries are contained
in a JAR file that is JDK 1.3 compatible. Other JDK
1.4 specific features are contained in another
optional JAR.
III. Interaction with other packages
JCS has dependencies on several standard commons
packages, including: commons-lang,
commons-collections, and commons-logging. We also
depend on Doug Lea's util concurrent JAR for some of
our locking and thread pools. Some of the optional
auxiliaries depend on other libraries. For instance,
the JGroups jar depends on the JGroups release. The,
JDK 1.4 optional, Berkeley DB auxiliary depends on the
related project.
The Cocoon project currently uses JCS as its caching
mechanism.
IV. Source of the package
I contributed JCS to the Stratum project, a subproject
of Turbine, over three years ago. It has been a sub
project of Turbine for about 2 years.
V. Base name for the package
The JCS code is currently checked into CVS with the
following root package name:
org.apache.jcs
VI. Coding conventions
The code follows a modified version of Sun's standard
coding conventions, with the following stylistic
changes:
� instance variables are prefixed with an underscore
� a newline is inserted before all braces
VII. Jakarta resources to be created
The current mailing lists are turbine-jcs-user@
jakarta.apache.org and turbine-jcs-dev@
jakarta.apache.org. We should forward these lists to,
or just create, these two new lists:
jcs-user@jakarta.apache.org -- User discussions
jcs-dev@jakarta.apache.org -- Developer discussions
and CVS update notifications
VIII. Initial set of committers
There are currently four committers on the JCS
project, all of whom have licenses on file.
Aaron Smuts <as...@apache.org>
James Taylor <ja...@jamestaylor.org>
Hanson Char <hc...@apache.org>
Travis Savo <ts...@IFILM.com>
VIII. Documentation
You can find the current JCS documentation here:
http://jakarta.apache.org/turbine/jcs/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE README
Posted by Aaron Smuts <as...@yahoo.com>.
I'd prefer that experimental ideas be put into an
experimental directory. We would do well to start
playing around with what jdk 1.5 will do for us.
Clearly this is nothing that we would release or jar.
Other caches, such as jboss cache, which I heard a
presentation on today (which is cool, but more like a
database than a cache, and will probably never perform
well), are using 1.4 features and are looking into 1.5
features. . .
If there are any legal issues, we should take the test
1.5 cache out of the repository. I wish it were not
in the experimental build directory, had proper apache
licenses, and was packaged appropriately. If these
things were done and it was removed from sourceforge,
then it seems fine.
If Hanson would rather play on sourceforge with new
ideas, then fine, but I don't want any problems if we
decide to use something for a memory module. I'd
prefer that we have some kind of sandbox in jcs
though. I think log4j has something like this. The
admin servlet was in it for a while (and may still be
there). I'd like to see a new memory cache module
come out of the 1.5 stuff he is working on. We have
1.4 extensions, but no 1.5 . . . I'd hope that this
kind of work could happen within jcs.
I lost the template for a project proposal. I'll just
try to submit something that addresses all the
concerns on the web site. Should I post a draft on
the mailing list first?
Aaron
--- Scott Eade <se...@backstagetech.com.au> wrote:
> Okay, but who is Joe Emporium (listed as the Project
> Developer and sole
> developer on SourceForge) and is there an ASF CLA on
> file for him?
>
> Have there been any other contributors to yajcache?
>
> Have you seen http://incubator.apache.org/index.html
> - this is the path
> by which projects must enter the ASF.
>
> It strikes me that there should have at least been
> some public
> discussion before this code is brought into the ASF.
>
> There have been a number of attempts at prodding
> Aaron to get his act
> together and propose that JCS move out from beneath
> Turbine to a direct
> subproject of Jakarta. Adding yajcache in this
> manner at this point in
> time may well complicate matters.
>
> Aaron: Would you mind please commenting on your
> progress with the
> proposal for JCS to become a direct Jakarta
> subproject. Do you have a
> handle at all on yajcache?
>
> Scott
>
>
> Hanson Char wrote:
>
> >The purpose is to have a jdk1.5 version of an
> experimental cache.
> >Details are explained in the README file . Will
> fix up the licenses
> >shortly.
> >
> >H
> >
> >
> >On Thu, 20 Jan 2005 22:59:04 +1100, Scott Eade
> <se...@apache.org> wrote:
> >
> >
> >>hchar@apache.org wrote:
> >>
> >>
> >>>hchar 2005/01/19 03:01:15
> >>>
> >>> Added:
> auxiliary-builds/jdk15/yajcache/cache build.xml
> LICENSE
> >>> README
> >>> Log:
> >>> no message
> >>>
> >>>
> >>It would be great if you could describe what you
> are committing.
> >><snip />
> >>
> >>
> >>> 1.1
>
jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache/LICENSE
> >>>
> >>> Index: LICENSE
> >>>
>
===================================================================
> >>>
> >>> Copyright 2005 Hanson Char
> >>>
> >>>
> >>I believe the above line should actually be:
> >> Copyright 2005 The Apache Software
> Foundation
> >>
> >>
> >>> Licensed under the Apache License, Version
> 2.0 (the "License");
> >>> you may not use this file except in
> compliance with the License.
> >>> You may obtain a copy of the License at
> >>>
> >>>
> http://www.apache.org/licenses/LICENSE-2.0
> >>>
> >>> Unless required by applicable law or agreed
> to in writing, software
> >>> distributed under the License is distributed
> on an "AS IS" BASIS,
> >>> WITHOUT WARRANTIES OR CONDITIONS OF ANY
> KIND, either express or implied.
> >>> See the License for the specific language
> governing permissions and
> >>> limitations under the License.
> >>>
> >>>
> >><snip />
> >>
> >>In the LICENSE file you should include the full
> ASL 2.0 text. Pretty
> >>much every other file should include the short
> version from:
> >>http://wiki.apache.org/general/LicenseFormats
> >>
> >>Given that this appears to be the yajcache project
> from sf.net, what
> >>procedures are being followed to import this code
> into the ASF? Usualy
> >>there is some kind of incubation process. I
> haven't seen any mention of
> >>the impending import of this code on
> turbine-jcs-dev or any of the more
> >>generic jakarta mailing lists.
> >>
> >>I think you may have skipped a few important steps
> with getting this
> >>code into the ASF. Would you mind please
> explaining your intentions.
> >>
> >>Thanks,
> >>
> >>Scott
> >>
>
>>---------------------------------------------------------------------
> >>To unsubscribe, e-mail:
> turbine-jcs-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
>
>---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> turbine-jcs-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache
build.xml LICENSE README
Posted by Scott Eade <se...@backstagetech.com.au>.
Okay, but who is Joe Emporium (listed as the Project Developer and sole
developer on SourceForge) and is there an ASF CLA on file for him?
Have there been any other contributors to yajcache?
Have you seen http://incubator.apache.org/index.html - this is the path
by which projects must enter the ASF.
It strikes me that there should have at least been some public
discussion before this code is brought into the ASF.
There have been a number of attempts at prodding Aaron to get his act
together and propose that JCS move out from beneath Turbine to a direct
subproject of Jakarta. Adding yajcache in this manner at this point in
time may well complicate matters.
Aaron: Would you mind please commenting on your progress with the
proposal for JCS to become a direct Jakarta subproject. Do you have a
handle at all on yajcache?
Scott
Hanson Char wrote:
>The purpose is to have a jdk1.5 version of an experimental cache.
>Details are explained in the README file . Will fix up the licenses
>shortly.
>
>H
>
>
>On Thu, 20 Jan 2005 22:59:04 +1100, Scott Eade <se...@apache.org> wrote:
>
>
>>hchar@apache.org wrote:
>>
>>
>>>hchar 2005/01/19 03:01:15
>>>
>>> Added: auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE
>>> README
>>> Log:
>>> no message
>>>
>>>
>>It would be great if you could describe what you are committing.
>><snip />
>>
>>
>>> 1.1 jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache/LICENSE
>>>
>>> Index: LICENSE
>>> ===================================================================
>>>
>>> Copyright 2005 Hanson Char
>>>
>>>
>>I believe the above line should actually be:
>> Copyright 2005 The Apache Software Foundation
>>
>>
>>> Licensed under the Apache License, Version 2.0 (the "License");
>>> you may not use this file except in compliance with the License.
>>> You may obtain a copy of the License at
>>>
>>> http://www.apache.org/licenses/LICENSE-2.0
>>>
>>> Unless required by applicable law or agreed to in writing, software
>>> distributed under the License is distributed on an "AS IS" BASIS,
>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>>> See the License for the specific language governing permissions and
>>> limitations under the License.
>>>
>>>
>><snip />
>>
>>In the LICENSE file you should include the full ASL 2.0 text. Pretty
>>much every other file should include the short version from:
>>http://wiki.apache.org/general/LicenseFormats
>>
>>Given that this appears to be the yajcache project from sf.net, what
>>procedures are being followed to import this code into the ASF? Usualy
>>there is some kind of incubation process. I haven't seen any mention of
>>the impending import of this code on turbine-jcs-dev or any of the more
>>generic jakarta mailing lists.
>>
>>I think you may have skipped a few important steps with getting this
>>code into the ASF. Would you mind please explaining your intentions.
>>
>>Thanks,
>>
>>Scott
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>
>
>
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE README
Posted by Hanson Char <ha...@gmail.com>.
The purpose is to have a jdk1.5 version of an experimental cache.
Details are explained in the README file . Will fix up the licenses
shortly.
H
On Thu, 20 Jan 2005 22:59:04 +1100, Scott Eade <se...@apache.org> wrote:
> hchar@apache.org wrote:
> > hchar 2005/01/19 03:01:15
> >
> > Added: auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE
> > README
> > Log:
> > no message
> It would be great if you could describe what you are committing.
> <snip />
> > 1.1 jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache/LICENSE
> >
> > Index: LICENSE
> > ===================================================================
> >
> > Copyright 2005 Hanson Char
> I believe the above line should actually be:
> Copyright 2005 The Apache Software Foundation
> >
> > Licensed under the Apache License, Version 2.0 (the "License");
> > you may not use this file except in compliance with the License.
> > You may obtain a copy of the License at
> >
> > http://www.apache.org/licenses/LICENSE-2.0
> >
> > Unless required by applicable law or agreed to in writing, software
> > distributed under the License is distributed on an "AS IS" BASIS,
> > WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> > See the License for the specific language governing permissions and
> > limitations under the License.
> <snip />
>
> In the LICENSE file you should include the full ASL 2.0 text. Pretty
> much every other file should include the short version from:
> http://wiki.apache.org/general/LicenseFormats
>
> Given that this appears to be the yajcache project from sf.net, what
> procedures are being followed to import this code into the ASF? Usualy
> there is some kind of incubation process. I haven't seen any mention of
> the impending import of this code on turbine-jcs-dev or any of the more
> generic jakarta mailing lists.
>
> I think you may have skipped a few important steps with getting this
> code into the ASF. Would you mind please explaining your intentions.
>
> Thanks,
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache
build.xml LICENSE README
Posted by Scott Eade <se...@apache.org>.
hchar@apache.org wrote:
> hchar 2005/01/19 03:01:15
>
> Added: auxiliary-builds/jdk15/yajcache/cache build.xml LICENSE
> README
> Log:
> no message
It would be great if you could describe what you are committing.
<snip />
> 1.1 jakarta-turbine-jcs/auxiliary-builds/jdk15/yajcache/cache/LICENSE
>
> Index: LICENSE
> ===================================================================
>
> Copyright 2005 Hanson Char
I believe the above line should actually be:
Copyright 2005 The Apache Software Foundation
>
> Licensed under the Apache License, Version 2.0 (the "License");
> you may not use this file except in compliance with the License.
> You may obtain a copy of the License at
>
> http://www.apache.org/licenses/LICENSE-2.0
>
> Unless required by applicable law or agreed to in writing, software
> distributed under the License is distributed on an "AS IS" BASIS,
> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> See the License for the specific language governing permissions and
> limitations under the License.
<snip />
In the LICENSE file you should include the full ASL 2.0 text. Pretty
much every other file should include the short version from:
http://wiki.apache.org/general/LicenseFormats
Given that this appears to be the yajcache project from sf.net, what
procedures are being followed to import this code into the ASF? Usualy
there is some kind of incubation process. I haven't seen any mention of
the impending import of this code on turbine-jcs-dev or any of the more
generic jakarta mailing lists.
I think you may have skipped a few important steps with getting this
code into the ASF. Would you mind please explaining your intentions.
Thanks,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org