Source artifacts

[Greg Brown <gk...@mac.com>]

Niclas,

How strict is the release policy regarding source artifacts? Currently, our build process generates a source archive that isn't inherently buildable. It contains all of the source for Pivot, but it isn't laid out in such a way that Eclipse or our Ant script can build it. Essentially, it is a "flattened" view of the source tree, with the source for all Pivot sub-projects (Core, WTK, Web, etc.) consolidated into a single tree.

Is this acceptable, or should I modify the packaging process to produce something that is more readily buildable (assuming that the developer installs all the required library dependencies)?

Thanks,
Greg

Re: Source artifacts

[Niclas Hedhman <ni...@hedhman.org>]

On Fri, Mar 27, 2009 at 2:38 AM, Greg Brown <gk...@mac.com> wrote:
>>> We already have an Ant build, which is actually why I'm asking the question. Our SVN repository is laid out in such a way that our Ant script can easily build from it. In other words, it is optimized for Pivot *developers*. Our source artifact is laid out such that it is easily browsable by Pivot *users*, who may be interested in looking at the source, but not necessarily building it (for example, I have often looked at the source code for the JDK, but I have never attempted to build it). We see these as two very distinct use cases, so we have structured our release artifacts accordingly.
>>
>>This is not a problem. Just note that The ASF releases Source. We're
>>Open Source after al :)
>
> Of course.  :-)
>
> Glad to hear that our current approach is OK, because I do think that source-code savvy users (not developers) will find it easier to navigate.
>

I am not sure what you are agreeing on here. The Source Release
Tarball MUST be buildable through provided instructions. Now, you can
simplify the instructions and say "cd apache-pivot ; ant install" or
go through all the steps required to produce a document that any
"regular Java developer" (or preferably "any developer") without prior
knowledge of your chosen toolset. I am sure that the latter will be a
lot more long-term pain, than the former.
Checking out from SVN is not an acceptable solution. It is lacking all
security features and it is possible for people to manipulate the
tagged sources without anyone noticing...

Cheers
Niclas
-- 
http://www.qi4j.org - New Energy for Java

Re: Source artifacts

[Greg Brown <gk...@mac.com>]

>> We already have an Ant build, which is actually why I'm asking the question. Our SVN repository is laid out in such a way that our Ant script can easily build from it. In other words, it is optimized for Pivot *developers*. Our source artifact is laid out such that it is easily browsable by Pivot *users*, who may be interested in looking at the source, but not necessarily building it (for example, I have often looked at the source code for the JDK, but I have never attempted to build it). We see these as two very distinct use cases, so we have structured our release artifacts accordingly.
>
>This is not a problem. Just note that The ASF releases Source. We're
>Open Source after al :)

Of course.  :-)  

Glad to hear that our current approach is OK, because I do think that source-code savvy users (not developers) will find it easier to navigate.

Re: Source artifacts

[Martijn Dashorst <ma...@gmail.com>]

On Thu, Mar 26, 2009 at 4:42 PM, Greg Brown <gk...@mac.com> wrote:
> We already have an Ant build, which is actually why I'm asking the question. Our SVN repository is laid out in such a way that our Ant script can easily build from it. In other words, it is optimized for Pivot *developers*. Our source artifact is laid out such that it is easily browsable by Pivot *users*, who may be interested in looking at the source, but not necessarily building it (for example, I have often looked at the source code for the JDK, but I have never attempted to build it). We see these as two very distinct use cases, so we have structured our release artifacts accordingly.

This is not a problem. Just note that The ASF releases Source. We're
Open Source after al :)

>>There is one thing to take into consideration: source jars also need
>>to be signed an contain the incubator disclaimer.
>
> You are referring to the PGP signature, as opposed to Java code signing, correct?

Yes. Java code signing is not a requirement for releasing within the
ASF (though it may be for a particular project).

Martijn

Re: Source artifacts

[Greg Brown <gk...@mac.com>]

Hi Martijn-

>If you are able to turn in it into a maven assembly, or an ant build,
>it would become quite less cumbersome :).

We already have an Ant build, which is actually why I'm asking the question. Our SVN repository is laid out in such a way that our Ant script can easily build from it. In other words, it is optimized for Pivot *developers*. Our source artifact is laid out such that it is easily browsable by Pivot *users*, who may be interested in looking at the source, but not necessarily building it (for example, I have often looked at the source code for the JDK, but I have never attempted to build it). We see these as two very distinct use cases, so we have structured our release artifacts accordingly.

>There is one thing to take into consideration: source jars also need
>to be signed an contain the incubator disclaimer.

You are referring to the PGP signature, as opposed to Java code signing, correct?

Greg

Re: Source artifacts

[Martijn Dashorst <ma...@gmail.com>]

Well,

If you are able to turn in it into a maven assembly, or an ant build,
it would become quite less cumbersome :).

It is not required to use maven or ant, but it is highly recommended
to ensure you don't paint yourself into a particular process that only
works on your particular toolset. Ant and maven tend to make this
possible.

There is one thing to take into consideration: source jars also need
to be signed an contain the incubator disclaimer.

Martijn

On Thu, Mar 26, 2009 at 2:33 PM, Greg Brown <gk...@mac.com> wrote:
> Niclas,
>
> How strict is the release policy regarding source artifacts? Currently, our build process generates a source archive that isn't inherently buildable. It contains all of the source for Pivot, but it isn't laid out in such a way that Eclipse or our Ant script can build it. Essentially, it is a "flattened" view of the source tree, with the source for all Pivot sub-projects (Core, WTK, Web, etc.) consolidated into a single tree.
>
> Is this acceptable, or should I modify the packaging process to produce something that is more readily buildable (assuming that the developer installs all the required library dependencies)?
>
> Thanks,
> Greg
>
>
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

Re: Source artifacts

[Todd Volkert <tv...@gmail.com>]

My 2c: I'd think that they could check out the release tag from SVN if
they wanted to build -- the source distribution is more to allow users
to see what's going on under the covers without actually building it.

-T

On Thu, Mar 26, 2009 at 9:33 AM, Greg Brown <gk...@mac.com> wrote:
> Niclas,
>
> How strict is the release policy regarding source artifacts? Currently, our build process generates a source archive that isn't inherently buildable. It contains all of the source for Pivot, but it isn't laid out in such a way that Eclipse or our Ant script can build it. Essentially, it is a "flattened" view of the source tree, with the source for all Pivot sub-projects (Core, WTK, Web, etc.) consolidated into a single tree.
>
> Is this acceptable, or should I modify the packaging process to produce something that is more readily buildable (assuming that the developer installs all the required library dependencies)?
>
> Thanks,
> Greg
>
>
>
>