headers
Hedrick Charles | 10 Feb 00:53
Picon
Favicon

[Building Sakai] lesson builder binaries

I've just uploaded

https://source.sakaiproject.org/svn/lessonbuilder/binaries/lessonbuilder-assembly-1.4-sakai2.8.1-tomcat-overlay.zip

This is a ZIP file with binaries, designed to be unzipped in the main tomcat directory. 

This is the version being run at Rutgers, except using RSF 0.7.5 rather than 0.8-SNAPSHOT. It is built for
2.8.1, but I believe it will work for 2.8 as well. Please tell me if it doesn't and I'll do a separate one.

_______________________________________________
sakai-dev mailing list
sakai-dev <at> collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe <at> collab.sakaiproject.org with a subject of "unsubscribe"
Permalink | Reply |
headers
Hedrick Charles | 10 Feb 01:00
Picon
Favicon

Re: [Building Sakai] lesson builder binaries

I assume you will have auto.ddl on. Otherwise, please use the appropriate file from
https://source.sakaiproject.org/svn/lessonbuilder/branches/lessonbuilder-1.4.x/hbm/src/ddl/
 in the folder for your database.

On Feb 9, 2012, at 6:53:02 PM, Hedrick Charles wrote:

> I've just uploaded
> 
> https://source.sakaiproject.org/svn/lessonbuilder/binaries/lessonbuilder-assembly-1.4-sakai2.8.1-tomcat-overlay.zip
> 
> This is a ZIP file with binaries, designed to be unzipped in the main tomcat directory. 
> 
> This is the version being run at Rutgers, except using RSF 0.7.5 rather than 0.8-SNAPSHOT. It is built for
2.8.1, but I believe it will work for 2.8 as well. Please tell me if it doesn't and I'll do a separate one.
> 

_______________________________________________
sakai-dev mailing list
sakai-dev <at> collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe <at> collab.sakaiproject.org with a subject of "unsubscribe"
Permalink | Reply |
headers
Steve Swinsburg | 10 Feb 01:15
Picon
Gravatar

Re: [Building Sakai] lesson builder binaries

Hi Chuck,

These shouldn't go into SVN. Binaries (ie tomcat overlays) are created as part of the release process and
uploaded to the Sakai maven repo. The source is also automatically tagged as part of this process (when
releasing actual stable artifacts).

People can then include a pom block in core-deploy and they are automatilcally retrieved and unpacked,
like how the others in there are deployed (profile2, sites stats etc)

Do you have permissions to do a Maven release? If not, I can check out the source and push a release for you.

I see a lot of snapshot dependencies in the 1.4 branch though so before a stable release can be tagged and
packaged, they need to be stabilised. Instead we can create a snapshot release of the 1.4 branch for now.

cheers,
Steve

On 10/02/2012, at 10:53 AM, Hedrick Charles wrote:

> I've just uploaded
> 
> https://source.sakaiproject.org/svn/lessonbuilder/binaries/lessonbuilder-assembly-1.4-sakai2.8.1-tomcat-overlay.zip
> 
> This is a ZIP file with binaries, designed to be unzipped in the main tomcat directory. 
> 
> This is the version being run at Rutgers, except using RSF 0.7.5 rather than 0.8-SNAPSHOT. It is built for
2.8.1, but I believe it will work for 2.8 as well. Please tell me if it doesn't and I'll do a separate one.
> 
> _______________________________________________
> sakai-dev mailing list
(Continue reading)

Permalink | Reply |
headers
Hedrick Charles | 10 Feb 04:01
Picon
Favicon

Re: [Building Sakai] lesson builder binaries

The problem is that the normal build generates binaries for 2.9. I don't think I have permissions to put
things anywhere other than svn.

Because of limitations in mvn, building a 2.8 version requires changes in the pom.xml file. If you can think
of a way to get the release process to build a separate version of code with a separate pom file that would be great.

On Feb 9, 2012, at 7:15:02 PM, Steve Swinsburg wrote:

