Hi,
The Apache ManifoldCF community has voted to release our first set of artifacts
and now would like an Incubator vote. Since this is our first release, extra
attention to detail is appreciated.
You can find the artifacts at http://people.apache.org/~kwright/
Thanks,
Grant
Hi Grant,
Is this a source or binary release? How are you guys making the release? Using
Ant or Maven?
Can you guys provide a KEYS and CHANGES.txt file as part of the release
artifacts?
Cheers,
Chris
On Jan 6, 2011, at 5:12 AM, Grant Ingersoll wrote:
Hi,
The Apache ManifoldCF community
Answering on Grant's behalf, the ManifoldCF artifact contains both
source and binary, and the KEYS and CHANGES.txt files are within the
artifact, as seems to be standard Apache practice. You just need to
untar/unzip it.
Karl
On Thu, Jan 6, 2011 at 10:09 AM, Mattmann, Chris A (388J)
Hi Karl,
On Jan 6, 2011, at 7:14 AM, Karl Wright wrote:
Answering on Grant's behalf, the ManifoldCF artifact contains both
source and binary, and the KEYS and CHANGES.txt files are within the
artifact, as seems to be standard Apache practice.
Well I won't say it's standard Apache practice in
I am happy to provide clear-text versions of KEYS and CHANGES.txt if
that is what you require. I've just never seen any other Apache
project that did that.
As for whether there should be separate source and binary
distributions, bear in mind that a binary-only distribution of
ManifoldCF makes
The download size of sources alone is about 32M for each .zip/.tar.gz.
I can't upload CHANGES.txt or KEYS to people.apache.org right now
because of a firewall restriction, so I've attached the files for your
convenience.
Karl
On Thu, Jan 6, 2011 at 11:10 AM, Karl Wright daddy...@gmail.com
On 6 January 2011 16:10, Karl Wright daddy...@gmail.com wrote:
I am happy to provide clear-text versions of KEYS and CHANGES.txt if
that is what you require. I've just never seen any other Apache
project that did that.
All Apache releases require pgp signatures, and the KEYS file must
contain
The key should also be added to a pgp key server.
The key has already been added to the MIT web of trust - I presume
that is what you meant?
AIUI there must be a source distribution; the binary distribution is optional.
The consumer should not be forced to download the binary distribution
On 6 January 2011 13:12, Grant Ingersoll gsing...@apache.org wrote:
Hi,
The Apache ManifoldCF community has voted to release our first set of
artifacts and now would like an Incubator vote. Since this is our first
release, extra attention to detail is appreciated.
You can find the
On 6 January 2011 17:34, Karl Wright daddy...@gmail.com wrote:
The key should also be added to a pgp key server.
The key has already been added to the MIT web of trust - I presume
that is what you meant?
Yes, I meant that the key should be retrievable from a pgp key server
- which it is
On 6 January 2011 18:03, sebb seb...@gmail.com wrote:
On 6 January 2011 13:12, Grant Ingersoll gsing...@apache.org wrote:
Hi,
The Apache ManifoldCF community has voted to release our first set of
artifacts and now would like an Incubator vote. Since this is our first
release, extra
Very well; we will discontinue all binary distributions.
That's not what I said.
You can have a binary distribution if you wish, but there must be a
source distribution.
As I said before, it makes no sense to distribute ManifoldCF binaries
without complete sources. So we could (I suppose)
Also, the NOTICE and LICENSE files don't seem to be quite right.
The NOTICE file is for required notices only; so for example there is
no need to mention other ASF projects.
The LICENSE file references JUnit, which does not need to be
distributed, so is not needed in the LICENSE.
These
The md5 hash file has an odd syntax, which makes it harder to use with
automated checking tools.
apache-manifoldcf-0.1-incubator.zip: A3 3E 0A 9F 58 94 DC 64 F7 B3 ED DB 63
2E
CB EF
The standard format is
a33e0a9f5894dc64f7b3eddb632ecbef
On 6 January 2011 18:23, Karl Wright daddy...@gmail.com wrote:
Very well; we will discontinue all binary distributions.
That's not what I said.
You can have a binary distribution if you wish, but there must be a
source distribution.
As I said before, it makes no sense to distribute
The whole question of ease-of-use is what drove this packaging
arrangement. I was told it was unacceptable to not have a working
example out of the box that could be executed in a single line. Build
and execution Instructions which involve obtaining a couple of dozen
jars from other places do
Hi Karl,
On Jan 6, 2011, at 10:49 AM, Karl Wright wrote:
The whole question of ease-of-use is what drove this packaging
arrangement. I was told it was unacceptable to not have a working
example out of the box that could be executed in a single line. Build
and execution Instructions which
It's unacceptable to not release software according to Apache guidelines.
There's some flexibility in those guidelines (whether to include a binary
release or not, whether to include jar files in a distro or use Maven, etc.),
and then there's not (must include a source release; must have a
On Thu, Jan 6, 2011 at 1:12 PM, Grant Ingersoll gsing...@apache.org wrote:
Hi,
The Apache ManifoldCF community has voted to release our first set of
artifacts and now would like an Incubator vote. Since this is our first
release, extra attention to detail is appreciated.
You can find the
Hi Karl,
It's all the same license. The dependent jars are copied into the
appropriate target locations by the build process. So without the
build, you have one copy of each dependent jar.
Cool, thanks.
It's a huge issue everywhere. Your release will be mirrored around the world
using
Where is the SVN tag for the release?
On 6 January 2011 13:12, Grant Ingersoll gsing...@apache.org wrote:
Hi,
The Apache ManifoldCF community has voted to release our first set of
artifacts and now would like an Incubator vote. Since this is our first
release, extra attention to detail is
Since this is a release candidate, and the release has not yet been
signed off, the tag has not yet been created. There is, however, a
release branch, from which the release candidates get built. When the
sign off occurs, the tag will be created from that branch.
Karl
On Thu, Jan 6, 2011 at
It's quite difficult finding the resources for the Manifold Connector Framework.
The Incubator web-site is at:
http://incubator.apache.org/connectors/
SVN appears to be at:
http://svn.apache.org/repos/asf/incubator/lcf/
The Java package is
org.apache.manifoldcf
So the project currently
On 6 January 2011 20:06, Karl Wright daddy...@gmail.com wrote:
Since this is a release candidate, and the release has not yet been
signed off, the tag has not yet been created. There is, however, a
release branch, from which the release candidates get built. When the
sign off occurs, the tag
The official name of the project has changed repeatedly. The current
official name is ManifoldCF. The community expects to change both
the SVN root and the web-site root upon incubation in any case, which
is why we have not changed either of these yet. A bigger area of
concern is the prefix
Yes, that is the correct branch.
If there is an official Apache tagging strategy, I'm fine with that.
Heretofore I've been using the MetaCarta release tagging strategy,
which was partly gated on a restriction in the MetaCarta svn setup
that prevented tags from being renamed or deleted. Your
The failure to build occurs because the directory it is complaining
about doesn't seem to exist after the zip is unpacked. The directory
is empty at the time of the build. It's not clear whether the problem
is the built zip itself or the way you are unpacking it. I'll need to
look into this
On 6 January 2011 20:29, Karl Wright daddy...@gmail.com wrote:
The official name of the project has changed repeatedly. The current
official name is ManifoldCF. The community expects to change both
the SVN root and the web-site root upon incubation in any case, which
is why we have not
On 6 January 2011 20:41, Karl Wright daddy...@gmail.com wrote:
The failure to build occurs because the directory it is complaining
about doesn't seem to exist after the zip is unpacked. The directory
is empty at the time of the build. It's not clear whether the problem
is the built zip
Just noticed that there are a lot of source files without AL headers.
The RAT tool can detect these for you.
Also, there should normally be a DISCLAIMER file at the top-level of
archives and SVN trees.
It's simpler to have this in a separate file, which can then just be
deleted upon graduation.
Karl Wright wrote:
Very well; we will discontinue all binary distributions.
One major problem will therefore be that we rely on Apache Forrest to
build the documentation pages. Forrest requires Java 1.5. The
availability of documentation in the release will therefore depend on
the
We've been using the RAT tool. The files without headers are in part
Microsoft project files, which cannot have headers added without
breaking them. Also, we build JSON sources, which are licensed with
an accepted JSON license that RAT does not recognize.
I've captured a lot of these exceptions
On 6 January 2011 22:38, Karl Wright daddy...@gmail.com wrote:
We've been using the RAT tool.
In which case it would be helpful to provide the RAT report(s).
The files without headers are in part
Microsoft project files, which cannot have headers added without
breaking them. Also, we build
The .cs files are maintained by Visual Studio and you cannot change
the format if you want them to keep working. Same with the .map file.
I will add them to exclusions for the rat target
The .tld's were taken from Apache Tomcat, but did not include Apache
headers. I am not sure what I should
They were downloaded from the jakarta standard taglibs 1.1.2, from this URL:
http://jakarta.apache.org/site/downloads/downloads_taglibs-standard.cgi
The project was folded into tomcat, but I simply used the tag
libraries from the separately-bundled artifact. It turns out that the
Apache headers
The RAT report after these changes looks good except for two files,
which come from the skins in the site:
[rat:report] Unapproved licenses:
[rat:report]
[rat:report]
C:/wip/mcf-release/release-0.1-branch/site/src/documentation/skins/common/xslt/html/split.xsl
[rat:report]
36 matches
Mail list logo
