Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[sebb]

On 23 February 2012 20:11, Damian Steer  wrote:
>
> On 23 Feb 2012, at 18:32, sebb wrote:
>
>>> == Proposed dist/ area:
>>>
>>> The following will be added to the existing distribution area:
>>>
>>> http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-4/
>>
>> Where is the source that corresponds to:
>>
>> download/apache-jena-tdb-0.9.0-incubating.zip
>>
>> It's not easy to find.
>>
>> And the reverse is just as hard.
>
> I see only one file under source, and it seems to build everything found 
> under dist.
>
>>> https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/
>>
>> There are a lot of source files without AL headers.
>> These need to be fixed.
>
> jena-tdb-0.9.0-incubating-RC-4 pldms$ ack  -v -l 'Licensed to the Apache 
> Software Foundation' .
> ...
> src-dev/dev/LongTermIssues.java
> ...
>
> Only one source file is missing this (plus a number of configuration files 
> and shell scripts). Am I missing something obvious? (a: probably)

All of those should have AL headers.

> Damian
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[sebb]

On 23 February 2012 19:42, Mattmann, Chris A (388J)
 wrote:
> Hi Sebb,
>
> On Feb 23, 2012, at 12:13 PM, sebb wrote:
>
>>>
>>> On the contrary, they are plenty useful to Maven. They are used by its
>>> assembly plugin to allow for transitive dependencies and the ability to
>>> unpackage those distros as needed.
>>
>> Huh?
>> Are you sure?
>
> Yep, I'm not an expert, but we push tar.gz and .zip distributions in OODT, and
> then we have specialized assembly.xml descriptors in downstream OODT 
> components
> that depend on the tarballs, and Maven will go and get them remotely.
>
> Paul Ramirez knows a ton about this in OODT: I've mainly just been a watcher 
> of
> his "Maven magic" :) But, I do know they are useful, at least to us in OODT, 
> and
> wanted to mention it.

Sounds like that is specific to the way OODT does its resolution.

> Cheers,
> Chris
>
> ++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattm...@nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[sebb]

On 23 February 2012 20:44, Andy Seaborne  wrote:
> On 23/02/12 18:32, sebb wrote:
>
> Hi sebb,
>
> Thanks for the review,
>
>
>>> == Staging repository
>>>
>>> https://repository.apache.org/content/repositories/orgapachejena-001/
>>
>> This contains zip and tar.gz binary and source archives, which should
>> be deleted as they are not useful to Maven.
>
>
> There are two addition classifiers used: source-release and distribution.
>
> To take the file jena-tdb-0.9.0-incubating-source-release.zip specifically,
> this gets there because
>
>   mvn release:perform -Papache-release
>
> puts it there.  This seems to be the practice elsewhere as well:
>
> e.g.
> https://repository.apache.org/content/repositories/releases/org/apache/sling/org.apache.sling.engine/2.2.4/
>
>
> For "distribution":
>
> We distribute through maven but also many of our users are not experienced
> developers but students, including ones new to java.
>
> To make it as easy as possible for this category of user, we ship a
> distribution which is the collection of jars needed for use without a
> maven/ivy infrastructure.

That's fine, so long as the N&L files agree with the contents.

> This is created in the maven target/ area - and it is then renamed into the
> dist/ area as apache-jena* by the distribution build script.  Maven forces
> the name to be jena-tdb- on staging whatever assembly root name is
> given.

Again that's OK, but the layout of the dist area - and the naming
convention - is very confusing.

There is no direct correspondance between the binary and source archives.
It should be immediately obvious how to find the source and
corresponding binary, but that's not the case at present.

>
>>> == SVN tag
>>> >
>>> >  The module is currently tagged with the version and "-RC-4".  If voted
>>> > on
>>> >  successfully, the tag will be changed ("svn mv") to the same but minus
>>> > the
>>> >  "RC" labelling.
>>> >
>>> >
>>> >  https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/
>>
>> There are a lot of source files without AL headers.
>> These need to be fixed.
>>
>
> Could you say which ones you mean?
>
> Following the recent discussion on this (LEGAL-124), I thought the
> conclusion was it wasn't necessary on short files with little or no
> creativity or value.
>
> The files in testing/ are short test files - we do put the ASF header on the
> manifests.
>
> e.g:
> https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/testing/Pattern/pattern-1.rq
>
> 
> PREFIX :  <http://example/OTHER>
>
> SELECT *
> {
>    :NoSuchNode ?p ?z .
>    ?x ?p ?z
> }
> 
> I found
>  A total of 118 files that do not contain th line
> "Licensed to the Apache Software Foundation (ASF) under"
>
>  67 under testing/
>  25 are scripts

The scripts can all have AL headers; there are some XML files as well
that could have them.
There is one Java file that has no AL header.

>  12 are NOTICE/LICENSE/DEPENDENCIES etc.

These are OK

> and then there setting and eclipse files that you have commented on before.
>
> (aside: we tried autogenerating Eclipse files following previous comments
> but encountered problems with eclipse:eclipse which we are investigating)

No need to autogenerate; just don't store them with the default names or paths.

Perhaps store them under a resources/eclipse directory.

>
>        Andy
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[sebb]

On 23 February 2012 21:21, Mattmann, Chris A (388J)
 wrote:
> Hi Sebb,
>
> On Feb 23, 2012, at 1:15 PM, sebb wrote:
>
>>>
>>> Yep, I'm not an expert, but we push tar.gz and .zip distributions in OODT, 
>>> and
>>> then we have specialized assembly.xml descriptors in downstream OODT 
>>> components
>>> that depend on the tarballs, and Maven will go and get them remotely.
>>>
>>> Paul Ramirez knows a ton about this in OODT: I've mainly just been a 
>>> watcher of
>>> his "Maven magic" :) But, I do know they are useful, at least to us in 
>>> OODT, and
>>> wanted to mention it.
>>
>> Sounds like that is specific to the way OODT does its resolution.
>
> Well not really. It's the Maven assembly plugin and specific to it.

I'm suprised that Maven - which normally handles dependency resolution
very well - should rely on components packaging their dependencies for
downstream components. It should be able to resolve the dependencies
from the pom, and then fetch them directly from the repo, rather than
having to unpack an archive.

But this is getting seriously OT for this thread.

> Cheers,
> Chris
>
> ++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattm...@nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[sebb]

On 24 February 2012 12:11, Andy Seaborne  wrote:
>
>>> We distribute through maven but also many of our users are not
>>> experienced
>>> developers but students, including ones new to java.
>>>
>>> To make it as easy as possible for this category of user, we ship a
>>> distribution which is the collection of jars needed for use without a
>>> maven/ivy infrastructure.
>>
>>
>> That's fine, so long as the N&L files agree with the contents.
>
>
> They should do.
>
>
>>> This is created in the maven target/ area - and it is then renamed into
>>> the
>>> dist/ area as apache-jena* by the distribution build script.  Maven
>>> forces
>>> the name to be jena-tdb- on staging whatever assembly root name is
>>> given.
>>
>>
>> Again that's OK, but the layout of the dist area - and the naming
>> convention - is very confusing.
>>
>> There is no direct correspondance between the binary and source archives.
>> It should be immediately obvious how to find the source and
>> corresponding binary, but that's not the case at present.
>
>
> The directory structures align:
>
> /download/jena-tdb-0.9.0-incubating
> /source-release/jena-tdb-0.9.0-incubating

I see the following files (amongst others) in the RC area
http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-4/

KEYS
download/apache-jena-tdb-0.9.0-incubating.zip
download//jena-tdb-0.9.0-incubating/jena-tdb-0.9.0-incubating.jar
source-release/jena-tdb-0.9.0-incubating/jena-tdb-0.9.0-incubating-source-release.zip

Note that the source release is in
  source-release/jena-tdb-0.9.0-incubating/
whereas the corresponding binary release is in
  download/
i.e. different depths - and they have different names.

[I'm discounting the jar, since that is Maven-specific and is not
needed on the dist/ mirror site.]

> but since this isn't "/binaries" and "/sources" we'll build about RC - we'll
> be back in a week to 10 day I hope.

Does not have to be binaries and source (sic), so long as the source
and binary archives are directly related.
They have different names at present, which makes it difficult to tie
them together.

Also, the convention is to have the source and binary archives:
- in the same directory, or
- in parallel directories (binaries/source)

In the case of OS-specific binaries, these could be in folders such as

binaries/plan9
binaries/windows

etc.

In such cases, the binary archives would be one level lower than the
source archive, but that is easy to follow.

>
>> The scripts can all have AL headers; there are some XML files as well
>> that could have them.
>
>
> I will put either short or full AL headers on the scripts.
>
> find . -name \*xml | xargs grep -L "Licensed to the Apache Software
> Foundation" | xargs wc -l
>
>  39 ./testing/Deployment/pom.xml
>   8 ./src/main/java/com/hp/hpl/jena/tdb/tdb-properties.xml
>   8 ./src/main/resources/org/apache/jena/tdb/tdb-properties.xml
>  55 total
>
> and tdb-properies.xml has 2 Java properties.
>
>        Andy
>
>
>> There is one Java file that has no AL header.
>>
>>>  12 are NOTICE/LICENSE/DEPENDENCIES etc.
>>
>>
>> These are OK
>>
>>> and then there setting and eclipse files that you have commented on
>>> before.
>>>
>>> (aside: we tried autogenerating Eclipse files following previous comments
>>> but encountered problems with eclipse:eclipse which we are investigating)
>>
>>
>> No need to autogenerate; just don't store them with the default names or
>> paths.
>>
>> Perhaps store them under a resources/eclipse directory.
>>
>>>
>>>        Andy
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[sebb]

On 24 February 2012 22:00, Andy Seaborne  wrote:
> On 24/02/12 14:04, sebb wrote:
>>>
>>> The directory structures align:
>>>
>>> /download/jena-tdb-0.9.0-incubating
>>> /source-release/jena-tdb-0.9.0-incubating
>>
>>
>> I see the following files (amongst others) in the RC area
>> http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-4/
>>
>> KEYS
>> download/apache-jena-tdb-0.9.0-incubating.zip
>> download//jena-tdb-0.9.0-incubating/jena-tdb-0.9.0-incubating.jar
>>
>> source-release/jena-tdb-0.9.0-incubating/jena-tdb-0.9.0-incubating-source-release.zip
>>
>> Note that the source release is in
>>   source-release/jena-tdb-0.9.0-incubating/
>> whereas the corresponding binary release is in
>>   download/
>> i.e. different depths - and they have different names.
>>
>> [I'm discounting the jar, since that is Maven-specific and is not
>> needed on the dist/ mirror site.]
>
>
> I see the confusion now - the main product of the codebase is the core
> jena-tdb-0.9.0-incubating.jar with
> apache-jena-tdb-0.9.0-incubating-distibution.zip being a subsidiary
> creation.
>
> If there were a file:
>
> download/jena-tdb-0.9.0-incubating/jena-tdb-0.9.0-incubating-distribution.zip
>
> then it would be aligned with the source-release hierarchy.
>
> The apache-jena-tdb... is then merely being a renamed file for browsing
> apache-jena-tdb-0.9.0-incubating-distribution.zip
>
> (c.f. Ant which has renamed items in it dist/ant)
>
> Would a structure:
>
> dist
> |-- binaries
> |   `-- jena-tdb-0.9.0-incubating
> |       |-- jena-tdb-0.9.0-incubating-distribution.tar.gz
> |       |-- jena-tdb-0.9.0-incubating-distribution.zip
> |       |-- jena-tdb-0.9.0-incubating-javadoc.jar
> |       |-- jena-tdb-0.9.0-incubating-sources.jar
> |       |-- jena-tdb-0.9.0-incubating.jar

The jars are not generally needed for dist/

> |-- download
> |   |-- apache-jena-tdb-0.9.0-incubating-distribution.tar.gz
> |   |-- apache-jena-tdb-0.9.0-incubating-distribution.zip

Are these the same as the distribution archives above?

> `-- source-release
>    `-- jena-tdb-0.9.0-incubating

What's the point of the subdirectory?

>        |-- jena-tdb-0.9.0-incubating-source-release.zip

Name does not agree with binary archives

> + the .asc, .md5 .sha1 files
>
> be acceptable?
>
> Or with "download/" removed its files at the top level?

I still find it very confusing.
e.g. where is the source file for jena-tdb-0.9.0-incubating-distribution.tar.gz?

Why is there a download directory and a binaries directory?

> Mocked up at:
>
> http://people.apache.org/~andy/dist-tdb-proto/
>

See my mockups at:

http://people.apache.org/~sebb/dist-tdb-proto/

one - parallel binaries/ and source/
two - single directory named after the release.

The latter is likely to be easier to manage when moving to svnpubsub.

$ ls -1R

./one:
KEYS
binaries
source

./one/binaries:
apache-jena-tdb-0.9.0-incubating-distribution.tar.gz
apache-jena-tdb-0.9.0-incubating-distribution.zip

./one/source:
apache-jena-tdb-0.9.0-incubating-source-release.zip

./two:
KEYS
apache-jena-tdb-0.9.0-incubating

./two/apache-jena-tdb-0.9.0-incubating:
apache-jena-tdb-0.9.0-incubating-distribution.tar.gz
apache-jena-tdb-0.9.0-incubating-distribution.zip
apache-jena-tdb-0.9.0-incubating-source-release.zip

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[sebb]

On 26 February 2012 15:41, Andy Seaborne  wrote:
> sebb,
>
> What I'm trying to get to at the moment is something that enables a release
> of TDB and we can apply to next module.
>
> jena is a number of modules, we have released 3 (5 actually - 2 are the
> parent POM and the distribution maker for the core) already; TDB is the
> sixth, and there are 3 more in the pipeline.
>
> People have been asking for more packaging forms - WAR file for the server
> functionality, OSGi for Jena as a whole, which seems to be a non-trivial
> exercise.
>
> One of the ones to come is not a simple jar build - it's a server that can
> used as a jar, as a combined dependencies jar or run from the command line.
>  I'm trying to understand the constraints required so that will be
> smooth(er).
>
> We are discussing rebuilding our build strategy but doing so, and to get it
> working reliably and stably will take time.  We chose to release with what
> we have, and not let reworking the build system become critical path for
> graduation.
>
>
>>> The apache-jena-tdb... is then merely being a renamed file for browsing
>>> apache-jena-tdb-0.9.0-incubating-distribution.zip
>>>
>>> (c.f. Ant which has renamed items in it dist/ant)
>
> I referred to Ant specifically because the incubator documentation for
> podling releases picks ant and httpd out as examples to look at.
>
> ant has top level items for easy discovery which are renamed duplicates of
> things in binaries/
>
>
>>> `-- source-release
>>>     `-- jena-tdb-0.9.0-incubating
>>
>> What's the point of the subdirectory?
>
> because there are other modules with their own source-release artifact.  The
> TDB release items will be merged into the existing directory.

So why don't you do the same for the download directory?

> We had been following a layout like CXF where source-release and binaries
> are in the same directory.  Given that is where a the maven-driven process
> puts them, someone taking the source releease doing "mvn package" is going
> to look in target/ and expect created items to be there.
>
> That was the RC-2 proposal for dist for TDB.  If, as seems necessary, we
> have to adopt a different layout, we'll reorganise the existing release
> items into the same structure.
>
>
>>> Would a structure:
>>>
>>> dist
>>> |-- binaries
>>> |   `-- jena-tdb-0.9.0-incubating
>>> |       |-- jena-tdb-0.9.0-incubating-distribution.tar.gz
>>> |       |-- jena-tdb-0.9.0-incubating-distribution.zip
>>> |       |-- jena-tdb-0.9.0-incubating-javadoc.jar
>>> |       |-- jena-tdb-0.9.0-incubating-sources.jar
>>> |       |-- jena-tdb-0.9.0-incubating.jar
>>
>>
>> The jars are not generally needed for dist/
>>
>>> |-- download
>>> |   |-- apache-jena-tdb-0.9.0-incubating-distribution.tar.gz
>>> |   |-- apache-jena-tdb-0.9.0-incubating-distribution.zip
>>
>>
>> Are these the same as the distribution archives above?
>>
>>> `-- source-release
>>>    `-- jena-tdb-0.9.0-incubating
>>
>>
>> What's the point of the subdirectory?
>>
>>>        |-- jena-tdb-0.9.0-incubating-source-release.zip
>>
>>
>> Name does not agree with binary archives
>>
>>> + the .asc, .md5 .sha1 files
>>>
>>> be acceptable?
>>>
>>> Or with "download/" removed its files at the top level?
>>
>>
>> I still find it very confusing.
>> e.g. where is the source file for
>> jena-tdb-0.9.0-incubating-distribution.tar.gz?

Sorry, that was a mistake - I meant where is the source for the dowload file

apache-jena-tdb-0.9.0-incubating-distribution.tar.gz

>
>
> jena-tdb-0.9.0-incubating-source-release.zip

Not only is the name different, but also the archive type is different.
That is very confusing.

> Given the way maven classifiers work, it is a reasonable expectation of the
> user to find the various classifier artifacts in target/ after
> "mvn package"

Yes, but what has Maven to do with the self-contained release archives?

>
>> Why is there a download directory and a binaries directory?
>
>
> Like ant, I pulled out the items which are "download-unpack-go".  The dist
> areas serves several audiences - for (new) users, not necessarily
> experienced maven users, we have the Jena website (we use Apache CMS to
> produce the website, not maven by the way) simply point to download/
> (mirrored).  Ditto URLs handled out on the web as being the place to go to
> download Jena.

There should be no need to 

Re: [VOTE] RAT Ready To Graduate As Apache Creadur Top Level Project

[sebb]

On 26 February 2012 16:03, Robert Burrell Donkin  wrote:
> The graduation guide[1] recommends that the Rat community demonstrates it's
> willingness to govern itself through a free VOTE before asking the IPMC to
> approve graduation. So, here it is :-)
>
> See [2] for a draft of the charter, excluding the list of initial
> committers. Unless anyone jumps into this thread, I'll assume that the
> current list of committers would be fine. Please read, review and jump in -
> but this is a vote on the principle of graduating now.
>
> This VOTE is open to all, and I'll tally this no early than Wednesday, 29
> Feb 2012 17:00 UTC.
>
> Robert
>
> --8<---
> [X] +1 the RAT community feels ready to graduate as Apache Creadur
> [ ] +0
> [ ] -0
> [ ] -1 Do not graduate RAT at this time
> ---
>
>
> [1] http://incubator.apache.org/guides/graduation.html#toplevel
> [2] Suggested Draft Charter:
>
>       WHEREAS, the Board of Directors deems it to be in the best
>       interests of the Foundation and consistent with the
>       Foundation's purpose to establish a Project Management
>       Committee charged with the creation and maintenance of
>       open-source software related to the comprehension and
>       auditing of software distributions for distribution at
>       no charge to the public.
>
>       NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>       Committee (PMC), to be known as the "Apache Creadur Project",
>       be and hereby is established pursuant to Bylaws of the
>       Foundation; and be it further
>
>       RESOLVED, that the Apache Creadur Project be and hereby is
>       responsible for the creation and maintenance of open-source
>       software related to the comprehension and auditing of software
>       distributions for distribution at no charge to the public
>
>       RESOLVED, that the office of "Vice President, Apache Creadur" be
>       and hereby is created, the person holding such office to
>       serve at the direction of the Board of Directors as the chair
>       of the Apache Creadur Project, and to have primary responsibility
>       for management of the projects within the scope of
>       responsibility of the Apache Creadur Project; and be it further
>
>       RESOLVED, that the persons listed immediately below be and
>       hereby are appointed to serve as the initial members of the
>       Apache Creadur Project:
>
>       ...
>
>       NOW, THEREFORE, BE IT FURTHER RESOLVED, that Robert Burrell
>       Donkin be appointed to the office of Vice President, Apache
>       Creadur, to serve in accordance with and subject to the
>       direction of the Board of Directors and the Bylaws of the
>       Foundation until death, resignation, retirement, removal or
>       disqualification, or until a successor is appointed; and be
>       it further
>
>       RESOLVED, that the initial Apache Creadur PMC be and hereby is
>       tasked with the creation of a set of bylaws intended to
>       encourage open development and increased participation in the
>       Apache Creadur Project; and be it further
>
>       RESOLVED, that the Apache Creadur Project be and hereby
>       is tasked with the migration and rationalization of the Apache
>       Incubator RAT podling; and be it further
>
>       RESOLVED, that all responsibilities pertaining to the Apache
>       Incubator RAT podling encumbered upon the Apache Incubator
>       Project are hereafter discharged.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [ATTN] Incubator releases distribution area reminder!

[sebb]

On 26 February 2012 18:39, Daniel Shahaf  wrote:
> Andy Seaborne wrote on Sun, Feb 26, 2012 at 17:37:49 +:
>> 3/
>>
>> [[
>> Often symbolic links are created from the root of the project
>> distribution directory to the latest version of each release. This
>> allows scripts or users to easily locate the latest release.

AIUI, this is a bad idea, because:
- the links are frequently not updated
- they don't work for mirrors, which means the mirrors space usage increases
- when the file is downloaded using the link, the file name does not
include the version information

Users will normally get the latest release from the download page, so
the only possible use is for scripts.

>> ]]
>>
>> is at odds with
>>
>> http://www.apache.org/dev/mirror-step-by-step.html
>> [[
>> 9. Do not use symbolic links in mirrored directories!
>> ]]
>> although that does say "Note: This file contains out-of-date information."
>>
>
> That refers to the suggestion to ssh www.  But yeah, I can assure you
> that until a few weeks ago no one (PMC or podling) used symlinks in that
> matter, and even today there exists only one such link in the entire
> dist/ tree.

Huh?

The use of symlinks under /www/www.apache.org/dist is unfortunately
still quite common.

pwd dist : pwd
/www/www.apache.org/dist
pwd dist : find . -type l -name "*current*.asc" -ls | wc -l
  77

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [ATTN] Incubator releases distribution area reminder!

[sebb]

On 27 February 2012 03:01, Daniel Shahaf  wrote:
> sebb wrote on Mon, Feb 27, 2012 at 02:17:15 +:
>> On 26 February 2012 18:39, Daniel Shahaf  wrote:
>> > Andy Seaborne wrote on Sun, Feb 26, 2012 at 17:37:49 +:
>> >> 3/
>> >>
>> >> [[
>> >> Often symbolic links are created from the root of the project
>> >> distribution directory to the latest version of each release. This
>> >> allows scripts or users to easily locate the latest release.
>>
>> AIUI, this is a bad idea, because:
>> - the links are frequently not updated
>> - they don't work for mirrors, which means the mirrors space usage increases
>> - when the file is downloaded using the link, the file name does not
>> include the version information
>>
>> Users will normally get the latest release from the download page, so
>> the only possible use is for scripts.
>>
>> >> ]]
>> >>
>> >> is at odds with
>> >>
>> >> http://www.apache.org/dev/mirror-step-by-step.html
>> >> [[
>> >> 9. Do not use symbolic links in mirrored directories!
>> >> ]]
>> >> although that does say "Note: This file contains out-of-date information."
>> >>
>> >
>> > That refers to the suggestion to ssh www.  But yeah, I can assure you
>> > that until a few weeks ago no one (PMC or podling) used symlinks in that
>> > matter, and even today there exists only one such link in the entire
>> > dist/ tree.
>>
>> Huh?
>>
>> The use of symlinks under /www/www.apache.org/dist is unfortunately
>> still quite common.
>>
>> pwd dist : pwd
>> /www/www.apache.org/dist
>> pwd dist : find . -type l -name "*current*.asc" -ls | wc -l
>>       77
>
> deltacloud/stable is only symlink that cron complain about.  (Feel free
> to compare it between archive and dist.)  It's on root@'s todo list,
> somewhere, to make those complaints stop.

deltacloud/stable is a softlink to a directory; there are several
other such links, e.g.

zookeeper/current
zookeeper/stable

I've no idea why deltacloud is the only such one that cron does not like.

But this is straying away from the question about the use of symlinks.

Why does the incubator document disagee with the dev/ document?

Are symlinks disallowed/deprecated/allowed?

Or perhaps only some types of links are allowed - e.g. README.html,
KEYS, i.e. files that are not release-specific.

The policy ought to be determined and documented properly, including
the assumptions/reasoning behind the policy.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: CMS! Re: buildbot success in ASF Buildbot on incubator-site-staging

[sebb]

On 1 March 2012 14:39, Joe Schaefer  wrote:
> OK http://incubator.staging.apache.org/ is up.
> All we need to do at this point is migrate site-author/
> to content/ and flip on svnpubsub for production.
>
> Any takers?

OK, I'm happy to do the SVN and build.xml changes.

Just to confirm what needs to be done:
- rename site-author/ as content/
- fix up build.xml (and any other scripts that use site-author)
- (test and) commit the changes

Is that correct?

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: CMS! Re: buildbot success in ASF Buildbot on incubator-site-staging

[sebb]

On 1 March 2012 20:44, Joe Schaefer  wrote:
> +1, thanks sebb!

[Top -posting?]

>
>
>>____
>> From: sebb 
>>To: general@incubator.apache.org; Joe Schaefer 
>>Sent: Thursday, March 1, 2012 3:42 PM
>>Subject: Re: CMS! Re: buildbot success in ASF Buildbot on 
>>incubator-site-staging
>>
>>On 1 March 2012 14:39, Joe Schaefer  wrote:
>>> OK http://incubator.staging.apache.org/ is up.
>>> All we need to do at this point is migrate site-author/
>>> to content/ and flip on svnpubsub for production.
>>>
>>> Any takers?
>>
>>OK, I'm happy to do the SVN and build.xml changes.
>>
>>Just to confirm what needs to be done:
>>- rename site-author/ as content/
>>- fix up build.xml (and any other scripts that use site-author)
>>- (test and) commit the changes
>>
>>Is that correct?

I've done a search for "site-author" and it appears in the build and
clutch scripts, as well in various documentation files.

I suspect that many of the docn files will need more updating than
just replacing site-author by content.

I propose to leave the site-author references in files that need more
than a simple replacement.
This is because it will be easy to find the string "site-author".

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[SITE] site-author renamed to content

[sebb]

In preparation for moving the Incubator site to svnpubsub, the SVN
source for the site, i.e. site-author/, has been renamed to content/

The site Ant build and clutch still work as before.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Apache RAT

[sebb]

RATify?

Or rat as in the verb -  to rat on something ;-)


On 25/10/2007, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> > RAT is a good name and popular but i'm still a little concerned that
> > there are existing open source projects named RAT as well as
> > commercial software containing RAT in their name.
>
> aRATicate, known as RAT for short?  ;-)
>
>--- Noel
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: ASF Web of Trust [was: Release Distribution Strategy]

