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
<henn...@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 <jvan...@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
> >> <vincent.sive...@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-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/SonatypeNexus
> > http://twitter.com/SonatypeM2E
> > ----------------------------------------------------------
> >
> > Simplex sigillum veri. (Simplicity is the seal of truth.)
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