> Hi Chuck,
> 
> These shouldn't go into SVN. Binaries (ie tomcat overlays) are created as part of the release process and
uploaded to the Sakai maven repo. The source is also automatically tagged as part of this process (when
releasing actual stable artifacts).
> 
> People can then include a pom block in core-deploy and they are automatilcally retrieved and unpacked,
like how the others in there are deployed (profile2, sites stats etc)
> 
> Do you have permissions to do a Maven release? If not, I can check out the source and push a release for you.
> 
> I see a lot of snapshot dependencies in the 1.4 branch though so before a stable release can be tagged and
packaged, they need to be stabilised. Instead we can create a snapshot release of the 1.4 branch for now.
> 
> cheers,
> Steve
> 
> 
> On 10/02/2012, at 10:53 AM, Hedrick Charles wrote:
> 
>> I've just uploaded
>>
(Continue reading)

Permalink | Reply |
headers
Steve Swinsburg | 10 Feb 04:52
Picon
Gravatar

Re: [Building Sakai] lesson builder binaries

To target different code to different versions of Sakai you'll need to use a branch. The various releases
can then be built from there. 

Alternatively, focus on trunk (which is actually 2.10) and provide instructions for running on 2.8. If
people want to run a tool designed for a later version of Sakai, and the binary is incompatible, then
building from source is what needs to be done.

This tool is on the list for 2.9, and the 1.4.x branch is where releases are being published from, however
those are still including snapshot and other (-hack?) dependencies. This needs to be cleaned up.

In general, the release team handles the releases of projects but you need to get the dependencies in order
for that to happen.

cheers,
Steve

On 10/02/2012, at 2:01 PM, Hedrick Charles wrote:

> The problem is that the normal build generates binaries for 2.9. I don't think I have permissions to put
things anywhere other than svn.
> 
> Because of limitations in mvn, building a 2.8 version requires changes in the pom.xml file. If you can
think of a way to get the release process to build a separate version of code with a separate pom file that
would be great.
> 
> 
> On Feb 9, 2012, at 7:15:02 PM, Steve Swinsburg wrote:
> 
>> Hi Chuck,
>>
(Continue reading)

Permalink | Reply |
headers
Hedrick Charles | 10 Feb 13:20
Picon
Favicon

Re: [Building Sakai] lesson builder binaries

The snapshot and hack dependencies are commented out, and would be replaced with the version that the site
is actually using if uncommented.

On Feb 9, 2012, at 10:52:10 PM, Steve Swinsburg wrote:

> To target different code to different versions of Sakai you'll need to use a branch. The various releases
can then be built from there. 
> 
> Alternatively, focus on trunk (which is actually 2.10) and provide instructions for running on 2.8. If
people want to run a tool designed for a later version of Sakai, and the binary is incompatible, then
building from source is what needs to be done.
> 
> This tool is on the list for 2.9, and the 1.4.x branch is where releases are being published from, however
those are still including snapshot and other (-hack?) dependencies. This needs to be cleaned up.
> 
> In general, the release team handles the releases of projects but you need to get the dependencies in order
for that to happen.
> 
> cheers,
> Steve
> 
> 
> 
> 
> On 10/02/2012, at 2:01 PM, Hedrick Charles wrote:
> 
>> The problem is that the normal build generates binaries for 2.9. I don't think I have permissions to put
things anywhere other than svn.
>> 
>> Because of limitations in mvn, building a 2.8 version requires changes in the pom.xml file. If you can
(Continue reading)

Permalink | Reply |
headers
Hedrick Charles | 10 Feb 13:26
Picon
Favicon

Re: [Building Sakai] lesson builder binaries

As far as I can see this email does not contain a practical answer to the requests for a binary that will work
with 2.8. I have enough trouble now keeping patches in sync with several versions, I don't think it's very
attractive to maintain separate branches that differ only in a few lines in the pom file. 

If you object to having the binary in svn, I can put it on a Rutgers server. I thought it would make more sense to
put it where people would normally look.

On Feb 9, 2012, at 10:52:10 PM, Steve Swinsburg wrote:

> To target different code to different versions of Sakai you'll need to use a branch. The various releases
can then be built from there. 
> 
> Alternatively, focus on trunk (which is actually 2.10) and provide instructions for running on 2.8. If
people want to run a tool designed for a later version of Sakai, and the binary is incompatible, then
building from source is what needs to be done.
> 
> This tool is on the list for 2.9, and the 1.4.x branch is where releases are being published from, however
those are still including snapshot and other (-hack?) dependencies. This needs to be cleaned up.
> 
> In general, the release team handles the releases of projects but you need to get the dependencies in order
for that to happen.
> 
> cheers,
> Steve
> 
> 
> 
> 
> On 10/02/2012, at 2:01 PM, Hedrick Charles wrote:
>
(Continue reading)