[sebb]

On 29/10/2007, Erik Abele <[EMAIL PROTECTED]> wrote:
> On 29.10.2007, at 03:13, Niclas Hedhman wrote:
>
> > On Sunday 28 October 2007 23:15, Erik Abele wrote:
> >> As BenL always says: "I don't give a shit about some random document,
> >> that could be faked anyway. All I care about is the email address
> >> connected to the key I intend to sign - is it really the address of
> >> the person in question?".
> >
> > Ok, and if you don't know the individual in person, you put the
> > trust in
> > a "Driver's license" or similar... but doesn't really care how that
> > 'trust'
> > was established.
>
> There's a ton of interpretations and levels of trust out there; I
> suggest you consult Google for that.
>
> > I must be plain dumb, but I don't "get" why this provides any
> > comfort to
> > end-users, even if they manage to figure out what to do with
> > the .ASCs (I bet
> > a very small percentage do).
>
> Well, if you verify an ASF release it can show you two things:
>
> a) if the signature is good you know that the file has not been
> tampered with;
>it's the same as when the release was originally cut by the RM
> b) if you can establish a trust path to the signer of the file then
> you can be
>pretty sure that it's a legit release and not a faked one

Even if you can't establish a trust path, the PGP signature gives a
bit more assurance than a hash. The KEY file should be in SVN, so you
can ensure that the person that added the key to the KEY file was at
least a committer to SVN.

> Again, please see http://httpd.apache.org/dev/verification.html -
> especially the sections on "Checking Signatures" [a) above] and
> "Validating Authenticity of a Key" [b) above].
>
> Re small percentage: I doubt that most users even care; the majority
> probably won't even think about it :(
>
> > And that is why I am asking for better tooling.
>
> Ok, feel free to improve that :-)
>
> >> See also http://wiki.apache.org/apachecon/PgpKeySigning
> >
> > Ok, it shows half the picture; How to sign the keys are left out...
>
> See one of the billions of tutorials in Google, or simply "man
> gpg" (--sign-key or --edit-key).
>
> >>> as well as tooling support for verifications.
> >> http://httpd.apache.org/dev/verification.html
> >
> > U, we probably have more than a million users. Do we expect
> > them all to
> > get a hook into the WOT ?? IMHO, there is something wrong with that
> > picture...
>
> The million users don't even care about all that - the ones who do
> will find a way to connect the dots or even get into the WOT (see
> examples provided by Robert).
>
> E.g. if I see that a release is signed by the key XYZ of S. Striker
> and I go and fetch that key from a public keyserver and take a look
> at the list of signatures, I'll find out that there a names like Roy
> T. Fielding, Jim Jagielski, and so on... now, when I compare the
> fingerprints and maybe also have a look at http://www.apache.org/dist/
> httpd/KEYS then I can be pretty sure that the release was made by an
> official member of the HTTPD PMC - that should be enough for Random
> Joe to feel comfortable...
>
> > Couldn't a simple; http://www.apache.org/verify where I put the ASC
> > file (and
> > the MD5 of download??) and get a "Authenticated" or not response be
> > done?? If
> > that is too hard to automate, I don't think we ever will see any
> > increase in
> > user awareness.
>
> http://people.apache.org/~henkp/cgi-bin/md5.cgi will verify the MD5
> for you - it doesn't really make sense to have the same for PGP
> signatures IMHO.
>
> > The process on the above page is beyond most users'
> > imagination.
>
> As said, they probably don't even care otherwise they would know...
>
> Cheers,
> Erik
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: ASF Web of Trust [was: Release Distribution Strategy]

[sebb]

On 29/10/2007, Gilles Scokart <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-----
> > From: sebb [mailto:[EMAIL PROTECTED]
> >
> > Even if you can't establish a trust path, the PGP signature gives a
> > bit more assurance than a hash. The KEY file should be in SVN, so you
> > can ensure that the person that added the key to the KEY file was at
> > least a committer to SVN.
>
> That's only for the users who have https access to SVN (and who can reliably 
> verify the SSH key of the server).  The
> others have to assume that server from which they are reading the KEY file is 
> the real one.
>

Strictly speaking, yes.

The KEY file can be downloaded without needing https access, but as
you point out, this is not necessarily a guarantee of authenticity.

However, it is one more obstacle that a hacker would have to surmount
- they would have to subvert the SVN host as well as the main apache
host holding the KEY file.

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

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

Re: [VOTE] Approve release CXF 2.0.3-incubator

[sebb]

On 10/11/2007, Daniel Kulp <[EMAIL PROTECTED]> wrote:
>
> We held a vote on [EMAIL PROTECTED] to publish a new patch
> release of Apache CXF.This release is mostly a patch release to fix
> problems and issues (82 JIRA items resolved) that users have encountered
> in the 2.0.2-incubator
> release.
>
> From an IPMC review standpoint, the major changes are:
> 1) Upgraded to newer versions of a couple libs.   No license changes or
> anything.
>
> 2) The NOTICE file has a new format.   We upgraded to newer versions of
> the remote-resources stuff that allows a much more organized and easier
> to follow NOTICE files.   The information is all the same, just clearer.
>
>
> For a full list of the issues, see:
> http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312800&styleName=Text&projectId=12310511&Create=Create
>
> The staging area is at:
> http://people.apache.org/~dkulp/stage_cxf/2.0.3-incubator-take1/

Minor nit: the MD5 files only contain the hash; some checking tools
also require the file name in the format *binaryfilename, e.g.

apache-cxf-2.0.3-incubator-src.zip.md5
would contain

4cb1791b3bdc91d302cb50f5eb1a3f88 *apache-cxf-2.0.3-incubator-src.zip

This can be added to Maven builds using a suitable Ant task.

>
> The distributions are in the "dist" directory. The "maven" directory
> contains the stuff that will by pushed to the m2-incubating-repository.
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.3-incubator/
>
>
> I've also created a list of the "!" files from rat and categoriezed
> them.   This is checked into SVN along with the tag:
> http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.3-incubator/etc/rat.unknowns.txt
>
>
> The vote on cxf-dev resulting in 15 +1 votes:
> +1 IPMC: 2   (jim, jgenender)
> +1 committers:  12 (dkulp, bmargulies, wjiang, gmazza, blin, ffang, jmao,
> jliu, jma, ubhole, gnodet, apaibir, ddiephouse)
> No 0 or -1 votes.
>
> Vote thread:
> http://www.nabble.com/-VOTE--Release-CXF-2.0.3-incubator-tf4760901.html
>
>
> This vote will remain open for at least 72 hours.  (probably longer due
> to travelling to ApacheCon, see you all there!)
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727C: 508-380-7194
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Removing ServiceMix from the list of incubating project

[sebb]

Does this help?

http://incubator.apache.org/guides/website.html

On 13/11/2007, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> Is the web site archived somewhere, should I just edit the web page under
>   /www/incubator.apache.org/projects/index.html
> or is there a better way to do that ?
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
>

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

RAT and MANIFEST.MF validation

[sebb]

RAT should not expect MANIFEST.MF to include a licence.

Would it be useful if it insisted on certain other contents of the
manifest file instead?

e.g.

Implementation-Title:
Implementation-Vendor:
Implementation-Vendor-Id:
Implementation-Version:

Specification-Title:
Specification-Vendor:
Specification-Version:

Just a thought.

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

Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating

[sebb]

[Eventually found the KEYS file in SVN, but it might be helpful to
provide a pointer in the vote mails]

The NOTICE file in uimaj-2.2.1-incubating-bin.zip refers to the
contributions from IBM:

"Software Grant License Agreement", informally known as the
"IBM UIMA License Agreement".

however, that license is not in LICENSE, nor is it linked from there.

There are some problems with the MD5 and SHA1 files.

For example, uimaj-2.2.1-incubating-bin.tar.bz2.md5:


uimaj-2.2.1-incubating-bin.tar.bz2: 53 20 6A FB 75 1F 07 9D  BB 12 82 58 D0 7D
CA 4B


The hash is spread over two lines and into hex pairs. The normal
format is either:
53206afb751f079dbb128258d07dca4b
or
53206afb751f079dbb128258d07dca4b *uimaj-2.2.1-incubating-bin.tar.bz2

The SHA1 checksums have the same problem.

The PGP signatures are OK, however the format of the existing MD5/SHA1
files means that most (all?) checking programs will have difficulty
verifying the checksums.

I think these problems need to be corrected before release (if
necessary by editting the files)

On 15/12/2007, Jean T. Anderson <[EMAIL PROTECTED]> wrote:
> I reviewed the rat reports, checked the asc signatures, did a cursory
> review of DISCLAIMER, NOTICE, and LICENSE files in a couple of the src
> and bin files, and it all looks good to me.
>
> +1
>
> btw, the way you provide the rat reports up front is *very* helpful.
>
>  -jean
>
>
> Michael Baessler wrote:
> > The Apache UIMA committers ask the Apache Incubator PMC for permission
> > to publish a new bug fix release of Apache UIMA. This release contains
> > bug fixes of the Apache UIMA 2.2.0 release published in August 2007.
> > For details about the fixes, please have a look at the release notes.
> >
> > We had a vote on uima-dev that resulted in 6 binding +1s
> > (all the committers) and no 0s or -1s.  The vote thread
> > is here:
> > http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/200712.mbox/[EMAIL
> >  PROTECTED]
> >
> >
> > Please review the release candidate here:
> > http://people.apache.org/~mbaessler/uimaj-2.2.1/06/
> >
> > There are subdirectories like:
> > /bin - that contains the binary distribution files
> > /src - that contains the source distribution files
> > /rat - that contains the RAT reports (using RAT 0.5.1) with some
> > comments /eclipseUpdateSite - that contains the eclipse update site
> > artifacts
> > /maven - that contains the Maven artifacts we would like to release to
> > the incubator repository
> >
> > The SVN tag for this release candidate is:
> > https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.1/uimaj-2.2.1-06
> >
> >
> > Please vote:
> > [ ] +1  Accept to release Apache UIMA 2.2.1
> > [ ] -1  No, because
> >
> > Thanks!
> >
> > -- Michael
> >
> >
> >
> > -
> > 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]
>
>

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

Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating

[sebb]

On 15/12/2007, Jean T. Anderson <[EMAIL PROTECTED]> wrote:
> sebb wrote:
> > [Eventually found the KEYS file in SVN, but it might be helpful to
> > provide a pointer in the vote mails]
> >
> >
> yeah, I went to their website and followed the link from there.

So did I.

> > The NOTICE file in uimaj-2.2.1-incubating-bin.zip refers to the
> > contributions from IBM:
> >
> > "Software Grant License Agreement", informally known as the
> > "IBM UIMA License Agreement".
> >
> > however, that license is not in LICENSE, nor is it linked from there.
> >
> >
> this wording was approved in their first release -- iirc there were
> discussions about what specifically to put there [1] and I had a minor
> hand in that since they had borrowed wording from derby [2].

I'm not objecting to the wording in the NOTICE file.
However, since it refers to another license, I think that needs to be
present in the LICENSE file:

http://www.apache.org/dev/release.html#distributing-code-under-several-licenses

>  -jean
>
> [1] http://tinyurl.com/2jncrq
> [2] http://tinyurl.com/3bdz9n
>
> > There are some problems with the MD5 and SHA1 files.
> >
> > For example, uimaj-2.2.1-incubating-bin.tar.bz2.md5:
> >
> > 
> > uimaj-2.2.1-incubating-bin.tar.bz2: 53 20 6A FB 75 1F 07 9D  BB 12 82 58 D0 
> > 7D
> > CA 4B
> > 
> >
> > The hash is spread over two lines and into hex pairs. The normal
> > format is either:
> > 53206afb751f079dbb128258d07dca4b
> > or
> > 53206afb751f079dbb128258d07dca4b *uimaj-2.2.1-incubating-bin.tar.bz2
> >
> > The SHA1 checksums have the same problem.
> >
> > The PGP signatures are OK, however the format of the existing MD5/SHA1
> > files means that most (all?) checking programs will have difficulty
> > verifying the checksums.
> >
> > I think these problems need to be corrected before release (if
> > necessary by editting the files)
> >
> > On 15/12/2007, Jean T. Anderson <[EMAIL PROTECTED]> wrote:
> >
> >> I reviewed the rat reports, checked the asc signatures, did a cursory
> >> review of DISCLAIMER, NOTICE, and LICENSE files in a couple of the src
> >> and bin files, and it all looks good to me.
> >>
> >> +1
> >>
> >> btw, the way you provide the rat reports up front is *very* helpful.
> >>
> >>  -jean
> >>
> >>
> >> Michael Baessler wrote:
> >>
> >>> The Apache UIMA committers ask the Apache Incubator PMC for permission
> >>> to publish a new bug fix release of Apache UIMA. This release contains
> >>> bug fixes of the Apache UIMA 2.2.0 release published in August 2007.
> >>> For details about the fixes, please have a look at the release notes.
> >>>
> >>> We had a vote on uima-dev that resulted in 6 binding +1s
> >>> (all the committers) and no 0s or -1s.  The vote thread
> >>> is here:
> >>> http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/200712.mbox/[EMAIL
> >>>  PROTECTED]
> >>>
> >>>
> >>> Please review the release candidate here:
> >>> http://people.apache.org/~mbaessler/uimaj-2.2.1/06/
> >>>
> >>> There are subdirectories like:
> >>> /bin - that contains the binary distribution files
> >>> /src - that contains the source distribution files
> >>> /rat - that contains the RAT reports (using RAT 0.5.1) with some
> >>> comments /eclipseUpdateSite - that contains the eclipse update site
> >>> artifacts
> >>> /maven - that contains the Maven artifacts we would like to release to
> >>> the incubator repository
> >>>
> >>> The SVN tag for this release candidate is:
> >>> https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.1/uimaj-2.2.1-06
> >>>
> >>>
> >>> Please vote:
> >>> [ ] +1  Accept to release Apache UIMA 2.2.1
> >>> [ ] -1  No, because
> >>>
> >>> Thanks!
> >>>
> >>> -- Michael
> >>>
> >>>
> >>>
> >>> -
> >>> 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]
> >>
> >>
> >>
> >
> > -
> > 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]
>
>

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

Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating

[sebb]

On 17/12/2007, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> sebb wrote:
> > On 15/12/2007, Jean T. Anderson <[EMAIL PROTECTED]> wrote:
> >> sebb wrote:
> >>> [Eventually found the KEYS file in SVN, but it might be helpful to
> >>> provide a pointer in the vote mails]
> >>>
> >>>
> >> yeah, I went to their website and followed the link from there.
> >
> > So did I.
> >
> >>> The NOTICE file in uimaj-2.2.1-incubating-bin.zip refers to the
> >>> contributions from IBM:
> >>>
> >>> "Software Grant License Agreement", informally known as the
> >>> "IBM UIMA License Agreement".
> >>>
> >>> however, that license is not in LICENSE, nor is it linked from there.
> >>>
> >>>
> >> this wording was approved in their first release -- iirc there were
> >> discussions about what specifically to put there [1] and I had a minor
> >> hand in that since they had borrowed wording from derby [2].
> >
> > I'm not objecting to the wording in the NOTICE file.
> > However, since it refers to another license, I think that needs to be
> > present in the LICENSE file:
> >
> > http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
>
> We are not distributing code under several licenses.
> The only license applicable to UIMA is the AL.  The
> somewhat cryptic (to a non-lawyer) statement in the
> NOTICE file was put there on request by the IPMC, we
> didn't have it there originally.  To my way of thinking,
> what it is supposed to say is that some of the code
> originated with IBM, but has since been relicensed
> under the Apache License.

Sorry, I misread the paragraph originally - I somehow managed to
overlook the phrase "to the Apache Software Foundation" and thought it
referred to a standard 3rd party attribution notice.

Apologies for the noise on this matter.

> This exact version of the NOTICE and LICENSE file has
> been approved for our previous two releases, so I do
> hope they are still ok.

Yes, it's my "brian" that needs adjusting in this case...

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

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

Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating

[sebb]

On 17/12/2007, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> sebb wrote:
> > [Eventually found the KEYS file in SVN, but it might be helpful to
> > provide a pointer in the vote mails]
>
> Good point, will do next time.
>
> [...]
> >
> > There are some problems with the MD5 and SHA1 files.
> >
> > For example, uimaj-2.2.1-incubating-bin.tar.bz2.md5:
> >
> > 
> > uimaj-2.2.1-incubating-bin.tar.bz2: 53 20 6A FB 75 1F 07 9D  BB 12 82 58 D0 
> > 7D
> > CA 4B
> > 
> >
> > The hash is spread over two lines and into hex pairs. The normal
> > format is either:
> > 53206afb751f079dbb128258d07dca4b
> > or
> > 53206afb751f079dbb128258d07dca4b *uimaj-2.2.1-incubating-bin.tar.bz2
> >
> > The SHA1 checksums have the same problem.
> >
> > The PGP signatures are OK, however the format of the existing MD5/SHA1
> > files means that most (all?) checking programs will have difficulty
> > verifying the checksums.
>
> We generate the checksums with
>
> gpg --print-md MD5 [fileName] > [fileName].md5
>
> and
>
> gpg --print-md SHA1 [fileName] > [fileName].sha
>
> respectively (as described in the release signing FAQ; however,
> I suggested that text ;-).  The advantage of using gpg is that
> you just need one tool for the various signatures.  If there
> are alternatives, we'll be happy to entertain them (we use maven
> as our build env).

Maven can generate the MD5 and SHA1 checksums itself; no need for a
separate tool.

I'm not familiar with Maven, so I don't know the commands off-hand,
but I can probably find them.

> Can you elaborate on what checking programs are commonly used?

The programs for checking MD5s are referenced from a lot of download
pages, for example:

http://xerces.apache.org/xerces-c/download.cgi
and
http://myfaces.apache.org/download.html

All of these expect checksums which are a single string of hex digits.

> It was my understanding that the primary signing mechanisms were
> the PGP signatures, and the checksums were just for quick sanity
> checks (visual verification, as they are so short).  Thanks.

Yes, PGP sigs are the primary signing mechanisms. MD5 and SHA1 are not
as secure. However they are still useful, particularly for checking
that the files have been downloaded successfully. To that end, having
a format that can be automatically checked is essential.

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

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

Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating

[sebb]

On 17/12/2007, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> Kevan Miller wrote:
> >
> > On Dec 17, 2007, at 4:09 AM, Thilo Goetz wrote:
> >
> >> William A. Rowe, Jr. wrote:
> >>> Marshall Schor wrote:
>  We've put the LICENSE, NOTICES, and DISCLAIMERs into the top directory
>  of the source (and binary) distribution(s), but didn't realize this
>  also
>  needs to be in the top level of the SVN tag, because we didn't know
>  that
>  was considered part of the "distribution".
> 
>  Can you please confirm this is the case?  In which case, we'll of
>  course
>  comply.
> >>>
> >>> Your distribution must correspond to subversion, otherwise it's very
> >>> hard
> >>> to track the artifacts in the tarball, where they came from, how they
> >>> got there, and if they underwent the proper oversight prior to
> >>> packaging.
> >>> (Yes, we vote on the prepared tarball, but you can see how discrepancies
> >>> do create questions.)
> >>
> >> That's not how I interpret the policy document.  It says:
> >>
> >> "To apply the ALv2 to a new software distribution, include one copy of
> >> the license text by copying
> >> the file:
> >>
> >> http://www.apache.org/licenses/LICENSE-2.0.txt
> >>
> >> into a file called LICENSE in the top directory of your distribution.
> >> If the distribution is a jar
> >> or tar file, try to add the LICENSE file first in order to place it at
> >> the top of the archive."
> >>
> >> That's what we do.  Of course we'll make every effort to make
> >> our distribution easy to review.  However, it does seem that
> >> we're ok wrt current policy, and view this as a suggestion
> >> for next time.  Ok?
> >
> > Your interpretation works if your subversion repository is not a
> > "distribution". IMO, it is and should contain appropriate
> > license/notice/disclaimer.
>
> If that is the consensus opinion here, that's what we'll
> do.  But please put yourself in our shoes.  We can only go
> by the information that is available to us.  If this is a
> rule, it would be great if it could be written down so the
> next incubator project doesn't have to go through this.  I'd
> be happy to help with the docs.
>
> Out of curiosity, I started going through the Apache SVN repo
> to see what Apache projects complied with this requirement.  I
> stopped after C because I'd already found 4 that didn't
> comply: Avalon, Cayenne, Cocoon and Commons.

Avalon is defunct, so does not count.

Commons looks OK to me; there are N&L files in

http://svn.apache.org/repos/asf/commons/proper/attributes/trunk/
http://svn.apache.org/repos/asf/commons/proper/commons-build/trunk/
and
http://svn.apache.org/repos/asf/commons/proper/vfs/trunk/

to take a few at random

The top-level directory:
http://svn.apache.org/repos/asf/commons/
is not a project - see the README for details.

I agree that Cayenne and Cocoon are "non-compliant".

> Compliant
> were Activemq, Ant, APR and Beehive.
>
> --Thilo
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating

[sebb]

On 17/12/2007, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> On Dec 17, 2007 5:49 PM, Kevan Miller <[EMAIL PROTECTED]> wrote:
> >
> > Your interpretation works if your subversion repository is not a
> > "distribution". IMO, it is and should contain appropriate license/
> > notice/disclaimer.
> >

I agree with Kevan.

> I don't agree with this standpoint as for instance the LICENSE and
> DISCLAIMER docs can be automatically included into the correct distribution
> location from officially released bundles. This makes much more sense as it
> keeps the definition of those documents in one place. This process is
> repeatable using maven.
> IMO SVN does not have to mirror an unzipped release (there is no policy
> directing that, or if there is, please provide a link), as long as it is
> reproducible from the release tag.
>

I have asked about this on the legal discuss list.

Regardless of the outcome, I think that there are problems with
generating the NOTICE and LICENSE files automatically. Unless the
project is pure ASF, there are additional items that may need to be
added to the N &  L files. In any case, I think it's important that
these files are carefully considered to ensure that the required
entries are present. This is difficult if not impossible if the
contents of the N & L files are automatically generated.

The N & L files are unlikely to change frequently, so it really does
not save much work (if any) to create them by hand. Having them in the
top-level SVN directory seems sensible to me.

> Martijn
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-rc2 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
>

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

Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating

[sebb]

On 18/12/2007, Michael Baessler <[EMAIL PROTECTED]> wrote:
> Leo Simons wrote:
> > On Dec 18, 2007, at 12:15 PM, Bertrand Delacretaz wrote:
> >> On Dec 18, 2007 10:37 AM, ant elder <[EMAIL PROTECTED]> wrote:
> >>> ...So it is a new requirement and I don't think we should be making
> >>> up policy
> >>> during a release vote
> >
> > +1, that's even part of the policy! It is just *so* annoying that this
> > keeps happening.
> >
> >>> like this as it makes it very frustrating for
> >>> poddling. How about letting this UIMA release out as-is for now
> >>> while we
> >>> work this out?...
> >
> > Yup. It always gets fuzzy when voting and discussion intermix, but I
> > do count 3 +1 votes and more +1 votes than -1 votes. That typically
> > means the vote passes, so UIMA can release.
> >
> Right the vote runs for more than 72 hours and we have 3 +1 votes and
> one -1 vote.
>
> The other open issue was the checksum representation for MD5 and SHA1.
> The representation can be improved and we will do this for the next release.
> (I already opened a JIRA issue for that). It is just open what we have
> to do for the current release.

I've created reformatted versions for the src and bin archives in:

http://people.apache.org/~sebb/UIMA/

in case that helps.

I've not fixed the Maven hashes.

I don't know whether the Maven hash-checking can cope with the format
or not - and does it ignore hash files with incorrect format or what?
If it does not handle the format properly, this could cause download
problems.

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

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

Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating

[sebb]

On 18/12/2007, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> sebb wrote:
> > On 18/12/2007, Michael Baessler <[EMAIL PROTECTED]> wrote:
> >> Leo Simons wrote:
> >>> On Dec 18, 2007, at 12:15 PM, Bertrand Delacretaz wrote:
> >>>> On Dec 18, 2007 10:37 AM, ant elder <[EMAIL PROTECTED]> wrote:
> >>>>> ...So it is a new requirement and I don't think we should be making
> >>>>> up policy
> >>>>> during a release vote
> >>> +1, that's even part of the policy! It is just *so* annoying that this
> >>> keeps happening.
> >>>
> >>>>> like this as it makes it very frustrating for
> >>>>> poddling. How about letting this UIMA release out as-is for now
> >>>>> while we
> >>>>> work this out?...
> >>> Yup. It always gets fuzzy when voting and discussion intermix, but I
> >>> do count 3 +1 votes and more +1 votes than -1 votes. That typically
> >>> means the vote passes, so UIMA can release.
> >>>
> >> Right the vote runs for more than 72 hours and we have 3 +1 votes and
> >> one -1 vote.
> >>
> >> The other open issue was the checksum representation for MD5 and SHA1.
> >> The representation can be improved and we will do this for the next 
> >> release.
> >> (I already opened a JIRA issue for that). It is just open what we have
> >> to do for the current release.
> >
> > I've created reformatted versions for the src and bin archives in:
> >
> > http://people.apache.org/~sebb/UIMA/
> >
> > in case that helps.
>
> Thanks!
>
> >
> > I've not fixed the Maven hashes.
> >
> > I don't know whether the Maven hash-checking can cope with the format
> > or not - and does it ignore hash files with incorrect format or what?
> > If it does not handle the format properly, this could cause download
> > problems.
>
> The hashes for the maven artifacts are generated by maven, in the format
> that maven wants them.  There should be no problem, there hasn't been in
> the past.

OK.

I thought I'd seen one with the different format, but I've just
rechecked one or two and they hold just the hash. Sorry for th
diversion.

That format would be fine as the bin and src archive hashes too.
Having the file name as well is only essential for a file containing
multiple hashes.

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

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

Re: [Vote] Apache River 2.1.1 Incubating Release

[sebb]

The NOTICE files need to be updated for 2008, i.e. replace 2007 with
2007-2008 on line 3.

The hash files use a format which is difficult to use, as the hashes
may be split over two lines.

The common MD5 format is either

hex{32}
(i.e. no spaces between hex digits)

or

hex{32}(|*)filename

Similarly for SHA1.

Also the SHA1 hashes normally have the suffix ".sha1" rather than ".sha"

On 14/01/2008, Jim Hurley <[EMAIL PROTECTED]> wrote:
> Incubator PMC:
>
> The River community voted on and has approved a proposal to release
> River 2.1.1 incubating. This is the first release from our project.
> We would
> like to request permission of the Incubator PMC to publish the release
> on
> the River Download page.
>
> The vote will be open through Wednesday, January 16th.
>
> Thanks!
>
> -Jim
> [EMAIL PROTECTED]
>
>
> Release Proposal:
> 
>
> RAT output:
> 
>
> Vote result:
>   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]

