Re: [VOTE] Approve the release of Shindig Incubator 1.0
On Tue, Apr 28, 2009 at 1:14 PM, Jason van Zyl wrote: > Not mocking, just clarifying that on the aggregate level what is distributed > via the standard Apache mechanism easily has its analog source equivalent > which can be built. Ok, I think we are in general agreement. Are you personally of the opinion that -sources.jar are not adequate as formal ASF releases? I have the opinion it is currently not, but I don't mind seeing a change... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Multiple hosts can share a public IP address. This is often the case for organisations with many hosts on their internal Lan - all the hosts (there could be hundreds) will appear to have the IP address of the internet gateway. But this is getting a bit off-topic. IP is only part of how staging works. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
On Mon, Apr 27, 2009 at 3:14 AM, sebb wrote: > > > OK, it just looked odd to have it at the same level as the README, N & L > files. Agreed, however there's also a lot of people who just ftp the files to the their shared webhost and expect it to work, so to try to make it work for the most basic end-users too, this seemed the best solution. > The file php/README has trivial typo: > > (if your running from svn ... > s/your/you're/ > > but more importantly does not explain how to deploy a release tarball. > I've fixed both these issues. Deploying the release tarbal is as simple as 'copy / upload the files to the webroot', and all the instructions are identical except for one DirectoryRoot, so that's been clarified. Thanks for the feedback! -- Chris
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Niclas Hedhman wrote: On Tue, Apr 28, 2009 at 1:14 PM, Jason van Zyl wrote: Not mocking, just clarifying that on the aggregate level what is distributed via the standard Apache mechanism easily has its analog source equivalent which can be built. Ok, I think we are in general agreement. Are you personally of the opinion that -sources.jar are not adequate as formal ASF releases? I have the opinion it is currently not, but I don't mind seeing a change... There are changes that can be made to the ASF pom to produce the bundles that will meet the requirements. These changes will have a better chance of being made if concerns are brought to the Maven dev team. I just now learned of the month long discussion on legal-discuss via this thread in incubator. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
On 28-Apr-09, at 1:24 AM, Niclas Hedhman wrote: On Tue, Apr 28, 2009 at 1:14 PM, Jason van Zyl wrote: Not mocking, just clarifying that on the aggregate level what is distributed via the standard Apache mechanism easily has its analog source equivalent which can be built. Ok, I think we are in general agreement. Are you personally of the opinion that -sources.jar are not adequate as formal ASF releases? They are not, they do not need to be, and they would be useless for the purpose they serve. As long as the main distributables (like these at http://apache.org/dist/maven/) are accompanied by a source distribution which can be built. I have the opinion it is currently not, but I don't mind seeing a change... Right now the -sources.jars produced work with the default configurations of all the IDEs, if you want to figure out how to change all the IDEs then you're welcome to tackle that. I can tell you the number of users who have asked to be able to build from a - sources.jar over the last 5 years though. That would be zero. What is found at http://apache.org/dist/maven/ I believe is sufficient and adding the requirement of self-building -sources.jar is not required. That's not what their primary purpose is. A standard assembly descriptor that produced a standard Apache release from the top-level of a directory structure would be useful. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
On Tue, Apr 28, 2009 at 10:31 PM, Jason van Zyl wrote: >> Ok, I think we are in general agreement. Are you personally of the >> opinion that -sources.jar are not adequate as formal ASF releases? > > They are not, they do not need to be, and they would be useless for the > purpose they serve. As long as the main distributables (like these at > http://apache.org/dist/maven/) are accompanied by a source distribution > which can be built. Excellent, then we are on the same page after all. I totally agree to the usefulness of the -sources.jars, and that is not something I want to remove... (I obviously need to improve my skills of understanding how my communication can be interpreted and correct it to be less ambiguous). Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Brian just pointed me at the legal-discuss list thread ... Why on earth would you bring up how the releases are made for Maven anywhere but on the Maven list first? No one on our PMC has the faintest idea that you are talking about us. I find this incredibly disrespectful, and cannot understand why the simplest of issues devolve into subterfuge here time after time after time. Take the issue to the heart of the matter. It is quite demonstrable that no one here is actually going to change any of the tooling related to Maven except for the Maven developers, and while everyone bitches and complains the fact of the matter is that people here generally do very little constructively to fix something that is related to Maven. This is a case in point. I can assure that the most effective way to change something with the Maven-based release process is to actually make sure the Maven developers know. Without a heads up, a pointer, you have a pretty good chance that none of us have any idea what you're talking about. As per usual we, the Maven developers, will do everything to fix the problem and we're generally fine with that but I definitely do not like conversations happening that involve us yet no attempt is made to contact us. The legal-discuss list is not something any typical Apache PMC member or committer has the vaguest interest in and is probably not subscribed. Olivier who is a PMC member is asking for a pointer to the discussion because he has no idea what's happening. In the time you've spent talking about the problem -- and not with anyone who could probably fix it -- you probably could have altered the organization wide POM to make the assemblies you desire. On 28-Apr-09, at 8:07 AM, Niclas Hedhman wrote: On Tue, Apr 28, 2009 at 10:31 PM, Jason van Zyl wrote: Ok, I think we are in general agreement. Are you personally of the opinion that -sources.jar are not adequate as formal ASF releases? They are not, they do not need to be, and they would be useless for the purpose they serve. As long as the main distributables (like these at http://apache.org/dist/maven/) are accompanied by a source distribution which can be built. Excellent, then we are on the same page after all. I totally agree to the usefulness of the -sources.jars, and that is not something I want to remove... (I obviously need to improve my skills of understanding how my communication can be interpreted and correct it to be less ambiguous). Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
In the time you've spent talking about the problem -- and not with anyone who could probably fix it -- you probably could have altered the organization wide POM to make the assemblies you desire. Not that I'm aware of the concerns, I've started an additional thread at legal-discuss because at a minimum the currently documented information is insufficient imo and there are additional clarifications required that will dictate how we approach this problem. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Approve the release of FontBox 0.8.0-incubating
Hi, The PDFBox PPMC has voted to release version 0.8.0-incubating of the FontBox library included in PDFBox. The release candidate is available for review at http://people.apache.org/~lehmi/pdfbox/fontbox-0.8.0-incubating/ See the attached original vote messages for more details. Niall posted a RAT report at http://people.apache.org/~niallp/rat-fontbox-0.8.0.txt Please vote to approve this release. This IPMC vote is open for the next 72 hours. [ ] +1 Approve the release of FontBox 0.8.0-incubating [ ] -1 Do not approve this release because... The following three IPMC member votes were cast already on pdfbox-...@. I'm including these also in this vote. +1 Niall Pemberton +1 Jeremias Maerki +1 Jukka Zitting Andreas Lehmkühler --- Begin Message --- Hi, > Please vote on releasing this package as Apache FontBox > 0.8.0-incubating. The vote is open for the next 72 hours and passes if > a majority of at least three +1 PDFBox PPMC votes is reached. Assuming > the vote passes, I will ask the Incubator PMC to approve the release. > >[ ] +1 Release this package as Apache FontBox 0.8.0-incubating >[ ] -1 Do not release this package because... The vote passes as follows: +1 Andreas Lehmkühler +1 Niall Pemberton +1 Daniel Wilson +1 Takashi Komatsubara (no binding vote) +1 Phillip Koch +1 Jeremias Maerki +1 Jukka Zitting Thanks to all for your patience and for your support. I'll ask the IPMC to approve the release. Andreas Lehmkühler --- End Message --- --- Begin Message --- Hi, I have posted my third and hopefully last candidate for the first Apache release of the FontBox library developed within the PDFBox podling. I've fixed the last issue concerning the missing license files in the precompiled jar. The candidate can be found at http://people.apache.org/~lehmi/pdfbox/fontbox-0.8.0-incubating/ See the RELEASE-NOTES.txt file (also included at the end of this message) for details on release contents. The release candidate is a jar archive of the sources in http://svn.apache.org/repos/asf/incubator/pdfbox/fontbox/tags/0.8.0-incubating The MD5 checksum of the fontbox-0.8.0-incubating-src.jar release package is 37 D4 F0 31 B6 CC BD B0 EA BE AF F7 1B 63 41 AE Please vote on releasing this package as Apache FontBox 0.8.0-incubating. The vote is open for the next 72 hours and passes if a majority of at least three +1 PDFBox PPMC votes is reached. Assuming the vote passes, I will ask the Incubator PMC to approve the release. [ ] +1 Release this package as Apache FontBox 0.8.0-incubating [ ] -1 Do not release this package because... With the source release I have also included a pre-compiled jar file. The Maven POM file from the source release is also included so that we can deploy the released jar to the central Maven repository if the release vote passes. Here's my +1. Thanks in advance for your patience with me as manager of this release. Andreas Lehmkühler Release Notes -- Apache FontBox -- Version 0.8.0-incubating Introduction Apache FontBox is an open source Java library for working with PDF fonts. This 0.8.0-incubating release is the first FontBox release made at the Apache Software Foundation. The most notable change since the previous release (0.2.0) is the renaming of all Java packages from org.fontbox to org.apache.fontbox. If you've used FontBox before, you need to update all your client code to use the renamed FontBox packages. The version number of FontBox was upgraded from 0.2.0 to 0.8.0 to better match the version numbering of Apache PDFBox. The -incubating label included in the version number reflects the incubation status of the project. See the disclaimer below for more about incubation. See the Apache PDFBox website at http://incubator.apache.org/pdfbox/ for more information. Release Contents This release consists of a source archive (fontbox-0.8.0-incubating-src.jar). You can build the release with Apache Ant like this: jar xf fontbox-0.8.0-incubating-src.jar cd fontbox-0.8.0 ant The source archive is accompanied by SHA1 and MD5 checksums and a PGP signature that you can use to verify the authenticity of your download. The public key used for the PGP signature can be found at https://svn.apache.org/repos/asf/incubator/pdfbox/KEYS. Disclaimer -- Apache PDFBox is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. See http://incubator.apache.org/projects/pdfbox.html for the current incubation status of the Apache PDFBo
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Calm down, Jason. No one was attacking Maven.
The Apache Software Foundation requires a project (not just an incubator
podling. All projects) to release source in a form that can be used to
recreate the binaries.
For the current state of the Shindig release, this is not possible. Noone
was saying anything else.
For Apache, we release source code that is immediately consumable to users
by downloading an artifact from our servers through www.apache.org/dist and
potentially be able to rebuild the artifact.
In general, this is a tarball / zip of the contents of a Subversion tag.
Everything beyond that is
- optional
- a convenience to our users
This especially goes to
- binary archives (whether these are .jar archives in Java or Binary builds
for a platform in non-Java land)
- source/javadoc in another, better consumable form for IDEs
Supporting these is nice to users, but the required part is the tarball that
I can go into and say (be it ant, maven or make) and get
something that can be used.
This is not the case for Shinig in its current state. Whether this is
acceptable or not to the Incubator PMC members is another question.
Ciao
Henning
On Mon, Apr 27, 2009 at 09:49, Jason van Zyl wrote:
>
> On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
>
> On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
>> wrote:
>>
>> You need to do a checkout of the tag to build it.
>>> The source artifacts provide only java source, no build file.
>>>
>>
>> -1.
>>
>> As others have pointed out, the ASF releases Open SOURCE, not Open
>> Binaries and part of the policy is that the distributed artifact is
>> first and foremost a buildable source tarball. Without it, it is not a
>> release.
>> You may have system requirements ("thou shalt need Maven 2.0.6 or
>> 2.0.9" ) and you should provide full build instructions to produce the
>> projects binary. And if you distribute a binary, it should be the same
>> thing that gets produced by following your instructions.
>>
>> And the above is not really up for debate either. At the end of the
>> day, people will rely on tarballs, checksums (download integrity) and
>> signatures (manipulation integrity), and those are the primary
>> artifacts that Apache Infrastructure will archive and get mirrored
>> around the world.
>> Maven artifacts are really nice to have for Maven users, but is
>> exactly that; "Nice to have".
>>
>> Now, you are free to go banging on Maven's door that their built-in
>> workflow doesn't support the Apache policy very well.
>>
>
> Don't spread FUD like that. You don't have any idea how Maven releases work
> so I'll take a moment and explain it to you.
>
> For a release like Maven we have N modules, where each module produces a
> JAR, and each of those is released. Each JAR carries with it the POM inside
> it, but is in a form which can be automatically utilized by IDE integration
> to automatically be downloaded and integrated with debuggers. All the legal
> bits are in the JARs and legally intact as it were. The blue print to
> actually build that individual JAR is in the JAR by default in Maven. You
> can't just unpack that source JAR and build it and that's for a couple
> reasons: the first is that it's generally useless and the second is that we
> create a source archive of the entire release with all the modules which is
> what we recommend. As with Maven, the tagged sources for the build are
> distributed along with the binaries. This is a matter of setting up a source
> assembly, not hard to do.
>
> That said, show me any non-Maven project that makes individual JARs that
> have the capability of rebuilding themselves. There aren't any here at
> Apache. What gets produced is a overall source archive. And show me anything
> as advanced and useful to developers where grabbing the source JARs for
> debugging is transparent or materializing sources from binary artifact
> coordinates is a button click. Again, nothing does that besides Maven and
> the corresponding IDE integrations. So Maven adheres to any standard for the
> overall release but goes way above and beyond to actually produce something
> far more useful for actually doing work.
>
> So please don't try to explain to people what Maven does when you don't
> actually understand it yourself. What gets released as the N modules is
> complementary to aggregate release which is compliant with Apache. So if
> Shindig doesn't have the overarching source archive that's not hard to add.
> But there is not a single non-Maven build at Apache where a JAR emanating
> from multi-JAR build where that JAR carries with it the information to build
> itself. You are confusing an aggregate release with the releases of the
> individual components which is what Maven users need to consume. We account
> for both for the case where a user grabs the distribution to use, and the
> case where someone is building a Maven plugin (most often in an IDE where
> Maven is not installed) and transparently grabs the d
Re: [PROPOSAL] Apache Click graduation
What's wrong with a dictator for life? Larry Wall is the dictator for life for Perl but that doesn't mean that Perl isn't a meritocracy. Besides, what qualifies as "dictator for life" behavior, anyway? If all the contributors to a project are Sun employees, wouldn't Sun be essentially a dictator for life? And even if Sun doesn't engage in "dictator for life" behavior, what about Oracle, who bought Sun? Will Glass-Husain wrote: > Hi-- > > I went away from email for half a day and got a ton of new messages! > > As a mentor to Click, I can attest that there's a small but active > community involved. It's consistently operated in a transparent and > open manner. There's been no signs of "dictatator for life" behavior. > The founder of the project (Malcolm) is a frequent but not > heavy-handed presence on the lists. Bob Schellink has overseen many > of the details of going through the incubation process. (and Naoki > Takezoe has consistently contributed as well). Contributions and > discussion from a variety of contributors have been welcomed and > accepted. > > I note too that Malcolm has been part of the Velocity community for > some years with frequent feedback, bug reports, and occasional > patches. > > One issue that has come up is that none of the Mentors (myself > included) are users of Click (and hence not contributors). It would > be nice if the PMC and committership were larger but there are > successful projects with small PMCs - Velocity has had 3-5 active PMC > members for some years now while successfully supporting a much large > user base. I agree with Andrus that there's an opportunity to reach > out to people more specifically, but such efforts do not magically > turn contributors into committers. > > We had some discussion about graduation (and the committer size > specifically) on the Click list between the mentors and the community. > Our advice was essentially "go for it". > > Click's an innovative project with a small but open community. The > core members clearly get the Apache Way. And the size of the PMC, > while a concern, has potential to grow over time. I vote +1. > > WILL > > On Fri, Apr 24, 2009 at 6:50 AM, Bertrand Delacretaz > wrote: >> On Fri, Apr 24, 2009 at 3:09 PM, Andrus Adamchik >> wrote: >>> ...the project is fine, but should >>> take a break with graduation to reevaluate its ranks and recruit willing and >>> deserving individuals, and come back here maybe in 2-3 months if this >>> endeavor is successful >> sounds like a plan, +1 to that. >> -Bertrand >> >> - >> 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 > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Henning, I asked some specific questions on the source release over at
legal-discuss, can we consolidate the requirements gathering over there?
Henning Schmiedehausen wrote:
Calm down, Jason. No one was attacking Maven.
The Apache Software Foundation requires a project (not just an incubator
podling. All projects) to release source in a form that can be used to
recreate the binaries.
For the current state of the Shindig release, this is not possible. Noone
was saying anything else.
For Apache, we release source code that is immediately consumable to users
by downloading an artifact from our servers through www.apache.org/dist and
potentially be able to rebuild the artifact.
In general, this is a tarball / zip of the contents of a Subversion tag.
Everything beyond that is
- optional
- a convenience to our users
This especially goes to
- binary archives (whether these are .jar archives in Java or Binary builds
for a platform in non-Java land)
- source/javadoc in another, better consumable form for IDEs
Supporting these is nice to users, but the required part is the tarball that
I can go into and say (be it ant, maven or make) and get
something that can be used.
This is not the case for Shinig in its current state. Whether this is
acceptable or not to the Incubator PMC members is another question.
Ciao
Henning
On Mon, Apr 27, 2009 at 09:49, Jason van Zyl wrote:
On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
wrote:
You need to do a checkout of the tag to build it.
The source artifacts provide only java source, no build file.
-1.
As others have pointed out, the ASF releases Open SOURCE, not Open
Binaries and part of the policy is that the distributed artifact is
first and foremost a buildable source tarball. Without it, it is not a
release.
You may have system requirements ("thou shalt need Maven 2.0.6 or
2.0.9" ) and you should provide full build instructions to produce the
projects binary. And if you distribute a binary, it should be the same
thing that gets produced by following your instructions.
And the above is not really up for debate either. At the end of the
day, people will rely on tarballs, checksums (download integrity) and
signatures (manipulation integrity), and those are the primary
artifacts that Apache Infrastructure will archive and get mirrored
around the world.
Maven artifacts are really nice to have for Maven users, but is
exactly that; "Nice to have".
Now, you are free to go banging on Maven's door that their built-in
workflow doesn't support the Apache policy very well.
Don't spread FUD like that. You don't have any idea how Maven releases work
so I'll take a moment and explain it to you.
For a release like Maven we have N modules, where each module produces a
JAR, and each of those is released. Each JAR carries with it the POM inside
it, but is in a form which can be automatically utilized by IDE integration
to automatically be downloaded and integrated with debuggers. All the legal
bits are in the JARs and legally intact as it were. The blue print to
actually build that individual JAR is in the JAR by default in Maven. You
can't just unpack that source JAR and build it and that's for a couple
reasons: the first is that it's generally useless and the second is that we
create a source archive of the entire release with all the modules which is
what we recommend. As with Maven, the tagged sources for the build are
distributed along with the binaries. This is a matter of setting up a source
assembly, not hard to do.
That said, show me any non-Maven project that makes individual JARs that
have the capability of rebuilding themselves. There aren't any here at
Apache. What gets produced is a overall source archive. And show me anything
as advanced and useful to developers where grabbing the source JARs for
debugging is transparent or materializing sources from binary artifact
coordinates is a button click. Again, nothing does that besides Maven and
the corresponding IDE integrations. So Maven adheres to any standard for the
overall release but goes way above and beyond to actually produce something
far more useful for actually doing work.
So please don't try to explain to people what Maven does when you don't
actually understand it yourself. What gets released as the N modules is
complementary to aggregate release which is compliant with Apache. So if
Shindig doesn't have the overarching source archive that's not hard to add.
But there is not a single non-Maven build at Apache where a JAR emanating
from multi-JAR build where that JAR carries with it the information to build
itself. You are confusing an aggregate release with the releases of the
individual components which is what Maven users need to consume. We account
for both for the case where a user grabs the distribution to use, and the
case where someone is building a Maven plugin (most often in an IDE where
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Just to clarify:
Our initial release deployment actually included a shindig-sources archive,
however because the PHP release *is* the source archive (the source is the
binary since it's still a scripting language), and the jar's already
included the source code too, we thought this would be confusing for the end
users... which archive (php, java, source) to pick when he wants to deploy
shindig, right? Vincent linked to this discussion thread earlier btw.
Also note that Henning's and many other's comments are only applicable to
50% of the release, for php users having a 'source archive' and a 'php
archive' is terribly confusing, especially since the file paths and configs
will be different between the two, and using any type of tools (make, ant,
maven, etc) is not typical at all for php users... We could solve this by
having a 'java-source' archive, but again that wouldn't qualify as what
Henning described as 'a tarbal of the svn tag'.
Now if it's a requirement, and one that I can fully understand, that the
'source archive' should be usable as to rebuild release archives, I'm sure
it's not a lot of effort at all to bring back the source archive option. and
we'll gladly live with the few slightly confused end users if that is what
it takes to get our incubating release done by the book.
-- Chris
On Tue, Apr 28, 2009 at 8:50 PM, Henning Schmiedehausen
wrote:
> Calm down, Jason. No one was attacking Maven.
>
> The Apache Software Foundation requires a project (not just an incubator
> podling. All projects) to release source in a form that can be used to
> recreate the binaries.
>
> For the current state of the Shindig release, this is not possible. Noone
> was saying anything else.
>
> For Apache, we release source code that is immediately consumable to users
> by downloading an artifact from our servers through www.apache.org/distand
> potentially be able to rebuild the artifact.
>
> In general, this is a tarball / zip of the contents of a Subversion tag.
>
> Everything beyond that is
>
> - optional
> - a convenience to our users
>
> This especially goes to
>
> - binary archives (whether these are .jar archives in Java or Binary builds
> for a platform in non-Java land)
> - source/javadoc in another, better consumable form for IDEs
>
> Supporting these is nice to users, but the required part is the tarball
> that
> I can go into and say (be it ant, maven or make) and get
> something that can be used.
>
> This is not the case for Shinig in its current state. Whether this is
> acceptable or not to the Incubator PMC members is another question.
>
>Ciao
> Henning
>
>
>
> On Mon, Apr 27, 2009 at 09:49, Jason van Zyl wrote:
>
> >
> > On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
> >
> > On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
> >> wrote:
> >>
> >> You need to do a checkout of the tag to build it.
> >>> The source artifacts provide only java source, no build file.
> >>>
> >>
> >> -1.
> >>
> >> As others have pointed out, the ASF releases Open SOURCE, not Open
> >> Binaries and part of the policy is that the distributed artifact is
> >> first and foremost a buildable source tarball. Without it, it is not a
> >> release.
> >> You may have system requirements ("thou shalt need Maven 2.0.6 or
> >> 2.0.9" ) and you should provide full build instructions to produce the
> >> projects binary. And if you distribute a binary, it should be the same
> >> thing that gets produced by following your instructions.
> >>
> >> And the above is not really up for debate either. At the end of the
> >> day, people will rely on tarballs, checksums (download integrity) and
> >> signatures (manipulation integrity), and those are the primary
> >> artifacts that Apache Infrastructure will archive and get mirrored
> >> around the world.
> >> Maven artifacts are really nice to have for Maven users, but is
> >> exactly that; "Nice to have".
> >>
> >> Now, you are free to go banging on Maven's door that their built-in
> >> workflow doesn't support the Apache policy very well.
> >>
> >
> > Don't spread FUD like that. You don't have any idea how Maven releases
> work
> > so I'll take a moment and explain it to you.
> >
> > For a release like Maven we have N modules, where each module produces a
> > JAR, and each of those is released. Each JAR carries with it the POM
> inside
> > it, but is in a form which can be automatically utilized by IDE
> integration
> > to automatically be downloaded and integrated with debuggers. All the
> legal
> > bits are in the JARs and legally intact as it were. The blue print to
> > actually build that individual JAR is in the JAR by default in Maven. You
> > can't just unpack that source JAR and build it and that's for a couple
> > reasons: the first is that it's generally useless and the second is that
> we
> > create a source archive of the entire release with all the modules which
> is
> > what we recommend. As with Maven, the tagged sources for the build are
> > distributed alo
Re: [VOTE] Approve the release of Shindig Incubator 1.0
but again that wouldn't qualify as what
Henning described as 'a tarbal of the svn tag'.
Now if it's a requirement, and one that I can fully understand, that the
'source archive' should be usable as to rebuild release archives,
This is what I'm trying to drive some consensus to and get documented.
The requirements should be clarified before we attempt to devise a
solution because the requirements would apply to all Apache releases.
I'm sure
it's not a lot of effort at all to bring back the source archive option. and
we'll gladly live with the few slightly confused end users if that is what
it takes to get our incubating release done by the book.
-- Chris
On Tue, Apr 28, 2009 at 8:50 PM, Henning Schmiedehausen
wrote:
Calm down, Jason. No one was attacking Maven.
The Apache Software Foundation requires a project (not just an incubator
podling. All projects) to release source in a form that can be used to
recreate the binaries.
For the current state of the Shindig release, this is not possible. Noone
was saying anything else.
For Apache, we release source code that is immediately consumable to users
by downloading an artifact from our servers through www.apache.org/distand
potentially be able to rebuild the artifact.
In general, this is a tarball / zip of the contents of a Subversion tag.
Everything beyond that is
- optional
- a convenience to our users
This especially goes to
- binary archives (whether these are .jar archives in Java or Binary builds
for a platform in non-Java land)
- source/javadoc in another, better consumable form for IDEs
Supporting these is nice to users, but the required part is the tarball
that
I can go into and say (be it ant, maven or make) and get
something that can be used.
This is not the case for Shinig in its current state. Whether this is
acceptable or not to the Incubator PMC members is another question.
Ciao
Henning
On Mon, Apr 27, 2009 at 09:49, Jason van Zyl wrote:
On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
wrote:
You need to do a checkout of the tag to build it.
The source artifacts provide only java source, no build file.
-1.
As others have pointed out, the ASF releases Open SOURCE, not Open
Binaries and part of the policy is that the distributed artifact is
first and foremost a buildable source tarball. Without it, it is not a
release.
You may have system requirements ("thou shalt need Maven 2.0.6 or
2.0.9" ) and you should provide full build instructions to produce the
projects binary. And if you distribute a binary, it should be the same
thing that gets produced by following your instructions.
And the above is not really up for debate either. At the end of the
day, people will rely on tarballs, checksums (download integrity) and
signatures (manipulation integrity), and those are the primary
artifacts that Apache Infrastructure will archive and get mirrored
around the world.
Maven artifacts are really nice to have for Maven users, but is
exactly that; "Nice to have".
Now, you are free to go banging on Maven's door that their built-in
workflow doesn't support the Apache policy very well.
Don't spread FUD like that. You don't have any idea how Maven releases
work
so I'll take a moment and explain it to you.
For a release like Maven we have N modules, where each module produces a
JAR, and each of those is released. Each JAR carries with it the POM
inside
it, but is in a form which can be automatically utilized by IDE
integration
to automatically be downloaded and integrated with debuggers. All the
legal
bits are in the JARs and legally intact as it were. The blue print to
actually build that individual JAR is in the JAR by default in Maven. You
can't just unpack that source JAR and build it and that's for a couple
reasons: the first is that it's generally useless and the second is that
we
create a source archive of the entire release with all the modules which
is
what we recommend. As with Maven, the tagged sources for the build are
distributed along with the binaries. This is a matter of setting up a
source
assembly, not hard to do.
That said, show me any non-Maven project that makes individual JARs that
have the capability of rebuilding themselves. There aren't any here at
Apache. What gets produced is a overall source archive. And show me
anything
as advanced and useful to developers where grabbing the source JARs for
debugging is transparent or materializing sources from binary artifact
coordinates is a button click. Again, nothing does that besides Maven and
the corresponding IDE integrations. So Maven adheres to any standard for
the
overall release but goes way above and beyond to actually produce
something
far more useful for actually doing work.
So please don't try
Re: [VOTE] Approve the release of Shindig Incubator 1.0
On 28-Apr-09, at 11:50 AM, Henning Schmiedehausen wrote:
Calm down, Jason. No one was attacking Maven.
I'm not upset, seriously. This is standard fare here, and only
pointing out having any solution which involves Maven might better be
on a path that actually involves Maven developers.
The Apache Software Foundation requires a project (not just an
incubator
podling. All projects) to release source in a form that can be used to
recreate the binaries.
For the current state of the Shindig release, this is not possible.
Noone
was saying anything else.
For Apache, we release source code that is immediately consumable to
users
by downloading an artifact from our servers through www.apache.org/dist
and
potentially be able to rebuild the artifact.
In general, this is a tarball / zip of the contents of a Subversion
tag.
Everything beyond that is
- optional
- a convenience to our users
This especially goes to
- binary archives (whether these are .jar archives in Java or Binary
builds
for a platform in non-Java land)
- source/javadoc in another, better consumable form for IDEs
Supporting these is nice to users, but the required part is the
tarball that
I can go into and say (be it ant, maven or make) and
get
something that can be used.
This is not the case for Shinig in its current state. Whether this is
acceptable or not to the Incubator PMC members is another question.
Ciao
Henning
On Mon, Apr 27, 2009 at 09:49, Jason van Zyl
wrote:
On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
wrote:
You need to do a checkout of the tag to build it.
The source artifacts provide only java source, no build file.
-1.
As others have pointed out, the ASF releases Open SOURCE, not Open
Binaries and part of the policy is that the distributed artifact is
first and foremost a buildable source tarball. Without it, it is
not a
release.
You may have system requirements ("thou shalt need Maven 2.0.6 or
2.0.9" ) and you should provide full build instructions to produce
the
projects binary. And if you distribute a binary, it should be the
same
thing that gets produced by following your instructions.
And the above is not really up for debate either. At the end of the
day, people will rely on tarballs, checksums (download integrity)
and
signatures (manipulation integrity), and those are the primary
artifacts that Apache Infrastructure will archive and get mirrored
around the world.
Maven artifacts are really nice to have for Maven users, but is
exactly that; "Nice to have".
Now, you are free to go banging on Maven's door that their built-in
workflow doesn't support the Apache policy very well.
Don't spread FUD like that. You don't have any idea how Maven
releases work
so I'll take a moment and explain it to you.
For a release like Maven we have N modules, where each module
produces a
JAR, and each of those is released. Each JAR carries with it the
POM inside
it, but is in a form which can be automatically utilized by IDE
integration
to automatically be downloaded and integrated with debuggers. All
the legal
bits are in the JARs and legally intact as it were. The blue print to
actually build that individual JAR is in the JAR by default in
Maven. You
can't just unpack that source JAR and build it and that's for a
couple
reasons: the first is that it's generally useless and the second is
that we
create a source archive of the entire release with all the modules
which is
what we recommend. As with Maven, the tagged sources for the build
are
distributed along with the binaries. This is a matter of setting up
a source
assembly, not hard to do.
That said, show me any non-Maven project that makes individual JARs
that
have the capability of rebuilding themselves. There aren't any here
at
Apache. What gets produced is a overall source archive. And show me
anything
as advanced and useful to developers where grabbing the source JARs
for
debugging is transparent or materializing sources from binary
artifact
coordinates is a button click. Again, nothing does that besides
Maven and
the corresponding IDE integrations. So Maven adheres to any
standard for the
overall release but goes way above and beyond to actually produce
something
far more useful for actually doing work.
So please don't try to explain to people what Maven does when you
don't
actually understand it yourself. What gets released as the N
modules is
complementary to aggregate release which is compliant with Apache.
So if
Shindig doesn't have the overarching source archive that's not hard
to add.
But there is not a single non-Maven build at Apache where a JAR
emanating
from multi-JAR build where that JAR carries with it the information
to build
itself. You are confusing an aggregate release with the releases of
the
individual components which is what Maven users need to consume. We
account
for both f
Re: [PROPOSAL] Apache Click graduation
On Tue, Apr 28, 2009 at 8:56 PM, Thomas Anderson wrote: > What's wrong with a dictator for life? Larry Wall is the dictator for > life for Perl but that doesn't mean that Perl isn't a meritocracy... We aim for high bus factors at Apache, dictator goes against that. > ...Besides, what qualifies as "dictator for life" behavior, anyway? If > all the contributors to a project are Sun employees, wouldn't Sun be > essentially a dictator for life? And even if Sun doesn't engage in > "dictator for life" behavior, what about Oracle, who bought Sun?... Sure - that's why we require committers from at least three independent commercial entities for graduation, and projects are supposed to watch this "rule" over their lifetime as well. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Click graduation
On Wed, Apr 29, 2009 at 2:56 AM, Thomas Anderson wrote: > What's wrong with a dictator for life? Larry Wall is the dictator for > life for Perl but that doesn't mean that Perl isn't a meritocracy. Nothing at all, except... the project doesn't belong here. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