Permalink | Reply |
headers
Steve Swinsburg | 10 Feb 13:51
Picon
Gravatar

Re: [Building Sakai] lesson builder binaries

Why do you need to distribute a binary for 2.8? It sounds like there is a lot of mucking about, just have older
versions build from source. Everyone that responded said they were building from source anyway. But you
really can't have this fiddling about in a release. I'm not trying to be difficult, but we do need to focus on
a stable release for 2.9.

In the pom for the 1.4.0-b02 tag I see these properties for dependency versions, which are not commented out:

<sakai.yaft.version>1.2.1-SNAPSHOT</sakai.yaft.version>
<sakai.mneme.version>1.2-hack</sakai.mneme.version>
<rsfutil.version>0.8-SNAPSHOT</rsfutil.version>
<sakairsf.version>0.8-SNAPSHOT</sakairsf.version>
<sakai.basiclti.version>2.0-SNAPSHOT</sakai.basiclti.version>

I know that these are for optional tools, but even so, a tagged release needs to depend on stable dependencies.

Is there anyway to extract the optional modules into some sort of extension libraries and they can be
installed separately? Then you could have a core release with the main functionality and deployers can
add in the modules they want (i.e. clog, mneme)

Then you can:

>>  … focus on trunk (which is actually 2.10) and provide instructions for running on 2.8. If people want to
run a tool designed for a later version of Sakai, and the binary is incompatible, then building from source
is what needs to be done.

And we can deliver binaries for 2.9 onwards from the Sakai maven repo.

regards,
Steve
(Continue reading)

Permalink | Reply |
headers
Hedrick Charles | 10 Feb 13:56
Picon
Favicon

Re: [Building Sakai] lesson builder binaries

Those are not dependencies. They are definitions of variables. The variables are used in tool/pom.xml, in
dependencies that are commented out. It seems silly to comment out the variable definitions as well. It
simply requires the user to make another edit to uncomment them, for no reason. The 0.8-SNAPSHOT is in the
2.8 profile, which is not used in building the release. I've just changed them to 0.7.5.

The optional code, which uses the extra dependencies, is in a separate directory, opt-src, which is used
only when the build-helper-maven-plugin section is uncommented. That plugin adds the opt-src section
to the build.

On Feb 10, 2012, at 7:51:12 AM, Steve Swinsburg wrote:

> Why do you need to distribute a binary for 2.8? It sounds like there is a lot of mucking about, just have older
versions build from source. Everyone that responded said they were building from source anyway. But you
really can't have this fiddling about in a release. I'm not trying to be difficult, but we do need to focus on
a stable release for 2.9.
> 
> In the pom for the 1.4.0-b02 tag I see these properties for dependency versions, which are not commented out:
> 
> <sakai.yaft.version>1.2.1-SNAPSHOT</sakai.yaft.version>
> <sakai.mneme.version>1.2-hack</sakai.mneme.version>
> <rsfutil.version>0.8-SNAPSHOT</rsfutil.version>
> <sakairsf.version>0.8-SNAPSHOT</sakairsf.version>
> <sakai.basiclti.version>2.0-SNAPSHOT</sakai.basiclti.version>
> 
> I know that these are for optional tools, but even so, a tagged release needs to depend on stable dependencies.
> 
> Is there anyway to extract the optional modules into some sort of extension libraries and they can be
installed separately? Then you could have a core release with the main functionality and deployers can
add in the modules they want (i.e. clog, mneme)
>
(Continue reading)

Permalink | Reply |
headers
Steve Swinsburg | 10 Feb 14:10
Picon
Gravatar

Re: [Building Sakai] lesson builder binaries

It's semantics. The property is defined to hold a version, then that property is used in the dependency declaration.

It's up to you if you want to support binaries that require code changes. They can still be pushed up to the
Maven repo though. Likewise with the optional extras, make releases that people can 'plugin' to their
installation and have a clean pom for normal use. It would certainly simplify the build.

regards,
Steve

On 10/02/2012, at 11:59 PM, Hedrick Charles wrote:

> I've had two requests, one via this list and one privately, for binaries from people who find it difficult
to build from source. I've also worked through problems with sites who surely would have preferred to take
a binary if one was available.