Re: [Vote] Apache River 2.1.1 Incubating Release

[sebb]

On 14/01/2008, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Jan 14, 2008 12:58 PM, sebb <[EMAIL PROTECTED]> wrote:
> > The NOTICE files need to be updated for 2008, i.e. replace 2007 with
> > 2007-2008 on line 3.
>
> The release was rolled on Jan 4th and there are no code changes since
> 2007, so I'd consider this at best a minor issue, probably even better
> to let the date remain 2007.

Well, the Ant files seem to have been changed in 2008.

> > The hash files use a format which is difficult to use, as the hashes
> > may be split over two lines.
>
> Not a blocker IMHO, but something we may want to change in future releases.

Agreed that it's not a blocker. The files can even be fixed manually if desired.

> I guess the checksums were generated with default Solaris tools. You
> can use "openssl md5" and "openssl sha1" to generate checksum output
> in the format Sebastian described.

Well, the format is closer, as the hash is not broken over two lines,
for example:

MD5(filename)= 464069695e3ac4998898d0633f8df032

> > Also the SHA1 hashes normally have the suffix ".sha1" rather than ".sha"
>
> Actually the suffix should be ".sha" and not ".sha1". See the "not
> normative" policy (a recommendation? :-) described in
> http://www.apache.org/dev/release-signing.html#policy.

OK, I had not noticed that.

Clearly a lot of other projects have not noticed either as there are
213 sha and 776 sha1 files under  /www/www.apache.org/dist/ - so my
statement was literally correct ;-)

> BR,
>
> Jukka Zitting
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [Vote] Apache River 2.1.1 Incubating Release

[sebb]

On 14/01/2008, sebb <[EMAIL PROTECTED]> wrote:
> On 14/01/2008, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On Jan 14, 2008 12:58 PM, sebb <[EMAIL PROTECTED]> wrote:
> > > The NOTICE files need to be updated for 2008, i.e. replace 2007 with
> > > 2007-2008 on line 3.
> >
> > The release was rolled on Jan 4th and there are no code changes since
> > 2007, so I'd consider this at best a minor issue, probably even better
> > to let the date remain 2007.
>
> Well, the Ant files seem to have been changed in 2008.
>
> > > The hash files use a format which is difficult to use, as the hashes
> > > may be split over two lines.
> >
> > Not a blocker IMHO, but something we may want to change in future releases.
>
> Agreed that it's not a blocker. The files can even be fixed manually if 
> desired.
>
> > I guess the checksums were generated with default Solaris tools. You
> > can use "openssl md5" and "openssl sha1" to generate checksum output
> > in the format Sebastian described.
>
> Well, the format is closer, as the hash is not broken over two lines,
> for example:
>
> MD5(filename)= 464069695e3ac4998898d0633f8df032
>
> > > Also the SHA1 hashes normally have the suffix ".sha1" rather than ".sha"
> >
> > Actually the suffix should be ".sha" and not ".sha1". See the "not
> > normative" policy (a recommendation? :-) described in
> > http://www.apache.org/dev/release-signing.html#policy.
>
> OK, I had not noticed that.
>

The document refers to SHA digests, not SHA-1 digests specifically.

Further investigation shows that these are not the same, at least for openssl:

pwd ~ : openssl sha /dev/null
SHA(/dev/null)= f96cea198ad1dd5617ac084a3d92c6107708c0ef
pwd ~ : openssl sha1 /dev/null
SHA1(/dev/null)= da39a3ee5e6b4b0d3255bfef95601890afd80709
pwd ~ :

[I assume that "openssl sha"  means SHA-0, but I could be wrong]

The document does not mention openssl, and gpg does not seem to
support SHA digests (whatever those may be), so presumably SHA means
SHA-1 in the document.

> Clearly a lot of other projects have not noticed either as there are
> 213 sha and 776 sha1 files under  /www/www.apache.org/dist/ - so my
> statement was literally correct ;-)
>
> > BR,
> >
> > Jukka Zitting
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

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

Re: [Vote] Apache River 2.1.1 Incubating Release

[sebb]

On 14/01/2008, Craig L Russell <[EMAIL PROTECTED]> wrote:
>
> On Jan 14, 2008, at 2:58 AM, sebb wrote:
>
> > The NOTICE files need to be updated for 2008, i.e. replace 2007 with
> > 2007-2008 on line 3.
>
> Not a blocker for me.
> >
> > The hash files use a format which is difficult to use, as the hashes
> > may be split over two lines.
> >
> > The common MD5 format is either
> >
> > hex{32}
> > (i.e. no spaces between hex digits)
> >
> > or
> >
> > hex{32}(|*)filename
> >
> > Similarly for SHA1.
> >
> > Also the SHA1 hashes normally have the suffix ".sha1" rather than
> > ".sha"

I was wrong about that - they should be called .sha - see Jukka's reply.

> The easiest way to fix this is to remove the .sha files. If the .md5
> and .asc checksums are good, the sha is just not needed.
>

So the .sha files can be kept.

> Craig
> >
> > On 14/01/2008, Jim Hurley <[EMAIL PROTECTED]> wrote:
> >> Incubator PMC:
> >>
> >> The River community voted on and has approved a proposal to release
> >> River 2.1.1 incubating. This is the first release from our project.
> >> We would
> >> like to request permission of the Incubator PMC to publish the
> >> release
> >> on
> >> the River Download page.
> >>
> >> The vote will be open through Wednesday, January 16th.
> >>
> >> Thanks!
> >>
> >> -Jim
> >> [EMAIL PROTECTED]
> >>
> >>
> >> Release Proposal:
> >> <http://people.apache.org/~fbarnaby/river/2.1.1/>
> >>
> >> RAT output:
> >> <http://people.apache.org/~fbarnaby/river/2.1.1/rat_output.txt>
> >>
> >> Vote result:
> >> <http://mail-archives.apache.org/mod_mbox/incubator-river-dev/
> >> 200801.mbox/[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]
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
>
>
>

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

Re: Synchronizing PMC Membership rosters

[sebb]

On 22/01/2008, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> On Jan 21, 2008 6:00 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>
> > Matthieu Riou wrote:
> >
> > > in committee but not in authorization:
> > > ["dashorst", "ekoneil", "gianugo", "henning", "jgenender", "kevan",
> > "matt",
> > >  "mvdb", "psteitz", "sbailliez"]
> >
> > Thanks.  Apparently, you missed Santiago (sgala) on that list, too, so I
> > am
> > presuming that you did it by hand.
> >
>
> With a script but when I ran it last night, Santiago was in neither files
> (looks like he added himself this morning).
>

Just wondering whether Labs would be a suitable place to collaborate
on scripts for cross-checking/reformatting the meta data? Also to
document the current meta data.

> Matthieu
>
>
> >
> > Fixed.
> >
> > > in authorization but not in committee:
> > > ["fielding", "stefano"]
> >
> > Roy resigned a year ago.  Would have to check the subversion log to see
> > when
> > Stefano was removed from the PMC roster.
> >
> > Fixed.
> >
> >--- Noel
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

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

Re: Synchronizing PMC Membership rosters

[sebb]

On 22/01/2008, J Aaron Farr <[EMAIL PROTECTED]> wrote:
>
> sebb <[EMAIL PROTECTED]> writes:
>
> > Just wondering whether Labs would be a suitable place to collaborate
> > on scripts for cross-checking/reformatting the meta data? Also to
> > document the current meta data.
>
> Technically the incubator PMC should be free to create a new
> subdirectory under /incubator in svn.  But if you don't want to do
> that, then, yeah, a lab is fine.
>

I was thinking that the same problems of duplicated meta data apply to
other PMCs as well - indeed to the ASF as a whole...

> --
>   J Aaron Farr jadetower.com[US] +1 724-964-4515
> 馮傑仁  cubiclemuses.com [HK] +852 8123-7905
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release

[sebb]

Some of the NOTICE files start with the text:

${pom.name}

e.g.

tools/wsdl2java
and
modules/policy

This does not seem right.

The top-level NOTICE and LICENSE files in demos/mortgage-loanapproval
are the standard ASF ones - however NOTICE and LICENSE.txt in the
demos/mortgage-loanapproval/src/main/resources/META-INF directory
include additional references to Eclipse licenses.

Again, I would expect the top-level L&N files for a directory tree to
agree with the lower level ones.

The file apache-tuscany-sca-1.1-incubating-src.tar.gz contains the
file derby.log which perhaps should not be there.

On 23/01/2008, Simon Laws <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The Tuscany project had a vote on [EMAIL PROTECTED] to publish the
> Tuscany SCA Java 1.1-incubating release. The vote thread on tuscany-dev has
> 7 +1s and an archive can be found at:
>
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27321.html
>
> The release includes new function and bug fixes. You can see a list of
> changes at:
>
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3/distribution/src/main/release/CHANGES
>
>
> The signed binary and source distributions, the RAT reports, and the Maven
> staging repository are listed at the following links.
>
> SVN Tag:
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3/
>
> Stage maven repo:
> http://people.apache.org/~slaws/tuscany/1.1-RC3/maven/
> 
>
> RAT report:
> http://people.apache.org/~slaws/tuscany/1.1-RC3/rat-1.1-RC3.txt
>
> Binary and source distros (zip/gz/asc/md5) :
> http://people.apache.org/~slaws/tuscany/1.1-RC3/
>
> Please review and approve the release. This vote will remain open for at
> least 72 hours.
>
> Thanks,
>
> Simon
>

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

Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release

[sebb]

On 24/01/2008, ant elder <[EMAIL PROTECTED]> wrote:
> I think the NOTICE files in the artifacts that are actually being
> distributed are OK.

Surely the archive bundles are also distributed?

==

There are some discrepancies in the jar files covered by the LICENSE
file - the names mentioned in the LICENSE file don't necessarily
appear in the lib directory (and vice versa)
(LIC=LICENSE, DIR=present in lib directory)

LIC: axis2-adb-codegen-1.3.jar
DIR: axis2-codegen-1.3.jar

LIC: derby-10.1.3.1.jar
DIR: derby-10.1.2.1.jar

LIC: stax-api-1.0.2.jar
DIR: stax-api-1.0-2.jar

The following are mentioned in the LICENSE file, but don't appear to be present:
addressing-1.3.mar
maven-artifact-2.0.2.jar
maven-artifact-manager-2.0.2.jar
maven-error-diagnostics-2.0.2.jar
maven-model-2.0.2.jar
maven-profile-2.0.2.jar
maven-project-2.0.2.jar
maven-repository-metadata-2.0.2.jar
maven-settings-2.0.2.jar
opensaml-1.1.jar
plexus-container-default-1.0-alpha-9.jar
plexus-utils-1.1.jar
rampart-1.3.mar
wagon-file-1.0-alpha-7.jar
wagon-http-lightweight-1.0-alpha-6.jar
wagon-provider-api-1.0-alpha-6.jar

Not sure what "dojotoolkit" mentioned in the LICENSE file refers to.

It would be useful if the LICENSE file used a standard format for the
jar files names, as is done for the ASF jars. Elsewhere in the file,
jars may be listed without the .jar extension and/or without the
version suffix, and sometimes multiple files are listed in a
paragraph.

The lack of a version suffix is potentially serious, as licenses may
change between releases.

> The ${pom.name} is changed by the build process so the
> generated artifact has the proper name, for example, the jar built for
> wsdl2java ends up with a NOTICE file containing "Apache Tuscany SCA
> WSDL2Java Tool", see inside:
> http://people.apache.org/~slaws/tuscany/1.1-RC3/maven/org/apache/tuscany/sca/tuscany-wsdl2java/1.1-incubating/tuscany-wsdl2java-1.1-incubating.jar

That looks OK.
 .
>
> The mortgage-loanapproval is only distributed within the src and bin
> distributions and the NOTICE file in those distributions does include all
> the necessary references so that also looks ok to me.
>
> Including the Derby.log is a mistake, but I don't think its a blocker :)

Agreed.

Though it reveals something about the builder's PC environment, so
they may wish it was not present ;-)

There are several other derby.log files in the source archive.

There's also some 40GB of log-nnn.dat files in the

tuscany-sca-1.1-incubating-src\itest\jms\activemq-data\localhost\journal

directory in the source archive.

Another smaller log file in:

tuscany-sca-1.1-incubating-src\modules\implementation-openjpa\test\log

There are also 3 db.lck files.

Are these really needed for the source archive?

> +1 to release.
>
>...ant
>
> On Jan 23, 2008 10:55 PM, sebb <[EMAIL PROTECTED]> wrote:
>
> > Some of the NOTICE files start with the text:
> >
> > ${pom.name}
> >
> > e.g.
> >
> > tools/wsdl2java
> > and
> > modules/policy
> >
> > This does not seem right.
> >
> > The top-level NOTICE and LICENSE files in demos/mortgage-loanapproval
> > are the standard ASF ones - however NOTICE and LICENSE.txt in the
> > demos/mortgage-loanapproval/src/main/resources/META-INF directory
> > include additional references to Eclipse licenses.
> >
> > Again, I would expect the top-level L&N files for a directory tree to
> > agree with the lower level ones.
> >
> > The file apache-tuscany-sca-1.1-incubating-src.tar.gz contains the
> > file derby.log which perhaps should not be there.
> >
> > On 23/01/2008, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > The Tuscany project had a vote on [EMAIL PROTECTED] to publish
> > the
> > > Tuscany SCA Java 1.1-incubating release. The vote thread on tuscany-dev
> > has
> > > 7 +1s and an archive can be found at:
> > >
> > > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27321.html
> > >
> > > The release includes new function and bug fixes. You can see a list of
> > > changes at:
> > >
> > >
> > http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3/distribution/src/main/release/CHANGES
> > >
> > >
> > > The signed binary and source distributions, the RAT reports, and the
> > Maven
> > > staging repository are listed at the following links.
> > >
> > > SVN Tag:
> > > http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3/
> > >
> > > Stage maven repo:
> > > http://people.apache.org/~slaws/tuscany/1.1-RC3/maven/<http://people.apache.org/%7Eslaws/tu

Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release

[sebb]

On 24/01/2008, Simon Laws <[EMAIL PROTECTED]> wrote:
> Hi sebb
>
> Thank you for the detailed review.
>
> Can you tell me what you mean by
>
> On Jan 24, 2008 4:57 PM, sebb <[EMAIL PROTECTED]> wrote:
>
> > On 24/01/2008, ant elder <[EMAIL PROTECTED]> wrote:
> > > I think the NOTICE files in the artifacts that are actually being
> > > distributed are OK.
> >
> > Surely the archive bundles are also distributed?

I meant that the files in the


Binary and source distros (zip/gz/asc/md5) :
http://people.apache.org/~slaws/tuscany/1.1-RC3/
 >
> >
> snip..
>
> Also can you tell me if you consider that the issues you have found to be
> blocking issues?
>

Yes, I think the discrepancies in the LICENSE file need to be addressed.

Also, comparing the SVN tag with the source archive shows that there
are quite a few files and directories that are missing from the source
archive.

There are several files in the source archive that are not in SVN,
which probably should be in SVN, for example:

BUILDING
CHANGES
DISCLAIMER
LICENSE
NOTICE
README
RELEASE_NOTES
demos/alert-aggregator-webapp/build-dependency.xml
demos/xml-bigbank/build-dependency.xml
itest/databindings/interop/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/InteropDatabindingTestCase.java
itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterService.java
itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClient.java
itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClientImpl.java
itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceImpl.java
itest/databindings/jaxbgen/src/test/java/org/apache/tuscany/sca/itest/jaxbdatabinding/DatabindingTestCase.java
itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterService.java
itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceClientImpl.java
itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceImpl.java
itest/databindings/sdogen/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/DatabindingTestCase.java
samples/calculator-webapp/build.xml
samples/calculator-ws-webapp/build.xml
samples/chat-webapp/build.xml
samples/feed-aggregator-webapp/build.xml
samples/helloworld-dojo-webapp/build-dependency.xml
samples/helloworld-jsonrpc-webapp/build.xml
samples/helloworld-ws-sdo-webapp/build-dependency.xml

There are also a lot of files in SVN, which are not in the source archive:

demos/alert-aggregator-webapp/alert-aggregator.svg
demos/bigbank-account/bigbank.svg
demos/bigbank-calculator/src/test
demos/secure-bigbank/secure-bigbank-account/bigbank.svg
demos/secure-bigbank/secure-bigbank-calculator/src/test
demos/xml-bigbank/xml-bigbank.svg
distribution/standalone/src/main/resources
distribution/tomcat/src/test
distribution/webapp/src/test
distribution/webapp/src/main/resources
itest/admin/src/test/java/test
itest/contribution-import-export/export-java/src/test
itest/contribution-import-export/export-wsdl/src/test
itest/contribution-import-export/export-wsdl/src/main/java
itest/contribution-multiple/src/main
itest/databindings/config.svg
itest/databindings/databinding.svg
itest/databindings/interop.svg
itest/domain/src/main/java/org
itest/interop-soap-client/src/test/resources
itest/osgi-contribution/contribution-classes-v2/src/test
itest/osgi-contribution/contribution-classes/src/test
itest/transaction/src/test/resources
itest/wsdl2java/src/main
itest/wsdl2java/src/test/java
modules/implementation-das
modules/binding-dwr/src/test
modules/binding-ws-axis2/src/main/assembly
modules/binding-ws/src/test
modules/contribution-java/src/test/resources
modules/contribution-namespace/src/test/resources
modules/contribution-osgi/src/test
modules/contribution/src/test
modules/core-databinding/src/test/java/org/apache/tuscany/core
modules/core-spi/src/test
modules/data-engine-helper/src/test
modules/data-engine-helper/src/main/resources
modules/databinding-saxon/src/test
modules/definitions/src/test
modules/definitions/src/main/resources
modules/domain-api/src/test
modules/domain/src/test
modules/extension-helper/src/test
modules/host-http/src/test
modules/host-jms-activemq/src/test
modules/host-jms/src/test
modules/host-osgi/src/test
modules/host-osgi/src/main/java
modules/host-webapp/src/test
modules/implementation-spring/src/test/java/org/apache/tuscany/implementation
modules/implementation-xquery/src/test
modules/implementation-xquery/src/main/java/org/apache/tuscany/implementation
modules/interface-wsdl-java2wsdl/src/main/resources
modules/interface-wsdl/src/test
modules/node-api/src/test
modules/node/src/test
modules/node/src/main/resources
modules/osgi-runtime/src/test/resources
modules/policy-transaction/src

Re: Tuscany 1.1 build failure

[sebb]

That finished with "BUILD SUCCESSFUL".

The errors I reported were when I was running plain mvn from the
top-level directory, which is what the vote e-mail said to do.

Are the missing artifacts due to a Maven bug or a bug in the
configuration or something else?


