You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Vincent Siveton <vs...@apache.org> on 2009/04/26 13:15:11 UTC
[VOTE] Approve the release of Shindig Incubator 1.0
Hi,
Please review and vote on approving the first release of Apache
Shindig version 1.0-incubating.
Apache Incubator Shindig is a JavaScript container and implementations
of the backend APIs and proxy required for hosting OpenSocial
applications.
Vote thread:
http://markmail.org/message/4blgcaxyk3iggyfe
Proposed release:
https://repository.apache.org/content/repositories/shindig-staging-016/
Binaries:
https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig/1.0-incubating/
https://repository.apache.org/content/repositories/shindig-staging-017/org/apache/shindig/shindig/1.0-incubating/
SVN Tag:
https://svn.apache.org/repos/asf/incubator/shindig/tags/shindig-project-1.0-incubating/
Vote open for 72 hours.
[ ] +1
[ ] +0
[ ] -1
Thanks,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
I have no idea what that means and how it relates to a ASF release
candidate. Care to elaborate?
Sebb's question is valid: There are two directories with similar named
artifacts.
Ciao
Henning
On Sun, 2009-04-26 at 10:17 -0400, BRIAN FOX wrote:
> >
> > Why are there two binary release directories?
> >
> > The 017 one only seems to have one archive (.bz2) in it, the rest of
> > the files are hashes or signatures (and even some hashes of sigs,
> > which could be safely deleted, as they serve no purpose)
> >
>
> Vincent, if you do multiple mvn builds that should go into the same
> staging folder, just don't close the first one between builds. Nexus
> will see these all and put them together into the same repo. But once
> it's closed, it's closed.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Brian Fox <br...@infinity.nu>.
> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
In 28/04/2009, Brian Fox <br...@infinity.nu> wrote:
> Gotcha, that's unusual i hope since we use ip as part of the uniqueness to
> sort out potentially simultaneous incoming deployments.
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.
>
> Vincent Siveton wrote:
>
> > Hi Brian,
> >
> > 2009/4/26 BRIAN FOX <br...@infinity.nu>:
> >
> >
> > >
> > > > Why are there two binary release directories?
> > > >
> > > > The 017 one only seems to have one archive (.bz2) in it, the rest of
> > > > the files are hashes or signatures (and even some hashes of sigs,
> > > > which could be safely deleted, as they serve no purpose)
> > > >
> > > >
> > > >
> > > Vincent, if you do multiple mvn builds that should go into the same
> staging
> > > folder, just don't close the first one between builds. Nexus will see
> these
> > > all and put them together into the same repo. But once it's closed, it's
> > > closed.
> > >
> > >
> >
> > Nope, just one time but my provider changed my IP during the release
> process.
> >
> > Cheers,
> >
> > Vincent
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail:
> general-help@incubator.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@incubator.apache.org
> For additional commands, e-mail:
> general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Brian Fox <br...@infinity.nu>.
Gotcha, that's unusual i hope since we use ip as part of the uniqueness
to sort out potentially simultaneous incoming deployments.
Vincent Siveton wrote:
> Hi Brian,
>
> 2009/4/26 BRIAN FOX <br...@infinity.nu>:
>
>>> Why are there two binary release directories?
>>>
>>> The 017 one only seems to have one archive (.bz2) in it, the rest of
>>> the files are hashes or signatures (and even some hashes of sigs,
>>> which could be safely deleted, as they serve no purpose)
>>>
>>>
>> Vincent, if you do multiple mvn builds that should go into the same staging
>> folder, just don't close the first one between builds. Nexus will see these
>> all and put them together into the same repo. But once it's closed, it's
>> closed.
>>
>
> Nope, just one time but my provider changed my IP during the release process.
>
> Cheers,
>
> Vincent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Vincent Siveton <vi...@gmail.com>.
Hi Brian,
2009/4/26 BRIAN FOX <br...@infinity.nu>:
>>
>> Why are there two binary release directories?
>>
>> The 017 one only seems to have one archive (.bz2) in it, the rest of
>> the files are hashes or signatures (and even some hashes of sigs,
>> which could be safely deleted, as they serve no purpose)
>>
>
> Vincent, if you do multiple mvn builds that should go into the same staging
> folder, just don't close the first one between builds. Nexus will see these
> all and put them together into the same repo. But once it's closed, it's
> closed.
Nope, just one time but my provider changed my IP during the release process.
Cheers,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by BRIAN FOX <br...@infinity.nu>.
>
> Why are there two binary release directories?
>
> The 017 one only seems to have one archive (.bz2) in it, the rest of
> the files are hashes or signatures (and even some hashes of sigs,
> which could be safely deleted, as they serve no purpose)
>
Vincent, if you do multiple mvn builds that should go into the same
staging folder, just don't close the first one between builds. Nexus
will see these all and put them together into the same repo. But once
it's closed, it's closed.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, Apr 26, 2009 at 10:40 PM, Vincent Siveton
<vi...@gmail.com> wrote:
> 2009/4/26 sebb <se...@gmail.com>:
>> Where are the source archive files?
>
> The community decided to not provide full source archived files.
Then you have no release and this whole vote thread is void.
See http://www.apache.org/dev/release.html#what
"The Apache Software Foundation produces open source software. All
releases are in the form of the source materials needed to make
changes to the software being released."
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Vincent Siveton <vi...@gmail.com>.
2009/4/26 sebb <se...@gmail.com>:
> I think there are some problems with the archives.
>
> The *java* archive contains a .war file which has 42 jars in the
> WEB-INF/lib directory.
>
> Some 17 or so of these are ASF files, but the rest are 3rd party files.
> None of the 3rd party files are mentioned in the META-INF NOTICE and
> LICENSE files.
> Yes, there is a DEPENDENCIES file, but AFAIK, that information should
> be in the N & L files. The NOTICE file does not mention the crypto
> dependencies.
These files are generated by Maven, and it seems we need to create
them by hand.
Could you help us by providing all list of 3rd party files?
> There is a COPYING file in the java archive top-level directory which
> is just a copy of AL 2.0; it could be deleted. I'm not sure the
> COMMITTERS file belongs in archives.
>
> The *php* archive also has the COPYING and COMMITTERS files. The
> NOTICE file says 2008.
> Not sure the .htaccess file belongs in it.
>
> Test files are not normally included in binary archives; they are
> usually only present in the source archive. This is where having
> separate source and binary archives even for interpreted code would
> help. Also the source archive should contain files such as pom.xml
> which are only needed for building the binary archive.
Thanks for this
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
On 26/04/2009, sebb <se...@gmail.com> wrote:
> I think there are some problems with the archives.
>
> The *java* archive contains a .war file which has 42 jars in the
> WEB-INF/lib directory.
>
> Some 17 or so of these are ASF files, but the rest are 3rd party files.
> None of the 3rd party files are mentioned in the META-INF NOTICE and
> LICENSE files.
> Yes, there is a DEPENDENCIES file, but AFAIK, that information should
> be in the N & L files. The NOTICE file does not mention the crypto
> dependencies.
Forgot to mention - there are also missing dependencies from the top
level N+L files.
I would expected each level of archive to contain N&L files that
relate to the content.
> There is a COPYING file in the java archive top-level directory which
> is just a copy of AL 2.0; it could be deleted. I'm not sure the
> COMMITTERS file belongs in archives.
>
> The *php* archive also has the COPYING and COMMITTERS files. The
> NOTICE file says 2008.
> Not sure the .htaccess file belongs in it.
>
> Test files are not normally included in binary archives; they are
> usually only present in the source archive. This is where having
> separate source and binary archives even for interpreted code would
> help. Also the source archive should contain files such as pom.xml
> which are only needed for building the binary archive.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Chris Chabot <ch...@google.com>.
On Mon, Apr 27, 2009 at 3:14 AM, sebb <se...@gmail.com> 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
Posted by sebb <se...@gmail.com>.
On 27/04/2009, Chris Chabot <ch...@google.com> wrote:
> On Mon, Apr 27, 2009 at 12:36 AM, sebb <se...@gmail.com> wrote:
>
> >
> > The *php* archive also has the COPYING and COMMITTERS files. The
> > NOTICE file says 2008.
>
>
>
> Those files are from the same source as the java archive, so when the new
> archives are created they will be updated too.
>
>
>
> >
> > Not sure the .htaccess file belongs in it.
> >
>
>
>
> I am ... sure that it belongs that is :)
OK, it just looked odd to have it at the same level as the README, N & L files.
> The java and php versions of shindig share the same javascript code
> ('features' in the project's terms) which depends on urls in the
> /gadgets/ifr format and not /path/to/some/phpfile.php, mod_rewrite is the
> only way to do that consistently, and a .htaccess in the web root is the
> only way to make that work out of the box.
>
> Thanks for the feedback so far guys,
Just noticed java/README:
Welcome to Apache Shindig ${project.version} !
Also there's no description of how to deploy the archive.
==
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.
>
> -- Chris
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Chris Chabot <ch...@google.com>.
On Mon, Apr 27, 2009 at 12:36 AM, sebb <se...@gmail.com> wrote:
>
> The *php* archive also has the COPYING and COMMITTERS files. The
> NOTICE file says 2008.
Those files are from the same source as the java archive, so when the new
archives are created they will be updated too.
>
> Not sure the .htaccess file belongs in it.
>
I am ... sure that it belongs that is :)
The java and php versions of shindig share the same javascript code
('features' in the project's terms) which depends on urls in the
/gadgets/ifr format and not /path/to/some/phpfile.php, mod_rewrite is the
only way to do that consistently, and a .htaccess in the web root is the
only way to make that work out of the box.
Thanks for the feedback so far guys,
-- Chris
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
I think there are some problems with the archives.
The *java* archive contains a .war file which has 42 jars in the
WEB-INF/lib directory.
Some 17 or so of these are ASF files, but the rest are 3rd party files.
None of the 3rd party files are mentioned in the META-INF NOTICE and
LICENSE files.
Yes, there is a DEPENDENCIES file, but AFAIK, that information should
be in the N & L files. The NOTICE file does not mention the crypto
dependencies.
There is a COPYING file in the java archive top-level directory which
is just a copy of AL 2.0; it could be deleted. I'm not sure the
COMMITTERS file belongs in archives.
The *php* archive also has the COPYING and COMMITTERS files. The
NOTICE file says 2008.
Not sure the .htaccess file belongs in it.
Test files are not normally included in binary archives; they are
usually only present in the source archive. This is where having
separate source and binary archives even for interpreted code would
help. Also the source archive should contain files such as pom.xml
which are only needed for building the binary archive.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
On 26/04/2009, sebb <se...@gmail.com> wrote:
> On 26/04/2009, Vincent Siveton <vi...@gmail.com> wrote:
> > 2009/4/26 sebb <se...@gmail.com>:
> >
> > > On 26/04/2009, Vincent Siveton <vi...@gmail.com> wrote:
> > >> 2009/4/26 Henning Schmiedehausen <he...@schmiedehausen.org>:
> > >>
> > >> > Sorry, to bother you here, but I don't believe, that you have a choice.
> > >>
> > >>
> > >> We provided both java and php source code.
> > >>
> > >> Java artifacts are given via the Maven repo as usual, ie [1]
> > >
> > > This is not usual; all other releases have
> > >
> > > Source archive(s) + sig + hash
> > > Binary archive(s) + sig + hash
> > > also
> > > Maven repo files (if applicable)
> >
> >
> > Each java artifact has the pom, bin, sources, javadoc with sig+hash.
> > https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig-common/1.0-incubating/
> > https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig-server/1.0-incubating/
> >
> > What is missing?
>
>
> Maybe nothing - so far I have only looked at the URLs for the binaries
> you provided earlier.
>
> I did not know these other URLs and files existed until now.
>
I've only had time to do a brief check, but there are some problems,
e.g. some web.*.xml files in the server war are not in the server
source jar. I don't know if this is the only such problem.
The contents of the source jars should all be in the SVN tag.
And all source files in binary archives should also exist in the
source archive and SVN.
Most SVN files should also be in one or more of the source archives
(there may be a few files that only belong in SVN, e.g. the DOAP file
if it exists does not really belong in a release artifact.)
> >
> > Vincent
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
On 26/04/2009, Vincent Siveton <vi...@gmail.com> wrote:
> 2009/4/26 sebb <se...@gmail.com>:
>
> > On 26/04/2009, Vincent Siveton <vi...@gmail.com> wrote:
> >> 2009/4/26 Henning Schmiedehausen <he...@schmiedehausen.org>:
> >>
> >> > Sorry, to bother you here, but I don't believe, that you have a choice.
> >>
> >>
> >> We provided both java and php source code.
> >>
> >> Java artifacts are given via the Maven repo as usual, ie [1]
> >
> > This is not usual; all other releases have
> >
> > Source archive(s) + sig + hash
> > Binary archive(s) + sig + hash
> > also
> > Maven repo files (if applicable)
>
>
> Each java artifact has the pom, bin, sources, javadoc with sig+hash.
> https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig-common/1.0-incubating/
> https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig-server/1.0-incubating/
>
> What is missing?
Maybe nothing - so far I have only looked at the URLs for the binaries
you provided earlier.
I did not know these other URLs and files existed until now.
>
> Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Vincent Siveton <vi...@gmail.com>.
2009/4/26 sebb <se...@gmail.com>:
> On 26/04/2009, Vincent Siveton <vi...@gmail.com> wrote:
>> 2009/4/26 Henning Schmiedehausen <he...@schmiedehausen.org>:
>>
>> > Sorry, to bother you here, but I don't believe, that you have a choice.
>>
>>
>> We provided both java and php source code.
>>
>> Java artifacts are given via the Maven repo as usual, ie [1]
>
> This is not usual; all other releases have
>
> Source archive(s) + sig + hash
> Binary archive(s) + sig + hash
> also
> Maven repo files (if applicable)
Each java artifact has the pom, bin, sources, javadoc with sig+hash.
https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig-common/1.0-incubating/
https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig-server/1.0-incubating/
What is missing?
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
On 26/04/2009, Vincent Siveton <vi...@gmail.com> wrote:
> 2009/4/26 Henning Schmiedehausen <he...@schmiedehausen.org>:
>
> > Sorry, to bother you here, but I don't believe, that you have a choice.
>
>
> We provided both java and php source code.
>
> Java artifacts are given via the Maven repo as usual, ie [1]
This is not usual; all other releases have
Source archive(s) + sig + hash
Binary archive(s) + sig + hash
also
Maven repo files (if applicable)
> For PHP, according Chris [2], the binary is the source and visa versa.
>
> Is it more clear?
>
> Cheers,
>
> Vincent
>
> [1] http://tinyurl.com/cejp5x
> [2] http://shindig-dev.markmail.org/message/phzlo76px5r2glyg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Brian Fox <br...@infinity.nu>.
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 <build-command> (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 <jv...@sonatype.com> wrote:
>
>
>> On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
>>
>> On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
>>
>>> <vi...@gmail.com> 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 dependencies -- the
>> individual JARs from a Maven release -- so they can build their project.
>>
>> We do the necessary and the nice to have. More working developers actually
>> care about the nice to have.
>>
>>
>> They won't be
>>
>>> surprised, and IIRC there has been a lot of discussion over there to
>>> make it happen.
>>>
>>>
>>> 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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Jason van Zyl <jv...@sonatype.com>.
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 <build-command> (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 <jv...@sonatype.com>
> wrote:
>
>>
>> On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
>>
>> On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
>>> <vi...@gmail.com> 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 dependencies --
>> the
>> individual JARs from a Maven release -- so they can build their
>> project.
>>
>> We do the necessary and the nice to have. More working developers
>> actually
>> care about the nice to have.
>>
>>
>> They won't be
>>> surprised, and IIRC there has been a lot of discussion over there to
>>> make it happen.
>>>
>>>
>>> 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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Brian Fox <br...@infinity.nu>.
> 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
> <he...@apache.org>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 <build-command> (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 <jv...@sonatype.com> wrote:
>>
>>
>>> On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
>>>
>>> On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
>>>
>>>> <vi...@gmail.com> 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 dependencies -- the
>>> individual JARs from a Maven release -- so they can build their project.
>>>
>>> We do the necessary and the nice to have. More working developers
>>>
>> actually
>>
>>> care about the nice to have.
>>>
>>>
>>> They won't be
>>>
>>>> surprised, and IIRC there has been a lot of discussion over there to
>>>> make it happen.
>>>>
>>>>
>>>> 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-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Chris Chabot <ch...@google.com>.
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
<he...@apache.org>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 <build-command> (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 <jv...@sonatype.com> wrote:
>
> >
> > On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
> >
> > On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
> >> <vi...@gmail.com> 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 dependencies -- the
> > individual JARs from a Maven release -- so they can build their project.
> >
> > We do the necessary and the nice to have. More working developers
> actually
> > care about the nice to have.
> >
> >
> > They won't be
> >> surprised, and IIRC there has been a lot of discussion over there to
> >> make it happen.
> >>
> >>
> >> 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-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Henning Schmiedehausen <he...@apache.org>.
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 <build-command> (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 <jv...@sonatype.com> wrote:
>
> On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
>
> On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
>> <vi...@gmail.com> 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 dependencies -- the
> individual JARs from a Maven release -- so they can build their project.
>
> We do the necessary and the nice to have. More working developers actually
> care about the nice to have.
>
>
> They won't be
>> surprised, and IIRC there has been a lot of discussion over there to
>> make it happen.
>>
>>
>> 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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Brian Fox <br...@infinity.nu>.
Niclas Hedhman wrote:
> On Tue, Apr 28, 2009 at 1:14 PM, Jason van Zyl <jv...@sonatype.com> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Brian Fox <br...@infinity.nu>.
>
> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Jason van Zyl <jv...@sonatype.com>.
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
> <jv...@sonatype.com> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Apr 28, 2009 at 10:31 PM, Jason van Zyl <jv...@sonatype.com> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Jason van Zyl <jv...@sonatype.com>.
On 28-Apr-09, at 1:24 AM, Niclas Hedhman wrote:
> On Tue, Apr 28, 2009 at 1:14 PM, Jason van Zyl
> <jv...@sonatype.com> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Apr 28, 2009 at 1:14 PM, Jason van Zyl <jv...@sonatype.com> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Jason van Zyl <jv...@sonatype.com>.
On 27-Apr-09, at 9:25 PM, Niclas Hedhman wrote:
> On Tue, Apr 28, 2009 at 12:49 AM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>
>> 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.
>
> Dude, chill! Mocking me isn't appreciated.
>
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. That this is not a problem with
Maven and there's nothing anyone needs to address with the Maven
folks. It would not be possible in 2.x to guess the structure so an
assembly is your option right now. My point to the constituent pieces
is that I've not seen many uses cases where someone grabs the source
outside an IDE. All the IDEs support grabbing Maven source JARs. But
if deemed useful a simple plugin could be made to grab a source JAR
and materialize a project by making a structure that would build. It's
all in the source JAR. The structure of a source JAR if altered to
have an enclosing directory so that when it unpacked it looked like a
normal Maven project with a POM would render it useless to debuggers
is the point I was trying to make. That it's not necessary or useful
that every JAR expand to a buildable project provided primary source
distribution of the entire set of JARs is buildable.
> I have been around the Maven block long enough (and you know that),
> use it more than I would like to admit, and at another OSS project we
> use the Release plugin as our *only* published output. The topic is on
> legal-discuss, and perhaps it should continue there only...
>
>> 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,
>
>> We do the necessary and the nice to have. More working developers
>> actually
>> care about the nice to have.
>
> Well, in my understanding of the ASF release spirit, we releases
> Sources that are buildable by those who downloads them, with certain
> legal requirements. The policy specifies indirectly that "whatever the
> source download is" it produces (with instructions! and possibly a set
> of system requirements) the binary, which may be provided as
> convenience. Maven "by default" (yes, I am aware of assemblies)
> doesn't do this and projects have to do a bit of work. That is what I
> have said before and until we sort out on legal-discuss it will remain
> my position on the topic. If you mean that I need Eclipse to "build"
> any source releases of Maven-based projects, you are testing *my*
> patience...
>
> For the record, Yes, I am a bit wary of lavish (either too complex to
> set up, requiring a GUI or too expensive for an average user) system
> requirements for builds and/or usage of Apache projects.
>
>
> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Apr 28, 2009 at 12:49 AM, Jason van Zyl <jv...@sonatype.com> wrote:
> 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.
Dude, chill! Mocking me isn't appreciated.
I have been around the Maven block long enough (and you know that),
use it more than I would like to admit, and at another OSS project we
use the Release plugin as our *only* published output. The topic is on
legal-discuss, and perhaps it should continue there only...
> 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,
> We do the necessary and the nice to have. More working developers actually
> care about the nice to have.
Well, in my understanding of the ASF release spirit, we releases
Sources that are buildable by those who downloads them, with certain
legal requirements. The policy specifies indirectly that "whatever the
source download is" it produces (with instructions! and possibly a set
of system requirements) the binary, which may be provided as
convenience. Maven "by default" (yes, I am aware of assemblies)
doesn't do this and projects have to do a bit of work. That is what I
have said before and until we sort out on legal-discuss it will remain
my position on the topic. If you mean that I need Eclipse to "build"
any source releases of Maven-based projects, you are testing *my*
patience...
For the record, Yes, I am a bit wary of lavish (either too complex to
set up, requiring a GUI or too expensive for an average user) system
requirements for builds and/or usage of Apache projects.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Jason van Zyl <jv...@sonatype.com>.
On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
> On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
> <vi...@gmail.com> 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 dependencies -- the individual
JARs from a Maven release -- so they can build their project.
We do the necessary and the nice to have. More working developers
actually care about the nice to have.
> They won't be
> surprised, and IIRC there has been a lot of discussion over there to
> make it happen.
>
>
> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
<vi...@gmail.com> 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. They won't be
surprised, and IIRC there has been a lot of discussion over there to
make it happen.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
On 26/04/2009, Vincent Siveton <vi...@gmail.com> wrote:
> 2009/4/26 Jukka Zitting <ju...@gmail.com>:
> > Hi,
> >
> > On Sun, Apr 26, 2009 at 11:20 PM, Vincent Siveton
> > <vi...@gmail.com> wrote:
> >> 2009/4/26 Jukka Zitting <ju...@gmail.com>:
> >>> How do I build this to produce the binaries you've deployed?
> >>
> >> mvn install -Prelease
> >
> > I can't, as there's no pom.xml in the source archive.
>
>
> You need to do a checkout of the tag to build it.
> The source artifacts provide only java source, no build file.
Again, that is not usual; source archives should include all the
source needed to build it.
> Cheers,
>
>
> Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Vincent Siveton <vi...@gmail.com>.
2009/4/26 Jukka Zitting <ju...@gmail.com>:
> Hi,
>
> On Sun, Apr 26, 2009 at 11:20 PM, Vincent Siveton
> <vi...@gmail.com> wrote:
>> 2009/4/26 Jukka Zitting <ju...@gmail.com>:
>>> How do I build this to produce the binaries you've deployed?
>>
>> mvn install -Prelease
>
> I can't, as there's no pom.xml in the source archive.
You need to do a checkout of the tag to build it.
The source artifacts provide only java source, no build file.
Cheers,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, Apr 26, 2009 at 11:20 PM, Vincent Siveton
<vi...@gmail.com> wrote:
> 2009/4/26 Jukka Zitting <ju...@gmail.com>:
>> How do I build this to produce the binaries you've deployed?
>
> mvn install -Prelease
I can't, as there's no pom.xml in the source archive.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Vincent Siveton <vi...@gmail.com>.
Hi,
2009/4/26 Jukka Zitting <ju...@gmail.com>:
> Hi,
>
> On Sun, Apr 26, 2009 at 11:06 PM, Vincent Siveton
> <vi...@gmail.com> wrote:
>> We provided both java and php source code.
>>
>> Java artifacts are given via the Maven repo as usual, ie [1]
>> [...]
>> [1] http://tinyurl.com/cejp5x
>
> How do I build this to produce the binaries you've deployed?
mvn install -Prelease
FYI here are our release process
http://incubator.apache.org/shindig/community/releasing.html
Cheers,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, Apr 26, 2009 at 11:06 PM, Vincent Siveton
<vi...@gmail.com> wrote:
> We provided both java and php source code.
>
> Java artifacts are given via the Maven repo as usual, ie [1]
> [...]
> [1] http://tinyurl.com/cejp5x
How do I build this to produce the binaries you've deployed?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Vincent Siveton <vi...@gmail.com>.
2009/4/26 Henning Schmiedehausen <he...@schmiedehausen.org>:
> Sorry, to bother you here, but I don't believe, that you have a choice.
We provided both java and php source code.
Java artifacts are given via the Maven repo as usual, ie [1]
For PHP, according Chris [2], the binary is the source and visa versa.
Is it more clear?
Cheers,
Vincent
[1] http://tinyurl.com/cejp5x
[2] http://shindig-dev.markmail.org/message/phzlo76px5r2glyg
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
Sorry, to bother you here, but I don't believe, that you have a choice.
An Apache releases consists of source code. Binary artifacts are just an
"add on bonus". I can ping Roy on that subject if you beg to
differ. ;-)
However, as (at least for the Java part), all source code is available
as source jars, this is good enough for me. It might not be good enough
for others, though.
Ciao
Henning
On Sun, 2009-04-26 at 16:40 -0400, Vincent Siveton wrote:
> Hi Sebb,
>
> 2009/4/26 sebb <se...@gmail.com>:
> > Why are there two binary release directories?
>
> My provider changed my IP during the release process, but no maven errors.
>
> > The 017 one only seems to have one archive (.bz2) in it, the rest of
> > the files are hashes or signatures (and even some hashes of sigs,
> > which could be safely deleted, as they serve no purpose)
> >
> > Where are the source archive files?
>
> The community decided to not provide full source archived files.
>
> We decided that user could do a check out to have the full source code
> (both java and php). BTW each Java artifact has a source jar.
>
> >> SVN Tag:
> >> https://svn.apache.org/repos/asf/incubator/shindig/tags/shindig-project-1.0-incubating/
> >
> > BTW, the NOTICE file thinks it is still 2008.
>
> Right!
>
> Vincent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Vincent Siveton <vi...@gmail.com>.
Hi Sebb,
2009/4/26 sebb <se...@gmail.com>:
> Why are there two binary release directories?
My provider changed my IP during the release process, but no maven errors.
> The 017 one only seems to have one archive (.bz2) in it, the rest of
> the files are hashes or signatures (and even some hashes of sigs,
> which could be safely deleted, as they serve no purpose)
>
> Where are the source archive files?
The community decided to not provide full source archived files.
We decided that user could do a check out to have the full source code
(both java and php). BTW each Java artifact has a source jar.
>> SVN Tag:
>> https://svn.apache.org/repos/asf/incubator/shindig/tags/shindig-project-1.0-incubating/
>
> BTW, the NOTICE file thinks it is still 2008.
Right!
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by Vincent Siveton <vi...@gmail.com>.
2009/4/26 sebb <se...@gmail.com>:
> The RAT report on SVN reports 476 files with unknown licences.
> Some of these may be test files (though even these should have AL if
> poss), but there seem to be quite a few files that should have the AL
> header, e.g. pom.xml etc.
Ok I saw the pom.xml in features and some js files
For java, the legal files are verified during the build by the
rat-maven-plugin and tools-maven-plugin (see parent pom)
See for instance this report:
http://incubator.apache.org/shindig/shindig-1.0.x/shindig-parent/shindig-common/rat-report.html
FYI the PHP code includes Zend and PHPUnit codes (BSD)
> Several source files in SVN have the executable flag set; this is not
> a release blocker but should really be corrected:
Thanks for this, we will fix it.
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
On 26/04/2009, sebb <se...@gmail.com> wrote:
> On 26/04/2009, Vincent Siveton <vs...@apache.org> wrote:
> > Hi,
> >
> > Please review and vote on approving the first release of Apache
> > Shindig version 1.0-incubating.
> > Apache Incubator Shindig is a JavaScript container and implementations
> > of the backend APIs and proxy required for hosting OpenSocial
> > applications.
> >
> > Vote thread:
> > http://markmail.org/message/4blgcaxyk3iggyfe
> >
> > Proposed release:
> > https://repository.apache.org/content/repositories/shindig-staging-016/
> > Binaries:
> > https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig/1.0-incubating/
> > https://repository.apache.org/content/repositories/shindig-staging-017/org/apache/shindig/shindig/1.0-incubating/
>
>
> Why are there two binary release directories?
>
> The 017 one only seems to have one archive (.bz2) in it, the rest of
> the files are hashes or signatures (and even some hashes of sigs,
> which could be safely deleted, as they serve no purpose)
>
> Where are the source archive files?
>
>
> > SVN Tag:
> > https://svn.apache.org/repos/asf/incubator/shindig/tags/shindig-project-1.0-incubating/
>
>
> BTW, the NOTICE file thinks it is still 2008.
>
The RAT report on SVN reports 476 files with unknown licences.
Some of these may be test files (though even these should have AL if
poss), but there seem to be quite a few files that should have the AL
header, e.g. pom.xml etc.
Several source files in SVN have the executable flag set; this is not
a release blocker but should really be corrected:
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/activity.js
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/collection.js
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/container.js
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/datarequest.js
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/dataresponse.js
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/environment.js
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/opensocial.js
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/person.js
svn pd svn:executable
features/src/main/javascript/features/opensocial-reference/responseitem.js
svn pd svn:executable javascript/container/sample5.html
svn pd svn:executable javascript/container/sample6.html
svn pd svn:executable javascript/container/sample7.html
svn pd svn:executable php/test/misc/testRest.php
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Thanks,
> >
> > Vincent
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Posted by sebb <se...@gmail.com>.
On 26/04/2009, Vincent Siveton <vs...@apache.org> wrote:
> Hi,
>
> Please review and vote on approving the first release of Apache
> Shindig version 1.0-incubating.
> Apache Incubator Shindig is a JavaScript container and implementations
> of the backend APIs and proxy required for hosting OpenSocial
> applications.
>
> Vote thread:
> http://markmail.org/message/4blgcaxyk3iggyfe
>
> Proposed release:
> https://repository.apache.org/content/repositories/shindig-staging-016/
> Binaries:
> https://repository.apache.org/content/repositories/shindig-staging-016/org/apache/shindig/shindig/1.0-incubating/
> https://repository.apache.org/content/repositories/shindig-staging-017/org/apache/shindig/shindig/1.0-incubating/
Why are there two binary release directories?
The 017 one only seems to have one archive (.bz2) in it, the rest of
the files are hashes or signatures (and even some hashes of sigs,
which could be safely deleted, as they serve no purpose)
Where are the source archive files?
> SVN Tag:
> https://svn.apache.org/repos/asf/incubator/shindig/tags/shindig-project-1.0-incubating/
BTW, the NOTICE file thinks it is still 2008.
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Vincent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org