On 10/02/2012, at 11:56 PM, Hedrick Charles wrote:

> Those are not dependencies. They are definitions of variables. The variables are used in tool/pom.xml,
in dependencies that are commented out. It seems silly to comment out the variable definitions as well. It
simply requires the user to make another edit to uncomment them, for no reason. The 0.8-SNAPSHOT is in the
2.8 profile, which is not used in building the release. I've just changed them to 0.7.5.
> 
> The optional code, which uses the extra dependencies, is in a separate directory, opt-src, which is used
only when the build-helper-maven-plugin section is uncommented. That plugin adds the opt-src section
to the build.
> 
> On Feb 10, 2012, at 7:51:12 AM, Steve Swinsburg wrote:
> 
>> Why do you need to distribute a binary for 2.8? It sounds like there is a lot of mucking about, just have
older versions build from source. Everyone that responded said they were building from source anyway.
(Continue reading)

Permalink | Reply |
headers
Hedrick Charles | 10 Feb 13:59
Picon
Favicon

Re: [Building Sakai] lesson builder binaries

I've had two requests, one via this list and one privately, for binaries from people who find it difficult to
build from source. I've also worked through problems with sites who surely would have preferred to take a
binary if one was available.

On Feb 10, 2012, at 7:51:12 AM, Steve Swinsburg wrote:

> Why do you need to distribute a binary for 2.8? It sounds like there is a lot of mucking about, just have older
versions build from source. Everyone that responded said they were building from source anyway. But you
really can't have this fiddling about in a release. I'm not trying to be difficult, but we do need to focus on
a stable release for 2.9.
> 
> In the pom for the 1.4.0-b02 tag I see these properties for dependency versions, which are not commented out:
> 
> <sakai.yaft.version>1.2.1-SNAPSHOT</sakai.yaft.version>
> <sakai.mneme.version>1.2-hack</sakai.mneme.version>
> <rsfutil.version>0.8-SNAPSHOT</rsfutil.version>
> <sakairsf.version>0.8-SNAPSHOT</sakairsf.version>
> <sakai.basiclti.version>2.0-SNAPSHOT</sakai.basiclti.version>
> 
> I know that these are for optional tools, but even so, a tagged release needs to depend on stable dependencies.
> 
> Is there anyway to extract the optional modules into some sort of extension libraries and they can be
installed separately? Then you could have a core release with the main functionality and deployers can
add in the modules they want (i.e. clog, mneme)
> 
> Then you can:
> 
>>> … focus on trunk (which is actually 2.10) and provide instructions for running on 2.8. If people want
to run a tool designed for a later version of Sakai, and the binary is incompatible, then building from
source is what needs to be done.
(Continue reading)

Permalink | Reply |
headers
Hedrick Charles | 10 Feb 04:04
Picon
Favicon

Re: [Building Sakai] lesson builder binaries

I actually know how to make the 2.9 binaries run on 2.8, but it's so hacky I'm  not sure I want to do it. The
problem is that FormattedText has been seriously restructured. I could put my own layer above it, and
dynamically detect which version is present in the system.. However at this late stage in the release
cycle I'd prefer not to make that kind of change, but just to supply binaries built using the normal processes.

On Feb 9, 2012, at 7:15:02 PM, Steve Swinsburg wrote:

> Hi Chuck,
> 
> These shouldn't go into SVN. Binaries (ie tomcat overlays) are created as part of the release process and
uploaded to the Sakai maven repo. The source is also automatically tagged as part of this process (when
releasing actual stable artifacts).
> 
> People can then include a pom block in core-deploy and they are automatilcally retrieved and unpacked,
like how the others in there are deployed (profile2, sites stats etc)
> 
> Do you have permissions to do a Maven release? If not, I can check out the source and push a release for you.
> 
> I see a lot of snapshot dependencies in the 1.4 branch though so before a stable release can be tagged and
packaged, they need to be stabilised. Instead we can create a snapshot release of the 1.4 branch for now.
> 
> cheers,
> Steve
> 
> 
> On 10/02/2012, at 10:53 AM, Hedrick Charles wrote:
> 
>> I've just uploaded
>> 
>> https://source.sakaiproject.org/svn/lessonbuilder/binaries/lessonbuilder-assembly-1.4-sakai2.8.1-tomcat-overlay.zip
(Continue reading)

Permalink | Reply |

Gmane