On 25/01/2008, Luciano Resende <[EMAIL PROTECTED]> wrote:
> Could you please try to build itest/osgi-implementation with a "mvn -U
> clean install" and see if you still have issues. I just tried and it
> completed successfully even with all felix artifacts removed from my
> local maven repo.
>
> On Jan 25, 2008 3:11 PM, sebb <[EMAIL PROTECTED]> wrote:
> >
> > On 25/01/2008, sebb <[EMAIL PROTECTED]> wrote:
> > > I got a couple of failures when trying to build the Tuscany 1.1 source.
> > >
> > > The first time, I got an out of memory error from Java.
> > >
> > > I'm assuming this was due to the hundreds of jar and digest files that
> > > were downloaded (at least 760 jar+digest), as the error did not occur
> > > the second time. Possibly this is a memory leak in Maven.
> > >
> > > BTW, it looks like the M2 build downloads multiple versions of some jars, 
> > > e.g :
> > >
> > > backport-util-concurrent v2.1 and v2.1
> > > jaxb-impl 2.0.2, 2.0.3, 2.1.2, 2.1.4 and 2.1.5
> > >
> > > However, the second time I tried, I got the following error:
> > >
> > > 
> > > ---
> > > [INFO] [tuscanywsdl2java:generate {execution: default}]
> > > [INFO] Generating Java service interfaces from
> > > D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\w
> > > sdl.sdo\StockExceptionTest.wsdl
> > > log4j:WARN No appenders could be found for logger
> > > (org.apache.axis2.description.AxisService).
> > > log4j:WARN Please initialize the log4j system properly.
> > > >>  Generating Java class
> > > stockexceptiontestservice.scatesttool.StockExceptionTest
> > > [WARNING] POM for
> > > 'com.sun.xml.stream.buffer:streambuffer:pom:0.4:compile' is invalid.
> > > It will be ignored for artifact resolution. R
> > > eason: Failed to validate POM for project
> > > com.sun.xml.stream.buffer:streambuffer at Artifact
> > > [com.sun.xml.stream.buffer:streambuffer
> > > :pom:0.4:compile]
> > > [WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:compile' is
> > > invalid. It will be ignored for artifact resolution. Reason: Not a v
> > > 4.0.0 POM. for project org.jvnet.staxex:stax-ex at C:\Documents and
> > > Settings\User\.m2\repository\org\jvnet\staxex\stax-ex\1.0\stax-e
> > > x-1.0.pom
> > > [INFO] [jaxws:wsimport {execution: generate-jaxb}]
> > > [INFO] Processing:
> > > D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl
> > > [INFO] jaxws:wsimport args: [-s,
> > > D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
> > > -d, D:
> > > \tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
> > > -verbose, -p, org.apache.tuscany.sca.test.exceptions.
> > > impl.jaxb, 
> > > D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
> > > parsing WSDL...
> > >
> > >
> > > generating code...
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault_Exception.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\MarketClosedFault.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\ObjectFactory.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTest.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTestService.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockOffer.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOffer.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOfferResponse.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\TestNotDeclaredAtSourceFault.java
> > > org\apache\tuscany\sca\test\exceptions\impl\jaxb\package-info.java
> > > [ERROR] null
> > > unknown location
> > >
> > > compilation failed, errors should have been reported
> > > [INFO] 
> > > --

Tuscany 1.1 build failure

[sebb]

I got a couple of failures when trying to build the Tuscany 1.1 source.

The first time, I got an out of memory error from Java.

I'm assuming this was due to the hundreds of jar and digest files that
were downloaded (at least 760 jar+digest), as the error did not occur
the second time. Possibly this is a memory leak in Maven.

BTW, it looks like the M2 build downloads multiple versions of some jars, e.g :

backport-util-concurrent v2.1 and v2.1
jaxb-impl 2.0.2, 2.0.3, 2.1.2, 2.1.4 and 2.1.5

However, the second time I tried, I got the following error:


---
[INFO] [tuscanywsdl2java:generate {execution: default}]
[INFO] Generating Java service interfaces from
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\w
sdl.sdo\StockExceptionTest.wsdl
log4j:WARN No appenders could be found for logger
(org.apache.axis2.description.AxisService).
log4j:WARN Please initialize the log4j system properly.
>>  Generating Java class
stockexceptiontestservice.scatesttool.StockExceptionTest
[WARNING] POM for
'com.sun.xml.stream.buffer:streambuffer:pom:0.4:compile' is invalid.
It will be ignored for artifact resolution. R
eason: Failed to validate POM for project
com.sun.xml.stream.buffer:streambuffer at Artifact
[com.sun.xml.stream.buffer:streambuffer
:pom:0.4:compile]
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:compile' is
invalid. It will be ignored for artifact resolution. Reason: Not a v
4.0.0 POM. for project org.jvnet.staxex:stax-ex at C:\Documents and
Settings\User\.m2\repository\org\jvnet\staxex\stax-ex\1.0\stax-e
x-1.0.pom
[INFO] [jaxws:wsimport {execution: generate-jaxb}]
[INFO] Processing:
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl
[INFO] jaxws:wsimport args: [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-d, D:
\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.exceptions.
impl.jaxb, 
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
parsing WSDL...


generating code...
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault_Exception.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\MarketClosedFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\ObjectFactory.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTest.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTestService.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOffer.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOfferResponse.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\TestNotDeclaredAtSourceFault.java
org\apache\tuscany\sca\test\exceptions\impl\jaxb\package-info.java
[ERROR] null
unknown location

compilation failed, errors should have been reported
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error executing: wsimport [-s,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
-
d, 
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
-verbose, -p, org.apache.tuscany.sca.test.except
ions.impl.jaxb,
D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 28 minutes 48 seconds
[INFO] Finished at: Thu Jan 24 18:59:33 GMT 2008
[INFO] Final Memory: 59M/63M
[INFO] 

---

I will probably try re-running the build again at some point so I can
collect the full log.

S///

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

Re: Tuscany 1.1 build failure

[sebb]

On 25/01/2008, sebb <[EMAIL PROTECTED]> wrote:
> I got a couple of failures when trying to build the Tuscany 1.1 source.
>
> The first time, I got an out of memory error from Java.
>
> I'm assuming this was due to the hundreds of jar and digest files that
> were downloaded (at least 760 jar+digest), as the error did not occur
> the second time. Possibly this is a memory leak in Maven.
>
> BTW, it looks like the M2 build downloads multiple versions of some jars, e.g 
> :
>
> backport-util-concurrent v2.1 and v2.1
> jaxb-impl 2.0.2, 2.0.3, 2.1.2, 2.1.4 and 2.1.5
>
> However, the second time I tried, I got the following error:
>
> 
> ---
> [INFO] [tuscanywsdl2java:generate {execution: default}]
> [INFO] Generating Java service interfaces from
> D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\w
> sdl.sdo\StockExceptionTest.wsdl
> log4j:WARN No appenders could be found for logger
> (org.apache.axis2.description.AxisService).
> log4j:WARN Please initialize the log4j system properly.
> >>  Generating Java class
> stockexceptiontestservice.scatesttool.StockExceptionTest
> [WARNING] POM for
> 'com.sun.xml.stream.buffer:streambuffer:pom:0.4:compile' is invalid.
> It will be ignored for artifact resolution. R
> eason: Failed to validate POM for project
> com.sun.xml.stream.buffer:streambuffer at Artifact
> [com.sun.xml.stream.buffer:streambuffer
> :pom:0.4:compile]
> [WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:compile' is
> invalid. It will be ignored for artifact resolution. Reason: Not a v
> 4.0.0 POM. for project org.jvnet.staxex:stax-ex at C:\Documents and
> Settings\User\.m2\repository\org\jvnet\staxex\stax-ex\1.0\stax-e
> x-1.0.pom
> [INFO] [jaxws:wsimport {execution: generate-jaxb}]
> [INFO] Processing:
> D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl
> [INFO] jaxws:wsimport args: [-s,
> D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
> -d, D:
> \tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
> -verbose, -p, org.apache.tuscany.sca.test.exceptions.
> impl.jaxb, 
> D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
> parsing WSDL...
>
>
> generating code...
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\InvalidSymbolFault_Exception.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\MarketClosedFault.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\ObjectFactory.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTest.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockExceptionTestService.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockOffer.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOffer.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\StockQuoteOfferResponse.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\TestNotDeclaredAtSourceFault.java
> org\apache\tuscany\sca\test\exceptions\impl\jaxb\package-info.java
> [ERROR] null
> unknown location
>
> compilation failed, errors should have been reported
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error executing: wsimport [-s,
> D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\jaxws\wsimport\java,
> -
> d, 
> D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\target\classes,
> -verbose, -p, org.apache.tuscany.sca.test.except
> ions.impl.jaxb,
> D:\tuscany-sca-1.1-incubating-src\itest\exceptions-cross-binding\src\main\resources\wsdl\StockExceptionTest.wsdl]
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 28 minutes 48 seconds
> [INFO] Finished at: Thu Jan 24 18:59:33 GMT 2008
> [INFO] Final Memory: 59M/63M
> [INFO] 
> 
>
> ---
>
> I will probably try re-running the build again at some point so I can
> collect the full log.
>

Had to increase the memory allocation.

Latest test failed with 3 missing artifacts:

1) org.

Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release

[sebb]

On 25/01/2008, Simon Laws <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2008 8:59 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Jan 24, 2008 9:39 PM, sebb <[EMAIL PROTECTED]> wrote:
> >
> > > On 24/01/2008, Simon Laws <[EMAIL PROTECTED] > wrote:
> > > > Hi sebb
> > > >
> > > > Thank you for the detailed review.
> > > >
> > > > Can you tell me what you mean by
> > > >
> > > > On Jan 24, 2008 4:57 PM, sebb < [EMAIL PROTECTED]> wrote:
> > > >
> > > > > On 24/01/2008, ant elder <[EMAIL PROTECTED]> wrote:
> > > > > > I think the NOTICE files in the artifacts that are actually being
> > > > > > distributed are OK.
> > > > >
> > > > > Surely the archive bundles are also distributed?
> > >
> > > I meant that the files in the
> > >
> > > 
> > > Binary and source distros (zip/gz/asc/md5) :
> > > http://people.apache.org/~slaws/tuscany/1.1-RC3/<http://people.apache.org/%7Eslaws/tuscany/1.1-RC3/>
> > < http://people.apache.org/%7Eslaws/tuscany/1.1-RC3/>
> > >  > >
> > > are actually being distributed.
> > >
> > > I took Ant Elder's comment to mean that these were not being
> > distributed.
> > >
> > > > >
> > > > >
> > > > snip..
> > > >
> > > > Also can you tell me if you consider that the issues you have found to
> > > be
> > > > blocking issues?
> > > >
> > >
> > > Yes, I think the discrepancies in the LICENSE file need to be addressed.
> > >
> > > Also, comparing the SVN tag with the source archive shows that there
> > > are quite a few files and directories that are missing from the source
> > > archive.
> > >
> > > There are several files in the source archive that are not in SVN,
> > > which probably should be in SVN, for example:
> > >
> > > BUILDING
> > > CHANGES
> > > DISCLAIMER
> > > LICENSE
> > > NOTICE
> > > README
> > > RELEASE_NOTES
> > > demos/alert-aggregator-webapp/build-dependency.xml
> > > demos/xml-bigbank/build-dependency.xml
> > >
> > >
> > itest/databindings/interop/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/InteropDatabindingTestCase.java
> >
> > >
> > >
> > itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterService.java
> > >
> > >
> > itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClient.java
> >
> > >
> > >
> > itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceClientImpl.java
> > >
> > >
> > itest/databindings/jaxbgen/src/main/java/org/apache/tuscany/sca/itest/jaxbdatabinding/GreeterServiceImpl.java
> >
> > >
> > >
> > itest/databindings/jaxbgen/src/test/java/org/apache/tuscany/sca/itest/jaxbdatabinding/DatabindingTestCase.java
> > >
> > >
> > itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterService.java
> >
> > >
> > >
> > itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceClientImpl.java
> > >
> > >
> > itest/databindings/sdogen/src/main/java/org/apache/tuscany/sca/itest/sdodatabinding/GreeterServiceImpl.java
> >
> > >
> > >
> > itest/databindings/sdogen/src/test/java/org/apache/tuscany/sca/itest/sdodatabinding/DatabindingTestCase.java
> > > samples/calculator-webapp/build.xml
> > > samples/calculator-ws-webapp/build.xml
> > > samples/chat-webapp/build.xml
> > > samples/feed-aggregator-webapp/build.xml
> > > samples/helloworld-dojo-webapp/build-dependency.xml
> > > samples/helloworld-jsonrpc-webapp/build.xml
> > > samples/helloworld-ws-sdo-webapp/build-dependency.xml
> > >
> > > There are also a lot of files in SVN, which are not in the source
> > archive:
> > >
> > > demos/alert-aggregator-webapp/alert-aggregator.svg
> > > demos/bigbank-account/bigbank.svg
> > > demos/bigbank-calculator/src/test
> > > demos/secure-bigbank/secure-bigbank-account/bigbank.svg
> > > demos/secure-bigbank/secure-bigbank-calculator/src/test
> > > demos/xml-bigbank/xml-bigbank.svg
> > > distribution/standalone/src

Re: [VOTE] Approve release CXF 2.0.4-incubator

[sebb]

There are several problems with the NOTICE and LICENSE files.

The NOTICE file should only pertain to artefacts actually included in
distribution; it should not have any details of transitive
dependencies. So the "/uses" text should be removed.

The line

This product includes/uses software(s) developed by 'an unknown organization'

is rather unhelpful; there are 3 organisations involved and the NOTICE
should mention these separately and by their proper names.

There are also multiple additional mentions of 'Apache Software
Foundation'; some of these give http://jakarta.apache.org/ as the ASF
web address, which is clearly wrong. None of the additional mentions
should be present - they just make the file difficult to read.

The LICENSE file needs to contain copies of all the 3rd party
licenses, or at least pointers to them, see:

http://www.apache.org/dev/apply-license.html#new

It should list the exact jars to which the 3rd party licenses apply, e.g.

jdom-1.0.jar - see licenses/jdom.txt

Having the version number is important as the license may change for
different versions.


On 30/01/2008, ant elder <[EMAIL PROTECTED]> wrote:
> The policy page says:
>
> "Therefore, should a Podling decide it wishes to perform a release, the
> Podling SHALL hold a vote on the Podling's public -dev list. At least three
> +1 votes are required (see the Apache Voting Process page), and only the
> PPMC member votes are binding. If the majority of all votes is positive,
> then the Podling SHALL send a summary of that vote to the Incubator's
> general list and formally request the Incubator PMC approve such a release.
> Three +1 Incubator PMC votes are required." -
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
> Its a separate approval vote so wouldn't that require an explicit vote? Is
> it so hard to vote over here as well?

+1

>...ant
>
> On Jan 29, 2008 6:10 PM, Craig L Russell <[EMAIL PROTECTED]> wrote:
>
> > As long as the vote was for the *same artifact*, I don't see what
> > difference it makes *where* the vote was posted.
> >
> > Craig
> >
> > On Jan 28, 2008, at 11:20 PM, ant elder wrote:
> >
> > > I'm not sure those votes on cxf-dev count in this vote unless they
> > > vote in
> > > this thread, no mater though as there are enough votes here now.
> > >
> > >   ...ant
> > >
> > > On Jan 26, 2008 5:56 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> > >
> > >>
> > >>
> > >> Just a quick update while the vote is open.
> > >>
> > >> Jim Jagielski and Jeff Genender both voted +1 on the thread on cxf-
> > >> dev.
> > >> Thus, that's two additional binding IPMC votes.   Vote is still
> > >> open :-)
> > >>
> > >> Dan
> > >>
> > >>
> > >> On Friday 25 January 2008, Daniel Kulp wrote:
> > >>> We held a vote on cxf-dev to release a new version of CXF. This
> > >>> version is pretty much just a big "bug fix rollup" compared to 2.0.3
> > >>> fixing over 50 JIRA issues reported by users and bugs encountered
> > >>> during some interop testing.
> > >>>
> > >>> For a full list of the issues, see:
> > >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=1231285
> > >>> 5&styleName=Html&projectId=12310511&Create=Create
> > >>>
> > >>> The vote thread is at:
> > >>> http://www.nabble.com/-VOTE--Release-CXF-2.0.4-incubator-to15025947.ht
> > >>> ml
> > >>>
> > >>> In summary, we have 11 +1 votes,  no 0 or -1 votes.  Two of the
> > >>> votes
> > >>> are from ASF members (bsnyder and gnodet).   I'm not sure if they
> > >>> are
> > >>> binding yet or not.  (I think they both sent in requests to join the
> > >>> IPMC, just not sure if that is finished yet).
> > >>>
> > >>>
> > >>> The staging area is at:
> > >>> http://people.apache.org/~dkulp/stage_cxf/2.0.4-incubator
> >  > >>> >
> > >>>
> > >>>
> > >>> The distributions are in the "dist" directory. The "m2repo"
> > >>> directory
> > >>> contains the stuff that will by pushed to the
> > >>> m2-incubating-repository.
> > >>>
> > >>> This release is tagged at:
> > >>> http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.4-incubator
> > >>> /
> > >>>
> > >>> We and our users appreciate you taking the time to look over this
> > >>> release!
> > >>
> > >>
> > >>
> > >> --
> > >> J. Daniel Kulp
> > >> Principal Engineer, IONA
> > >> [EMAIL PROTECTED]
> > >> http://www.dankulp.com/blog
> > >>
> > >> -
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> > 408 276-5638 mailto:[EMAIL PROTECTED]
> > P.S. A good JDO? O, Gasp!
> >
> >
>

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

Re: [VOTE] Approve release CXF 2.0.4-incubator

[sebb]

The CXF build fails several tests.

Environment:
Maven version: 2.0.8
Java version: 1.5.0_13
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

Log file:

http://people.apache.org/~sebb/CXF


On 30/01/2008, sebb <[EMAIL PROTECTED]> wrote:
> There are several problems with the NOTICE and LICENSE files.
>
> The NOTICE file should only pertain to artefacts actually included in
> distribution; it should not have any details of transitive
> dependencies. So the "/uses" text should be removed.
>
> The line
>
> This product includes/uses software(s) developed by 'an unknown organization'
>
> is rather unhelpful; there are 3 organisations involved and the NOTICE
> should mention these separately and by their proper names.
>
> There are also multiple additional mentions of 'Apache Software
> Foundation'; some of these give http://jakarta.apache.org/ as the ASF
> web address, which is clearly wrong. None of the additional mentions
> should be present - they just make the file difficult to read.
>
> The LICENSE file needs to contain copies of all the 3rd party
> licenses, or at least pointers to them, see:
>
> http://www.apache.org/dev/apply-license.html#new
>
> It should list the exact jars to which the 3rd party licenses apply, e.g.
>
> jdom-1.0.jar - see licenses/jdom.txt
>
> Having the version number is important as the license may change for
> different versions.
>
>
> On 30/01/2008, ant elder <[EMAIL PROTECTED]> wrote:
> > The policy page says:
> >
> > "Therefore, should a Podling decide it wishes to perform a release, the
> > Podling SHALL hold a vote on the Podling's public -dev list. At least three
> > +1 votes are required (see the Apache Voting Process page), and only the
> > PPMC member votes are binding. If the majority of all votes is positive,
> > then the Podling SHALL send a summary of that vote to the Incubator's
> > general list and formally request the Incubator PMC approve such a release.
> > Three +1 Incubator PMC votes are required." -
> > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
> >
> > Its a separate approval vote so wouldn't that require an explicit vote? Is
> > it so hard to vote over here as well?
>
> +1
>
> >...ant
> >
> > On Jan 29, 2008 6:10 PM, Craig L Russell <[EMAIL PROTECTED]> wrote:
> >
> > > As long as the vote was for the *same artifact*, I don't see what
> > > difference it makes *where* the vote was posted.
> > >
> > > Craig
> > >
> > > On Jan 28, 2008, at 11:20 PM, ant elder wrote:
> > >
> > > > I'm not sure those votes on cxf-dev count in this vote unless they
> > > > vote in
> > > > this thread, no mater though as there are enough votes here now.
> > > >
> > > >   ...ant
> > > >
> > > > On Jan 26, 2008 5:56 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> > > >
> > > >>
> > > >>
> > > >> Just a quick update while the vote is open.
> > > >>
> > > >> Jim Jagielski and Jeff Genender both voted +1 on the thread on cxf-
> > > >> dev.
> > > >> Thus, that's two additional binding IPMC votes.   Vote is still
> > > >> open :-)
> > > >>
> > > >> Dan
> > > >>
> > > >>
> > > >> On Friday 25 January 2008, Daniel Kulp wrote:
> > > >>> We held a vote on cxf-dev to release a new version of CXF. This
> > > >>> version is pretty much just a big "bug fix rollup" compared to 2.0.3
> > > >>> fixing over 50 JIRA issues reported by users and bugs encountered
> > > >>> during some interop testing.
> > > >>>
> > > >>> For a full list of the issues, see:
> > > >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=1231285
> > > >>> 5&styleName=Html&projectId=12310511&Create=Create
> > > >>>
> > > >>> The vote thread is at:
> > > >>> http://www.nabble.com/-VOTE--Release-CXF-2.0.4-incubator-to15025947.ht
> > > >>> ml
> > > >>>
> > > >>> In summary, we have 11 +1 votes,  no 0 or -1 votes.  Two of the
> > > >>> votes
> > > >>> are from ASF members (bsnyder and gnodet).   I'm not sure if they
> >

Re: [VOTE] Release NMaven 0.15-incubating

[sebb]

On 18/02/2008, Shane Isbell <[EMAIL PROTECTED]> wrote:
> On the NMaven dev list, we have passed a vote for our first release. We
> request approval of the release by the IPMC. The 0.15-incubating version
> supports:
>
> 1) Compiling C# projects (2.0 framework)
> 2) Strong Naming
> 3) Generation of assembly info based on pom metadata
> 4) Support for Microsoft and Novell/Mono platforms
>
> Staging repo:
> http://people.apache.org/~sisbell/staging_repo/

The NOTICE files in the jars don't agree with NOTICE.txt in SVN, in
that the Copyright says 2002-2008, whereas NOTICE.txt says just 2007.

Did the project really start in 2002?

Also, the NOTICE file is only supposed to include details of code that
is included in the distribution - not any external dependencies.

The proper heading is:

This product includes software developed by 'etc'

There is no need to itemise the individual projects within ASF.

See http://www.apache.org/legal/src-headers.html#notice for details.

The individual jars seem to have individual NOTICE file headings, e.g. in

maven-archetype-windows-application-0.15-incubating-sources.jar

the heading reads:

maven-archetype-dotnet-windows-application
Copyright 2002-2008 The Apache Software Foundation

Surely the official name of the project is "Apache NMaven" ?

Unless there is some non-ASF code included in the distribution, then
the NOTICE.txt file currently at the root of SVN is all that is needed
for the NOTICE in the jar files.

==

The Manifest.mf files in binary jars should ideally contain the Java
compiler source and target versions.

There's no need for the .asc.mdf and .asc.sha1 files - an .asc file is
only needed to verify the file sig, and if the .asc file is mangled it
won't agree with the file it is protecting.

>
> Vote Thread:
> http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html
>
> 4  +1 binding (PPMC),
> 1   +1 non-binding
> 0   0/-1
>
> Tag:
> http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/

NOTICE.txt says:
"Copyright 2007 The Apache Software Foundation"

That should be
"Copyright 2007-2008 The Apache Software Foundation" - assuming that
the project started in 2007.

There should ideally be a LICENSE file alongside the NOTICE file.

Some of the source files are missing the standard ASF header.

>
> Thanks,
> Shane
>

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

Re: [VOTE] Release NMaven 0.15-incubating

[sebb]

On 18/02/2008, Shane Isbell <[EMAIL PROTECTED]> wrote:
> Hi Sebb,
>
> Thanks for checking over the staging release. The only missing license
> headers that I could find are in the unit test and integration test source
> files. Do test class files also need the license header?
>

Yes, in general all files need headers.

The header can be omitted from certain files:

http://www.apache.org/legal/src-headers.html#faq-exceptions

> Thanks,
> Shane
>
> On Feb 18, 2008 10:59 AM, sebb <[EMAIL PROTECTED]> wrote:
>
> > On 18/02/2008, Shane Isbell <[EMAIL PROTECTED]> wrote:
> > > On the NMaven dev list, we have passed a vote for our first release. We
> > > request approval of the release by the IPMC. The 0.15-incubating version
> > > supports:
> > >
> > > 1) Compiling C# projects (2.0 framework)
> > > 2) Strong Naming
> > > 3) Generation of assembly info based on pom metadata
> > > 4) Support for Microsoft and Novell/Mono platforms
> > >
> > > Staging repo:
> > > http://people.apache.org/~sisbell/staging_repo/
> >
> > The NOTICE files in the jars don't agree with NOTICE.txt in SVN, in
> > that the Copyright says 2002-2008, whereas NOTICE.txt says just 2007.
> >
> > Did the project really start in 2002?
> >
> > Also, the NOTICE file is only supposed to include details of code that
> > is included in the distribution - not any external dependencies.
> >
> > The proper heading is:
> >
> > This product includes software developed by 'etc'
> >
> > There is no need to itemise the individual projects within ASF.
> >
> > See http://www.apache.org/legal/src-headers.html#notice for details.
> >
> > The individual jars seem to have individual NOTICE file headings, e.g. in
> >
> > maven-archetype-windows-application-0.15-incubating-sources.jar
> >
> > the heading reads:
> >
> > maven-archetype-dotnet-windows-application
> > Copyright 2002-2008 The Apache Software Foundation
> >
> > Surely the official name of the project is "Apache NMaven" ?
> >
> > Unless there is some non-ASF code included in the distribution, then
> > the NOTICE.txt file currently at the root of SVN is all that is needed
> > for the NOTICE in the jar files.
> >
> > ==
> >
> > The Manifest.mf files in binary jars should ideally contain the Java
> > compiler source and target versions.
> >
> > There's no need for the .asc.mdf and .asc.sha1 files - an .asc file is
> > only needed to verify the file sig, and if the .asc file is mangled it
> > won't agree with the file it is protecting.
> >
> > >
> > > Vote Thread:
> > >
> > http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html
> > >
> > > 4  +1 binding (PPMC),
> > > 1   +1 non-binding
> > > 0   0/-1
> > >
> > > Tag:
> > >
> > http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/
> >
> > NOTICE.txt says:
> > "Copyright 2007 The Apache Software Foundation"
> >
> > That should be
> > "Copyright 2007-2008 The Apache Software Foundation" - assuming that
> > the project started in 2007.
> >
> > There should ideally be a LICENSE file alongside the NOTICE file.
> >
> > Some of the source files are missing the standard ASF header.
> >
> > >
> > > Thanks,
> > > Shane
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

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

Re: Subversion vs other source control systems

[sebb]

[Apologies to incubator readers if you get this twice]

On 20/02/2008, Santiago Gala <[EMAIL PROTECTED]> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>

Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.

Switching between different repositories to work on them will generate
some overhead (if only having to think about it).

Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?

The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.

> > > and that copying/moving a file from one repo to another would not keep 
> > > history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)

Thanks.

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

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

Re: Subversion vs other source control systems

[sebb]

On 20/02/2008, Santiago Gala <[EMAIL PROTECTED]> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>

Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.

Switching between different repositories to work on them will generate
some overhead (if only having to think about it).

Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?

The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.

> > > and that copying/moving a file from one repo to another would not keep 
> > > history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)

Thanks.

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

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

Re: Graduation resolution feedback - Qpid as TLP

[sebb]

On 29/02/2008, Carl Trieloff <[EMAIL PROTECTED]> wrote:
> Comments on last version ..
>
>  - It looks like you are using a non-applicable template for the board
> resolution. Take a look at other incubator graduation resolutions.
>  - Specifically, the paragraph on establishing bylaws isn't applicable,
>  and the incubator needs to be discharged of responsibility.

See below - only half of the above seems to have been addressed.

> - Can you rework this; it's simply too recursive.  Deconstruct Qpid
> Messaging back to it's purpose/definition.  Thanks :)

Still seems recursive to me, see below.

>
> Attached is an updated charter with corrections for these. Please review
>
>  Kind regards.
>
>
>
>WHEREAS, the Board of Directors deems it to be in the best
>interests of the Foundation and consistent with the
>Foundation's purpose to establish a Project Management
>Committee charged with the creation and maintenance of
>open-source software related to the Qpid messaging implementation,

Is Qpid an existing independent implementation?
And is the project creating software for it?

I would expect the project to implement (i.e. create and maintain an
implementation of) a protocol or an API or other kind of
specification.

>for distribution at no charge to the public.
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache Qpid Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
>
>RESOLVED, that the Apache Qpid Project be and hereby is
>responsible for the creation and maintenance of software
>related to the Qpid messaging implementation; a multiple
>language implementation based on the Advanced Messaged
>Queuing Protocol (AMQP) and related technologies such as
>messaging transaction management, federation, security,
>management; and be it further

Still seems circular to me.
See also comments on Qpid above.

>RESOLVED, that the office of "Vice President, Qpid" be and
>hereby is created, the person holding such office to serve at
>the direction of the Board of Directors as the chair of the
>Apache Qpid Project, and to have primary responsibility for
>management of the projects within the scope of responsibility
>of the Apache Qpid Project; and be it further
>
>RESOLVED, that the persons listed immediately below be and
>hereby are appointed to serve as the initial members of the
>Apache Qpid Project:
>
>  * Alan Conway
>  * Arnaud Simon
>  * Carl Trieloff
>  * Gordon Sim
>  * John O'Hara
>  * Marnie McCormack
>  * Martin Ritchie
>  * Rafael Schloming
>  * Rajith Attapattu
>  * Robert Greig
>  * Robert Godfrey

None of the mentors seem to be included.
Perhaps this is normal for graduating podlings?

>NOW, THEREFORE, BE IT FURTHER RESOLVED, that
>Carl Trieloff be appointed to the office of Vice President,
>Qpid, to serve in accordance with and subject to the
>direction of the Board of Directors and the Bylaws of the
>Foundation until death, resignation, retirement, removal or
>disqualification, or until a successor is appointed; and be it
>further
>
>RESOLVED, that the initial Apache Qpid Project be and
>hereby is tasked with the creation of a set of bylaws intended
>to encourage open development and increased participation in
>the Qpid Project; and be it further

Is the above paragraph needed?

>RESOLVED, that all responsibility pertaining to the Qpid
>Project encumbered upon the Apache Incubator be hereafter
>discharged.
>
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Release Audit Report 2008-03-02

[sebb]

On 02/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>
>  Audit Report: 2008-01-29 -> 2008-03-02
>  ==
>
>   * 18 files were added
>   * 2 files were modified
>   * 0 files were deleted
>
>  For details see http://incubator.apache.org/audit/changes-2008-03-02.html
>

Which does not seem to exist ...

>  -BEGIN PGP SIGNATURE-
>  Version: GnuPG v2.0.7 (GNU/Linux)
>
>  iD8DBQFHyxN2l6Otx30NTe0RAvvAAKCEDUlT8O6J0vDp8/YlPFEdBFWeagCfQ4kC
>  VvZ/9e5te0LJsnOO5uHnens=
>  =yP2l
>  -END PGP SIGNATURE-
>
>
> -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>

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

Re: Graduation resolution feedback - Qpid as TLP

[sebb]

On 04/03/2008, Carl Trieloff <[EMAIL PROTECTED]> wrote:
> sebb wrote:
>  > On 29/02/2008, Carl Trieloff <[EMAIL PROTECTED]> wrote:
>  >
> > Craig L Russell wrote:
>  >> Comments on last version ..
>  >>
>  >>  - It looks like you are using a non-applicable template for the board
>  >> resolution. Take a look at other incubator graduation resolutions.
>  >>  - Specifically, the paragraph on establishing bylaws isn't applicable,

See below.

>  >>  and the incubator needs to be discharged of responsibility.
>  >>
>  >
>  > -See below - only half of the above seems to have been addressed.
>
> > Still seems recursive to me, see below.
>  >
>  >
>
>
> Take a look below at the update and see what you think... I believe I
>  have fixed
>  the recursion you noted.
>
>
>
>  >
>  >RESOLVED, that the initial Apache Qpid Project be and
>  >hereby is tasked with the creation of a set of bylaws intended
>  >to encourage open development and increased participation in
>  >the Qpid Project; and be it further
>  >
>  > Is the above paragraph needed?
>  >
>
>
> Checking with our mentors it seems that it is needed. any particular
>  reason why you
>  believe otherwise or just asking to be sure?
>

Because  of the comment above:

"Specifically, the paragraph on establishing bylaws isn't applicable,"

>  Updated resolution:
>
>
>
>
>   WHEREAS, the Board of Directors deems it to be in the best
>   interests of the Foundation and consistent with the
>   Foundation's purpose to establish a Project Management
>   Committee charged with the creation and maintenance
>   of open-source software related to distributed messaging,
>   for distribution at no charge to the public.

May need to mention AMQP in the above paragraph.

>   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>   Committee (PMC), to be known as the "Apache Qpid Project",
>   be and hereby is established pursuant to Bylaws of the
>   Foundation; and be it further
>
>   RESOLVED, that the Apache Qpid Project be and hereby is
>   responsible for the creation and maintenance of software
>   related to the distributed messaging; a multiple language

the distributed messaging => distributed messaging

>   implementation providing daemons and API's for publish &

API's => APIs

>   subscribe, eventing and a wide range of message distribution patterns
>   based on the Advanced Messaged Queuing Protocol (AMQP) and

s/Messaged/Message/

>   related technologies such as (transaction management, federation,
>   security, management); and be it further

How is this "distributed messaging" different from ActiveMQ?
Is it just because it is based on AMQP?

