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]
C:/wip/mcf-release
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
On 6 January 2011 23:53, Karl Wright wrote:
> 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 i
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 do
On 6 January 2011 22:38, Karl Wright 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 JSON sources, w
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
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
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.
On 6 January 2011 20:41, Karl Wright 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 itself or the way yo
On 6 January 2011 20:29, Karl Wright 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 changed either of
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 more
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 propo
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 us
On 6 January 2011 20:06, Karl Wright 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 will be create
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 uses
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 3:
Where is the SVN tag for the release?
On 6 January 2011 13:12, Grant Ingersoll 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.
>
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
>
On Thu, Jan 6, 2011 at 1:12 PM, Grant Ingersoll 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 artifacts at
> 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
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 whic
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 not
On 6 January 2011 18:23, Karl Wright 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 Manifold
>
> 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 *
>
> 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.
>
>> 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 s
On 6 January 2011 18:03, sebb wrote:
> On 6 January 2011 13:12, Grant Ingersoll 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 apprecia
On 6 January 2011 17:34, Karl Wright 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 (just checked).
On 6 January 2011 13:12, Grant Ingersoll 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 artifacts at http:/
> 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 distrib
On 6 January 2011 16:10, Karl Wright 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 necessa
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 wrote:
> I am happy to
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 lit
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
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)
wrote:
> Hi
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 communi
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
-
37 matches
Mail list logo
