You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2009/03/31 06:22:43 UTC
Releases
Guys,
Let's try this again...
Apache is about Open Source. There is a huge emphasis on the "Source"
part, to the degree that there are times when some projects don't even
release binaries at all, only the sources.
So the "Released Artifact" are the sources and the build system (incl
instructions) required to produce a useful binary. The binary output
is NOT included in the primary release artifact, but is "generated" by
it. So; SVN --(packaging)--> Source Release --(build+package)-->
Binary Release
So, on these grounds, I am not going to recommend the PMC to approve
the release.
Here is what is needed;
1. Create a target in the Ant build, that zips/tars up the SVN
sources, not including the .svn directories. Sources in this instance
means everything that is needed to build Pivot, except for "System
Requirements" (listed in the README/BUILD). Ant and JDK is typical
System Requirements, as are any external jar files that are only
required for the build, BUT some people (like myself) prefer to have
them part of the source dist.
2. That zip/tar IS your primary release artifact;
apache-pivot-1.1-incubating.tar.gz
3. Using that zip/tar, execute another Ant target (for instance
'install') which compiles, jars and sticks everything into a
'generated/apache-pivot-1.1-incubating' directory.
4. The same target could also create a zip/tar of the
'generated/apache-pivot-1.1-incubating', and that IS your
supplementary binary release.
5. Ask a couple of community members to sanity check the binary
release, and make sure it is useful.
6. Let people worry about Maven distro separately. And perhaps later
migrate to Maven build system, if you find Maven support important and
want to simplify such process.
7. Finally, the release artifacts needs checksums and signatures. The
PGP signature should be uploaded to at least one or two public PGP
servers, such as pgp.mit.edu, and eventually be cross-signed in person
with other people in Apache (for instance at an ApacheCon event). That
creates the Apache Web of Trust. This may seem like a lot of work for
nothing, but there are some people who takes this aspect of Apache
very, very seriously. See
http://www.apache.org/dev/release-signing.html for more details.
Apache level FAQ on releases are here; http://www.apache.org/dev/release.html
Note that additional requirements are imposed by the Incubator, and is
found embedded in
http://incubator.apache.org/guides/releasemanagement.html.
Hope this helps.
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
Re: Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Apr 2, 2009 at 11:29 AM, Todd Volkert <tv...@gmail.com> wrote:
> stax-api-1.0.jar should be in wtk/lib/ and should prevent that error
> in JDK 1.5 -- if it's not, you've got a stale copy of the tarball.
> Can you check the checksums on the tarball you've got against the ones
> posted online to make sure that you have the most recent copy?
>
> Otherwise, I'll run the build against JDK1.5 tomorrow morning to see
> what's wrong.
Yes, stax-api inclusion helped.
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
Re: Releases
Posted by Todd Volkert <tv...@gmail.com>.
stax-api-1.0.jar should be in wtk/lib/ and should prevent that error
in JDK 1.5 -- if it's not, you've got a stale copy of the tarball.
Can you check the checksums on the tarball you've got against the ones
posted online to make sure that you have the most recent copy?
Otherwise, I'll run the build against JDK1.5 tomorrow morning to see
what's wrong.
Thanks,
-T
On Wed, Apr 1, 2009 at 11:19 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> One more thing; The BUILD says JDK 1.5. I think that JDK 1.6 is needed since
>
> [javac] /Users/niclas/Downloads/apache-pivot-1.1-incubating/src/pivot/wtkx/WTKXSerializer.java:31:
> package javax.xml.stream does not exist
> [javac] import javax.xml.stream.XMLInputFactory;
>
> is not available in my JDK 1.5 libraries (but is in 1.6).
>
>
> 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
>
Re: Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
One more thing; The BUILD says JDK 1.5. I think that JDK 1.6 is needed since
[javac] /Users/niclas/Downloads/apache-pivot-1.1-incubating/src/pivot/wtkx/WTKXSerializer.java:31:
package javax.xml.stream does not exist
[javac] import javax.xml.stream.XMLInputFactory;
is not available in my JDK 1.5 libraries (but is in 1.6).
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
Re: Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Apr 2, 2009 at 12:52 AM, Todd Volkert <tv...@gmail.com> wrote:
>>> * plugin.jar
>>> This jar is part of Sun's JRE (but doesn't live in the CLASSPATH by
>>> default) and allows us to build against the LiveConnect API
>>> (netscape.javascript.*). We use this in pivot-wtk.jar to provide our
>>> component-DOM interaction API.
>>
>> This is too generic name for me to locate with Google. Can you provide
>> me with URL to the source of this.
>
> The functionality is described at
> http://java.sun.com/javase/6/webnotes/6u10/plugin2/liveconnect/, and
> it looks like it's licensed under
> http://developers.sun.com/license/berkeley_license.html
Looks to me that it is part of the JDK/JRE, and is Ok as system
requirement, even if the license is something else.
So, it seems that only the Jfree stuff is an issue. I'll look at this
again right now.
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
Re: Releases
Posted by Todd Volkert <tv...@gmail.com>.
>> * plugin.jar
>> This jar is part of Sun's JRE (but doesn't live in the CLASSPATH by
>> default) and allows us to build against the LiveConnect API
>> (netscape.javascript.*). We use this in pivot-wtk.jar to provide our
>> component-DOM interaction API.
>
> This is too generic name for me to locate with Google. Can you provide
> me with URL to the source of this.
The functionality is described at
http://java.sun.com/javase/6/webnotes/6u10/plugin2/liveconnect/, and
it looks like it's licensed under
http://developers.sun.com/license/berkeley_license.html
Re: Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 1, 2009 at 8:27 PM, Todd Volkert <tv...@gmail.com> wrote:
> * servlet-api.jar:
> We build against this to produce pivot-web.server.jar, which contains
> our server portion of our "web queries" API. Specifically, it
> contains a few servlets, which require that J2EE jar to build.
No problems. You can even include the version available from the
Tomcat (or is it Geronimo) projects as source code, modify it to your
hearts desire.
> * junit.jar
> We've written a few JUnit unit tests in the core-test package, and we
> plan to write more in other packages. This jar allows us to build our
> tests, which end up as pivot-core.test.jar, etc. The resulting jars
> are not part of our API - just our test cases. JUnit is licensed
> under the "common public license":
> http://junit.sourceforge.net/cpl-v10.html
CPL is classified as Category B. That means that depending on its
binary, and including a pre-built binary in the distribution is
kosher. Deriving anything from its sources is not.
> * plugin.jar
> This jar is part of Sun's JRE (but doesn't live in the CLASSPATH by
> default) and allows us to build against the LiveConnect API
> (netscape.javascript.*). We use this in pivot-wtk.jar to provide our
> component-DOM interaction API.
This is too generic name for me to locate with Google. Can you provide
me with URL to the source of this.
> * stax-api.jar
> We build pivot-wtk.jar against this to provide our WTKXSerializer
> (which translates our XML bean representation into objects). It's
> homepage is http://stax.codehaus.org/, and it looks like it's Apache
> 2.0, so we should be good.
Yes, it is good, and you are good.
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
Re: Releases
Posted by Greg Brown <gk...@mac.com>.
>You're preaching to the choir here - I voted in favor of versioned jars :)
Blah blah blah. :-)
As we discussed, we'll distribute this way when we support Maven. This way, everybody wins.
Re: Releases
Posted by Todd Volkert <tv...@gmail.com>.
> pivot-charts will therefor not be allowed to be released from Apache.
> Sorry. The release will not be approved with it.
Bummer :-(
> I think you have 3 options;
>
> 1. Rebuild the same functionality using a library that has a
> permissible license.
>
> 2. Stick that component at SourceForge or similar.
>
> 3. Create an SPI in Pivot, to which one can plug in an underlying
> implementation. You will need a bit of 'bridge code', which you stick
> in SF.
Charts have been Greg's domain - Greg, thoughts?
> Yeah, it is a big topic, and understanding the many nuances can be quite a ride.
So like you said: let's take our dependencies one by one. Here are
the ones I can think of now:
* servlet-api.jar:
We build against this to produce pivot-web.server.jar, which contains
our server portion of our "web queries" API. Specifically, it
contains a few servlets, which require that J2EE jar to build.
* junit.jar
We've written a few JUnit unit tests in the core-test package, and we
plan to write more in other packages. This jar allows us to build our
tests, which end up as pivot-core.test.jar, etc. The resulting jars
are not part of our API - just our test cases. JUnit is licensed
under the "common public license":
http://junit.sourceforge.net/cpl-v10.html
* plugin.jar
This jar is part of Sun's JRE (but doesn't live in the CLASSPATH by
default) and allows us to build against the LiveConnect API
(netscape.javascript.*). We use this in pivot-wtk.jar to provide our
component-DOM interaction API.
* stax-api.jar
We build pivot-wtk.jar against this to provide our WTKXSerializer
(which translates our XML bean representation into objects). It's
homepage is http://stax.codehaus.org/, and it looks like it's Apache
2.0, so we should be good.
>> Some context might help shed some light on why this continues to be an
>> issue. We build "pivot-foo.jar" internally for day to day builds and
>> wiki deployment, and only "pivot-foo-incubating.jar" as part of the
>> "dist" target, which creates a lot more than just the jars. And as
>> per our vote a few days back, version doesn't appear anywhere in the
>> jar files.
>
> Ok, but I still think that is a mistake. I have too many times come
> across work in companies using, let's say, struts.jar and having no
> clue what version it is, or even if it is an official build or
> modified in-house. Short-term small gain, over long-term serious
> problems.
You're preaching to the choir here - I voted in favor of versioned jars :)
Re: Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 1, 2009 at 12:39 PM, Todd Volkert <tv...@gmail.com> wrote:
>> So, let's start; What is JFree and how is it used?
>
> The JFree jars (jfreechart and jcommon) constitute a Java2D charting
> library. Our "pivot-charts-1.1-incubating.jar" is built against them
> and provides a Pivot charting component that allows you to present a
> JFree chart within the Pivot component hierarchy. Thus, our charting
> package is designed around the JFree API and won't build without the
> JFree jar files.
pivot-charts will therefor not be allowed to be released from Apache.
Sorry. The release will not be approved with it.
I think you have 3 options;
1. Rebuild the same functionality using a library that has a
permissible license.
2. Stick that component at SourceForge or similar.
3. Create an SPI in Pivot, to which one can plug in an underlying
implementation. You will need a bit of 'bridge code', which you stick
in SF.
You are allowed to refer to such external bits from your website at
Apache, but no direct download links and such. It must be clear to
user it is "something outside ASF".
> Tomorrow morning (I'm heading to bed now), I'll read up on category A,
> category B, category X, and System Requirements, and if those terms
> are official Apache classifications so I can be better educated in
> this area.
Yeah, it is a big topic, and understanding the many nuances can be quite a ride.
>> NOTICE contains a single paragraph about each source and binary
>> dependency used in the project, and where that dependency originate
>> from. It would also contain the VMware Copyright notice, and any other
>> individual's work that has been forked. So, license, origin, copyright
>> holder and year (if available) in one paragraph, followed by a blank
>> line.
>
> Ok. Does this include binary dependencies that are not included in
> the release artifact but are described in BUILD? (for instance, what
> if we decide *not* to include the JFree jars in our tarball - do we
> still include a paragraph in NOTICE for JFree?)
No, but it seems that your understanding of System Requirement is
slightly mis-aligned with my understanding of it. FSF's interpretation
of the LGPL is that Pivot is Derivative Works, and that triggers a
some clauses that are not compatible with ASF principles.
>> What surprises me is that you are struggling a lot with this. Isn't
>> just "version" a property in the Ant file at the top, which would be
>> appended to filenames?
>
> Some context might help shed some light on why this continues to be an
> issue. We build "pivot-foo.jar" internally for day to day builds and
> wiki deployment, and only "pivot-foo-incubating.jar" as part of the
> "dist" target, which creates a lot more than just the jars. And as
> per our vote a few days back, version doesn't appear anywhere in the
> jar files.
Ok, but I still think that is a mistake. I have too many times come
across work in companies using, let's say, struts.jar and having no
clue what version it is, or even if it is an official build or
modified in-house. Short-term small gain, over long-term serious
problems.
>> Well, I guess it is a balance. I am of the opinion that 2 separate
>> tarballs is preferred, but that could be due to my slow connection to
>> the Internet. If you have a single tarball, then the most important
>> bit is that it can be built to the same state as the in-house built
>> one.
>
> The way it's structured right now, it's a single tarball, and within
> that tarball is a src directory from which you can produce the same
> tarball.
>
> I prefer the single tarball approach, but if I might be alone in that
> preference, perhaps I should put this to a vote on this list.
Ok. I have no formal ojections to whatever the conclusion is.
But don't forget to toss the jfree stuff out before pushing for a new
release candidate. That is a show-stopper.
(If you think it is anal, yeah, I agree. But go look through the mail
archives for Harmony project, and you are once again glad that this is
simple in comparison. ;-) )
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
Re: Releases
Posted by Greg Brown <gk...@mac.com>.
>I prefer the single tarball approach, but if I might be alone in that
>preference, perhaps I should put this to a vote on this list.
I also prefer the single-artifact approach.
Re: Releases
Posted by Todd Volkert <tv...@gmail.com>.
> So, let's start; What is JFree and how is it used?
The JFree jars (jfreechart and jcommon) constitute a Java2D charting
library. Our "pivot-charts-1.1-incubating.jar" is built against them
and provides a Pivot charting component that allows you to present a
JFree chart within the Pivot component hierarchy. Thus, our charting
package is designed around the JFree API and won't build without the
JFree jar files.
Tomorrow morning (I'm heading to bed now), I'll read up on category A,
category B, category X, and System Requirements, and if those terms
are official Apache classifications so I can be better educated in
this area.
> NOTICE contains a single paragraph about each source and binary
> dependency used in the project, and where that dependency originate
> from. It would also contain the VMware Copyright notice, and any other
> individual's work that has been forked. So, license, origin, copyright
> holder and year (if available) in one paragraph, followed by a blank
> line.
Ok. Does this include binary dependencies that are not included in
the release artifact but are described in BUILD? (for instance, what
if we decide *not* to include the JFree jars in our tarball - do we
still include a paragraph in NOTICE for JFree?)
> What surprises me is that you are struggling a lot with this. Isn't
> just "version" a property in the Ant file at the top, which would be
> appended to filenames?
Some context might help shed some light on why this continues to be an
issue. We build "pivot-foo.jar" internally for day to day builds and
wiki deployment, and only "pivot-foo-incubating.jar" as part of the
"dist" target, which creates a lot more than just the jars. And as
per our vote a few days back, version doesn't appear anywhere in the
jar files.
> For this release, I will not make a fuzz over it, and I will try to
> help out 'hands on' with the Ant script later.
I'm not struggling with it technically - I just didn't want to
re-arrange the build file if I didn't have to. It's obviously an
issue, so I'll fix it :)
> Is 5. and 6. same question?
Yes - I should proof-read my emails before hitting send :)
> Well, I guess it is a balance. I am of the opinion that 2 separate
> tarballs is preferred, but that could be due to my slow connection to
> the Internet. If you have a single tarball, then the most important
> bit is that it can be built to the same state as the in-house built
> one.
The way it's structured right now, it's a single tarball, and within
that tarball is a src directory from which you can produce the same
tarball.
I prefer the single tarball approach, but if I might be alone in that
preference, perhaps I should put this to a vote on this list.
Re: Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 1, 2009 at 7:28 AM, Todd Volkert <tv...@gmail.com> wrote:
> 1) I tried but couldn't find definitive info on whether we can
> redistribute binary dependencies (System Requirements). I had
> originally assumed that we could NOT, so I removed all such jar files
> from the released source, and thus, as you saw, the build fails unless
> you download those jars yourself and put them on your classpath. I
> would love to include them, as it would make the user who's trying to
> build from source much happier. As you say, "some people (like
> myself) prefer to have them part of the source dist". What's the
> official word from legal on this? I know that the jfree stuff is
> LGPL, which from what I found sounds like we cannot redistribute, even
> in unmodified binary form.
Hold on a second here...
You may only redistribute Category A and Category B licensed binaries.
BUT, just saying that Category X is a System Requirement, may not be
sufficient. You can have any GPL'd licensed dependency marked as
System Requirement if it to build the system. For instance, you may
require the gcc compiler. You may not mark something non-optional as
System Requirement that your code directly depend on, rendering the
product unusable without it. The exceptions are obvious; Java, Python,
Perl and so forth are clearly system requirements, but Hibernate is
not, MySQL JDBC driver is not, where as "a JDBC driver" is.
So, it is fairly complicated, and I would be happy to give more
concrete answers to each individual case.
So, let's start; What is JFree and how is it used?
> 2) Our NOTICE file is currently blank. Is there anything that needs
> to go in there? I think this relates to question 1, in that we might
> have to put legal notices of the binaries that we're redistributing in
> there.
NOTICE contains a single paragraph about each source and binary
dependency used in the project, and where that dependency originate
from. It would also contain the VMware Copyright notice, and any other
individual's work that has been forked. So, license, origin, copyright
holder and year (if available) in one paragraph, followed by a blank
line.
> 3) With the changes I've made today, if a user were to download the
> release archive and follow the instructions in
> http://svn.apache.org/repos/asf/incubator/pivot/branches/1.1/BUILD to
> rebuild the JAR files, they'd end up with JAR files that are
> bit-for-bit identical to the ones that came with the distribution,
> *except* that the *built* file names would not contain "incubating".
> Is this a problem?
What surprises me is that you are struggling a lot with this. Isn't
just "version" a property in the Ant file at the top, which would be
appended to filenames?
For this release, I will not make a fuzz over it, and I will try to
help out 'hands on' with the Ant script later.
> 4) I've uploaded my pgp code signing public key to the MIT key server.
> Are there any other servers to which I should upload manually? I was
> originally under the assumption that the key would disseminate
> automatically, but that appears to have been a bad assumption.
I am not very well educated in PGP systems, so I have no clue...
> 5) Niclas, you said that "The binary output is NOT included in the
> primary release artifact, but is "generated" by it." However, I see
> many projects that include binaries in their main release artifact
> (again, Wicket is an example). What's the final word on this? It
> seems silly to me to not include the binaries, since pivot users don't
> particularly want to build Pivot - just build applications that use
> it.
> 6) You speak of the primary release being source and the supplementary
> release being binary, but I see some projects (again, Wicket, among
> others) that only release one artifact, which contains both source and
> binaries. This is what I was going for here, as I think it simplifies
> things. Is that not kosher?
Is 5. and 6. same question?
Well, I guess it is a balance. I am of the opinion that 2 separate
tarballs is preferred, but that could be due to my slow connection to
the Internet. If you have a single tarball, then the most important
bit is that it can be built to the same state as the in-house built
one.
Apache is less concerned about the quality of the released artifacts,
and only really really care about the legal requirements. So, you have
a lot of freedom, incl sticking binaries into the source tarball.
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
Re: Releases
Posted by Todd Volkert <tv...@gmail.com>.
Mentors:
Ok, I've changed the build script and am almost ready to post another
sanity check archive set. However, I have some questions before I do
so:
1) I tried but couldn't find definitive info on whether we can
redistribute binary dependencies (System Requirements). I had
originally assumed that we could NOT, so I removed all such jar files
from the released source, and thus, as you saw, the build fails unless
you download those jars yourself and put them on your classpath. I
would love to include them, as it would make the user who's trying to
build from source much happier. As you say, "some people (like
myself) prefer to have them part of the source dist". What's the
official word from legal on this? I know that the jfree stuff is
LGPL, which from what I found sounds like we cannot redistribute, even
in unmodified binary form.
2) Our NOTICE file is currently blank. Is there anything that needs
to go in there? I think this relates to question 1, in that we might
have to put legal notices of the binaries that we're redistributing in
there.
3) With the changes I've made today, if a user were to download the
release archive and follow the instructions in
http://svn.apache.org/repos/asf/incubator/pivot/branches/1.1/BUILD to
rebuild the JAR files, they'd end up with JAR files that are
bit-for-bit identical to the ones that came with the distribution,
*except* that the *built* file names would not contain "incubating".
Is this a problem?
4) I've uploaded my pgp code signing public key to the MIT key server.
Are there any other servers to which I should upload manually? I was
originally under the assumption that the key would disseminate
automatically, but that appears to have been a bad assumption.
5) Niclas, you said that "The binary output is NOT included in the
primary release artifact, but is "generated" by it." However, I see
many projects that include binaries in their main release artifact
(again, Wicket is an example). What's the final word on this? It
seems silly to me to not include the binaries, since pivot users don't
particularly want to build Pivot - just build applications that use
it.
6) You speak of the primary release being source and the supplementary
release being binary, but I see some projects (again, Wicket, among
others) that only release one artifact, which contains both source and
binaries. This is what I was going for here, as I think it simplifies
things. Is that not kosher?
Thanks!
-T
On Tue, Mar 31, 2009 at 11:42 AM, Todd Volkert <tv...@gmail.com> wrote:
> Replying on the dev list; I pinged you privately 'cause I was just
> hoping to catch you before I went to bed :)
>
> Your steps below explain very well what you saw and where you're
> coming from. I will address these issues today and post another
> candidate for a sanity check. Comments inline:
>
>> I really want you to get this right, and willing to assist as much as
>> I can. I know that the first round is really, really painful, but it
>> will get smoother if you manage to automate most stuff.
>>
>> Ok, here is what I did this morning;
>>
>> 1. I downloaded
>> http://people.apache.org/~tvolkert/pivot/apache-pivot-1.1-incubating.tar.gz
>>
>> 2. I downloaded
>> http://people.apache.org/~tvolkert/pivot/apache-pivot-1.1-incubating.zip
>> because I was curious why the size was so different, and assumed that
>> they were different (have not checked that yet).
>
> Yeah, this confused me as well. I set the compression level to 9 in
> the zip to try to get the size down, but it's still significantly
> larger than the tar.gz, which baffles me. Is ZIP really that much
> less efficient?
>
>> 3. I opened build.xml and saw the following;
>> <?xml version="1.0" encoding="UTF-8"?>
>> <project default="build">
>> <target name="build">
>> <mkdir dir="bin"/>
>> <javac srcdir="src" destDir="bin" debug="true"/>
>> </target>
>> </project>
>> And I went "Oh oh", since I know the build.xml in SVN is a mile long.
>
> Yeah, this relates to the discussion we had on list a few days back
> about whether the built binaries need to be packaged in jars the same
> way as our release archive or whether .class files are sufficient.
> I'll re-organize this today so that the release archive build.xml is
> the same as the SVN one, eliminating this issue.
>
>> 4. I looked in lib/ and I saw;
>> pivot-charts-incubating.jar pivot-tools-incubating.jar pivot-web-incubating.server.jar pivot-wtk-incubating.terra.jar
>> pivot-core-incubating.jar pivot-web-incubating.jar pivot-wtk-incubating.jar
>>
>> 5. I removed the everything in the lib folder, since that is obvious
>> binary outputs.
>
> I may be slow sometimes, but I finally understand that the goal is for
> the user to be able to produce an *exact match* with our binary
> distribution by building from source. :)
>
>> 6. I ran Ant. I got build problems and looked in the BUILD. It
>> explained why, and since I didn't have the system requirements
>> available, I stopped on that track.
>
> So you made reference yesterday to the fact that you prefer to include
> library dependencies in your distributions. I would love to as well,
> but I was under the impression that we couldn't legally include such
> JAR files. I'll look again on apache.org for guidelines, but I take
> it that this is an option for us?
>
>> 7. I went to pgp.mit.edu and looked up "Todd Volkert" and low and
>> below there was an entry. "Excellent I thought.", but the email wasn't
>> one I was used to, and it dated back to 2000, so I assumed that was
>> not the key that you have used to sign with. The re-iteration in the
>> list, is just to emphasize the importance and not criticism that
>> something is not right.
>
> No worries - I was not offended, just confused. :) I did upload my
> public key using 'gpg --send-key DB0924F6' on Friday (March 27).
> http://apache.org/dev/release-signing.html#keyserver states that "The
> major public key servers synchronize their records regularly so a key
> uploaded to one should be disseminated to the rest.", so I assumed
> that my work was done with respect to uploading my public key. How do
> I make sure that the MIT key server gets it?
>
> With respect to the key you found, that's from a previous life :) The
> one at http://people.apache.org/~tvolkert/pivot/KEYS is the one that I
> created for the purpose of release signing and the one I want to get
> propagated to the public key servers.
>
> Also, with respect to the web of trust, I won't get a chance to attend
> ApacheCon until November (ApacheCon US) -- can we release if my key is
> not in the web of trust?
>
>> We will get this right... It just will take a while.
>
> Thanks for your help and patience.
>
Re: Releases
Posted by Todd Volkert <tv...@gmail.com>.
> How do I make sure that the MIT key server gets it?
Nevermind - http://pgp.mit.edu/ is pretty self-explanatory :)
Re: Releases
Posted by Todd Volkert <tv...@gmail.com>.
Replying on the dev list; I pinged you privately 'cause I was just
hoping to catch you before I went to bed :)
Your steps below explain very well what you saw and where you're
coming from. I will address these issues today and post another
candidate for a sanity check. Comments inline:
> I really want you to get this right, and willing to assist as much as
> I can. I know that the first round is really, really painful, but it
> will get smoother if you manage to automate most stuff.
>
> Ok, here is what I did this morning;
>
> 1. I downloaded
> http://people.apache.org/~tvolkert/pivot/apache-pivot-1.1-incubating.tar.gz
>
> 2. I downloaded
> http://people.apache.org/~tvolkert/pivot/apache-pivot-1.1-incubating.zip
> because I was curious why the size was so different, and assumed that
> they were different (have not checked that yet).
Yeah, this confused me as well. I set the compression level to 9 in
the zip to try to get the size down, but it's still significantly
larger than the tar.gz, which baffles me. Is ZIP really that much
less efficient?
> 3. I opened build.xml and saw the following;
> <?xml version="1.0" encoding="UTF-8"?>
> <project default="build">
> <target name="build">
> <mkdir dir="bin"/>
> <javac srcdir="src" destDir="bin" debug="true"/>
> </target>
> </project>
> And I went "Oh oh", since I know the build.xml in SVN is a mile long.
Yeah, this relates to the discussion we had on list a few days back
about whether the built binaries need to be packaged in jars the same
way as our release archive or whether .class files are sufficient.
I'll re-organize this today so that the release archive build.xml is
the same as the SVN one, eliminating this issue.
> 4. I looked in lib/ and I saw;
> pivot-charts-incubating.jar pivot-tools-incubating.jar pivot-web-incubating.server.jar pivot-wtk-incubating.terra.jar
> pivot-core-incubating.jar pivot-web-incubating.jar pivot-wtk-incubating.jar
>
> 5. I removed the everything in the lib folder, since that is obvious
> binary outputs.
I may be slow sometimes, but I finally understand that the goal is for
the user to be able to produce an *exact match* with our binary
distribution by building from source. :)
> 6. I ran Ant. I got build problems and looked in the BUILD. It
> explained why, and since I didn't have the system requirements
> available, I stopped on that track.
So you made reference yesterday to the fact that you prefer to include
library dependencies in your distributions. I would love to as well,
but I was under the impression that we couldn't legally include such
JAR files. I'll look again on apache.org for guidelines, but I take
it that this is an option for us?
> 7. I went to pgp.mit.edu and looked up "Todd Volkert" and low and
> below there was an entry. "Excellent I thought.", but the email wasn't
> one I was used to, and it dated back to 2000, so I assumed that was
> not the key that you have used to sign with. The re-iteration in the
> list, is just to emphasize the importance and not criticism that
> something is not right.
No worries - I was not offended, just confused. :) I did upload my
public key using 'gpg --send-key DB0924F6' on Friday (March 27).
http://apache.org/dev/release-signing.html#keyserver states that "The
major public key servers synchronize their records regularly so a key
uploaded to one should be disseminated to the rest.", so I assumed
that my work was done with respect to uploading my public key. How do
I make sure that the MIT key server gets it?
With respect to the key you found, that's from a previous life :) The
one at http://people.apache.org/~tvolkert/pivot/KEYS is the one that I
created for the purpose of release signing and the one I want to get
propagated to the public key servers.
Also, with respect to the web of trust, I won't get a chance to attend
ApacheCon until November (ApacheCon US) -- can we release if my key is
not in the web of trust?
> We will get this right... It just will take a while.
Thanks for your help and patience.
Re: Releases
Posted by Todd Volkert <tv...@gmail.com>.
Comments inline:
> Apache is about Open Source. There is a huge emphasis on the "Source"
> part, to the degree that there are times when some projects don't even
> release binaries at all, only the sources.
I apologize if I got this very wrong. I looked at several Apache TLP
projects and used them as guidance. Specifically, this sample release
artifact is based on Wicket, which, unpacked, looks almost identical
in its structure (see
http://mirror.cinquix.com/pub/apache/wicket/1.3.5/apache-wicket-1.3.5.tar.gz).
The theory was that our release artifact contains both the binaries
(in the lib folder in the archive) and the source (the src folder in
the archive).
> So the "Released Artifact" are the sources and the build system (incl
> instructions) required to produce a useful binary. The binary output
> is NOT included in the primary release artifact, but is "generated" by
> it. So; SVN --(packaging)--> Source Release --(build+package)-->
> Binary Release
Is that not the case in the sample I sent out? The user can browse
the source in the src dir and run "ant" at the root folder to produce
a useful binary.
> So, on these grounds, I am not going to recommend the PMC to approve
> the release.
I hadn't put it to a vote yet (even on this list, let alone incubator
general), as I was looking for feedback before I did so. As such, I
wouldn't expect that you'd recommend to release this yet :)
> Here is what is needed;
>
> 1. Create a target in the Ant build, that zips/tars up the SVN
> sources, not including the .svn directories. Sources in this instance
> means everything that is needed to build Pivot, except for "System
> Requirements" (listed in the README/BUILD). Ant and JDK is typical
> System Requirements, as are any external jar files that are only
> required for the build, BUT some people (like myself) prefer to have
> them part of the source dist.
The dist target does this - that's what lies in the src folder of the
release archive. We also figured there were legal issues with
packaging up library dependencies. Is this not the case?
> 2. That zip/tar IS your primary release artifact;
> apache-pivot-1.1-incubating.tar.gz
Yes, what I sent out *is* just that. No offense (seriously), but I
honestly am wondering whether you looked at the same thing that I
created. Are we both talking about the files in
http://people.apache.org/~tvolkert/pivot/ ??
> 3. Using that zip/tar, execute another Ant target (for instance
> 'install') which compiles, jars and sticks everything into a
> 'generated/apache-pivot-1.1-incubating' directory.
The tarball *contains* the apache-pivot-1.1-incubating folder, a-la Wicket.
> 4. The same target could also create a zip/tar of the
> 'generated/apache-pivot-1.1-incubating', and that IS your
> supplementary binary release.
The binary release is contained in the folder, as a sibling of the src folder.
> 5. Ask a couple of community members to sanity check the binary
> release, and make sure it is useful.
That was the email I sent out to which you are replying.
> 6. Let people worry about Maven distro separately. And perhaps later
> migrate to Maven build system, if you find Maven support important and
> want to simplify such process.
Yes, we decided that today on the thread entitled "Version numbering solution?"
> 7. Finally, the release artifacts needs checksums and signatures. The
> PGP signature should be uploaded to at least one or two public PGP
> servers, such as pgp.mit.edu, and eventually be cross-signed in person
> with other people in Apache (for instance at an ApacheCon event). That
> creates the Apache Web of Trust. This may seem like a lot of work for
> nothing, but there are some people who takes this aspect of Apache
> very, very seriously. See
> http://www.apache.org/dev/release-signing.html for more details.
This is one reason that I think you may have looked at the wrong
thing. Our KEYS file is checked in, is provided at
http://people.apache.org/~tvolkert/pivot/, along with the PGP ascii
armored detached signature (.asc) files, along with the MD5 and SHA
digest files. I am actually one of those people that take this aspect
very, very seriously :)
> Apache level FAQ on releases are here; http://www.apache.org/dev/release.html
> Note that additional requirements are imposed by the Incubator, and is
> found embedded in
> http://incubator.apache.org/guides/releasemanagement.html.
Yes, I read these pages at least three times each to make sure I was
in compliance to the best of my effort, which is why I'm left
extremely confused at your email to which I'm currently replying...
-T