>   RESOLVED, that the office of "Vice President, Qpid" be and
>   hereby is created, the person holding such office to serve at
>   the direction of the Board of Directors as the chair of the
>   Apache Qpid Project, and to have primary responsibility for
>   management of the projects within the scope of responsibility
>   of the Apache Qpid Project; and be it further
>
>   RESOLVED, that the persons listed immediately below be and
>   hereby are appointed to serve as the initial members of the
>   Apache Qpid Project:
>
> * Alan Conway
> * Arnaud Simon
> * Carl Trieloff
> * Gordon Sim
> * John O'Hara
> * Marnie McCormack
> * Martin Ritchie
> * Paul Fremantle
> * Rafael Schloming
> * Rajith Attapattu
> * Robert Greig
> * Robert Godfrey
> * Yoav Shapira
>
>
>   NOW, THEREFORE, BE IT FURTHER RESOLVED, that
>   Carl Trieloff be appointed to the office of Vice President,
>   Qpid, to serve in accordance with and subject to the
>   direction of the Board of Directors and the Bylaws of the
>   Foundation until death, resignation, retirement, removal or
>   disqualification, or until a successor is appointed; and be it
>   further
>
>   RESOLVED, that the initial Apache Qpid Project be and
>   hereby is tasked with the creation of a set of bylaws intended
>   to encourage open development and increased participation in
>   the Qpid Project; and be it further
>
>
>   RESOLVED, that all responsibility pertaining to the Qpid
>
>   encumbered upon the Apache Incubator be hereafter discharged.
>
>
>
>
>

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

Re: FW: (qpid) Diversity

[sebb]

On 05/03/2008, Roland Weber <[EMAIL PROTECTED]> wrote:
> Marnie McCormack wrote:
>  > All,
>  >
>  > Several of our project (Qpid) memebers are legally in a difficult position
>  > disclosing their employer in Apache world.
>
>
> Does that mean they are contributing in their private time rather
>  than as part of their jobs? If so, they should be considered as
>  independents. If contributing to the project is part of their job
>  responsibilities, they should be required to disclose the employer.
>

If the actual employers cannot be disclosed, perhaps it would be
possible to list the different companies anonymously?

e.g.
Company 1 employs Adrian, Barbara, Cedric
Company 2 employs Peter, Quentin, Rick

This might help with determining diversity.

>
>  > They have signed a legal
>  > document, in order to be allowed to contribute to Apache, and thus this is
>  > not a simple preference issue.
>
>
> My own employer's requirements are something like "must not create
>  the impression to act on behalf of the employer". It doesn't say
>  "is not allowed to disclose the employer". A statement like
>  "independent contributor, working for XXX in the day job"
>  would satisfy that.
>  If it's just one or two of that category, I wouldn't care about
>  the employer at all. But previous postings suggest that a lot of
>  people are working for the same employer, and that's something
>  that should be clarified. Maybe it's a club of spare time developers
>  that met at work and are now jointly working on Qpid?
>
>  cheers,
>
>Roland
>
>
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve the release of Tuscany SDO Java 1.1-incubating (release candidate 2)

[sebb]

On 10/03/2008, kelvin goodson <[EMAIL PROTECTED]> wrote:
> The Tuscany community had a vote to release SDO Java 1.1-incubating release
>  candidate 2 [1] which was passed with 7+1s and no -1s.
>
>  Please vote to approve this release.
>
>  The distribution files are at [2]
>  Maven artifacts for the release candidate are available at [3]
>  The tag for the release is at [4]
>
>  The rat report is at - [5], [6]
>
>  Here's my +1
>
>  Kelvin.
>
>  [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg28403.html
>  [2] 
> http://people.apache.org/~amita/tuscany/1.1-RC2

-1: the source archive ought to have a NOTICE file alongside the
LICENSE file at the root.

-0: The MD5 files use a non-standard format, which means that existing
utilities cannot check them.

Instead of:

apache-tuscany-sdo-1.1-incubating-src.zip:
ED 69 2B B1 5E 6B 3C DB  DD 18 08 0A 2A 9D 4D 9A

they should be

ED692BB15E6B3CDBDD18080A2A9D4D9A

or

ED692BB15E6B3CDBDD18080A2A9D4D9A *apache-tuscany-sdo-1.1-incubating-src.zip

Note that the Maven MD5 files use a correct format (at least the ones
I checked).

-0: the jar manifests ought to contain the Java source and target versions.
And the Implementation-Version should reflect the actual version

-0.5: the manifest in the binary zip is inadequate; it does not
contain any information on the product.

>  [3] 
> http://people.apache.org/~amita/tuscany/1.1-RC2/maven

-0.5: the jar manifests ought to contain the Java source and target
versions. And the correct Implementation-Version.

>  [4]
>  
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1-incubating/

-1: There should be LICENSE and NOTICE files at the root of the directory tree.

A README would also be useful, e.g. to say which Java version is
needed and how to build/install the software (or pointers to the
instructions).

>  [5]
>  
> http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txt
>  [6]
>  
> http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2-Exceptions.txt
>

-1: where is the KEYS file? This probably ought to be in SVN. Whoever
signed the files must add their public key to the file.

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

Re: [VOTE] Approve Apache XAP 0.5.0 Release

[sebb]

On 10/03/2008, Bob Buffone <[EMAIL PROTECTED]> wrote:
> Incubator PM,
>
>  The XAP team has put together a new release of the project (0.5.0) and
>  it has been approved by the xap-dev list with 8 (+1s) and 0 (others). We

It would be helpful to have a link to the vote thread.

>  are now asking the Incubator PM to approve this release so we can
>  distribute it.
>
>  The release candidate has been posted at:
>  http://people.apache.org/~bbuffone/xap-release/0.5.0-incubator/
>

Which SVN tag was used for the release?

Where is the KEYS file containing the signer's public key?

Is there a RAT report?

Normally there are separate source and binary archives.

>  Please cast your votes:
>
>  [ ] +1 Release is approved
>  [ ] -1 Veto the release (provide specific comments)
>
>  Thank you,
>  Bob (Buffone)
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve Apache XAP 0.5.0 Release

[sebb]

On 11/03/2008, Bob Buffone <[EMAIL PROTECTED]> wrote:
>
>
>  -Original Message-
>  From: sebb [mailto:[EMAIL PROTECTED]
>  Sent: Monday, March 10, 2008 9:23 AM
>  To: general@incubator.apache.org
>  Subject: Re: [VOTE] Approve Apache XAP 0.5.0 Release
>
>  On 10/03/2008, Bob Buffone <[EMAIL PROTECTED]> wrote:
>  > Incubator PM,
>  >
>  >  The XAP team has put together a new release of the project (0.5.0)
>  and
>  >  it has been approved by the xap-dev list with 8 (+1s) and 0 (others).
>  We
>  >
>  >It would be helpful to have a link to the vote thread.
>
>
> http://www.g8l.us/49f
>
>
>  >
>  >
>  >  are now asking the Incubator PM to approve this release so we can
>  >  distribute it.
>  >
>  >  The release candidate has been posted at:
>  >  http://people.apache.org/~bbuffone/xap-release/0.5.0-incubator/
>  >
>  >
>  >Which SVN tag was used for the release?
>  >
>
>
> XAP_0.5.0
>

This seems to contain lots of files that are not in the archive:

unittests/
JSDoc-1.9.9.2/

Also, some of the files in the archive are different from the tagged files, e.g.

build-manufacturing.xml has two different versions.

build.bat does not seem to be the same file at all

buildUtil$py.class

There seem to be a lot of class files in SVN - this is not usual.

>  >
>  >Where is the KEYS file containing the signer's public key?
>  >
>
>
> http://svn.apache.org/repos/asf/incubator/xap/KEYS
>
>
>  >
>  >Is there a RAT report?
>  >
>
>
> There is one, I have put it at
>  http://people.apache.org/~bbuffone/xap-release/0.5.0-incubator/rat_outpu
>  t.txt
>
>
>  >
>  >Normally there are separate source and binary archives.
>  >
>
>
> Being that this is an Ajax toolkit, we have included all the source
>  files in the distribution to allow people to be able to customize the
>  application loading profile of their application.  Users can either load
>  one large file upfront and make zero JavaScript requests later, or a
>  smaller upfront file and more JavaScript requests later.
>

But does the archive need to contain the build files as well?


There seem to be several copies of some files, e.g.

dojo.js.uncompressed.js
custom_rhino.jar
flash6_gateway.fla

Is it necessary to include both xapcore.js and xapcore.js.gz?
Similarly for the other .js/.js.gz file pairs.

Should the two "Thumbs.db" files be included? They look like Windows
system files.

>  >  Please cast your votes:
>  >
>  >  [ ] +1 Release is approved
>  >  [ ] -1 Veto the release (provide specific comments)
>  >
>  >  Thank you,
>  >  Bob (Buffone)
>  >
>  >
>  >  -
>  >  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]
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve Apache XAP 0.5.0 Release

[sebb]

On 13/03/2008, Bob Buffone <[EMAIL PROTECTED]> wrote:
>
>
>  -Original Message-
>  From: sebb [mailto:[EMAIL PROTECTED]
>
> Sent: Thursday, March 13, 2008 7:01 PM
>  To: general@incubator.apache.org
>  Subject: Re: [VOTE] Approve Apache XAP 0.5.0 Release
>
>  On 11/03/2008, Bob Buffone <[EMAIL PROTECTED]> wrote:
>  >
>  >
>  >  -Original Message-
>  >  From: sebb [mailto:[EMAIL PROTECTED]
>  >  Sent: Monday, March 10, 2008 9:23 AM
>  >  To: general@incubator.apache.org
>  >  Subject: Re: [VOTE] Approve Apache XAP 0.5.0 Release
>  >
>  >  On 10/03/2008, Bob Buffone <[EMAIL PROTECTED]> wrote:
>  >  > Incubator PM,
>  >  >
>  >  >  The XAP team has put together a new release of the project (0.5.0)
>  >  and
>  >  >  it has been approved by the xap-dev list with 8 (+1s) and 0
>  (others).
>  >  We
>  >  >
>  >  >It would be helpful to have a link to the vote thread.
>  >
>  >
>  > http://www.g8l.us/49f
>  >
>  >
>  >  >
>  >  >
>  >  >  are now asking the Incubator PM to approve this release so we can
>  >  >  distribute it.
>  >  >
>  >  >  The release candidate has been posted at:
>  >  >  http://people.apache.org/~bbuffone/xap-release/0.5.0-incubator/
>  >  >
>  >  >
>  >  >Which SVN tag was used for the release?
>  >  >
>  >
>  >
>  > XAP_0.5.0
>  >
>
>  >This seems to contain lots of files that are not in the archive:
>  >
>  >unittests/
>
>
> Is used to run the unit tests on the project and we do not include them.
>

These are normally included with the source used to create the binary archive.

>
>  >JSDoc-1.9.9.2/
>
>
> Creates the documentation for the project and is also not included.
>

This is often included in the source archive.

>
>  >
>  Also, some of the files in the archive are different from the tagged
>  files, e.g.
>
>  build-manufacturing.xml has two different versions.
>  build.bat does not seem to be the same file at all
>  buildUtil$py.class
>

Why are the above files different?

>
> There seem to be a lot of class files in SVN - this is not usual.  These
>  files are not build from source but used in the build process when the
>  JavaScript file concatenation and compression is performed.
>

If they are executed, why not create a jar that contains them?

>
>  >  >
>  >  >Where is the KEYS file containing the signer's public key?
>  >  >
>  >
>  >
>  > http://svn.apache.org/repos/asf/incubator/xap/KEYS
>  >
>  >
>  >  >
>  >  >Is there a RAT report?
>  >  >
>  >
>  >
>  > There is one, I have put it at
>  >
>  http://people.apache.org/~bbuffone/xap-release/0.5.0-incubator/rat_outpu
>  >  t.txt
>  >
>  >
>  >  >
>  >  >Normally there are separate source and binary archives.
>  >  >
>  >
>  >
>  > Being that this is an Ajax toolkit, we have included all the source
>  >  files in the distribution to allow people to be able to customize the
>  >  application loading profile of their application.  Users can either
>  load
>  >  one large file upfront and make zero JavaScript requests later, or a
>  >  smaller upfront file and more JavaScript requests later.
>  >
>
>  >But does the archive need to contain the build files as well?
>
>
> The structure of the distribution file is as follows.
>
>  dist - Contains the application structure a developer would need to be
>  used as a starting point for developing a XAP application.
>  docs - These would be the documentation files.
>  samples - These are the sample showing people different features.
>  source - Yes? These are all the source files that people use to build
>  the xapcode.js files from the source included in the project.  So I
>  guess in a way we could separate these files into another (distribution
>  file) and label it "-source.(zip)|(tar.gz).
>
>  Would that make sense?

Normally the binary jar contains the runtime stuff, and the source jar
contains what would be needed to create the binary jar.

Samples and doc are usually in the binary jar.

It looks like you have two classes of developers here:
- developers (i.e. users) using XAP to create a XAP application
- developers maintaining XAP.

A user would normally expect to download only the binary archive (plus
any required dependencies).

>
>  >There seem to be several copies of some files, e.g.
>  >
>  >dojo.js.uncompressed.js
>  >custom_rhino.jar
&g

Re: KEYS file in distribution

[sebb]

On 18/03/2008, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 9:44 PM, Christopher Lenz <[EMAIL PROTECTED]> wrote:
>
>  > On 18.03.2008, at 22:06, Robert Burrell Donkin wrote:
>  > > On Tue, Mar 18, 2008 at 8:40 PM, Christopher Lenz <[EMAIL PROTECTED]>
>  > > wrote:
>  > >> I wonder because with CouchDB, source tarballs are created through
>  > >> the
>  > >> GNU-Autotools based build process, rather than being a raw `svn
>  > >> export` of the release tag. We don't keep the auto*-generated
>  > >> configure/make files in the repository (they are generated files
>  > >> after
>  > >> all), but do include them in source tarballs to limit build-time
>  > >> dependencies and make the build process easier for the user.
>  > >>
>  > >> I guess we could start checking in the generating build files into
>  > >> SVN
>  > >> if that's required. But maybe you can back that statement up a bit
>  > >> before we do so?
>  > >
>  > > lots of binary distributions at apache contain source. this makes them
>  > > binary distributions containing source, not source distributions.
>  >
>  > Maybe I didn't explain properly… our previous (pre-incubation) source
>  > distributions did not contain any binaries, only source. The
>  > difference between the tarballs and a source control checkout is that
>  > the former has some generated build scripts.
>
>
>
> yes: you explained that quite well the first time
>
>  any distribution containing stuff which isn't in subversion is by definition
>  a binary distribution
>

Is this documented anywhere?

>
>  Looking into the HTTPD repos and comparing to the HTTPD source
>  > tarballs, they appear to be doing the same thing: there's a
>  > "configure" file in the source tarball, but not in the repos. In
>  > general I'd say this is common practice for any project based on
>  > Autotools.
>
>
>
> IMHO it's not worth getting into arguments about HTTPD current verses
>  original/best practice
>
>  yes, it's common practice but it's important to distinguish terminology from
>  presentation. what a source distribution means is a direct export from
>  subversion. it's fine to create a distribution containing generated stuff;
>  call it what you will; recommend it to users who want to build from source.
>  still counts as a binary as far as rules and whatnot go.

And where are these rules defined?

>  there is a slight possibility that fans of source distribution may complain
>  if you don't issue a source distribution. IMHO if that's the case then
>  that's the time to present your arguments. till then, it's just terminology.
>
>
>  [snip]
>  > > source distributions (svn exports) are aimed at developers so they can
>  > > create accurate diffs and contribute patches, not users. they are also
>  > > useful for downstream distributors who want to be able to accurately
>  > > and
>  > > selectively apply patches. these groups should be able to build in
>  > > the same
>  > > way committers do so they don't really need it easy. binary
>  > > distributions
>  > > are for users, source distributions for developers.
>  >
>  >
>  > The generated source tarballs don't in anyway prevent developers from
>  > providing good patches. They contain the source plus some build files
>  > pre-generated for convenience (which can be regenerated from the very
>  > same tarballs nonetheless).
>
>
>
> IMHO it's best to avoid getting into this kind of argument: it's just
>  terminology
>
>
>  Also, again similar to HTTPD, the source tarball is actually the main
>  > distribution for users, too (except the Windows camp, which we don't
>  > support yet anyway).
>
>
>
> that's fine
>
>
>  - robert
>

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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating

[sebb]

That's not the only problem.

The source zip file seems to contain quite a few odd files:

derby.log
.lock
redo.log
locks
db.lck
log.ctrl
logmirror.ctrl
log1.dat

Not sure what all the .dat files are for. They don't look like source...

Also contains couchdb4j-0.1.2.jar which itself has some rather odd
content, and does not have a NOTICE file even though it appears to be
an ASF jar. Also its manifest is incomplete.

The source zip file seems to contain two copies of NOTICE and LICENSE
at the top level.
Maybe this is an artefact of Winzip.

On 24/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
> Good catch; sorry for missing that.  Will get those fixed shortly.
>
>
>  - James
>
>
>  Luciano Resende wrote:
>  > Have you guys run RAT over the release ? I tried it over the source
>  > distribution and various source files are missing ASF license header.
>  >
>  > [1] http://people.apache.org/~lresende/abdera/rat.log
>  >
>  > On Sun, Mar 23, 2008 at 3:37 PM, Dan Diephouse
>  > <[EMAIL PROTECTED]> wrote:
>  >> The Apache Abdera project has voted to release the 0.4.0-incubating
>  >>  release [1]. The vote passed with 7 +1s. Two of these were IPMC votes,
>  >>  Garrett Rooney and Davanum Srinivas.
>  >>
>  >>  Binary distributions:
>  >>
>  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
>  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
>  >>
>  >>  Source distributions:
>  >>
>  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
>  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
>  >>
>  >>  Maven Repository: http://people.apache.org/~dandiep/abdera-take4/
>  >>
>  >>  Please take a look and cast your vote!
>  >>
>  >>  - Abdera Team
>  >>
>  >>  1.
>  >>  
> http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200803.mbox/[EMAIL
>  PROTECTED]
>  >>
>  >>  --
>  >>  Dan Diephouse
>  >>  MuleSource
>  >>  http://mulesource.com | http://netzooid.com
>  >>
>  >>
>  >>  -
>  >>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  >>  For additional commands, e-mail: [EMAIL PROTECTED]
>  >>
>  >>
>  >
>  >
>  >
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating

[sebb]

Which SVN tag was used to create the distribution?

On 24/03/2008, sebb <[EMAIL PROTECTED]> wrote:
> That's not the only problem.
>
>  The source zip file seems to contain quite a few odd files:
>
>  derby.log
>  .lock
>  redo.log
>  locks
>  db.lck
>  log.ctrl
>  logmirror.ctrl
>  log1.dat
>
>  Not sure what all the .dat files are for. They don't look like source...
>
>  Also contains couchdb4j-0.1.2.jar which itself has some rather odd
>  content, and does not have a NOTICE file even though it appears to be
>  an ASF jar. Also its manifest is incomplete.
>
>  The source zip file seems to contain two copies of NOTICE and LICENSE
>  at the top level.
>  Maybe this is an artefact of Winzip.
>
>
>  On 24/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>  > Good catch; sorry for missing that.  Will get those fixed shortly.
>  >
>  >
>  >  - James
>  >
>  >
>  >  Luciano Resende wrote:
>  >  > Have you guys run RAT over the release ? I tried it over the source
>  >  > distribution and various source files are missing ASF license header.
>  >  >
>  >  > [1] http://people.apache.org/~lresende/abdera/rat.log
>  >  >
>  >  > On Sun, Mar 23, 2008 at 3:37 PM, Dan Diephouse
>  >  > <[EMAIL PROTECTED]> wrote:
>  >  >> The Apache Abdera project has voted to release the 0.4.0-incubating
>  >  >>  release [1]. The vote passed with 7 +1s. Two of these were IPMC votes,
>  >  >>  Garrett Rooney and Davanum Srinivas.
>  >  >>
>  >  >>  Binary distributions:
>  >  >>
>  >  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
>  >  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
>  >  >>
>  >  >>  Source distributions:
>  >  >>
>  >  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
>  >  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
>  >  >>
>  >  >>  Maven Repository: http://people.apache.org/~dandiep/abdera-take4/
>  >  >>
>  >  >>  Please take a look and cast your vote!
>  >  >>
>  >  >>  - Abdera Team
>  >  >>
>  >  >>  1.
>  >  >>  
> http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200803.mbox/[EMAIL
>  PROTECTED]
>  >  >>
>  >  >>  --
>  >  >>  Dan Diephouse
>  >  >>  MuleSource
>  >  >>  http://mulesource.com | http://netzooid.com
>  >  >>
>  >  >>
>  >  >>  -
>  >  >>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  >  >>  For additional commands, e-mail: [EMAIL PROTECTED]
>  >  >>
>  >  >>
>  >  >
>  >  >
>  >  >
>  >
>  >  -
>  >  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>

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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating

[sebb]

On 24/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> These things are my fault, I think I screwed up the last cut. We'll fix
>  up the license and distro issues and get try again :-)
>
>  I used:
>
>  
> http://svn.apache.org/repos/asf/incubator/abdera/java/branches/abdera-0.4.0-incubating/
>
>  I haven't made the tag as its not officially released.
>

I thought the idea was to create an RC tag, vote on that, and then
copy the tag to a release tag if the vote passes.

There are other ways of doing this, but AFAIK, each release must have
a corresponding tag.  A branch is not suitable as that will normally
change.

>
>  Dan
>
>
>  sebb wrote:
>  > Which SVN tag was used to create the distribution?
>  >
>  > On 24/03/2008, sebb <[EMAIL PROTECTED]> wrote:
>  >
>  >> That's not the only problem.
>  >>
>  >>  The source zip file seems to contain quite a few odd files:
>  >>
>  >>  derby.log
>  >>  .lock
>  >>  redo.log
>  >>  locks
>  >>  db.lck
>  >>  log.ctrl
>  >>  logmirror.ctrl
>  >>  log1.dat
>  >>
>  >>  Not sure what all the .dat files are for. They don't look like source...
>  >>
>  >>  Also contains couchdb4j-0.1.2.jar which itself has some rather odd
>  >>  content, and does not have a NOTICE file even though it appears to be
>  >>  an ASF jar. Also its manifest is incomplete.
>  >>
>  >>  The source zip file seems to contain two copies of NOTICE and LICENSE
>  >>  at the top level.
>  >>  Maybe this is an artefact of Winzip.
>  >>
>  >>
>  >>  On 24/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>  >>  > Good catch; sorry for missing that.  Will get those fixed shortly.
>  >>  >
>  >>  >
>  >>  >  - James
>  >>  >
>  >>  >
>  >>  >  Luciano Resende wrote:
>  >>  >  > Have you guys run RAT over the release ? I tried it over the source
>  >>  >  > distribution and various source files are missing ASF license 
> header.
>  >>  >  >
>  >>  >  > [1] http://people.apache.org/~lresende/abdera/rat.log
>  >>  >  >
>  >>  >  > On Sun, Mar 23, 2008 at 3:37 PM, Dan Diephouse
>  >>  >  > <[EMAIL PROTECTED]> wrote:
>  >>  >  >> The Apache Abdera project has voted to release the 0.4.0-incubating
>  >>  >  >>  release [1]. The vote passed with 7 +1s. Two of these were IPMC 
> votes,
>  >>  >  >>  Garrett Rooney and Davanum Srinivas.
>  >>  >  >>
>  >>  >  >>  Binary distributions:
>  >>  >  >>
>  >>  >  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
>  >>  >  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
>  >>  >  >>
>  >>  >  >>  Source distributions:
>  >>  >  >>
>  >>  >  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
>  >>  >  >>  
> http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
>  >>  >  >>
>  >>  >  >>  Maven Repository: http://people.apache.org/~dandiep/abdera-take4/
>  >>  >  >>
>  >>  >  >>  Please take a look and cast your vote!
>  >>  >  >>
>  >>  >  >>  - Abdera Team
>  >>  >  >>
>  >>  >  >>  1.
>  >>  >  >>  
> http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200803.mbox/[EMAIL
>  PROTECTED]
>  >>  >  >>
>  >>  >  >>  --
>  >>  >  >>  Dan Diephouse
>  >>  >  >>  MuleSource
>  >>  >  >>  http://mulesource.com | http://netzooid.com
>  >>  >  >>
>  >>  >  >>
>  >>  >  >>  
> -
>  >>  >  >>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  >>  >  >>  For additional commands, e-mail: [EMAIL PROTECTED]
>  >>  >  >>
>  >>  >  >>
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >
>  >>  >  -
>  >>  >  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  >>  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >>  >
>  >>  >
>  >>
>  >>
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>
>
>  --
>  Dan Diephouse
>  MuleSource
>  http://mulesource.com | http://netzooid.com
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve release CXF 2.0.5-incubator

[sebb]

On 28/03/2008, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> On Thursday 27 March 2008, sebb wrote:
>  > On 26/03/2008, Daniel Kulp <[EMAIL PROTECTED]> wrote:
>
> > >  The staging area is at:
>  > >  http://people.apache.org/~dkulp/stage_cxf/2.0.5-incubator
>  >
>  > The binary jar contains lots of non-CXF jars in the lib directory;
>  > these should probably be dropped and listed as external dependencies.
>
>
> Huh?   Then the binary distibution wouldn't work.  That's silly.  Users
>  should be able to download this, unpack it, and run the samples and
>  stuff to see it working without tramping all over the internet to find
>  jars and stuff.  If you install MS office on your machine, do you then
>  have to go off and find the spell checker, the thesauras, etc...?
>
>

Well - it makes the download much bigger, and they may have some of
the dependencies already. Also, some of the included jars have been
updated with newer versions. You could provide a separate libraries
archive for the external jars.

>
>  > Typo in LICENSE file in binary zip: "librarie"  should be "libraries"
>
>
> Fixed on trunk.  Good catch.  I must have looked at that several times
>  and it never triggered my brain.  Must be getting old... :-(
>
>
>
>  > The CXF jar manifests should really include source and target Java
>  > versions.
>
>
> Why?
>

So that one can tell which Java version is required ...

>
>  > The CXF jars contain the file DEPENDENCIES in META-INF - this seems
>  > out of place.
>
>
> This was discussed on legal-discuss and no objections raised.
>
>
>  > Also the DEPENDENCIES contents still refer to jakarta for some commons
>  > modules, and  'Apache Software Foundation' => 'The Apache Software
>  > Foundation'
>
>
> Well.  It's automatically generated from the information the other
>  projects provide.  As long as Jakarta/commons keep providing
>  crap.
>  Seriously, if the poms say they came from jakarta, the versions we are
>  using probably are the jakarta versions.   See Davids response at:
>  
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200803.mbox/<4047F63C-2D55-437A-AE95-6B52E98BEF7D%40yahoo.com>
>
>
>  > >  The distributions are in the "dist" directory. The "m2repo"
>  > > directory contains the stuff that will by pushed to the
>  > > m2-incubating-repository.
>  > >
>  > >  This release is tagged at:
>  > >
>  > > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.5-incubat
>  > >or/
>  >
>  > -1: there should be NOTICE and LICENSE files at the top level in SVN.
>  >
>  > -1: SVN and the source archive don't agree; there are files and
>  > directories in each that are not in the other.
>
>
> I'll wait and respond to any of this once the other thread concludes.
>
>
>
>  > There are lots of files incorrectly marked as executable in SVN, and
>  > various other files don't have the correct properties. See attached
>  > script.
>
>
> Thanks for the script. I'll have to figure out how to get it to apply
>  without breaking the merges from trunk.   Probably will run on trunk
>  (which is slightly different) and svnmerge out to the branches.  I'll
>  have to experiment a bit.   Anyway, thanks for that.
>

It won't affect merges. You can just apply the script to trunk and
branch and tag if necessary.

Ideally whoever is creating the files initially with the incorrect
properties needs to update their svn properties file.

>  --
>
> J. Daniel Kulp
>  Principal Engineer, IONA
>  [EMAIL PROTECTED]
>  http://www.dankulp.com/blog
>

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

Re: Source tar ball != svn tag (was: Re: [VOTE] Approve release CXF 2.0.5-incubator)

[sebb]

On 27/03/2008, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> On 3/27/08, sebb <[EMAIL PROTECTED]> wrote:
>  >  >  This release is tagged at:
>  >  >  http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.5-incubator/
>  >
>  > -1: there should be NOTICE and LICENSE files at the top level in SVN.
>  >
>  >  -1: SVN and the source archive don't agree; there are files and
>  >  directories in each that are not in the other.
>
>  According to my knowledge there is no policy that this has to be so.
>  The notice and license file MUST be in the src tar ball, but there is
>  no policy requiring them to be in SVN.
>
>  The policy (or rather faq, [1]) states that:
>
>  "In particular, every artifact distributed must contain appropriate
>  LICENSE and NOTICE files."
>
>  To the best of my knowledge an svn tag is not an artifact which is 
> distributed.
>

SVN URLs are published on most sites; this is effectivel distribution.

>  >  There are lots of files incorrectly marked as executable in SVN, and
>  >  various other files don't have the correct properties. See attached
>  >  script.
>
>  Again, to my knowledge there is no policy that states that this MUST
>  or SHOULD be so.
>
>  Martijn
>
>  [1] http://apache.org/dev/release.html#what-must-every-release-contain
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve release CXF 2.0.5-incubator

[sebb]

On 31/03/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 27, 2008 at 11:15 PM, sebb <[EMAIL PROTECTED]> wrote:
> >
> > -1: there should be NOTICE and LICENSE files at the top level in SVN.

May I suggest resolving this via Legal discuss?
It's also pretty easy to add the two files to SVN...

> > -1: SVN and the source archive don't agree; there are files and
> > directories in each that are not in the other.
> >

I can understand why you may wish to omit the bin and benchmark
directories, but I think consumers expect to find everything they need
in the archives; it should not be necessary to retrieve additional
files from SVN.

Are the following directories really not needed in the source archive?

distribution/src/main/release/samples/callback/build
distribution/src/main/release/samples/ws_policy/build
distribution/src/main/release/samples/ws_rm/build

Also build.xml

> >
>
> Could you please reconsider your vote?  AFAIK, we have always voted on
> releases, not on the SVN tag.  The tag is just a way to (re-)build the
> release and not something we vote on and distribute.  Furthermore, there's
> no policies yet around these issues that are still being discussed.
>
>
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/

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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[sebb]

On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
> The Abdera project has resolved the issues raised previously and have
>  voted to release a new build of the 0.4.0-incubating release.
>
>  Binary distributions:
>
>  
> http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
>  
> http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
>
>  Source distributions:
>
>  
> http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
>  
> http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
>

-1: There are MD5 and SHA1 digests in the directory, but the archives
have no signatures.

>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>

-0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
have any content - only the META-INF directory is present. Is that
correct?

-1: The NOTICE files in that jar (and others) contains far too much.
The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
There's really no need to repeat ASF for each project used by Abdera.

-0: The Maven abdera-bundle-0.4.0-incubating.jar file contains a
LICENSE for Xalan and HtmlParser, but does not actually contain
either.

-1: The LICENSE files need to either contain copies of the 3rd party
licenses, or they need to have a reference to the 3rd party licences.
Equally, there is no need for the lib directory to contain copies of
the AL for every ASF product.

-1: RAT report says:

99 Unknown Licenses

Some of these are trivial, but most require an AL header.

What is the SVN tag that corresponds with the archives?


=== Other comments ===

mvn test succeeded, however there were quite a few stack traces printed.
If possible, these should be suppressed.

The jar MANIFEST files could do with a bit more information.
This makes it easier to trace the provenance of the jars.

For example:

Built-By: x
Implementation-Title: Apache Abdera (Incubating)
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version:
Specification-Title:
Specification-Vendor: The Apache Software Foundation
Specification-Version: xxx
Build-Jdk: 1.5.0_12 (e.g.)
X-Compile-Source-JDK: 1.3 (e.g.)
X-Compile-Target-JDK: 1.3 (e.g.)


>  Please take a look and cast your vote!
>
>  - Abdera Team
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[sebb]

On 31/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> sebb wrote:
>  > On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>  >
>  >>
>  >
>
> > -1: There are MD5 and SHA1 digests in the directory, but the archives
>  > have no signatures.
>  >
>  >
>
> OK, I will fix this.
>
> >>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>  >>
>  >>
>  >
>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>  > have any content - only the META-INF directory is present. Is that
>  > correct?
>  >
>
> This is just a by-product of Maven. We can delete it.
>
> > -1: The NOTICE files in that jar (and others) contains far too much.
>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>  > There's really no need to repeat ASF for each project used by Abdera.
>  >
>
> Having too much information in the NOTICE files is not a crime. The
>  Maven remote-resources plugin aggregates all this stuff for us so we
>  never miss any notice that we need to put in.

Unfortunately the plugin generates incorrect information.
It *is* a problem having all the redundant information.

See for example:

http://www.apache.org/legal/src-headers.html
also
http://wiki.apache.org/legal/3party/notice
http://wiki.apache.org/legal/3party/notice/discuss

> > -1: The LICENSE files need to either contain copies of the 3rd party
>  > licenses, or they need to have a reference to the 3rd party licences.
>  > Equally, there is no need for the lib directory to contain copies of
>  > the AL for every ASF product.
>  >
>
> Why does the LICENSE file need to have a copy of all the other licenses?
>  These are contained in the lib/ directory like many other ASF projects.
>

See the last paragraph of:

http://www.apache.org/dev/apply-license.html#new

>  Re: the ASL license in lib/ - once again having too much information is
>  not a crime. This is a service to uesrs so they know where the libraries
>  came from.

I agree the source is useful, but the place for this is the LICENSE file.

> > -1: RAT report says:
>  >
>  > 99 Unknown Licenses
>  >
>  > Some of these are trivial, but most require an AL header.
>  >
>
> Not true - there is not consensus that properties/xml files need to have
>  headers. All the Java source code files have headers. If there are
>  specific files that you feel should have a license that don't please
>  list them and explain why. I'm not saying that we didn't miss something,
>  but I am saying that the ones that I know about don't necessarily
>  require a header.

Yes, they do, see:

http://www.apache.org/legal/src-headers.html#faq-exceptions

> > What is the SVN tag that corresponds with the archives?
>  >
>  >
>
> the branch will be tagged once its released.
>
>  Dan
>
>
>  --
>  Dan Diephouse
>  MuleSource
>  http://mulesource.com | http://netzooid.com
>
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve release CXF 2.0.5-incubator

[sebb]

On 31/03/2008, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> On Monday 31 March 2008, sebb wrote:
>  > On 31/03/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>  > > On Thu, Mar 27, 2008 at 11:15 PM, sebb <[EMAIL PROTECTED]> wrote:
>  > > > -1: there should be NOTICE and LICENSE files at the top level in
>  > > > SVN.
>  >
>  > May I suggest resolving this via Legal discuss?
>  > It's also pretty easy to add the two files to SVN...
>
>
> Fine.   We'll take that under advisement for 2.0.6 as legal-discuss and
>  other discussions figure it out.   For 2.0.5, I don't think we should be
>  changing requirements in the middle of a vote.  The current setup has
>  been fine for MANY releases from CXF and from other projects.  Once
>  legal or whomever finalizes things, we can adjust, but that shouldn't
>  hold up the 2.0.5 release.
>

I don't think it is a change of requirements, just that these
requirements were not fully documented.

See in particular:

http://wiki.apache.org/legal/3party/notice/discuss

... [RoyFielding] Yes, the repository itself is a form of distribution


>
>  > > > -1: SVN and the source archive don't agree; there are files and
>  > > > directories in each that are not in the other.
>  >
>  > I can understand why you may wish to omit the bin and benchmark
>  > directories, but I think consumers expect to find everything they need
>  > in the archives; it should not be necessary to retrieve additional
>  > files from SVN.
>  >
>  > Are the following directories really not needed in the source archive?
>  >
>  > distribution/src/main/release/samples/callback/build
>  > distribution/src/main/release/samples/ws_policy/build
>  > distribution/src/main/release/samples/ws_rm/build
>
>
> No.  They are empty directories that shouldn't be in svn either.   I've
>  gone ahead and deleted them on trunk.  Will get the 2.0.x branch in a
>  bit.   But it's pretty irrelevant for the 2.0.5 release.

OK

>  > Also build.xml
>  Which is ONLY there for the cruisecontrol instance we have running inside
>  IONA.   It's relatively specific to that machine and thus is not
>  something that should be "released" like the benchmark dir.  It's a
>  specific file that is there to make sure the builds keep running
>  smoothly and devs don't break the build.

OK

>  Dan
>
>
>
>  > > Could you please reconsider your vote?  AFAIK, we have always voted
>  > > on releases, not on the SVN tag.  The tag is just a way to
>  > > (re-)build the release and not something we vote on and distribute.
>  > > Furthermore, there's no policies yet around these issues that are
>  > > still being discussed.
>  > >
>  > >
>  > >
>  > > --
>  > > Cheers,
>  > > Guillaume Nodet
>  > > 
>  > > Blog: http://gnodet.blogspot.com/
>  >
>
> > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>  --
>  J. Daniel Kulp
>  Principal Engineer, IONA
>  [EMAIL PROTECTED]
>  http://www.dankulp.com/blog
>

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

Fixes to Abdera SVN properties

[sebb]

Thanks.

There are quite a few problems with the SVN properties; see script at

http://people.apache.org/~sebb/SVNfixes/

(which should work on Unix - and in a DOS box if suitably
 named)

 These are not critical to the release, but not having them causes
 problems when working across systems with different EOLs.

 On 31/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:

> Oops hit "ctrl enter" instead of "ctrl-v enter".  Here's the tag:
 >
 >  
 > http://svn.apache.org/repos/asf/incubator/abdera/java/tags/abdera-0.4.0-incubating/
 >
 >
 >  Dan
 >
 >
 >  Dan Diephouse wrote:
 >  > I removed the empty sources jar and tagged the release:
 >  >
 >  > Dan Diephouse wrote:
 >  >> sebb wrote:
 >  >>> On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
 >  >>>
 >  >>>>
 >  >>>
 >  >>> -1: There are MD5 and SHA1 digests in the directory, but the archives
 >  >>> have no signatures.
 >  >>>
 >  >>>
 >  >> OK, I will fix this.
 >  >>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
 >  >>>>
 >  >>>>
 >  >>>
 >  >>> -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
 >  >>> have any content - only the META-INF directory is present. Is that
 >  >>> correct?
 >  >>>
 >  >> This is just a by-product of Maven. We can delete it.
 >  >>> -1: The NOTICE files in that jar (and others) contains far too much.
 >  >>> The NOTICE file is for required attribtions ONLY (e.g. as per an
 >  >>> About box)
 >  >>> There's really no need to repeat ASF for each project used by Abdera.
 >  >>>
 >  >> Having too much information in the NOTICE files is not a crime. The
 >  >> Maven remote-resources plugin aggregates all this stuff for us so we
 >  >> never miss any notice that we need to put in.
 >  >>> -1: The LICENSE files need to either contain copies of the 3rd party
 >  >>> licenses, or they need to have a reference to the 3rd party licences.
 >  >>> Equally, there is no need for the lib directory to contain copies of
 >  >>> the AL for every ASF product.
 >  >>>
 >  >> Why does the LICENSE file need to have a copy of all the other
 >  >> licenses? These are contained in the lib/ directory like many other
 >  >> ASF projects.
 >  >>
 >  >> Re: the ASL license in lib/ - once again having too much information
 >  >> is not a crime. This is a service to uesrs so they know where the
 >  >> libraries came from.
 >  >>> -1: RAT report says:
 >  >>>
 >  >>> 99 Unknown Licenses
 >  >>>
 >  >>> Some of these are trivial, but most require an AL header.
 >  >>>
 >  >> Not true - there is not consensus that properties/xml files need to
 >  >> have headers. All the Java source code files have headers. If there
 >  >> are specific files that you feel should have a license that don't
 >  >> please list them and explain why. I'm not saying that we didn't miss
 >  >> something, but I am saying that the ones that I know about don't
 >  >> necessarily require a header.
 >  >>> What is the SVN tag that corresponds with the archives?
 >  >>>
 >  >>>
 >  >> the branch will be tagged once its released.
 >  >>
 >  >> Dan
 >  >>
 >  >
 >  >
 >
 >
 >  --
 >  Dan Diephouse
 >  MuleSource
 >  http://mulesource.com | http://netzooid.com
 >
 >
 >  -
 >  To unsubscribe, e-mail: [EMAIL PROTECTED]
 >  For additional commands, e-mail: [EMAIL PROTECTED]
 >
 >

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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[sebb]

nt, they arguably should not
>  contain license headers because the presence of the license header could
>  potentially impact the results of the tests.
>

Probably.
Though if the AL header affects the parsing, then there may well be a
problem with the parsing...

>   ? adapters/hibernate/src/test/resources/abdera/adapter/hibernate.cfg.xml
>   ? adapters/hibernate/src/test/resources/abdera/adapter/DummyData.hbm.xml
>   ? extensions/opensearch/src/test/resources/opensearch.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace3.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace2.xml
>   ? parser/src/test/resources/www.snellspace.com/public/xmlbase.xml
>   ? parser/src/test/resources/www.snellspace.com/public/ordertest.xml
>   ? parser/src/test/resources/www.snellspace.com/public/linktests.xml
>   ? parser/src/test/resources/www.snellspace.com/public/contentsummary.xml
>   ? parser/src/test/resources/simpleFeed.xml
>   ? parser/src/test/resources/xmlcontent.xml
>   ? parser/src/test/resources/feed.xml
>   ? parser/src/test/resources/simple.xml
>   ?
>  
> parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64_2.xml
>   ?
>  
> parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64.xml
>   ?
>  
> parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_email.xml
>   ?
>  
> parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_name.xml
>   ?
>  
> parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/atom10_namespace.xml
>   ? parser/src/test/resources/complete.xml
>   ? parser/src/test/resources/simpleService.xml
>   ? parser/src/test/resources/simpleEntry.xml
>   ? parser/src/test/resources/test.xslt
>   ? parser/src/test/resources/entry.xml
>   ? parser/src/test/resources/content.xslt
>   ? spring/src/test/resources/org/apache/abdera/spring/beans.xml
>   ? contrib/rss/src/test/resources/rss1.rdf
>   ?
>  adapters/hibernate/src/test/resources/abdera/adapter/hibernate.properties
>   ? security/src/test/resources/log4j.properties
>   ? server/src/test/resources/abdera/adapter/sample.properties
>
>  This one documentation file, which contains only a single one sentence
>  statement, does not contain a license header.
>
>   ? docs/knownissues.txt
>
>  Which of these files do you think we absolutely have to add license
>  headers to?
>
>
>  - James
>
>
>  sebb wrote:
>  > On 31/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:
>  >> sebb wrote:
>  >>  > On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>  >>  >
>  >>  >>
>  >>  >
>  >>
>  >>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>  >>  > have no signatures.
>  >>  >
>  >>  >
>  >>
>  >> OK, I will fix this.
>  >>
>  >>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>  >>  >>
>  >>  >>
>  >>  >
>  >>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>  >>  > have any content - only the META-INF directory is present. Is that
>  >>  > correct?
>  >>  >
>  >>
>  >> This is just a by-product of Maven. We can delete it.
>  >>
>  >>> -1: The NOTICE files in that jar (and others) contains far too much.
>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About 
> box)
>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>  >>  >
>  >>
>  >> Having too much information in the NOTICE files is not a crime. The
>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>  >>  never miss any notice that we need to put in.
>  >
>  > Unfortunately the plugin generates incorrect information.
>  > It *is* a problem having all the redundant information.
>  >
>  > See for example:
>  >
>  > http://www.apache.org/legal/src-headers.html
>  > also
>  > http://wiki.apache.org/legal/3party/notice
>  > http://wiki.apache.org/legal/3party/notice/discuss
>  >
>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>  >>  > Equally, there is no need for the lib directory to contain copies of
>  >>  &

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[sebb]

On 31/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> sebb wrote:
>  >
>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About 
> box)
>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>  >>  >
>  >>
>  >> Having too much information in the NOTICE files is not a crime. The
>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>  >>  never miss any notice that we need to put in.
>  >>
>  >
>  > Unfortunately the plugin generates incorrect information.
>  >
>
> It does NOT generate incorrect information. It simply generates extra
>  attributions for all the ASF projects we reuse.
>
> > It *is* a problem having all the redundant information.
>  >
>  > See for example:
>  >
>  > http://www.apache.org/legal/src-headers.html
>  > also
>  > http://wiki.apache.org/legal/3party/notice
>  > http://wiki.apache.org/legal/3party/notice/discuss
>  >
>
> It says "should" not requires w.r.t. the mandatory license attributions.
>  Once again, I maintain that this is not a problem.
>
>
>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>  >>>
>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>  >>  > Equally, there is no need for the lib directory to contain copies of
>  >>  > the AL for every ASF product.
>  >>  >
>  >>
>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>  >>  These are contained in the lib/ directory like many other ASF projects.
>  >>
>  >>
>  >
>  > See the last paragraph of:
>  >
>  > http://www.apache.org/dev/apply-license.html#new
>  >
>  >
>
> "or at least put a pointer in the LICENSE file to the third-party
>  license" - which we in the NOTICE file.
>

But they need to go in the LICENSE file, see:

http://www.apache.org/dev/apply-license.html#new

>  There is not a legal requirement here that it must be in the LICENSE
>  file itself - if so, please point me to the place in the license. This
>  is page is to provide "guidance" (see the first sentence), not be the
>  ultimate authority on what exactly is legally permissible for distributions.
>
>   If you look at many other ASF projects in the incubator and outside,
>  you'll see that this is not an enforced policy - this is simply telling
>  developers one way to get started here.
>
>
>  Dan
>
>  --
>  Dan Diephouse
>  MuleSource
>  http://mulesource.com | http://netzooid.com
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[sebb]

The following do not seem to be test files, nor are they trivially short.
So they should have AL headers please:

core/src/main/resources/abdera.properties.example
dependencies/deps.properties

The top level NOTICE file should not have the 4 line == header.
Also, SVN includes the file
dependencies/i18n/src/main/java/org/apache/abdera/i18n/text/data/CompositionExclusions.txt
which is not AL licensed; IMO it should be attributed in the NOTICE file.

Probably something needs to go in the LICENSE file as well



On 01/04/2008, James M Snell <[EMAIL PROTECTED]> wrote:
> I've added license headers to the build scripts and to the localization
>  file and log4j.properties file. The rest I intend to leave as is.  Is
>  that sufficient?  If so, we'll roll a new build.
>
>
>  - James
>
>  sebb wrote:
>  > On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>  >> In the FAQ I see this: "A file without any degree of creativity in
>  >>  either its literal elements or its structure is not protected by
>  >>  copyright law; therefore, such a file does not require a license header.
>  >
>  > Yes, but:
>  >
>  >>   If in doubt about the extent of the file's creativity, add the license
>  >>  header to the file."
>  >
>  >>  Here's the breakdown that I see from Rat:
>  >>
>  >>  None of the build scripts contain license headers.  Given that the build
>  >>  scripts are everyday, normal maven build scripts, I do believe they
>  >>  qualify under the "a file without any degree of creativity" clause.
>  >
>  > I disagree.
>  >
>  > Note that all Commons poms include the AL header.
>  >
>  >>   ? adapters/pom.xml
>  >>   ? client/pom.xml
>  >>   ? core/pom.xml
>  >>   ? examples/pom.xml
>  >>   ? extensions/pom.xml
>  >>   ? extensions/gdata/pom.xml
>  >>   ? extensions/geo/pom.xml
>  >>   ? extensions/html/pom.xml
>  >>   ? extensions/json/pom.xml
>  >>   ? extensions/main/pom.xml
>  >>   ? extensions/media/pom.xml
>  >>   ? extensions/oauth/pom.xml
>  >>   ? extensions/opensearch/pom.xml
>  >>   ? extensions/serializer/pom.xml
>  >>   ? extensions/sharing/pom.xml
>  >>   ? extensions/wsse/pom.xml
>  >>   ? parser/pom.xml
>  >>   ? security/pom.xml
>  >>   ? server/pom.xml
>  >>   ? spring/pom.xml
>  >>   ? dependencies/deps.properties
>  >>
>  >>  The following file used to provide localization strings may possibly
>  >>  require a license header.
>  >>
>  >>   ? core/src/main/resources/abderamessages.properties
>  >>
>  >>  The following are configuration files used at runtime, the majority of
>  >>  which consist of only a few lines of text and also fall under the above
>  >>  quoted clause.
>  >>
>  >>   ? client/src/main/java/log4j.properties
>  >>   ? core/src/main/resources/abdera.properties.example
>  >>   ?
>  >
>  > These have less content, so the creative aspect is definitely lower.
>  > However, I don't think there's no creativity involved.
>  >
>  >>  
> core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory.example
>  >>   ?
>  >>  
> core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  
> core/src/test/resources/META-INF/services/org.apache.abdera.converter.ConverterProvider
>  >>   ?
>  >>  
> examples/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  
> extensions/complete/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  >>   ?
>  >>  
> extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  
> extensions/complete/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>  >>   ?
>  >>  
> extensions/html/src/main/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>  >>   ?
>  >>  
> extensions/json/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  >>  !?
>  >>  
> extensions/main/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  
> extensions/media/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  
> extensions/opensearch/src/main/resources/META-INF/services/org.apache

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[sebb]

On 01/04/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>
>
>  sebb wrote:
>  > The following do not seem to be test files, nor are they trivially short.
>  > So they should have AL headers please:
>  >
>  > core/src/main/resources/abdera.properties.example
>  > dependencies/deps.properties
>  >
>
>
> Done
>

Thanks

>  > The top level NOTICE file should not have the 4 line == header.
>
>
> Removed
>

Thanks

>  > Also, SVN includes the file
>  > 
> dependencies/i18n/src/main/java/org/apache/abdera/i18n/text/data/CompositionExclusions.txt
>  > which is not AL licensed; IMO it should be attributed in the NOTICE file.
>  >
>
>
> I've just removed the file completely as we actually no longer need it
>  at runtime. In the future, I plan to automate the process of downloading
>  and processing that file during the build process.
>

However the product still depends on the file - I don't think the fact
that the file is not in SVN makes any dfference.

>
>  - James
>
>
>  > Probably something needs to go in the LICENSE file as well
>  >
>  >
>  >
>  > On 01/04/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>  >> I've added license headers to the build scripts and to the localization
>  >>  file and log4j.properties file. The rest I intend to leave as is.  Is
>  >>  that sufficient?  If so, we'll roll a new build.
>  >>
>  >>
>  >>  - James
>  >>
>  >>  sebb wrote:
>  >>  > On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>  >>  >> In the FAQ I see this: "A file without any degree of creativity in
>  >>  >>  either its literal elements or its structure is not protected by
>  >>  >>  copyright law; therefore, such a file does not require a license 
> header.
>  >>  >
>  >>  > Yes, but:
>  >>  >
>  >>  >>   If in doubt about the extent of the file's creativity, add the 
> license
>  >>  >>  header to the file."
>  >>  >
>  >>  >>  Here's the breakdown that I see from Rat:
>  >>  >>
>  >>  >>  None of the build scripts contain license headers.  Given that the 
> build
>  >>  >>  scripts are everyday, normal maven build scripts, I do believe they
>  >>  >>  qualify under the "a file without any degree of creativity" clause.
>  >>  >
>  >>  > I disagree.
>  >>  >
>  >>  > Note that all Commons poms include the AL header.
>  >>  >
>  >>  >>   ? adapters/pom.xml
>  >>  >>   ? client/pom.xml
>  >>  >>   ? core/pom.xml
>  >>  >>   ? examples/pom.xml
>  >>  >>   ? extensions/pom.xml
>  >>  >>   ? extensions/gdata/pom.xml
>  >>  >>   ? extensions/geo/pom.xml
>  >>  >>   ? extensions/html/pom.xml
>  >>  >>   ? extensions/json/pom.xml
>  >>  >>   ? extensions/main/pom.xml
>  >>  >>   ? extensions/media/pom.xml
>  >>  >>   ? extensions/oauth/pom.xml
>  >>  >>   ? extensions/opensearch/pom.xml
>  >>  >>   ? extensions/serializer/pom.xml
>  >>  >>   ? extensions/sharing/pom.xml
>  >>  >>   ? extensions/wsse/pom.xml
>  >>  >>   ? parser/pom.xml
>  >>  >>   ? security/pom.xml
>  >>  >>   ? server/pom.xml
>  >>  >>   ? spring/pom.xml
>  >>  >>   ? dependencies/deps.properties
>  >>  >>
>  >>  >>  The following file used to provide localization strings may possibly
>  >>  >>  require a license header.
>  >>  >>
>  >>  >>   ? core/src/main/resources/abderamessages.properties
>  >>  >>
>  >>  >>  The following are configuration files used at runtime, the majority 
> of
>  >>  >>  which consist of only a few lines of text and also fall under the 
> above
>  >>  >>  quoted clause.
>  >>  >>
>  >>  >>   ? client/src/main/java/log4j.properties
>  >>  >>   ? core/src/main/resources/abdera.properties.example
>  >>  >>   ?
>  >>  >
>  >>  > These have less content, so the creative aspect is definitely lower.
>  >>  > However, I don't think there's no creativity involved.
>  >>  >
>  >>  >>  
> core/src/main/resources/META-INF/services/org.apache.abd

Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

[sebb]

On 02/04/2008, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
>  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>
>
> > Dan Diephouse wrote:
> >
> > > sebb wrote:
> > >
> > > > On 31/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > > >>> -1: The LICENSE files need to either contain copies of the 3rd
> party
> > > > > >>>
> > > > > >>  > licenses, or they need to have a reference to the 3rd party
> licences.
> > > > > >>  > Equally, there is no need for the lib directory to contain
> copies of
> > > > > >>  > the AL for every ASF product.
> > > > > >>  >
> > > > > >>
> > > > > >> Why does the LICENSE file need to have a copy of all the other
> licenses?
> > > > > >>  These are contained in the lib/ directory like many other ASF
> projects.
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > See the last paragraph of:
> > > > > >
> > > > > > http://www.apache.org/dev/apply-license.html#new
> > > > > >
> > > > > >
> > > > >
> > > > > "or at least put a pointer in the LICENSE file to the third-party
> > > > > license" - which we in the NOTICE file.
> > > > >
> > > > >
> > > > >
> > > >
> > > > But they need to go in the LICENSE file, see:
> > > >
> > > > http://www.apache.org/dev/apply-license.html#new
> > > >
> > > >
> > > Did you not read the next paragraph?
> > >
> > > >
> > > > > There is not a legal requirement here that it must be in the LICENSE
> > > > > file itself - if so, please point me to the place in the license.
> This
> > > > > is page is to provide "guidance" (see the first sentence), not be
> the
> > > > > ultimate authority on what exactly is legally permissible for
> distributions.
> > > > >
> > > > >  If you look at many other ASF projects in the incubator and
> outside,
> > > > > you'll see that this is not an enforced policy - this is simply
> telling
> > > > > developers one way to get started here.
> > > > >
> > > > >
> > > >
> > > Can other people please chime in here?
> > >
> > > I have never ever seen this enforced and I do not believe its a
> requirement. Just to summarize - do we need to 1) include all the licenses
> for all our dependencies in a single libary or can we 2) have our top
> LICENSE file which is ASL and then have individual LICENSE files for each
> library in the lib/ directory.
> > >
> > > I think not allowing the second would be a HUGE mistake. It makes it
> much clearer which license applies to which file.
> > >
> > > Dan
> > >
> > >
> > I misspoke. Here's what I meant to ask:
> >
> > Do we need to 1) include all the licenses for all our dependencies in a
> single LICENSE file or can we 2) have our top LICENSE file which is ASL and
> then have individual LICENSE files for each library in the lib/ directory.
> >
>
>  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
> document says you don't have to append 3rd-party licenses to the LICENSE
> file. It does say you should put a pointer to the license files. So, IMO, 2)
> is fine. Other Apache projects do this also.

2) is fine so long as the main LICENSE jar tells users where to find
the other license - i.e. it  has pointers to the other licenses.

>  I do think LICENSE information in jar files should be complete (i.e. jar
> files shouldn't reference information that would only be found in a full
> binary distribution). It looks like your jars are ok, in that respect.
>
>  On the other hand, I believe there must be only one NOTICE file. I see
> multiple NOTICE files in your jars. I haven't downloaded the full
> distribution given the number of changes which seem to be occurring... Hard
> to keep track.
>
>  --kevan

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

Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

[sebb]

On 02/04/2008, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 8:59 PM, sebb <[EMAIL PROTECTED]> wrote:
>  > On 02/04/2008, Kevan Miller <[EMAIL PROTECTED]> wrote:
>  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>
>
> 
>
>
>  >  > > I misspoke. Here's what I meant to ask:
>  >  > >
>  >  > > Do we need to 1) include all the licenses for all our dependencies in 
> a
>  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL 
> and
>  >  > then have individual LICENSE files for each library in the lib/ 
> directory.
>  >  > >
>  >  >
>  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In 
> fact, the
>  >  > document says you don't have to append 3rd-party licenses to the LICENSE
>  >  > file. It does say you should put a pointer to the license files. So, 
> IMO, 2)
>  >  > is fine. Other Apache projects do this also.
>  >
>  >  2) is fine so long as the main LICENSE jar tells users where to find
>  >  the other license - i.e. it  has pointers to the other licenses.
>
>
> AIUI this is not policy
>

My understanding differs, so I think this needs to be resolved and
formally documented.

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

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

Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

[sebb]

On 03/04/2008, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 11:08 PM, sebb <[EMAIL PROTECTED]> wrote:
>  >
>  > On 02/04/2008, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
>  >  > On Wed, Apr 2, 2008 at 8:59 PM, sebb <[EMAIL PROTECTED]> wrote:
>  >  >  > On 02/04/2008, Kevan Miller <[EMAIL PROTECTED]> wrote:
>  >  >  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>  >  >
>  >  >
>  >  > 
>  >  >
>  >  >
>  >  >  >  > > I misspoke. Here's what I meant to ask:
>  >  >  >  > >
>  >  >  >  > > Do we need to 1) include all the licenses for all our 
> dependencies in a
>  >  >  >  > single LICENSE file or can we 2) have our top LICENSE file which 
> is ASL and
>  >  >  >  > then have individual LICENSE files for each library in the lib/ 
> directory.
>  >  >  >  > >
>  >  >  >  >
>  >  >  >  >  I'm not aware of a requirement for having only 1 LICENSE file. 
> In fact, the
>  >  >  >  > document says you don't have to append 3rd-party licenses to the 
> LICENSE
>  >  >  >  > file. It does say you should put a pointer to the license files. 
> So, IMO, 2)
>  >  >  >  > is fine. Other Apache projects do this also.
>  >  >  >
>  >  >  >  2) is fine so long as the main LICENSE jar tells users where to find
>  >  >  >  the other license - i.e. it  has pointers to the other licenses.
>  >  >
>  >  >
>  >  > AIUI this is not policy
>  >  >
>  >
>  >  My understanding differs, so I think this needs to be resolved and
>  >  formally documented.
>
>
> where did you find the rule you based your understanding of policy on?
>

Please see the first message in this thread.

We should be making it as easy as possible for users to find the
relevant licenses.

That's presumably why the main license file is only called LICENSE or
LICENSE.txt, not license.doc or readme.license etc, and the file is
always in the top level directory (or META-INF for jars).

Why should we force users to go looking around the directory structure
to find all the relevant additional licenses?

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

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

Re: [VOTE] Approve the 1.1 release of Tuscany SDO

[sebb]

On 07/04/2008, ant elder <[EMAIL PROTECTED]> wrote:
> Please vote to approve the 1.1 release of Tuscany SDO.
>
>  This is RC4 fixing the issues found in the previous RC2. The release
>  artifacts including source and binary distributions, maven staging
>  repository, and RAT report are at:
>  http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4a

http://people.apache.org/~antelder/tuscany/sdo/1.1-RC4a/

works better ;-)

>  The tag for the release is at:
>  https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1/
>
>  KEYS file is at: https://svn.apache.org/repos/asf/incubator/tuscany/KEYS
>
>  The tuscany-dev list vote thread is at:
>  http://apache.markmail.org/message/xgaeb7klnsfdkrmx
>
>  Many thanks,
>
>
>...ant
>

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

Re: [VOTE] Approve Apache XAP 0.5.0 Release

[sebb]

On 07/04/2008, Bob Buffone <[EMAIL PROTECTED]> wrote:
> Incubator PM,
>
>  The XAP team has taken into account the feedback from sedd and created
>  two distribution files. The first one is a "framework" package that
>  contains everything anyone would need to use XAP.  The second one is
>  geared towards developers that want to modify and develop XAP itself,
>  this is called "codebase". We are now asking the Incubator PM to approve
>  this release so we can distribute it.
>
>  The release candidate has been posted at:
>  http://people.apache.org/~bbuffone/xap-release/0.5.0-incubator/

There is no need for both tar and tar.gz archives; the tar files
should be deleted
(this should really be done by the build file once it has created the gz).

The archives don't have a top-level directory - normally there is a
directory which includes the name of the product and the version, e.g.
the recent Tuscany RC has:

tuscany-sdo-1.1-incubating
tuscany-sdo-1.1-incubating-src

Where is the SVN tag please?

The RAT report shows a lot of files with "unknown" licenses.

Some of these look like they may have been created at the ASF under
the AL 2.0 license, in which case they should have the requisite AL
headers.

>  Please cast your votes:
>
>  [ ] +1 Release is approved
>  [ ] -1 Veto the release (provide specific comments)
>
>  Thank you,
>  Bob (Buffone)
>
>
>  -
>  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]
>
>

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

Re: [VOTE] Release Abdera 0.4.0-incubating Take 7

[sebb]

On 07/04/2008, James M Snell <[EMAIL PROTECTED]> wrote:
> Ok, we've updated the release candidate... please review
>
>  Take 7 of the vote to release Apache Abdera 0.4.0-incubating. The
>  following things have changed:
>  - All necessary files now include ASL headers
>  - LICENSE file now includes pointers to non-ASL licenses and Mark
>  Pilgrim's license
>  - NOTICE files in the jars are much cleaner thanks to the new
>  maven-remote-resource plugin.
>  - Information about a jar's dependencies and their licenses are now
>  included in META-INF/DEPENDENCIES instead of the NOTICE file.
>  - The NOTICE file in the distributions contains all the stuff not in
>  lib/*-LICENSE.txt and provides a pointer to the lib directory for the
>  additional stuff.
>  - Everything is signed

But where can I find the key?

>  Binary distributions:
>
> http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
> http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
>
>  Source distributions:
>
> http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
> http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
>
>  Maven Repository:
> http://people.apache.org/~dandiep/abdera-take7/
>

And where is the SVN tag please?

>  - The Abdera folks
>
>
> -
>  To unsubscribe, e-mail:
> [EMAIL PROTECTED]
>  For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Release Abdera 0.4.0-incubating Take 7

[sebb]

On 07/04/2008, sebb <[EMAIL PROTECTED]> wrote:
> On 07/04/2008, James M Snell <[EMAIL PROTECTED]> wrote:
>  > Ok, we've updated the release candidate... please review
>  >
>  >  Take 7 of the vote to release Apache Abdera 0.4.0-incubating. The
>  >  following things have changed:
>  >  - All necessary files now include ASL headers
>  >  - LICENSE file now includes pointers to non-ASL licenses and Mark
>  >  Pilgrim's license
>  >  - NOTICE files in the jars are much cleaner thanks to the new
>  >  maven-remote-resource plugin.
>  >  - Information about a jar's dependencies and their licenses are now
>  >  included in META-INF/DEPENDENCIES instead of the NOTICE file.
>  >  - The NOTICE file in the distributions contains all the stuff not in
>  >  lib/*-LICENSE.txt and provides a pointer to the lib directory for the
>  >  additional stuff.
>  >  - Everything is signed
>
>
> But where can I find the key?
>
>
>  >  Binary distributions:
>  >
>  > 
> http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
>  > 
> http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
>  >
>  >  Source distributions:
>  >
>  > 
> http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
>  > 
> http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
>  >

Some of the MD5 digest files are missing.

>  >  Maven Repository:
>  > http://people.apache.org/~dandiep/abdera-take7/
>  >
>
>
> And where is the SVN tag please?
>
>
>  >  - The Abdera folks
>  >
>  >
>  > -
>  >  To unsubscribe, e-mail:
>  > [EMAIL PROTECTED]
>  >  For additional commands, e-mail:
>  > [EMAIL PROTECTED]
>  >
>  >
>

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

Re: [VOTE] Release Abdera 0.4.0-incubating Take 7

[sebb]

Runner.runUnprotected(TestMethodRunner.java:81)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at 
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at 
org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at 
org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at 
org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at 
org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at 
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:612)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:334)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:980)
Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
 at [EMAIL PROTECTED]
at 
com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:661)
at 
com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2134)
at 
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2040)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
at 
org.apache.abdera.parser.stax.FOMBuilder.getNextElementToParse(FOMBuilder.java:163)
at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:187)
... 29 more



On 07/04/2008, James M Snell <[EMAIL PROTECTED]> wrote:
> Dan's added the missing md5's.
>
>  - James
>
>  Martijn Dashorst wrote:
>
> > On 4/7/08, James M Snell <[EMAIL PROTECTED]> wrote:
> >
> > >  Not critical. We can generate the md5 files for the zip files and make
> > > those available with the final release.
> > >
> >
> > I tend to disagree here. How can we tell the file hasn't been updated
> > in the mean time? Or that the version Sebb has downloaded is the same
> > as you have published?
> >
> > IMO the .md5 files are an essential part of a release.
> >
> > Martijn
> >
> >
>
> -
>  To unsubscribe, e-mail:
> [EMAIL PROTECTED]
>  For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Release Abdera 0.4.0-incubating Take 7

[sebb]

On 07/04/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> sebb wrote:
>
> > What about
> >  apache-abdera-0.4.0-incubating.pom?
> > Does that not need an MD5?
> >
> >
> >
>  Fixed.
>
> > It would be helpful if the Java requirements were documented in some
> > obvious places such as in BUILDING and on the overview, building and
> > download sections of the website.
> >

It would be helpful to say that the code is only is only intended to
support Java 1.5, if this is indeed the case.

> > Two of the tests fail on IBM Java 6:
> > java version "1.6.0"
> > Java(TM) SE Runtime Environment (build pwi3260-20071123_01)
> > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32
> > jvmwi3260-20071121_15015 (JIT enabled)
> >
> >
> ---
> > Test set: org.apache.abdera.test.parser.stax.FOMTest
> >
> ---
> >
> >
>  Thanks, but I believe tests only pass on Java 5 at the moment due to
> various JDK changes on Java6. Our build server verifies this and none of our
> releases have ever been published without running the full test suite.
>

I forgot to say that the build works fine on Sun Java 1.6.
Unfortunately I don't have access to IBM Java 1.5.

>  Dan
>
>  --
>  Dan Diephouse
>  MuleSource
>  http://mulesource.com | http://netzooid.com
>
> -
>  To unsubscribe, e-mail:
> [EMAIL PROTECTED]
>  For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>

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

UIMA release - lots of missing SVN eol-style property settings

[sebb]

The SVN tag

https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05

has lots of missing SVN eol-style settings. See the file

uimaj-2.2.2-05.sh
in
http://people.apache.org/~sebb/SVNfixes/

This should probably be applied to trunk as well ...

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

Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating

[sebb]

On 10/04/2008, Michael Baessler <[EMAIL PROTECTED]> wrote:
> The Apache UIMA committers ask the Apache Incubator PMC for permission to 
> publish a new bug fix
>  release of Apache UIMA version 2.2.2. This release contains bug fixes of for 
> release version 2.2.1
>  that was published in December 2007. For details about the fixes, please 
> have a look at the release
>  notes.
>
>  We had a vote on uima-dev that resulted in 6 binding +1s
>  (all the committers) and no 0s or -1s.  The vote thread
>  is here:
>  
> http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/200804.mbox/[EMAIL
>  PROTECTED]
>
>  Please review the release candidate here:
>  http://people.apache.org/~mbaessler/uimaj-2.2.2/05/
>
>  There are subdirectories like:
>  /bin - contains the binary distribution files
>  /src - contains the source distribution files
>  /rat - contains the RAT reports (using RAT 0.5.1) with some comments

Not sure I agree that RELEASE_NOTES don't require an AL header.
It would not do any harm to add the header.

Problem building uimaj:

1) javax.activation:activation:jar:1.0.2

<...>

  Path to dependency:
1) org.apache.uima:uimaj-adapter-soap:jar:2.2.2-incubating
2) javax.activation:activation:jar:1.0.2

Should it not be using a more recent version, e.g. 1.1 ?


>  The SVN tag for this release candidate is:
>  
> https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05
>
>  The KEYS file can be found in the SVN at:
>  
> http://svn.apache.org/repos/asf/incubator/uima/uimaj/trunk/uimaj-distr/src/main/readme/KEYS
>

See separate e-mail regarding eol-style settings.

Also, there are 3 .GIF files - the rest are all .gif. Could these be mistakes?

>  Please vote:
>  [ ] +1  Accept to release Apache UIMA 2.2.2
>  [ ] -1  No, because
>
>  Thanks!
>
>  -- Michael
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve the 1.1 release of Tuscany SDO

[sebb]

On 11/04/2008, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
>  On Apr 10, 2008, at 8:42 PM, Luciano Resende wrote:
>
>
> > The files that have this license are listed in the LICENSE [1] file
> > (search for "Apache Tuscany SDO for Java Subcomponents") and I also
> > see a mention of osoa.org in the NOTICE [2].
> >
> > Is this what you were looking for ?
> >
>
>  For files without src license headers, I was referring to files like:
>
>
> ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/impl/model/SDO.mdl
>
> ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/impl/src/test/resources/customer1.xml
>  ...
>
>  Looks like most are test files. I won't quibble much about the test files.
> Easiest (in the long run) to add license headers, IMO. Not sure what to make
> of the SDO.mdl file.
>
>  Yes, I saw the simple osoa.org attribution in the notice file. However, IMO
> that is not sufficient. I think the NOTICE should contain the copyright info
> and I believe the OSOA license requires it. From the OSOA license:
>
>  1.A link or URL to the Artifacts at this location:
> http://www.osoa.org/display/Main/Service+Data+Objects+Specifications
>
>  2.The full text of this copyright notice as shown in the Artifacts.
>
>  I would add both of those to the NOTICE file.
>

The NOTICE file is for attributions only.

The rest goes in the LICENSE file, as has already been done

>  --kevan
>
>
> >
> >
> > [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1-RC3/LICENSE
> > [2]
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1-RC3/NOTICE
> >
> > On Thu, Apr 10, 2008 at 5:28 PM, Kevan Miller <[EMAIL PROTECTED]>
> wrote:
> >
> > > Hi Ant,
> > > Apologies for the slow review. Can you comment on the src files that
> don't
> > > have src license headers?
> > >
> > > I also note that the commonj src files contain the following copyright
> > > statement. I would expect to find it in the base NOTICE file as well as
> any
> > > jar files containing commonj classes...
> > >
> > >
> ===
> > >
> > >
> ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/sdo-api/src/main/java/commonj/sdo/ChangeSummary.java
> > >
> ===
> > >  /**
> > >  * 
> > >  *
> > >  * Service Data Objects
> > >  * Version 2.1.0
> > >  * Licensed Materials
> > >  *
> > >  * (c) Copyright BEA Systems, Inc., International Business Machines
> > > Corporation,
> > >  * Oracle Corporation, Primeton Technologies Ltd., Rogue Wave Software,
> SAP
> > > AG.,
> > >  * Software AG., Sun Microsystems, Sybase Inc., Xcalia, Zend
> Technologies,
> > >  * 2005, 2006. All rights reserved.
> > >  *
> > >  * 
> > >  *
> > >  */
> > >
> > > Everything else looked good to me.
> > >
> > > --kevan
> > >
> > >
> > > On Apr 6, 2008, at 7:10 PM, ant elder wrote:
> > >
> > >
> > >
> > > > Please vote to approve the 1.1 release of Tuscany SDO.
> > > >
> > > > This is RC4 fixing the issues found in the previous RC2. The release
> > > > artifacts including source and binary distributions, maven staging
> > > > repository, and RAT report are at:
> > > >
> http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4a
> > > >
> > > > The tag for the release is at:
> > > >
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1/
> > > >
> > > > KEYS file is at:
> https://svn.apache.org/repos/asf/incubator/tuscany/KEYS
> > > >
> > > > The tuscany-dev list vote thread is at:
> > > > http://apache.markmail.org/message/xgaeb7klnsfdkrmx
> > > >
> > > > Many thanks,
> > > >
> > > > ...ant
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende
> > http://lresende.blogspot.com/
> >
> >
> -
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
>

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

Re: UIMA release - lots of missing SVN eol-style property settings

[sebb]

On 11/04/2008, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> sebb wrote:
>
> >
> > The SVN tag
> >
> >
> https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05
> >
> > has lots of missing SVN eol-style settings. See the file
> >
> > uimaj-2.2.2-05.sh
> > in
> > http://people.apache.org/~sebb/SVNfixes/
> >
> > This should probably be applied to trunk as well ...
> >
> >
> -
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
>
>  Hi Sebb,
>
>  thanks for looking over our release.
>
>  There are a lot of files in your list where not setting
>  the eol-style property is intentional: all our test files.

Which extensions are these?
I can change my script to treat these differently.

>  Setting eol-style:native would make our tests fail on one
>  platform or another as they're usually compared to some
>  expected output, which in turn depends on the exact byte
>  content of the files.
>
>  Unfortunately, there is no (valid) eol-style:none
>  or such that allows us to make this intention explicit.

In which case, the tests may fail to work on OSes with a different
line ending, unless you set the mime-type to binary.

>  For the java code we could set it to native.  We just never
>  felt the need.  Since we need to be careful with our test
>  files, we don't follow the automatic eol-style client setup
>  as recommended.  AFAIK, all UIMA developers use Eclipse
>  for their development, and Eclipse doesn't care about
>  eol style (or not that I noticed anyway).

No it doesn't mind. But SVN does.
If you edit a Java file on Unix and commit to SVN, then someone who
edits it on Mac or Windows and commits to SVN will generate an SVN
diff which shows the whole file has been changed. Makes it very
difficult to see what has actually changed. Likewise for pom.xml etc.

>  I hope you'll agree that it's up to the project to set an
>  eol-style policy.  Our policy is not to set the property
>  unless it's required (e.g., for .sh or .bat files).

Indeed, but see also:

http://www.apache.org/dev/version-control.html#https-svn-config

These conventions are generally used by Java projects, e.g. all of Commons.

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

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

Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating

[sebb]

On 11/04/2008, Michael Baessler <[EMAIL PROTECTED]> wrote:
> sebb wrote:
>  > On 10/04/2008, Michael Baessler <[EMAIL PROTECTED]> wrote:
>  >> The Apache UIMA committers ask the Apache Incubator PMC for permission to 
> publish a new bug fix
>  >>  release of Apache UIMA version 2.2.2. This release contains bug fixes of 
> for release version 2.2.1
>  >>  that was published in December 2007. For details about the fixes, please 
> have a look at the release
>  >>  notes.
>  >>
>  >>  We had a vote on uima-dev that resulted in 6 binding +1s
>  >>  (all the committers) and no 0s or -1s.  The vote thread
>  >>  is here:
>  >>  
> http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/200804.mbox/[EMAIL
>  PROTECTED]
>  >>
>  >>  Please review the release candidate here:
>  >>  http://people.apache.org/~mbaessler/uimaj-2.2.2/05/
>  >>
>  >>  There are subdirectories like:
>  >>  /bin - contains the binary distribution files
>  >>  /src - contains the source distribution files
>  >>  /rat - contains the RAT reports (using RAT 0.5.1) with some comments
>  >
>  > Not sure I agree that RELEASE_NOTES don't require an AL header.
>  > It would not do any harm to add the header.
>  >
>
> Most parts of the RELEASE_NOTES are generated using JIRA, so I thought we can 
> apply the rule

Which rule?

>  mentioned on at http://www.apache.org/legal/src-headers.html. But if you 
> think it would be better to
>  have one, we will add a header next time. Hope that this is not a release 
> stopper.
>

"If in doubt add the AL header"

Not a blocker per se.


>
>  > Problem building uimaj:
>  >
>  > 1) javax.activation:activation:jar:1.0.2
>  >
>  > <...>
>  >
>  >   Path to dependency:
>  > 1) org.apache.uima:uimaj-adapter-soap:jar:2.2.2-incubating
>  > 2) javax.activation:activation:jar:1.0.2
>  >
>  > Should it not be using a more recent version, e.g. 1.1 ?
>  >
>
> When I remember correctly, I think we explicitly use this version because of 
> some license changes
>  for in the latter versions. Maybe some other UIMA committer can explain more 
> detailed.
>

Unfortunately only the POM and metadata are present in the M2 repo for
that version - the jar is not present. I raised a JIRA issue for this:

http://jira.codehaus.org/browse/MAVENUPLOAD-2014

>
>  >
>  >>  The SVN tag for this release candidate is:
>  >>  
> https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05
>  >>
>  >>  The KEYS file can be found in the SVN at:
>  >>  
> http://svn.apache.org/repos/asf/incubator/uima/uimaj/trunk/uimaj-distr/src/main/readme/KEYS
>  >>
>  >
>  > See separate e-mail regarding eol-style settings.
>  >
>  > Also, there are 3 .GIF files - the rest are all .gif. Could these be 
> mistakes?
>
>
> We don't see any issues during our testing of this components (CDE plugin) 
> but we will change it for
>  the next release to lower case.
>

Please!

>  Thanks for checking our release!
>
>
>  -- Michael
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: UIMA release - lots of missing SVN eol-style property settings

[sebb]

On 11/04/2008, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> sebb wrote:
>
> > On 11/04/2008, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> >
> > > sebb wrote:
> > >
> > >
> > > > The SVN tag
> > > >
> > > >
> > > >
> > >
> https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05
> > >
> > > > has lots of missing SVN eol-style settings. See the file
> > > >
> > > > uimaj-2.2.2-05.sh
> > > > in
> > > > http://people.apache.org/~sebb/SVNfixes/
> > > >
> > > > This should probably be applied to trunk as well ...
> > > >
> > > >
> > > >
> > >
> -
> > >
> > > > To unsubscribe, e-mail:
> > > >
> > > [EMAIL PROTECTED]
> > >
> > > > For additional commands, e-mail:
> > > >
> > > [EMAIL PROTECTED]
> > >  Hi Sebb,
> > >
> > >  thanks for looking over our release.
> > >
> > >  There are a lot of files in your list where not setting
> > >  the eol-style property is intentional: all our test files.
> > >
> >
> > Which extensions are these?
> > I can change my script to treat these differently.
> >
>
>  .txt mostly, some .xml.  So I think one needs to handle this
>  on an individual file level.
>

My script can be set up to allow optional values, e.g. at present pdf
files can have a mime-type of either
   'application/octet-stream'
 or
   'application/pdf'

>
> >
> >
> > >  Setting eol-style:native would make our tests fail on one
> > >  platform or another as they're usually compared to some
> > >  expected output, which in turn depends on the exact byte
> > >  content of the files.
> > >
> > >  Unfortunately, there is no (valid) eol-style:none
> > >  or such that allows us to make this intention explicit.
> > >
> >
> > In which case, the tests may fail to work on OSes with a different
> > line ending, unless you set the mime-type to binary.
> >
>
>  I don't understand that remark.
>
>
> >
> >
> > >  For the java code we could set it to native.  We just never
> > >  felt the need.  Since we need to be careful with our test
> > >  files, we don't follow the automatic eol-style client setup
> > >  as recommended.  AFAIK, all UIMA developers use Eclipse
> > >  for their development, and Eclipse doesn't care about
> > >  eol style (or not that I noticed anyway).
> > >
> >
> > No it doesn't mind. But SVN does.
> > If you edit a Java file on Unix and commit to SVN, then someone who
> > edits it on Mac or Windows and commits to SVN will generate an SVN
> > diff which shows the whole file has been changed. Makes it very
> > difficult to see what has actually changed. Likewise for pom.xml etc.
> >
>
>  True.  We try to avoid that ;-).  Although most of us work on windows,
>  we use unix style eol chars for all source code.
>

That probably annoys the Mac Users...

>
> >
> >
> > >  I hope you'll agree that it's up to the project to set an
> > >  eol-style policy.  Our policy is not to set the property
> > >  unless it's required (e.g., for .sh or .bat files).
> > >
> >
> > Indeed, but see also:
> >
> >
> http://www.apache.org/dev/version-control.html#https-svn-config
> >
> > These conventions are generally used by Java projects, e.g. all of
> Commons.
> >
>
>  Yes, and they don't work for us, as I pointed out earlier.
>
>  There are also settings in there that I find rather doubtful.  What
>  is the point of having eol-style for .bat files set to native?

No idea - I would have thought CRLF would be more appropriate.

>
>  So how do you create a distribution?  To my mind, it shouldn't matter
>  if you extracted the code on linux or windows.  The distribution should
>  come out the same and work on both platforms.
>
>
>  --Thilo
>
> -
>  To unsubscribe, e-mail:
> [EMAIL PROTECTED]
>  For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>

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

Re: UIMA release - lots of missing SVN eol-style property settings

[sebb]

On 11/04/2008, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> Daniel Kulp wrote:
>
> > On Friday 11 April 2008, Thilo Goetz wrote:
> >
> > >
> > > > Indeed, but see also:
> > > >
> > > >
> http://www.apache.org/dev/version-control.html#https-svn-config
> > > >
> > > > These conventions are generally used by Java projects, e.g. all of
> > > > Commons.
> > > >
> > > Yes, and they don't work for us, as I pointed out earlier.
> > >
> > > There are also settings in there that I find rather doubtful.  What
> > > is the point of having eol-style for .bat files set to native?
> > >
> >
> > So a unix person can edit it without leaving lines that don't have the
> cr/lf (or have to see ^M marks all over the place).   I do all kinds of
> edits to bat files from my Linux box.  However, if they get committed with
> "mixed" styles, some versions of windows complain loudly when you try to run
> them.
> >
>
>  Ok, I'll take your word for it ;-)
>
>  So how do you handle releases, as I asked in a different mail
>  in this thread?  If you now extract the code on unix, you have
>  .bat files with unix eol chars.  I don't think the windows shell
>  handles that.  Same for .sh files, just the other way around.
>  I'm sure people have a solution for that, but I don't see it.
>

use eol-style: LF for .sh and CRLF for .bat/.cmd

>  [In case this is not clear: we create one distribution with both
>  .sh files and .bat files.  The distro should work correctly on
>  unix and windows.  Just so we're all on the same page.]
>
>  --Thilo
>
>
>
> -
>  To unsubscribe, e-mail:
> [EMAIL PROTECTED]
>  For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating

[sebb]

On 11/04/2008, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> Daniel Kulp wrote:
>
> > On Friday 11 April 2008, Adam Lally wrote:
> >
> > > On Fri, Apr 11, 2008 at 9:10 AM, sebb <[EMAIL PROTECTED]> wrote:
> > >
> > > > On 11/04/2008, Michael Baessler <[EMAIL PROTECTED]> wrote:
> > > >  > sebb wrote:
> > > >  >  > Problem building uimaj:
> > > >  >  >
> > > >  >  > 1) javax.activation:activation:jar:1.0.2
> > > >
> > > >  Unfortunately only the POM and metadata are present in the M2 repo
> > > > for that version - the jar is not present. I raised a JIRA issue for
> > > > this:
> > > >
> > > >  http://jira.codehaus.org/browse/MAVENUPLOAD-2014
> > > >
> > > This is because Sun's license prevents this jar from being
> > > redistributed from the central Maven repository:
> > >
> http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html
> > >
> > > In the build instructions on the UIMA website, we describe how to
> > > obtain the jar yourself and add it to your local Maven repo:
> > >
> http://incubator.apache.org/uima/svn.html#building.command.line
> > >
> >
> > Any particular reason you don't exclude this dependency in you poms and
> then pull in a version that IS available.  Either the 1.1 version from
> java.net:
> > http://download.java.net/maven/1/javax.activation/jars/
> >
> > or the geronimo-specs version available at central:
> > http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> >
> > (In general, I prefer the geronimo specs versions, but it doesn't really
> matter)
> >
> >
>
>  If that works, it'll be vastly preferable to the manual do-hicky
>  we have now.  We'll follow up on uima-dev.
>

FYI: the Geronimo-specs approach works fine for building JMeter.

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

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

Re: maven-repository cont.

[sebb]

On 30/05/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> I personally think we have conflicting rules in the way we handle
>  incubator releases.
>
>
>
>  On the one hand, we require incubator releases to be in a separate
>  repository... for whatever reason (they aren't part of Apache, they
>  aren't stable enough, etc).
>  On the other hand, we allow regular releases
>  of apache artifacts into the central repository with dependencies on
>  incubator artifacts.
>

That's wrong, IMO.

>
>  On many occasions, I've seen this cause people lots of confusion because
>  they update to a new version of an existing artifact and suddenly their
>  build fails to find a dependency. (because the new version is now using
>  an incubating artifact)
>
>
>
>  IMO, things going into the central repository must have their entire
>  transitive hull available in the central repository. Therefore, we must
>  draw one of two conclusions:
>
>
>
>  1.  Incubator releases go into Central

-1

>
>  2.  Regular releases cannot use Incubator artifacts
>

+1

>
>  Since the whole point of the incubator releases is to get some people to
>  use them and prove them out, I say 2 is not really an option.

They can still be tried.

But products should not be released to the repository with a
dependency on incubator releases.

>  If the PMC
>  of a given project tests out an incubator artifact and deems it good
>  enough for a release, then that should be enough

As has been pointed out before, it's not just about code quality.

AIUI, formal ASF releases have some legal protection for the people
who make the release.
This is not the case if the software has not been formally approved as
an ASF release.

>  But let's make it
>  easier for the users by having those dependencies available.
>
>
>
>  --Brian
>
>
>
>

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

Re: maven-repository cont.

[sebb]

On 30/05/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
>  >we've been arguing for years about ease of use verses informed choice
>  >for users of incubator artifacts. not sure that any consensus has been
>  >reached. the current policy just introduces friction (until someone
>  >uploads the artifact to the central repository).
>
>
> So are we considering informed choice to be transitive? The informed
>  choice is a red herring in the case of regular Apache releases depending
>  on the incubator artifacts. If they add the incubator repo to their pom,
>  then most users of their artifact won't even notice it. Only those that
>  are using repo managers or other policies are getting trapped by this.

All the more reason not to allow regular releases to depend on
incubator artefacts.

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

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

Re: maven repository

[sebb]

On 30/05/2008, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> My proposed solution:
>
>  1.  A podling could not issue a release until after IP issues have
>  been cleared by the IPMC.
>  2.  Once a podling's release has been approved (which includes IP
>  approval), they would release to the central maven repository under
>  the group id org.apache.incubator.podlingname, enabling easy adoption
>  by end users.
>
>  Having the word 'incubator' in the group id conforms to repo
>  conventions matching domain names thereby not surprising any
>  end-users, and also explicitly requires the developer editing the pom
>  or ivy config to visually recognize it is _not_ an ASF TLP.  Because
>  they explicitly manually include the word 'incubator', they know its
>  not an official ASF endorsed project.

Assuming that the meaning of "Incubator" is well understood - which
may not be the case.

Also, then a non-incubator project uses the incubator project as a dependency.
This hides the incubator dependency - no thank you!

>  On Fri, May 30, 2008 at 12:16 PM, James Carman
>
> <[EMAIL PROTECTED]> wrote:
>  > So, let's define the goals here:
>  >
>  > 1.  The ASF would like folks who want to use incubating projects to do
>  > so knowingly somehow.  This is somewhat of a CYA tactic so that people
>  > are acknowledging "yes, I understand this is not an 'official' ASF
>  > project, but I'd like to use it anyway."
>  > 2.  Incubating projects would like to be able to get releases in front
>  > of people so that they can build their community.
>  >
>  >
>  >
>  > On Fri, May 30, 2008 at 11:43 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
>  >> Hrm - I thought you had to have IP clearance before you even were
>  >> accepted as a podling.  Or maybe its just that Alan is such a great
>  >> Champion for us, that he helped us along that path before we even
>  >> submitted our proposal ;)
>  >>
>  >> Under this assumption (that IP clearance exists already), it makes
>  >> much more sense to allow the podling to publish approved releases to
>  >> the central repository, but still under an
>  >> org.apache.incubator.projectname group id to maintain
>  >> convention/simplicity.
>  >>
>  >> On Fri, May 30, 2008 at 11:38 AM, James Carman
>  >> <[EMAIL PROTECTED]> wrote:
>  >>> On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <[EMAIL PROTECTED]> wrote:
>   So it seems that a valid question is whether or not publishing to one
>   repository or another indicates an endorsement.
>  >>>
>  >>> Yes, that's certainly a valid question.  Again, that's just my
>  >>> personal point of view.
>  >>>
>  >>> The biggest problem with incubator projects (again my opinion) having
>  >>> releases is the IP clearance.  Perhaps there should be multiple stages
>  >>> of incubation.  The first stage should be where you verify the IP
>  >>> clearance and projects in that stage shouldn't be allowed to do
>  >>> releases at all.  Then they might graduate to the next stage and that
>  >>> would be a "community building" stage where we make sure the project
>  >>> has enough community around it.  These projects should be able to
>  >>> provide incubating releases.
>  >>>
>  >>> -
>  >>> 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]
>  >>
>  >>
>  >
>  > -
>  > 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]
>
>

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

Re: maven repository

[sebb]

On 02/06/2008, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>  > Henri Yandell wrote:
>  >
>  >> Noel J. Bergman wrote:
>  >> > I really do not know why we have to revisit this same topic year after
>  > year
>  >> > after year.  We do not want people to be using any Incubator artifact
>  >> > without explicit knowledge and action, so we do not want them polluting
>  > the
>  >> > standard repository.
>  >
>  >> And as with every year I'll call "BS" :)
>  >
>  >> We do want people to use them, and we do want them on the standard
>  >> repository. They are releases.
>  >
>  > They are *Incubator* releases.  And we do care that people are aware of 
> that
>  > status.  You are free to try to convince the Board and/or Membership to
>  > change the Incubator's mandate, but until then that is the issue.
>
>
> Where is that mandate defined? I see nothing in the original
>  resolution to imply this. To my understanding, treating Incubator
>  podlings differently from Apache subprojects is an invention of the
>  Incubator PMC.
>
>
>  > We want awareness and consent by the end-user, not "hinderance."  This is
>  > analogous to the multiverse repository (or even a PPA repository), vs main
>  > and security in Ubuntu-land.  A user must explicitly choose to allow
>  > artifacts found in repositories other than main and security.  There are
>  > disclaimers associated with the repositories.
>
>
> Not a great analogy though.
>
>  Main = central.
>
>  Project A is in central. It goes to Apache. It can no longer be in
>  central because it is no longer a trusted project until Apache bless
>  it. It's a nuts policy.

It's no longer the same project.

The original project can stay in central.

Once the project has been rebranded as ASF and passed through the
other changes required by the incubation process it can go back into
central as the new project.

>  Project B does not exist and is being created. Anywhere else, it goes
>  into central. At Apache, it has to sit it out in its own sandbox
>  waiting to be considered acceptable.

Which is one reason why the ASF brand is more trusted than some.

>  That's if it is created in the
>  Incubator (or a previously private project that is going public via
>  the Incubator), or if it is in Labs where any releases have to happen
>  outside of Apache as they can't happen inside, but not if it is a new
>  subproject to an existing Apache project.
>
>  We cut off our nose to spite our face.

I don't see it that way.

I see it as protecting the ASF name.

>
>  > FWIW, I agree with James that we would use signing to be more fine-grained,
>  > but didn't want to go into that degree of detail in the earlier discussion.
>  >
>  >> If the nays get their way though - the solution is easy. Release your
>  >> incubating release outside the ASF and get it sync'd from there to the
>  >> central repository.
>  >
>  > Before suggesting that projects intentionally circumvent ASF procedure, you
>  > might want to discuss that with Justin and/or Dave Johnson, since they 
> spent
>  > a lot of time dealing with it for Roller.
>
>
> I seem to remember spending a lot of time on it too - it had nothing
>  to do with this issue but with the fact that it wanted to include an
>  LGPL dependency. The solution was the same, release outside the ASF
>  until it passes the ASF bar - the difference is that this thread
>  claims there is a bar on ASF releases beyond the legal policies and
>  the 3 +1s.
>
>  Hen
>
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: maven-repository cont.

[sebb]

On 02/06/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>  >
>
> > 1.  Incubator releases go into Central
>
>
> +1
>
>  I think having the "incubator" or "incubating" word in the version
>  name brings sufficient awareness to the users.

But Maven does not warn about using incubator versions.

If you are adding a direct dependency on an incubator version, then
the user may understand the significance of the word. Or they may not,
depending on whether they understand the jargon correctly.

But if the dependency is a transitive one, then the user does not get
to know about this (unless they scan the maven log very carefully)

>  While ServiceMix was in incubation, we had sometime a hard time to
>  tell our users that being in incubation has nothing to do with the
>  quality of the code, but rather with IP and mostly community building.
>   Given we had to explain that, it is clear our users were aware that
>  the project was still incubating.
>
>
>  >
>  > 2.  Regular releases cannot use Incubator artifacts
>  >
>  >
>
>
>
>
> --
>  Cheers,
>  Guillaume Nodet
>  
>  Blog: http://gnodet.blogspot.com/
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: maven-repository cont.

[sebb]

On 02/06/2008, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> That's just the thing though:
>
>  At the end of the day, the vast majority of TLP end users could care less if
>  the TLP uses an incubator dependency or not, as long as it is Apache 2.0
>  compatible and easily available (i.e. in the central repo).  They trust the
>  TLP to do their due diligence to ensure the dependency works as expected
>  within the TLP, is tested and has gone through stability sanity checks.  The
>  'incubator' name in the release plus maybe a DISCLAIMER or entry in a README
>  file is good enough.  Anything requiring manual intervention is just a pain
>  to deal with for almost everyone.
>
>  I feel very strongly the incubator releases should be in the main repo for
>  simplicity's sake and to encourage adoption, and that a TLP should be able
>  to use its judgment on whether or not to include an incubator dependency -
>  they know their project best and will support their community best.
>
>  So I'm very much in agreement with 1) allowing incubator releases to go to
>  the central repo and 2) allowing TLPs to decide themselves to include an
>  incubator dependency or not.
>
>  Both Incubator _and_ TLP communities will feel unnecessary burden or
>  hindrance otherwise.
>

Part of the Incubation process is to ensure that there is sufficient
community to maintain the code after incubation.

Not all incubator projects achieve this.

It seems a bad idea to allow artefacts into the main repository where
they can become dependencies unless there is some chance that they
will be maintained.

Yes, there are ASF projects that fall by the wayside too, but that is
not the point.

>  On Mon, Jun 2, 2008 at 10:52 AM, sebb <[EMAIL PROTECTED]> wrote:
>
>
> > On 02/06/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>  > > On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]>
>  > wrote:
>  > >  >
>  > >
>  > > > 1.  Incubator releases go into Central
>  > >
>  > >
>  > > +1
>  > >
>  > >  I think having the "incubator" or "incubating" word in the version
>  > >  name brings sufficient awareness to the users.
>  >
>  > But Maven does not warn about using incubator versions.
>  >
>  > If you are adding a direct dependency on an incubator version, then
>  > the user may understand the significance of the word. Or they may not,
>  > depending on whether they understand the jargon correctly.
>  >
>  > But if the dependency is a transitive one, then the user does not get
>  > to know about this (unless they scan the maven log very carefully)
>  >
>  > >  While ServiceMix was in incubation, we had sometime a hard time to
>  > >  tell our users that being in incubation has nothing to do with the
>  > >  quality of the code, but rather with IP and mostly community building.
>  > >   Given we had to explain that, it is clear our users were aware that
>  > >  the project was still incubating.
>  > >
>  > >
>  > >  >
>  > >  > 2.  Regular releases cannot use Incubator artifacts
>  > >  >
>  > >  >
>  > >
>  > >
>  > >
>  > >
>  > > --
>  > >  Cheers,
>  > >  Guillaume Nodet
>  > >  
>  > >  Blog: http://gnodet.blogspot.com/
>  > >
>  > >  -
>  > >  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > >  For additional commands, e-mail: [EMAIL PROTECTED]
>  > >
>  > >
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>

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

Re: Podling status files

[sebb]

On 10/06/2008, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 9, 2008 at 9:49 PM, Upayavira <[EMAIL PROTECTED]> wrote:
>  > On Mon, 2008-06-09 at 15:23 -0400, Carl Trieloff wrote:
>  >> Martijn Dashorst wrote:
>  >> > I see a trend in podlings not filling in their status files. Shindig
>  >> > and Pig both have the bare template as their status file. Can someone
>  >> > (e.g. the mentors of said projects) update the status files please?
>  >> > I'm hoping for a completely checked status file, but in the very least
>  >> > I'd expect a list of initial committers augmented with the committers
>  >> > that were added after incubation started. A list of actual mentors is
>  >> > also welcomed.
>  >> >
>  >> > Martijn
>  >> >
>  >> >
>  >>
>  >> While we are on the subject, many people also do not do a svn up before
>  >> they update
>  >> their status files, etc and revert other projects files. I will not name
>  >> names, but please make
>  >> sure to not revert other projects status files when you update your 
> project
>  >
>  > Are you sure that's it? SVN won't allow you to commit to a file if there
>  > are commits that you haven't even updated.
>  >
>  > What I think is happening is that folks are committing changes to the
>  > HTML, and then someone does it right - they rebuild the HTML from XML,
>  > and commit the HTML over the top of those changes.
>  >
>  > That isn't the fault of the person who reruns Anakia, that is the fault
>  > of the person who edited the HTML directly.
>
>
> should this be checked in the build script...?
>

How would that work? What can the script check?

Perhaps worth adding a big banner to the start of the HTML files
warning people not to update them directly. This is what has been done
for the Apache site. However people sometimes still miss the warning,
possibly because the warning comes after the AL header.

But worth a try ...

>  - robert
>
>
>  -
>  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]

Website still shows Tuscany

[sebb]

The Incubator web-site still shows Tuscany in the RHS navigation, but
it is now TLP.

Perhaps the link should be removed?

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

Re: Website still shows Tuscany

[sebb]

On 19/06/2008, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Looks like the Tuscany project is not listed on www.apache.org home page
> yet. Is that being handled? Otherwise, what do we have to do to make it
> happen?
>

If no-one else is doing it, I can.

BTW, adding it will change all the pages, so any other missing ones
should be added at the same time...


>  Thanks,
>  Raymond
>
>  --
>  From: "Robert Burrell Donkin" <[EMAIL PROTECTED]>
>  Sent: Thursday, June 19, 2008 10:14 AM
>  To: 
>  Subject: Re: Website still shows Tuscany
>
>
>
> > On Thu, Jun 19, 2008 at 2:57 PM, sebb <[EMAIL PROTECTED]> wrote:
> >
> > > The Incubator web-site still shows Tuscany in the RHS navigation, but
> > > it is now TLP.
> > >
> > > Perhaps the link should be removed?
> > >
> >
> > +1
> >
> > feel free to jump in ;-)
> >
> > - robert
> >
> >
> -
> > 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]
>
>

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

Re: Website still shows Tuscany

[sebb]

On 19/06/2008, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 19, 2008 at 10:18 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
>  > Hi,
>  >
>  > Looks like the Tuscany project is not listed on www.apache.org home page
>  > yet. Is that being handled? Otherwise, what do we have to do to make it
>  > happen?
>
>
> you're a TLP now :-)
>
>  if you don't make it happen, no one else will :-)
>
>  see:
>
>  http://incubator.apache.org/guides/graduation.html#new-project-hand-over
>  http://www.apache.org/dev/
>  http://www.apache.org/dev/infra-site.html
>

The only other missing TLP seems to be Quetz[alcoatl], but that has no
web-site as yet as far as I can tell.

There is another minor fix that needs to be made to the index -
Turbine appears with a space before it; the line break needs to be
removed.

I'm happy to do the edits if you want - but please provide a title
(hover text) for the link.

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

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

Re: TLP migration: Adding Tuscany to http://www.apache.org

[sebb]

On 20/06/2008, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 20, 2008 at 3:59 PM, Simon Laws <[EMAIL PROTECTED]>
>
> wrote:
>
>  > On Fri, Jun 20, 2008 at 11:10 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]
>  > >
>  > wrote:
>  >
>  > > On Fri, Jun 20, 2008 at 2:34 PM, Mike Edwards <
>  > > [EMAIL PROTECTED]> wrote:
>  > >
>  > > > Raymond Feng wrote:
>  > > >
>  > > >> Hi,
>  > > >>
>  > > >> One of the steps for TLP migration is to add Tuscany to
>  > > >> http://www.apache.org. We need to have a title (hover text) for
>  > > Tuscany.
>  > > >> What should we have?
>  > > >>
>  > > >> What about "A Distributed Composite Application Framework Implementing
>  > > >> SCA"?
>  > > >>
>  > > >> Thanks,
>  > > >> Raymond
>  > > >>
>  > > > Raymond,
>  > > >
>  > > > I think that's a little long - how about something shorter and
>  > punchier?
>  > > >
>  > > > "Composite SOA Applications using SCA"
>  > >
>  > > Sounds better.
>  > >
>  > >
>  > > >
>  > > >
>  > > >
>  > > > Yours,  Mike.
>  > > >
>  > > >
>  > > > -
>  > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > > > For additional commands, e-mail: [EMAIL PROTECTED]
>  > > >
>  > > >
>  > >
>  >
>  > I fall in between Mike and Raymond...
>  >
>  > "Composite SOA Application framework using SCA"
>  > or
>  > "Build composite SOA Applications using SCA"
>
>
> +1 for the second one.
>

s/Application/application/

Note that the title can be changed later, but doing so creates a lot
of changed files.

It does not have to be perfect, as not everyone will bother looking at
the hover text...

>
>  >
>  >
>  > As we are not actually delivering composite SOA applications but the means
>  > to build them.
>  >
>  > Simon
>  >
>

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

Re: [VOTE] Apache CouchDB 0.8.0-incubating release

[sebb]

On 20/06/2008, Noah Slater <[EMAIL PROTECTED]> wrote:
> Hello,
>
>  This is the first release under the patronage of the ASF Incubator.
>
>  The community has voted on and approved a proposal to release 
> 0.8.0-incubating.
>
>  Unfortunately, we did not have any votes or feedback from our mentors.
>
>  Pursuant to the Releases section of the Incubation Policy we would now like 
> to
>  request the approval of the Incubator PMC to make the release.
>
>  Release proposal:
>
>   
> http://mail-archives.apache.org/mod_mbox/incubator-couchdb-dev/200806.mbox/[EMAIL
>  PROTECTED]
>

Assuming you are referring to the artefacts at:

http://people.apache.org/~nslater/dist/

1) there is only a tar.gz archive - it is normal to provide zip
archives as well.

2) the md5 and sha hash files have an unusual format; most automatic
hash checkers expect the hashes without embedded spaces.


>  Vote result:
>
>   
> http://mail-archives.apache.org/mod_mbox/incubator-couchdb-dev/200806.mbox/[EMAIL
>  PROTECTED]
>
>  Thanks,
>
>
>  --
>  Noah Slater, http://people.apache.org/~nslater/
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Apache CouchDB 0.8.0-incubating release

[sebb]

On 20/06/2008, Noah Slater <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 20, 2008 at 04:05:47PM +0100, sebb wrote:
>  > Assuming you are referring to the artefacts at:
>  >
>  > http://people.apache.org/~nslater/dist/
>
>
> Yes, the artifacts are the same as in the original proposal.
>
>
>  > 1) there is only a tar.gz archive - it is normal to provide zip
>  > archives as well.
>
>
> I had missed this fact, providing a zip archive will be no problem.
>
>
>  > 2) the md5 and sha hash files have an unusual format; most automatic
>  > hash checkers expect the hashes without embedded spaces.
>
>
> I took the release signing from the following document:
>
>   http://www.apache.org/dev/release-signing.html
>
>  Which states:
>
>   gpg --print-md MD5 [fileName] > [fileName].md5
>   gpg --print-md SHA1 [fileName] > [fileName].sha
>
>  I changed this slightly to:
>
>   gpg --print-md MD5 < [fileName] > [fileName].md5
>   gpg --print-md SHA1 < [fileName] > [fileName].sha
>
>  Are either of these the correct method to use?
>
>  Should md5sum and sha1sum be used instead? If this is the case I am guessing 
> I
>  should propose a correction of the release signing documentation.
>
>  Are these issues significant enough to block the release?

Lack of zip is signifcant, IMO.

Hashes - not critical.

You could just use an editor to remove the spaces.

Or use
gpg --print-md SHA1 < [fileName] | sed -e's/ //g' > [fileName].sha

At least the data is all on one line, unlike some I have seen ...

>
>  Thanks,
>
>  --
>  Noah Slater, http://people.apache.org/~nslater/
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [VOTE] Apache CouchDB 0.8.0-incubating release

[sebb]

On 21/06/2008, Noah Slater <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 21, 2008 at 05:53:21PM +0300, Jukka Zitting wrote:
>  > Personally, I think it's entirely up to the project to decide in which
>  > formats they want to make their releases available. Do you really need
>  > a zip, or are you asking for it just because of convention? Or more
>  > generally (and mostly to couchdb-dev@), are there potential CouchDB
>  > users who would be better served by a release in zip format?
>
>
> From http://incubator.apache.org/guides/releasemanagement.html
>
>   Though utilities for all major compression formats are available for all 
> major
>   platforms, not all platforms support all major compression formats by
>   default. Users find it convenient to download the distribution compressed 
> in a
>   familiar format that is easy to decompress on their platform. It is 
> therefore
>   recommended that each type of distribution is shipped in a variety of 
> compressed
>   formats. Ship at least one of tar.gz, bz or bz2 for UNIX and linux (but note
>   this). Ship zip for windows.
>
>  CouchDB does not currently support Windows, so providing a zip seems 
> redundant.
>

OK, in that case I agree, the Zip is not essential.

>
>  --
>
> Noah Slater, http://people.apache.org/~nslater/
>
>  -
>
> 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]