You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Henri Yandell <fl...@gmail.com> on 2005/11/01 05:14:38 UTC

Re: Roller 1.3 release

On 10/31/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>
> On Oct 31, 2005, at 4:54 PM, Henri Yandell wrote:
> >
> > To business. Where are we on the following:
> > * Informed Incubator PMC of the result (and they're happy about the
> > LGPL bit?)
>
> Not sure about this one. We haven't be told how we can resolve the LGPL
> issue. Since this is not an official or sanctioned release, I think we
> are, to quote Sam Ruby on the topic of the Roller 1.3 release: "good to
> go".

My worry is that we'll be hammered for releasing with LGPL via the
ASF, and hammered for releasing outside the ASF. This'll be an
official release as far as I understand; ie) we'll be putting it on
the mirrors and announcing to some portion of the user community even
if it's just those who read the wiki page.

Cc'ing Noel as I don't think I got added to the Incubator PMC list (if
I did then it's very, very quiet). Noel, what's your take on the
status of this release?

> > * Apache webpage to point to the downloads (rather than
> > rollerweblogger one, unsure where  the move to an ASF website fits
> > currently)?
>
> No.

This one is linked into the status of the release I'm guessing. If a
full ASF release, then we'll need a webpage so that a person who is
sent there to download the project is well aware it is meant to be
coming from the ASF mirrors. If we're in some kind of half-world
still, ie) just using ASF mirrors, then maybe we don't even need this
page.

> > * All problems with RC files fixed?
>
> Not sure what you mean.

The stuff Anil brought up; though I think those were to do with the
wiki site instead of the actual release files. Basically a 'has
someone looked at the tar.gz/zips, and do they appear to work' bit.

Planning to take a look at them myself. Do a full Postgres install and
make sure it starts up okay etc.

> > * Release tagged?
>
> No. I can do this part tonight.

Cool.

Hen

Re: Legal worries... Was: Roller 1.3 release

Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 6, 2005, at 1:47 PM, Henri Yandell wrote:

> On 11/6/05, Noel J. Bergman <no...@devtech.com> wrote:
>
>> Henri Yandell wrote:
>>
>>> We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
>>> activation) jars in there.
>>>
>>
>>
>>> jta and jdbc-stdext are BCL.
>>>
>>
>>
>>> hibernate is LGPL.
>>>
>>
>> The BCL files are forbidden by that license to be in source  
>> control, and
>> must be removed.  They *are* permitted to be distributed in a  
>> package.  The
>> same issue exists for JAMES, Tomcat, and many other packages.  At  
>> some point
>> in the future, they should not be an issue, as Sun's new versions  
>> will be
>> under a more open license.
>>
>
> Geronimo have their own implementations (or at least compilable
> implementations) that can be used for compiling against for probably
> all 4 of these. Then we just need to figure out how  you get the Sun
> implementation in place for distributions.
>
>
>> MySQL must be the OLD LGPL driver, and is "safe" because it is  
>> invoked via
>> the generic JDBC interface.  The new GPL driver is forbidden  
>> because our
>> legal advice to date was that MySQL's "FOSS" exception was flawed and
>> inadequate.  That should be put to Cliff to raise with MySQL, but  
>> he doesn't
>> appear to be around right now.
>>
>
> MySQL driver, be it LGPL or GPL, cannot be in our dists or our source
> repository.
>
> The only point where the move from LGPL to GPL has any effect is if we
> are importing the MySQL driver code directly and not via JDBC. ie)
> it's fine for us to have code that works with the GPL'd MySQL 3.x, it
> just can't import com.mysql.*; whereas the LGPL'd version could be
> imported (based on the newer forthcoming policy).
>
> I doubt we even need the MySQL driver in svn. Users should be putting
> it in the container themselves.
>
> That leaves us with ekit, jazzy and Hibernate.
>
> ekit and jazzy are both optional features. Hibernate not. With the new
> policy, which we pretty much need, ekit and jazzy are fine as long as
> the system works without them (so we need a little bit of magic and
> the ability for the spell-check button to not show); while we would
> have a limited time in which to replace Hibernate.
>
> Anyone know if there are usable implementations of the new JSR that
> Hibernate will be working against?

Hibernate itself does implement the EJB3 persistence engine (which is  
what you are referring to...)

That is still LGPL though - the upside is that the API is standard so  
there's no import problem, just distribution.

We'll eventually have on in Geronimo-land somehow, as we need it for  
J2EE 5 (or JEE 5 or whatever it's called...).  I'd also like to see  
that API strapped onto the JDO project's persistence engine - it  
shouldn't be that hard, but I just don't have the time.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Re: Legal worries... Was: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
On 11/6/05, Noel J. Bergman <no...@devtech.com> wrote:
> Henri Yandell wrote:
> > We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
> > activation) jars in there.
>
> > jta and jdbc-stdext are BCL.
>
> > hibernate is LGPL.
>
> The BCL files are forbidden by that license to be in source control, and
> must be removed.  They *are* permitted to be distributed in a package.  The
> same issue exists for JAMES, Tomcat, and many other packages.  At some point
> in the future, they should not be an issue, as Sun's new versions will be
> under a more open license.

Geronimo have their own implementations (or at least compilable
implementations) that can be used for compiling against for probably
all 4 of these. Then we just need to figure out how  you get the Sun
implementation in place for distributions.

> MySQL must be the OLD LGPL driver, and is "safe" because it is invoked via
> the generic JDBC interface.  The new GPL driver is forbidden because our
> legal advice to date was that MySQL's "FOSS" exception was flawed and
> inadequate.  That should be put to Cliff to raise with MySQL, but he doesn't
> appear to be around right now.

MySQL driver, be it LGPL or GPL, cannot be in our dists or our source
repository.

The only point where the move from LGPL to GPL has any effect is if we
are importing the MySQL driver code directly and not via JDBC. ie)
it's fine for us to have code that works with the GPL'd MySQL 3.x, it
just can't import com.mysql.*; whereas the LGPL'd version could be
imported (based on the newer forthcoming policy).

I doubt we even need the MySQL driver in svn. Users should be putting
it in the container themselves.

That leaves us with ekit, jazzy and Hibernate.

ekit and jazzy are both optional features. Hibernate not. With the new
policy, which we pretty much need, ekit and jazzy are fine as long as
the system works without them (so we need a little bit of magic and
the ability for the spell-check button to not show); while we would
have a limited time in which to replace Hibernate.

Anyone know if there are usable implementations of the new JSR that
Hibernate will be working against?

It seems to me that we need to do a java.net release of 1.3. ie) a
community supported 'fork'; and hold 2.0 back until we get the issues
above dealt with. I don't see any reason why we can't do 'internal'
releases; namely tagging SVN at special points and having Sun, IBM,
JRoller build from those tags (given that it's pretty simple and
they're involved with the project anyway).

Hen

Re: Legal worries... Was: Roller 1.3 release

Posted by Anil Gangolli <an...@busybuddha.org>.
Henri,

Thanks for pushing this and also doing an audit/survey of our dependency 
jars.

I was surprised to see the the BCL jars mentioned.  Are Sun BCL 
redistributables also not kosher here?  This is the first time I've 
heard of that, and I don't quite understand the rationale, (as opposed 
to LGPL, where I think I do).  Is this due to the US export restriction 
compliance clause?  Pointer to some description of this issue on Apache?

--a.



Henri Yandell wrote:

>
> Problems, problems. Which I really hate to bring up as I want Roller 
> to succeed as an Apache project as much as anyone.
>
> http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/lib/
>
> We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail, 
> activation) jars in there.
>
> http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/hibernate-3.0/lib/ 
>
>
> jta and jdbc-stdext are BCL.
>
> http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/hibernate-3.0/ 
>
>
> hibernate is LGPL.
>
> ----
>
> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not 
> meant to have these in SVN, and that the imports on the LGPL jars are 
> not meant to be in SVN either.
>
> Now I know that this was well known before Roller joined, so what's 
> the status of this? What I've read on legal-discuss/board is not the 
> same as the message we're giving Roller, so I'm confused. On 
> roller-dev, Noel has said:
>
> "Check with Cliff, but I believe that projects will be given a 
> timeframe with which to eliminate LGPL dependencies.  It isn't a legal 
> (as in viral) so much as policy issue.  We would certainly need 
> appropriate notices, in addition to the Incubator disclaimer."
>
> As far as I know, that's for the imports not for the inclusion in 
> distributions/SVN. It's also going through one of its customary 
> dead-in-the-water periods regarding becoming new policy.
>
> We (roller-dev) will also need the Incubator PMC to create 
> 'appropriate notices', depending on what you mean by that. [I'm a part 
> of both, so this isn't me shirking work :) ].
>
> So what's the deal? How do I make a release of Roller, ie) what needs 
> to be different from a normal release; and how do I explain this to 
> Cliff without it sounding like we're ignoring the lawyers.
>
> Hen
>
>


Re: Legal worries... Was: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
On 11/7/05, Anil Gangolli <an...@busybuddha.org> wrote:
> Inline comments below...
> Henri Yandell wrote:
>
> >
> >For 2.0 I think we should be trying to get a clear LGPL message, or
> >proto-message; and get things dealt with prior to the release.
> >
> >Effectively this means:
> >
> >1) Removing 'bad' jars from SVN.
> >2) Modifying install process/build instructions to instruct user to
> >download the relevant jars themselves.
> >
> >
> For item (2), I'd like to understand the boundary of what we can do.
> For example, can we provide ant scripts / other build infrastructure
> that is generic, and configured specifically to download these jars?  If
> so, we should start building a network-based pre-build target and an
> installer in the Roller 2.x line.

Usually the legality is that the user has to initiate the download.
It's an issue lots of things have (Netbeans has it I think), often
with the BCL licensed things.

JAMES probably have a good strategy which we can use.

> >3) Ensuring nobody is concerned with the various usages of LGPL'd code.
> >
> >Hen
> >
> >
> For Hibernate, we do import org.hibernate.* classes and use Hibernate
> APIs directly currently.  So we are currently in the "worst" category of
> "offenders".

Not so bad; the worst part is having the jars in SVN.

The legality of being allowed to import org.hibernate.* is pretty much
all cleared up, the question is over the policy. Should ASF projects
depend on LGPL or should it not. Historically the answer was that yes
they can, but only for optional features. Currently it's suggested
that they can for required features too, but with a time limit (1 year
currently the floated time).

> A JSR-220-based rewrite would entail quite a bit of effort for 2.0, and
> I think will force us to require Java 5 / JDK 1.5.x.

Yep, looks like Java 5. :(

> The main thing
> that bugs me about this direction is the cramped timing with respect to
> the maturity levels of JSR 220 and the Hibernate support for it,
> although alternate supporting implementations might be considered along
> this line as well.

Yep, though we would have a time period in which to get it done (and
for Hibernate to mature its JSR 220 support).

Hen

Re: Legal worries... Was: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
On 11/7/05, Matt Raible <mr...@gmail.com> wrote:
> On 11/7/05, Henri Yandell <fl...@gmail.com> wrote:
> > On 11/7/05, Allen Gilliland <Al...@sun.com> wrote:
> > > Actually, I'm not sure it's important to Sun.  To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.
> >
> >
> > While not wanting to end up in a 'he-said, she-said'; I thought the
> > history was that the Roller chose not to join prior to Dave joining
> > Sun, but that Sun pointed out further advantages. One of these being
> > attention to legal issues, and the matter was rethought. I apologise
> > if I've got that wrong though, much of that is probably reading into
> > things being said.
> >
> > I just mailed concerning the issue being over ASF policy now; that
> > policy is most concerned with the rights of downstream users. ie) if a
> > company were to release a commercial version of the project, that the
> > LGPL usage wouldn't torpedo their desire to do so.
>
> I know this is a dead horse, but I feel like beating something today. ;-)

I'll be at ApacheCon, just promise to give me some beer after the beating :)

> http://www.hibernate.org/196.html
>
> <quote>
> Using Hibernate (by importing Hibernate's public interfaces in your
> Java code), and extending Hibernate (by subclassing or implementation
> of an extension interface) is considered by the authors of Hibernate
> to be dynamic linking. Hence our interpretation of the LGPL is that
> the use of the unmodified Hibernate source does not affect the license
> of your application code.
> </quote>
>
> We haven't modified Hibernate at all, so including hibernate3.jar in
> our code does not have a viral nature to it - at least as far as I'm
> concerned.

Yep. Kinda. No. My head hurts.

So src/java/roller is fine, not affected by the LGPL licence, however
Roller.zip is affected by the LGPL. The product would not be ASL, but
rather ASL/LGPL. Given that LGPL is stricter on some subjects than ASL
(I'll have to dig into email to list them), this means that
effectively the Roller distribution is more encumbered than a product
from Apache usually is.

Although originally the aim was to get the Hibernate clause recognised
as usable, and we even made a generic lawyer-written version of it,
talking with the FSF allowed Cliff to get to a point where we're all
happy that linkage is not a problem; distribution then reared its
head.

> That being said, if it's just a matter of not being able to include
> JARs in SVN, we could use Maven 2's Ant tasks, and download them
> dynamically before building everything.  I've played with this a bit
> and it seems to work pretty well (though the metadata for Maven's
> transitive dependencies still needs quite a bit of work).

I think an important legal part is user awareness. Or even possibly interaction.

If we had a bit that pops up and says:  "Please click here to download
FOO, by clicking here you are agreeing to the licence in <url to
LGPL>", then I think we can do it. Or we might have to actually show
them the license.

In reality the onus would be on us to match what the community is
doing; ie) how much do James do etc. If that's not enough, the ASF at
large would need to adjust.

Easiest, in the short term, is just to ask people to download jars
from ibiblio urls with a disclaimer that they are accepting the LGPL
license.

> I'd rather pursue fancy installation
> tactics than re-write anything.  Although, we probably could've
> re-wrote everything by now rather than sending all these e-mails. ;-)

The above takes care of the short term problem, and then just leaves
questions of the pressure to not have a required dependency on LGPL
licensed works. ie) pressure to make Hibernate optional.

Hen

Re: Legal worries... Was: Roller 1.3 release

Posted by Matt Raible <mr...@gmail.com>.
On 11/7/05, Henri Yandell <fl...@gmail.com> wrote:
> On 11/7/05, Allen Gilliland <Al...@sun.com> wrote:
> > Actually, I'm not sure it's important to Sun.  To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.
>
>
> While not wanting to end up in a 'he-said, she-said'; I thought the
> history was that the Roller chose not to join prior to Dave joining
> Sun, but that Sun pointed out further advantages. One of these being
> attention to legal issues, and the matter was rethought. I apologise
> if I've got that wrong though, much of that is probably reading into
> things being said.
>
> I just mailed concerning the issue being over ASF policy now; that
> policy is most concerned with the rights of downstream users. ie) if a
> company were to release a commercial version of the project, that the
> LGPL usage wouldn't torpedo their desire to do so.

I know this is a dead horse, but I feel like beating something today. ;-)

http://www.hibernate.org/196.html

<quote>
Using Hibernate (by importing Hibernate's public interfaces in your
Java code), and extending Hibernate (by subclassing or implementation
of an extension interface) is considered by the authors of Hibernate
to be dynamic linking. Hence our interpretation of the LGPL is that
the use of the unmodified Hibernate source does not affect the license
of your application code.
</quote>

We haven't modified Hibernate at all, so including hibernate3.jar in
our code does not have a viral nature to it - at least as far as I'm
concerned.

That being said, if it's just a matter of not being able to include
JARs in SVN, we could use Maven 2's Ant tasks, and download them
dynamically before building everything.  I've played with this a bit
and it seems to work pretty well (though the metadata for Maven's
transitive dependencies still needs quite a bit of work).

We could also have an "installer" that downloads JARs and prompts the
user to restart their context.  I'd rather pursue fancy installation
tactics than re-write anything.  Although, we probably could've
re-wrote everything by now rather than sending all these e-mails. ;-)

Matt

>
>
> > That being said, I agree with Matt.  I am just here to develop code and make the project better.  From all the recent discussions it sounds like being part of Apache will force us to backtrack quite a bit for no good reason.  So I agree that if we can't find a way to resolve the legal issues fairly easily then maybe we shouldn't be an Apache project yet.
>
>
> Agreed. +1 :) What needs deciding is what we think 'fairly easily' is.
>
> Currently I see us needing to:
>
> 1) remove some jars from SVN and have Ant post a message to the user
> asking them to put those files in place (with URLs). Not pretty, but
> good and workable.
>
> 2) do the same when installing a distribution
>
> 3) have a plan for required dependencies (namely Hibernate). JSR 220
> seems like a good eventual plan, we just have to get a feel for the
> timing. We're already on the right version of Hibernate right?
>
> Then we have to decide how long we release 'forks' at java.net and
> when we can start to release at apache.org. 1.3 is looking like a
> java.net; and it sounds like 2.0 wants to release very quickly so that
> would imply java.net there too.
>
> So... is the above too far from 'fairly easily'? Should we be talking
> about extracting to java.net, or about modifying things?
>
> Hen
>

Re: Legal worries... Was: Roller 1.3 release

Posted by Allen Gilliland <Al...@Sun.COM>.
On Mon, 2005-11-07 at 11:06, Henri Yandell wrote:
> On 11/7/05, Allen Gilliland <Al...@sun.com> wrote:
> > Actually, I'm not sure it's important to Sun.  To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.
> 
> 
> While not wanting to end up in a 'he-said, she-said'; I thought the
> history was that the Roller chose not to join prior to Dave joining
> Sun, but that Sun pointed out further advantages. One of these being
> attention to legal issues, and the matter was rethought. I apologise
> if I've got that wrong though, much of that is probably reading into
> things being said.
> 
> I just mailed concerning the issue being over ASF policy now; that
> policy is most concerned with the rights of downstream users. ie) if a
> company were to release a commercial version of the project, that the
> LGPL usage wouldn't torpedo their desire to do so.
> 

I actually don't know anything about the connection between Sun and moving to Apache, I am really just a code monkey.  However, I wouldn't have thought Sun would encourage us to move out of java.net.

> 
> > That being said, I agree with Matt.  I am just here to develop code and make the project better.  From all the recent discussions it sounds like being part of Apache will force us to backtrack quite a bit for no good reason.  So I agree that if we can't find a way to resolve the legal issues fairly easily then maybe we shouldn't be an Apache project yet.
> 
> 
> Agreed. +1 :) What needs deciding is what we think 'fairly easily' is.
> 
> Currently I see us needing to:
> 
> 1) remove some jars from SVN and have Ant post a message to the user
> asking them to put those files in place (with URLs). Not pretty, but
> good and workable.

this is really only a pain for us developers and something I'm sure we could live with.

> 
> 2) do the same when installing a distribution

a bummer, but would it be possible for us to package this stuff somewhere non-Apache like rollerweblogger.org and have an easy bundle for people to access?  i.e. a Roller-1.3-dependencies.zip?

> 
> 3) have a plan for required dependencies (namely Hibernate). JSR 220
> seems like a good eventual plan, we just have to get a feel for the
> timing. We're already on the right version of Hibernate right?

this is the part I have a problem with.  I think Anil's points are exactly the same concerns I have.

- how mature is JSR 220?  do we really want to commit to it now even if we don't have to implement it until later in the year?

- jdk 1.5?  i think this would be a big no-no.  i strongly disagree with requiring our users to be on the very latest jdk.  i think we should be supporting the 2 latest jdk versions, which at this time is 1.4 and 1.5

- and even if we did agree on both of the above, we would have to go back and do a fairly significant amount of work just to change something that's already working just fine :(

-- Allen


> 
> Then we have to decide how long we release 'forks' at java.net and
> when we can start to release at apache.org. 1.3 is looking like a
> java.net; and it sounds like 2.0 wants to release very quickly so that
> would imply java.net there too.
> 
> So... is the above too far from 'fairly easily'? Should we be talking
> about extracting to java.net, or about modifying things?
> 
> Hen


Re: Legal worries... Was: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
On 11/7/05, Allen Gilliland <Al...@sun.com> wrote:
> Actually, I'm not sure it's important to Sun.  To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.


While not wanting to end up in a 'he-said, she-said'; I thought the
history was that the Roller chose not to join prior to Dave joining
Sun, but that Sun pointed out further advantages. One of these being
attention to legal issues, and the matter was rethought. I apologise
if I've got that wrong though, much of that is probably reading into
things being said.

I just mailed concerning the issue being over ASF policy now; that
policy is most concerned with the rights of downstream users. ie) if a
company were to release a commercial version of the project, that the
LGPL usage wouldn't torpedo their desire to do so.


> That being said, I agree with Matt.  I am just here to develop code and make the project better.  From all the recent discussions it sounds like being part of Apache will force us to backtrack quite a bit for no good reason.  So I agree that if we can't find a way to resolve the legal issues fairly easily then maybe we shouldn't be an Apache project yet.


Agreed. +1 :) What needs deciding is what we think 'fairly easily' is.

Currently I see us needing to:

1) remove some jars from SVN and have Ant post a message to the user
asking them to put those files in place (with URLs). Not pretty, but
good and workable.

2) do the same when installing a distribution

3) have a plan for required dependencies (namely Hibernate). JSR 220
seems like a good eventual plan, we just have to get a feel for the
timing. We're already on the right version of Hibernate right?

Then we have to decide how long we release 'forks' at java.net and
when we can start to release at apache.org. 1.3 is looking like a
java.net; and it sounds like 2.0 wants to release very quickly so that
would imply java.net there too.

So... is the above too far from 'fairly easily'? Should we be talking
about extracting to java.net, or about modifying things?

Hen

Re: Legal worries... Was: Roller 1.3 release

Posted by Allen Gilliland <Al...@Sun.COM>.
Actually, I'm not sure it's important to Sun.  To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.

That being said, I agree with Matt.  I am just here to develop code and make the project better.  From all the recent discussions it sounds like being part of Apache will force us to backtrack quite a bit for no good reason.  So I agree that if we can't find a way to resolve the legal issues fairly easily then maybe we shouldn't be an Apache project yet.

-- Allen


On Mon, 2005-11-07 at 08:29, Matt Raible wrote:
> I know that having Roller as an Apache project is important for Dave
> and Sun.  However, I think it's important to state my opinion.  If
> it's going to require a significant re-write of Roller - my vote is to
> back out of the incubator and continue as an open-source project on
> java.net (or another location that doesn't have LGPL restrictions).
> 
> Matt
> 
> On 11/7/05, Anil Gangolli <an...@busybuddha.org> wrote:
> > Inline comments below...
> > Henri Yandell wrote:
> >
> > >
> > >For 2.0 I think we should be trying to get a clear LGPL message, or
> > >proto-message; and get things dealt with prior to the release.
> > >
> > >Effectively this means:
> > >
> > >1) Removing 'bad' jars from SVN.
> > >2) Modifying install process/build instructions to instruct user to
> > >download the relevant jars themselves.
> > >
> > >
> > For item (2), I'd like to understand the boundary of what we can do.
> > For example, can we provide ant scripts / other build infrastructure
> > that is generic, and configured specifically to download these jars?  If
> > so, we should start building a network-based pre-build target and an
> > installer in the Roller 2.x line.
> >
> >
> > >3) Ensuring nobody is concerned with the various usages of LGPL'd code.
> > >
> > >Hen
> > >
> > >
> > For Hibernate, we do import org.hibernate.* classes and use Hibernate
> > APIs directly currently.  So we are currently in the "worst" category of
> > "offenders".
> >
> > A JSR-220-based rewrite would entail quite a bit of effort for 2.0, and
> > I think will force us to require Java 5 / JDK 1.5.x.  The main thing
> > that bugs me about this direction is the cramped timing with respect to
> > the maturity levels of JSR 220 and the Hibernate support for it,
> > although alternate supporting implementations might be considered along
> > this line as well.
> >
> >
> >


Re: Legal worries... Was: Roller 1.3 release

Posted by Matt Raible <mr...@gmail.com>.
I know that having Roller as an Apache project is important for Dave
and Sun.  However, I think it's important to state my opinion.  If
it's going to require a significant re-write of Roller - my vote is to
back out of the incubator and continue as an open-source project on
java.net (or another location that doesn't have LGPL restrictions).

Matt

On 11/7/05, Anil Gangolli <an...@busybuddha.org> wrote:
> Inline comments below...
> Henri Yandell wrote:
>
> >
> >For 2.0 I think we should be trying to get a clear LGPL message, or
> >proto-message; and get things dealt with prior to the release.
> >
> >Effectively this means:
> >
> >1) Removing 'bad' jars from SVN.
> >2) Modifying install process/build instructions to instruct user to
> >download the relevant jars themselves.
> >
> >
> For item (2), I'd like to understand the boundary of what we can do.
> For example, can we provide ant scripts / other build infrastructure
> that is generic, and configured specifically to download these jars?  If
> so, we should start building a network-based pre-build target and an
> installer in the Roller 2.x line.
>
>
> >3) Ensuring nobody is concerned with the various usages of LGPL'd code.
> >
> >Hen
> >
> >
> For Hibernate, we do import org.hibernate.* classes and use Hibernate
> APIs directly currently.  So we are currently in the "worst" category of
> "offenders".
>
> A JSR-220-based rewrite would entail quite a bit of effort for 2.0, and
> I think will force us to require Java 5 / JDK 1.5.x.  The main thing
> that bugs me about this direction is the cramped timing with respect to
> the maturity levels of JSR 220 and the Hibernate support for it,
> although alternate supporting implementations might be considered along
> this line as well.
>
>
>

Re: Legal worries... Was: Roller 1.3 release

Posted by Anil Gangolli <an...@busybuddha.org>.
Inline comments below...
Henri Yandell wrote:

>
>For 2.0 I think we should be trying to get a clear LGPL message, or
>proto-message; and get things dealt with prior to the release.
>
>Effectively this means:
>
>1) Removing 'bad' jars from SVN.
>2) Modifying install process/build instructions to instruct user to
>download the relevant jars themselves.
>  
>
For item (2), I'd like to understand the boundary of what we can do.  
For example, can we provide ant scripts / other build infrastructure 
that is generic, and configured specifically to download these jars?  If 
so, we should start building a network-based pre-build target and an 
installer in the Roller 2.x line.


>3) Ensuring nobody is concerned with the various usages of LGPL'd code.
>
>Hen
>  
>
For Hibernate, we do import org.hibernate.* classes and use Hibernate 
APIs directly currently.  So we are currently in the "worst" category of 
"offenders".

A JSR-220-based rewrite would entail quite a bit of effort for 2.0, and 
I think will force us to require Java 5 / JDK 1.5.x.  The main thing 
that bugs me about this direction is the cramped timing with respect to 
the maturity levels of JSR 220 and the Hibernate support for it, 
although alternate supporting implementations might be considered along 
this line as well. 



Legal worries... Was: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
(Dropped the PMC, sorry, resending).

On 11/6/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> On Nov 6, 2005, at 1:16 PM, Justin Erenkrantz wrote:
> > On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
> >> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not
> >> meant
> >> to have these in SVN, and that the imports on the LGPL jars are not
> >> meant
> >> to be in SVN either.
> >
> > Correct.  The official ASF policy today is "No LGPL dependencies in
> > Java
> > projects."  As you mention, the board has discussed allowing LGPL for
> > Java projects but any resolution stating that has been tabled
> > indefinitely.  A small part of the reason for the delay is that we've
> > been told Eben Moglen from the FSF will be issuing an opinion
> > clarifying
> > the relationship between LGPL and Java.
>
> We in the Roller project and the Apache folks who helped usher us into
> the Incubator were all well aware of Roller's dependence on LGPL
> libraries. When we voted to move Roller to Apache, we all knew that
> work would have to be done to resolve the LGPL issue.  We also
> discussed the worst-case scenario of replacing Hibernate with JDO or
> something similar.

The thinking is that we can replace Hibernate with the JSR-xxx API.
Then Hibernate would be much like using a JDBC driver.

> We heard that a new LGPL policy was forthcoming, so
> we entered the incubator and crossed our fingers hoping for the best.
>
> I keep on hearing different proposed LGPL policies, so I'm pretty
> confused at this point.

It's confusing. I'll buy you a beer in San Diego and bring you up to
date on however things are then.

> In the interim, we still need to ship releases to our users. Roller 1.3
> is ready for release and Roller 2.0 is close on it's heels. If we've
> really painted ourselves into a corner and can't make releases through
> either the ASF or Java.Net, then we should back out of the Incubator
> and come back later when ASF has figured out an LGPL policy.

There's no reason to my mind why we can't release through Java.Net. It
leaves a bad taste in some people's mouths for committers to release
forks (which in essence this would be); and yet we fight for the right
for companies to be able to re-release/fork our code. Anyone who
complains need merely be invited to submit some patches to solve the
LGPL issue :)

The important part to figure out is whether the previous release was
correct. We need to make sure it's not called Apache Xxxxat all, and
make sure we include "This code based on Apache code" type of
messages.

> I really REALLY don't want to do that, so can we please get a green
> light to ship interim "incubating" releases through Java.Net?

+1. It's the only way forward for 1.3.

We need to kill the bad jars from SVN asap; but hopefully we can make
a java.net release more asap than killing the bad jars. Any open
issues with 1.3 apart from the LGPL stuff?

For 2.0 I think we should be trying to get a clear LGPL message, or
proto-message; and get things dealt with prior to the release.

Effectively this means:

1) Removing 'bad' jars from SVN.
2) Modifying install process/build instructions to instruct user to
download the relevant jars themselves.
3) Ensuring nobody is concerned with the various usages of LGPL'd code.

Hen

Re: Legal worries... Was: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
On 11/6/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> On Nov 6, 2005, at 1:16 PM, Justin Erenkrantz wrote:
> > On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
> >> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not
> >> meant
> >> to have these in SVN, and that the imports on the LGPL jars are not
> >> meant
> >> to be in SVN either.
> >
> > Correct.  The official ASF policy today is "No LGPL dependencies in
> > Java
> > projects."  As you mention, the board has discussed allowing LGPL for
> > Java projects but any resolution stating that has been tabled
> > indefinitely.  A small part of the reason for the delay is that we've
> > been told Eben Moglen from the FSF will be issuing an opinion
> > clarifying
> > the relationship between LGPL and Java.
>
> We in the Roller project and the Apache folks who helped usher us into
> the Incubator were all well aware of Roller's dependence on LGPL
> libraries. When we voted to move Roller to Apache, we all knew that
> work would have to be done to resolve the LGPL issue.  We also
> discussed the worst-case scenario of replacing Hibernate with JDO or
> something similar.

The thinking is that we can replace Hibernate with the JSR-xxx API.
Then Hibernate would be much like using a JDBC driver.

> We heard that a new LGPL policy was forthcoming, so
> we entered the incubator and crossed our fingers hoping for the best.
>
> I keep on hearing different proposed LGPL policies, so I'm pretty
> confused at this point.

It's confusing. I'll buy you a beer in San Diego and bring you up to
date on however things are then.

> In the interim, we still need to ship releases to our users. Roller 1.3
> is ready for release and Roller 2.0 is close on it's heels. If we've
> really painted ourselves into a corner and can't make releases through
> either the ASF or Java.Net, then we should back out of the Incubator
> and come back later when ASF has figured out an LGPL policy.

There's no reason to my mind why we can't release through Java.Net. It
leaves a bad taste in some people's mouths for committers to release
forks (which in essence this would be); and yet we fight for the right
for companies to be able to re-release/fork our code. Anyone who
complains need merely be invited to submit some patches to solve the
LGPL issue :)

The important part to figure out is whether the previous release was
correct. We need to make sure it's not called Apache Xxxxat all, and
make sure we include "This code based on Apache code" type of
messages.

> I really REALLY don't want to do that, so can we please get a green
> light to ship interim "incubating" releases through Java.Net?

+1. It's the only way forward for 1.3.

We need to kill the bad jars from SVN asap; but hopefully we can make
a java.net release more asap than killing the bad jars. Any open
issues with 1.3 apart from the LGPL stuff?

For 2.0 I think we should be trying to get a clear LGPL message, or
proto-message; and get things dealt with prior to the release.

Effectively this means:

1) Removing 'bad' jars from SVN.
2) Modifying install process/build instructions to instruct user to
download the relevant jars themselves.
3) Ensuring nobody is concerned with the various usages of LGPL'd code.

Hen

Re: Legal worries... Was: Roller 1.3 release

Posted by Cliff Schmidt <cl...@apache.org>.
On Nov 6, 2005, at 2:24 PM, Dave Johnson wrote:

> On Nov 6, 2005, at 1:16 PM, Justin Erenkrantz wrote:
>> On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
>>> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're  
>>> not meant
>>> to have these in SVN, and that the imports on the LGPL jars are  
>>> not meant
>>> to be in SVN either.
>>
>> Correct.  The official ASF policy today is "No LGPL dependencies  
>> in Java
>> projects."  As you mention, the board has discussed allowing LGPL for
>> Java projects but any resolution stating that has been tabled
>> indefinitely.  A small part of the reason for the delay is that we've
>> been told Eben Moglen from the FSF will be issuing an opinion  
>> clarifying
>> the relationship between LGPL and Java.
>
> We in the Roller project and the Apache folks who helped usher us  
> into the Incubator were all well aware of Roller's dependence on  
> LGPL libraries. When we voted to move Roller to Apache, we all knew  
> that work would have to be done to resolve the LGPL issue.  We also  
> discussed the worst-case scenario of replacing Hibernate with JDO  
> or something similar. We heard that a new LGPL policy was  
> forthcoming, so we entered the incubator and crossed our fingers  
> hoping for the best.
 >
> I keep on hearing different proposed LGPL policies, so I'm pretty  
> confused at this point. One proposed policy said that we can depend  
> on LGPL, but we can't ship it. Another said that we can ship LGPL  
> jars, but we can't have a "hard" dependency on them. So I'm all for  
> resolving the LGPL issues but I want to see the new policy first.  
> We've got a lot of features on our TODO list and I really don't  
> want to do unnecessary work.  Please put the LGPL issue back on the  
> table. We need a resolution.

And I apologize that this policy has taken as long as it has.  The  
easy part for me was doing the research to understand the LGPL  
incompatibility issues.    The hard part was getting consensus across  
the ASF about what other-licensed software we should be taking  
dependencies on and/or distributing.  I've already tried solving the  
LGPL issue in a one-off style, and it was rejected.  I now realize  
the only way to deal with the LGPL issue is to get some solid  
licensing principles ratified by the board, based on a policy that  
has more consensus than anything that has been proposed so far.

So, I'm not sure if this seems like too far from now for you, but I  
am committed to getting something formally agreed upon and announced  
by ApacheCon, on 12 Dec -- five weeks from tomorrow.

Cliff

> In the interim, we still need to ship releases to our users. Roller  
> 1.3 is ready for release and Roller 2.0 is close on it's heels. If  
> we've really painted ourselves into a corner and can't make  
> releases through either the ASF or Java.Net, then we should back  
> out of the Incubator and come back later when ASF has figured out  
> an LGPL policy.
>
> I really REALLY don't want to do that, so can we please get a green  
> light to ship interim "incubating" releases through Java.Net?
>
> - Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@incubator.apache.org
> For additional commands, e-mail: pmc-help@incubator.apache.org
>


Re: Legal worries... Was: Roller 1.3 release

Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 6, 2005, at 1:16 PM, Justin Erenkrantz wrote:
> On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
>> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not 
>> meant
>> to have these in SVN, and that the imports on the LGPL jars are not 
>> meant
>> to be in SVN either.
>
> Correct.  The official ASF policy today is "No LGPL dependencies in 
> Java
> projects."  As you mention, the board has discussed allowing LGPL for
> Java projects but any resolution stating that has been tabled
> indefinitely.  A small part of the reason for the delay is that we've
> been told Eben Moglen from the FSF will be issuing an opinion 
> clarifying
> the relationship between LGPL and Java.

We in the Roller project and the Apache folks who helped usher us into 
the Incubator were all well aware of Roller's dependence on LGPL 
libraries. When we voted to move Roller to Apache, we all knew that 
work would have to be done to resolve the LGPL issue.  We also 
discussed the worst-case scenario of replacing Hibernate with JDO or 
something similar. We heard that a new LGPL policy was forthcoming, so 
we entered the incubator and crossed our fingers hoping for the best.

I keep on hearing different proposed LGPL policies, so I'm pretty 
confused at this point. One proposed policy said that we can depend on 
LGPL, but we can't ship it. Another said that we can ship LGPL jars, 
but we can't have a "hard" dependency on them. So I'm all for resolving 
the LGPL issues but I want to see the new policy first. We've got a lot 
of features on our TODO list and I really don't want to do unnecessary 
work.  Please put the LGPL issue back on the table. We need a 
resolution.

In the interim, we still need to ship releases to our users. Roller 1.3 
is ready for release and Roller 2.0 is close on it's heels. If we've 
really painted ourselves into a corner and can't make releases through 
either the ASF or Java.Net, then we should back out of the Incubator 
and come back later when ASF has figured out an LGPL policy.

I really REALLY don't want to do that, so can we please get a green 
light to ship interim "incubating" releases through Java.Net?

- Dave


Re: Legal worries... Was: Roller 1.3 release

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not meant 
> to have these in SVN, and that the imports on the LGPL jars are not meant 
> to be in SVN either.

Correct.  The official ASF policy today is "No LGPL dependencies in Java
projects."  As you mention, the board has discussed allowing LGPL for
Java projects but any resolution stating that has been tabled
indefinitely.  A small part of the reason for the delay is that we've
been told Eben Moglen from the FSF will be issuing an opinion clarifying
the relationship between LGPL and Java.

However, none of the board's discussions around LGPL have discussed
allowing any LGPL code to be checked into the ASF Subversion repository.

What has been discussed is allowing an ASF project, under the ALv2
license, to optionally *use* but not *distribute* LGPL code.  If a
project requires LGPL code to operate, the board has discussed a
one-year exception to remove that hard dependency.

Plus, if an ASF project wants to use an LGPL library, end users will
have to fetch the LGPL dependencies themselves.

However, none of this has been approved by the Board.  There might be
some eventual wiggle room in allowing re-distribution in end-user
releases, but that would have to be hammered out.  -- justin

Re: Legal worries... Was: Roller 1.3 release

Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 6, 2005, at 3:12 PM, Henri Yandell wrote:

>
>
> On Sun, 6 Nov 2005, Geir Magnusson Jr. wrote:
>
>
>>
>> On Nov 6, 2005, at 1:10 PM, Noel J. Bergman wrote:
>>
>>
>>> Henri Yandell wrote:
>>> The BCL files are forbidden by that license to be in source  
>>> control, and
>>> must be removed.  They *are* permitted to be distributed in a  
>>> package.  The
>>> same issue exists for JAMES, Tomcat, and many other packages.  At  
>>> some point
>>> in the future, they should not be an issue, as Sun's new versions  
>>> will be
>>> under a more open license.
>>>
>>
>> Why?  The BCL requires us (and our users) to indemnify Sun.   
>> That's now acceptable?
>>
>
> Something for you to continue to push on legal-discuss/board etc  
> Geir. The current policy that I've seen repeated is that we can  
> ship as a package, but not individually or put in svn (unsure if  
> that's because putting in svn would mean ship individually).

Ug.  Yes, the license prevents distribution outside of the program  
that uses it, hence no CVS/SVN.  When I was focused on this with Sun,  
they did offer to give us permission to keep in SVN/CVS because that  
was part of our bona fide open source development process, rather  
than a distribution system.

We got rid of the field of use problem (no use in nukes...) but never  
could get past the indemnification.

>
> Until we have an official policy on it, the community policy is all  
> we have to work with; so another one for Cliff's TODO list to get  
> ironed out :)
>

Yes, I'll certainly defer to Cliff on this one.

geir


> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@incubator.apache.org
> For additional commands, e-mail: pmc-help@incubator.apache.org
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Re: Legal worries... Was: Roller 1.3 release

Posted by Henri Yandell <ba...@generationjava.com>.

On Sun, 6 Nov 2005, Geir Magnusson Jr. wrote:

>
> On Nov 6, 2005, at 1:10 PM, Noel J. Bergman wrote:
>
>> Henri Yandell wrote:
>> 
>> The BCL files are forbidden by that license to be in source control, and
>> must be removed.  They *are* permitted to be distributed in a package.  The
>> same issue exists for JAMES, Tomcat, and many other packages.  At some 
>> point
>> in the future, they should not be an issue, as Sun's new versions will be
>> under a more open license.
>
> Why?  The BCL requires us (and our users) to indemnify Sun.  That's now 
> acceptable?

Something for you to continue to push on legal-discuss/board etc Geir. The 
current policy that I've seen repeated is that we can ship as a package, 
but not individually or put in svn (unsure if that's because putting in 
svn would mean ship individually).

Until we have an official policy on it, the community policy is all we 
have to work with; so another one for Cliff's TODO list to get ironed out 
:)

Hen

Re: Legal worries... Was: Roller 1.3 release

Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 6, 2005, at 1:10 PM, Noel J. Bergman wrote:

> Henri Yandell wrote:
>
>> We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
>> activation) jars in there.
>>
>
>
>> jta and jdbc-stdext are BCL.
>>
>
>
>> hibernate is LGPL.
>>
>
> The BCL files are forbidden by that license to be in source  
> control, and
> must be removed.  They *are* permitted to be distributed in a  
> package.  The
> same issue exists for JAMES, Tomcat, and many other packages.  At  
> some point
> in the future, they should not be an issue, as Sun's new versions  
> will be
> under a more open license.

Why?  The BCL requires us (and our users) to indemnify Sun.  That's  
now acceptable?

>
> MySQL must be the OLD LGPL driver, and is "safe" because it is  
> invoked via
> the generic JDBC interface.  The new GPL driver is forbidden  
> because our
> legal advice to date was that MySQL's "FOSS" exception was flawed and
> inadequate.  That should be put to Cliff to raise with MySQL, but  
> he doesn't
> appear to be around right now.
>
> I cannot comment on the other LGPL code beyond the current  
> discussions,
> which have yet to be ratified.
>
>
>> I believe that projects will be given a timeframe with which to  
>> eliminate
>> LGPL dependencies.  It isn't a legal (as in viral) so much as policy
>>
> issue.
>
>
>> We (roller-dev) will also need the Incubator PMC to create  
>> 'appropriate
>> notices', depending on what you mean by that.
>>
>
> The standard Incubator disclaimer, plus notice of any license other  
> than the
> Apache License.
>
>
>> how do I explain this to Cliff
>>
>
> Cliff should understand this well.  If he is around, we can try to  
> push
> through a ratified policy.
>
>     --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@incubator.apache.org
> For additional commands, e-mail: pmc-help@incubator.apache.org
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



RE: Legal worries... Was: Roller 1.3 release

Posted by "Noel J. Bergman" <no...@devtech.com>.
Henri Yandell wrote:
> We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
> activation) jars in there.

> jta and jdbc-stdext are BCL.

> hibernate is LGPL.

The BCL files are forbidden by that license to be in source control, and
must be removed.  They *are* permitted to be distributed in a package.  The
same issue exists for JAMES, Tomcat, and many other packages.  At some point
in the future, they should not be an issue, as Sun's new versions will be
under a more open license.

MySQL must be the OLD LGPL driver, and is "safe" because it is invoked via
the generic JDBC interface.  The new GPL driver is forbidden because our
legal advice to date was that MySQL's "FOSS" exception was flawed and
inadequate.  That should be put to Cliff to raise with MySQL, but he doesn't
appear to be around right now.

I cannot comment on the other LGPL code beyond the current discussions,
which have yet to be ratified.

> I believe that projects will be given a timeframe with which to eliminate
> LGPL dependencies.  It isn't a legal (as in viral) so much as policy
issue.

> We (roller-dev) will also need the Incubator PMC to create 'appropriate
> notices', depending on what you mean by that.

The standard Incubator disclaimer, plus notice of any license other than the
Apache License.

> how do I explain this to Cliff

Cliff should understand this well.  If he is around, we can try to push
through a ratified policy.

	--- Noel


Legal worries... Was: Roller 1.3 release

Posted by Henri Yandell <ba...@generationjava.com>.
Problems, problems. Which I really hate to bring up as I want Roller to 
succeed as an Apache project as much as anyone.

http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/lib/

We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail, 
activation) jars in there.

http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/hibernate-3.0/lib/

jta and jdbc-stdext are BCL.

http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/hibernate-3.0/

hibernate is LGPL.

----

So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not meant 
to have these in SVN, and that the imports on the LGPL jars are not meant 
to be in SVN either.

Now I know that this was well known before Roller joined, so what's the 
status of this? What I've read on legal-discuss/board is not the same as 
the message we're giving Roller, so I'm confused. On roller-dev, Noel has 
said:

"Check with Cliff, but I believe that projects will be given a timeframe 
with which to eliminate LGPL dependencies.  It isn't a legal (as in viral) 
so much as policy issue.  We would certainly need appropriate notices, in 
addition to the Incubator disclaimer."

As far as I know, that's for the imports not for the inclusion in 
distributions/SVN. It's also going through one of its customary 
dead-in-the-water periods regarding becoming new policy.

We (roller-dev) will also need the Incubator PMC to create 'appropriate 
notices', depending on what you mean by that. [I'm a part of both, so this 
isn't me shirking work :) ].

So what's the deal? How do I make a release of Roller, ie) what needs to 
be different from a normal release; and how do I explain this to Cliff 
without it sounding like we're ignoring the lawyers.

Hen

Re: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
[cc'ing incubator-pmc as this is definitely an issue for them instead
of just roller-dev]

On 11/4/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> I hope/don't think we need a final statement on LGPL policy before we
> ship
> Roller 1.3 and Roller 2.0.  We get can that later, we just need a green
> light
> to ship an officially unofficial and unendorsed release. I thought we
> had that.

An 'officially unofficial and unendorsed release' isn't a concept I
know of, so this isn't just my being worried about whether we'll get
in trouble over the LGPL dependency, I need to figure out how/where
you would release such a release.

Currently it'd be putting the files in
http://people.apache.org/~snoopdave/ and mentioning it on the
roller-dev list (but not -user list). Effectively exactly what you've
done already except you need to make a public_html directory on
people.apache.org to put them in.

Once you start announcing things though, it's effectively official.
Given that, you might as well just declare a tag in subversion and let
the Sun and JRoller admins know to build from that tag (presuming
they're the major ones waiting for it).

That's a pretty nifty way of getting around the whole problem :) Why
even do binary releases, just point to tags in SVN and tell people to
check them out. Given that they just want to check out a read-only
copy, they don't even need SVN, they can mount the drive over webdav.
Install instructions become:

Mount http://svn.apache.org/..... (easy on Win/Mac, unsure on Linux)
cd into dir
run 'build all'

Might have to cp -r the mounted directory; unsure if the build all
would piss things off royally.

Which is one reason why having stuff in CVS/SVN is effectively
distributing and just by having the hibernate jar in there we must
already have some kind of permission to distribute. Aargh. This stuff
messes with your head I swear.

> Anyhow, I'm cool with another Java.Net release, I just want to get the
> code out to the folks who're waiting for it.

Right, my wife wants to get her blog back :) (her 0.9.x one is messed
up somehow and I'm waiting on 1.3 to do an upgrade and get it fixed).
So I'm definitely motivated for a release.

Hen

Re: Roller 1.3 release

Posted by Dave Johnson <da...@rollerweblogger.org>.
I hope/don't think we need a final statement on LGPL policy before we 
ship
Roller 1.3 and Roller 2.0.  We get can that later, we just need a green 
light
to ship an officially unofficial and unendorsed release. I thought we 
had that.
Anyhow, I'm cool with another Java.Net release, I just want to get the
code out to the folks who're waiting for it.

- Dave


On Nov 4, 2005, at 5:21 PM, Henri Yandell wrote:

> I understand it, but I'm also aware that it doesn't seem to have board
> consensus yet. It seems to be a big issue for us doing an ASF release,
> so I'll keep pushing.
>
> Although it's frowned on, there is nothing wrong with releasing at
> java.net again, provided we do it right. Effectively we're forking the
> project on paper (but as it's the same community forking it, it's not
> the fear that would usually associate with the word fork). It'll be
> interesting to define exactly how you fork something. ie) you can't
> claim to be the ASF, but I presume that you don't have to remove
> 'apache' from the package names.
>
> Anyway, I'll keep pushing. I've not heard back from Cliff yet, but
> there's a balance between the politeness of hassling.
>
> Hen
>
> On 11/4/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>> Max respect Noel, but I don't really understand the path forward on
>> LGPL components in Apache projects. I have heard conflicting stories
>> from different people and never seen a definitive/final statement of
>> the policy. So I'd be *very* happy to see an official policy 
>> statement.
>>
>> - Dave
>>
>>
>> On Nov 3, 2005, at 3:03 PM, Noel J. Bergman wrote:
>>>> as far as I know we've not announced ...
>>>
>>> Then push back via Cliff.  IMO, we understand the issues reasonably
>>> well
>>> enough to allow things to proceed.  Dave already understands, and the
>>> rest
>>> of the Roller community need to understand, the path forward.
>>>
>>>       --- Noel
>>>
>>
>>
>


Re: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
I understand it, but I'm also aware that it doesn't seem to have board
consensus yet. It seems to be a big issue for us doing an ASF release,
so I'll keep pushing.

Although it's frowned on, there is nothing wrong with releasing at
java.net again, provided we do it right. Effectively we're forking the
project on paper (but as it's the same community forking it, it's not
the fear that would usually associate with the word fork). It'll be
interesting to define exactly how you fork something. ie) you can't
claim to be the ASF, but I presume that you don't have to remove
'apache' from the package names.

Anyway, I'll keep pushing. I've not heard back from Cliff yet, but
there's a balance between the politeness of hassling.

Hen

On 11/4/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> Max respect Noel, but I don't really understand the path forward on
> LGPL components in Apache projects. I have heard conflicting stories
> from different people and never seen a definitive/final statement of
> the policy. So I'd be *very* happy to see an official policy statement.
>
> - Dave
>
>
> On Nov 3, 2005, at 3:03 PM, Noel J. Bergman wrote:
> >> as far as I know we've not announced ...
> >
> > Then push back via Cliff.  IMO, we understand the issues reasonably
> > well
> > enough to allow things to proceed.  Dave already understands, and the
> > rest
> > of the Roller community need to understand, the path forward.
> >
> >       --- Noel
> >
>
>

Re: Roller 1.3 release

Posted by Dave Johnson <da...@rollerweblogger.org>.
Max respect Noel, but I don't really understand the path forward on 
LGPL components in Apache projects. I have heard conflicting stories 
from different people and never seen a definitive/final statement of 
the policy. So I'd be *very* happy to see an official policy statement.

- Dave


On Nov 3, 2005, at 3:03 PM, Noel J. Bergman wrote:
>> as far as I know we've not announced ...
>
> Then push back via Cliff.  IMO, we understand the issues reasonably 
> well
> enough to allow things to proceed.  Dave already understands, and the 
> rest
> of the Roller community need to understand, the path forward.
>
> 	--- Noel
>


RE: Roller 1.3 release

Posted by "Noel J. Bergman" <no...@devtech.com>.
> as far as I know we've not announced ...

Then push back via Cliff.  IMO, we understand the issues reasonably well
enough to allow things to proceed.  Dave already understands, and the rest
of the Roller community need to understand, the path forward.

	--- Noel


Re: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
On 11/3/05, Noel J. Bergman <no...@devtech.com> wrote:
> > My worry is that we'll be hammered for releasing with LGPL via the
> > ASF
>
> Check with Cliff, but I believe that projects will be given a timeframe with
> which to eliminate LGPL dependencies.  It isn't a legal (as in viral) so
> much as policy issue.  We would certainly need appropriate notices, in
> addition to the Incubator disclaimer.

Right. But as far as I know we've not announced that LGPL isn't a
legal issue; and we've not announced the new policy?

Either a) any idea if it's just been quietly announced or I've simply
missed it, or b) is Roller free to assume the legal issue is fully
cleared up?

Hen

RE: Roller 1.3 release

Posted by "Noel J. Bergman" <no...@devtech.com>.
> My worry is that we'll be hammered for releasing with LGPL via the
> ASF

Check with Cliff, but I believe that projects will be given a timeframe with
which to eliminate LGPL dependencies.  It isn't a legal (as in viral) so
much as policy issue.  We would certainly need appropriate notices, in
addition to the Incubator disclaimer.

As I understand it, one future direction could be to use JSR 220 as the API,
since the Hibernate folks will provide Hibernate as an implementation of the
standard.

  ref: http://www.jcp.org/en/jsr/detail?id=220

	--- Noel


Re: Roller 1.3 release

Posted by Anil Gangolli <an...@busybuddha.org>.
I spent some time searching for Dave's binary distribution tarball and 
finally found it in his home dir, so you have to scp it down, which is 
probably better for now anyway.

Yes, I had forgotten about the new theme management stuff being in 1.3; 
I was thinking it was in 2.x only.

I did a from-scratch installation without problems.  I was using the 
dist before Dave patched it.  On MySQL, I hit no issue with the null. 

I haven't tried an upgrade installation yet; the upgrade is usually 
where issues seem to arise so I think we should be testing that.  I hope 
to do that this evening, at least from 1.2.

--a.

Re: Roller 1.3 release

Posted by Anil Gangolli <an...@busybuddha.org>.
Dave Johnson wrote:

>
> On Nov 4, 2005, at 11:52 AM, Anil Gangolli wrote:
>
>> Dave,  I'd just like to try an upgrade install test with this before 
>> releasing.  I just downloaded it a while ago.  I may need to get the 
>> latest to retest.
>
>
> Much appreciated! - Dave
>
>
Hi.  I did an upgrade install test; it worked with the following 
confusion:  one inevitably will get an error running the db migration 
script.  Both forms of statement to drop the "not null" restriction on 
defaultpageid are present for each database (see below).   It works with 
an error message as long as the proper form for your database is first, 
or if whatever you use to execute the script will skip over the error 
without stopping; otherwise you never get to the working one.   To be 
safe in general, the user has to comment out the wrong one; are we 
providing instructions to do this? 

Clearly, I didn't realize we were doing this.  For 2.0 and beyond, I 
suggest we use Velocity not Ant filters to preprocess these in our 
build.  This will allow us to use conditionals in the "raw" one to get 
the right form in each expanded one.  There may be a way to do this with 
Ant filters too, but I don't know; if it is indeed easy to fix for 1.3, 
we should consider fixing it.

--a.

--------
Transcript of my db upgrade follows:

mysql> use roller;
Database changed
mysql> source 120-to-130-migration.sql
Query OK, 2 rows affected (0.45 sec)
Records: 2  Duplicates: 0  Warnings: 0

ERROR 1064 (42000): You have an error in your SQL syntax; check the 
manual that
corresponds to your MySQL server version for the right syntax to use 
near 'not n
ull' at line 1
mysql> quit
Bye

THAT WAS ACTUALLY A SUCCESSFUL RUN.


C:\jakarta-tomcat-5.5.7\webapps\blog\WEB-INF\dbscripts\mysql>more 
120-to-130-migration.sql

-- Upgrading from 1.2 to 1.3 requires one small change. The website table
-- column defaultpageid is now allowed to be null. Unfortunately, MySQL
-- requires non-standard alter table syntax for this.

-- So if you're on MySQL do this:
alter table website modify defaultpageid varchar(48);

-- And for all other databases do this:
alter table website alter column defaultpageid drop not null;


Re: Roller 1.3 release

Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 4, 2005, at 11:52 AM, Anil Gangolli wrote:
> Dave,  I'd just like to try an upgrade install test with this before 
> releasing.  I just downloaded it a while ago.  I may need to get the 
> latest to retest.

Much appreciated! - Dave


Re: Roller 1.3 release

Posted by Anil Gangolli <an...@busybuddha.org>.
Dave,  I'd just like to try an upgrade install test with this before 
releasing.  I just downloaded it a while ago.  I may need to get the 
latest to retest.

--a.


Dave Johnson wrote:

> I made a slight change to the 120-130 database migration script and 
> added some additional disclaimers to the Roller 1.3 release files in 
> ~snoopdave at people.apache.org. I contend that the files are ready 
> for release.
>
> - Dave
>
>
> Below is the start of the README.txt file include in the release.
> Note the incubation and LGPL disclaimers.
>
>
> README.txt
>
>    This release of Roller is not endorsed by the Apache Software 
> Foundation.
>    Roller is in the Apache Incubator and is not an official Apache 
> project.
>
>    To install Roller, follow the instructions in the Installation Guide:
>    http://rollerweblogger.org/wiki/Wiki.jsp?page=InstallationGuide
>
>    To use Roller, follow the instructions in the Users Guide:
>    http://rollerweblogger.org/wiki/Wiki.jsp?page=UserGuide
>
> LICENSING TERMS
>
>    Roller is licensed under the Apache Licence Version 2.0, please see
>    the included file LICENSE.txt for the full text of the Apache license.
>
>    PLEASE NOTE: Roller contains some components that are licensed 
> under the
>    terms of the LGPL licence.
>
>


Re: Roller 1.3 release

Posted by paksegu <pa...@yahoo.com>.
Is the anyway we can make Roller 1.3 released under java.net till all the legal issues has been resolve then move that release to Apache?
Thanks

Dave Johnson <da...@rollerweblogger.org> wrote:
I made a slight change to the 120-130 database migration script and 
added some additional disclaimers to the Roller 1.3 release files in 
~snoopdave at people.apache.org. I contend that the files are ready for 
release.

- Dave


Below is the start of the README.txt file include in the release.
Note the incubation and LGPL disclaimers.


README.txt

This release of Roller is not endorsed by the Apache Software 
Foundation.
Roller is in the Apache Incubator and is not an official Apache 
project.

To install Roller, follow the instructions in the Installation Guide:
http://rollerweblogger.org/wiki/Wiki.jsp?page=InstallationGuide

To use Roller, follow the instructions in the Users Guide:
http://rollerweblogger.org/wiki/Wiki.jsp?page=UserGuide

LICENSING TERMS

Roller is licensed under the Apache Licence Version 2.0, please see
the included file LICENSE.txt for the full text of the Apache 
license.

PLEASE NOTE: Roller contains some components that are licensed under 
the
terms of the LGPL licence.



Ransford Segu-Baffoe

paksegu@yahoo.com
paksegu@noqturnalmediasystems.com

http://www.noqturnalmediasystems.com/
		
---------------------------------
 Yahoo! FareChase - Search multiple travel sites in one click.  

Re: Roller 1.3 release

Posted by Dave Johnson <da...@rollerweblogger.org>.
I made a slight change to the 120-130 database migration script and 
added some additional disclaimers to the Roller 1.3 release files in 
~snoopdave at people.apache.org. I contend that the files are ready for 
release.

- Dave


Below is the start of the README.txt file include in the release.
Note the incubation and LGPL disclaimers.


README.txt

    This release of Roller is not endorsed by the Apache Software 
Foundation.
    Roller is in the Apache Incubator and is not an official Apache 
project.

    To install Roller, follow the instructions in the Installation Guide:
    http://rollerweblogger.org/wiki/Wiki.jsp?page=InstallationGuide

    To use Roller, follow the instructions in the Users Guide:
    http://rollerweblogger.org/wiki/Wiki.jsp?page=UserGuide

LICENSING TERMS

    Roller is licensed under the Apache Licence Version 2.0, please see
    the included file LICENSE.txt for the full text of the Apache 
license.

    PLEASE NOTE: Roller contains some components that are licensed under 
the
    terms of the LGPL licence.


Re: Roller 1.3 release

Posted by Allen Gilliland <Al...@Sun.COM>.
actually, the line you added to the upgrade script does not work with
mysql.  this is the same problem i had when attempting to alter the
datetime column to allow for null values, there is no database
independent manner for doing that.

[ag@unknown:/app/blogs/dev ] /app/mysql/bin/mysql -u roller -proller
roller_dev <
/export/home/workspace/roller_bsc/roller-1.3/build/roller/WEB-INF/dbscripts/mysql/120-to-130-migration.sql
ERROR 1064 (42000) at line 3: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near 'not null' at line 1

we are going to have to do that in a database independent fashion.

is it time we drop the "-raw" sql scripts and simply maintain different
scripts for each db?

-- Allen


On Tue, 2005-11-01 at 08:19, Dave Johnson wrote:
> I fixed that problem (ROL-869), did a new build and uploaded to my  
> space (~snoopdave) on people.apache.org just a couple of minutes ago.
> 
> - Dave
> 
> 
> On Nov 1, 2005, at 12:38 AM, Henri Yandell wrote:
> > I hit an error when I tried to run an update on the Website->Settings
> > page. I changed the editor, hit save and got a Hibernate error of:
> >
> > =========================================================
> > net.sf.hibernate.JDBCException: Could not execute JDBC batch update
> > Caused by: Batch entry 0 update website set name='Mr Testy\'s Weblog',
> > description='Mr Testy\'s Weblog',
> > userid='ff808081074a49d901074a4ac8770006', defaultpageid=null,
> > weblogdayid='dummy', enablebloggerapi='t',
> > bloggercatid='ff808081074a49d901074a4ac8840009',
> > defaultcatid='ff808081074a49d901074a4ac8840009',
> > editorpage='editor-dhtml.jsp', ignorewords='', allowcomments='t',
> > emailcomments='f', emailfromaddress='', editortheme='sotto',
> > locale='en_US', timezone='US/Eastern', defaultplugins='',
> > isenabled='t' where id='ff808081074a49d901074a4ac8830008' was aborted.
> > 	at org.postgresql.jdbc2.Statement.executeBatch(Statement.java:201)
> > 	at  
> > org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStat 
> > ement.java:294)
> > 	at  
> > net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.ja 
> > va:54)
> > =========================================================
> >
> > The only odd thing about the data on the page is that the default page
> > select box has nothing in it. Thus the null in defaultpageid. This is
> > a not-null in the database, so I'm guessing this is the problem.
> 
> 
> 
> 
> 
> >
> > ----
> >
> > I was able to modify the user settings (Website->User) without
> > entering a password.
> >
> > The right-to-left plugin didn't switch my text to be right to left,
> > but that could be because that's not what it does :)
> >
> > ----
> >
> > Otherwise things looked to be good. Just the one error that seems to
> > be a problem.
> >
> > Hen
> >
> 


Re: Roller 1.3 release

Posted by Dave Johnson <da...@rollerweblogger.org>.
I fixed that problem (ROL-869), did a new build and uploaded to my  
space (~snoopdave) on people.apache.org just a couple of minutes ago.

- Dave


On Nov 1, 2005, at 12:38 AM, Henri Yandell wrote:
> I hit an error when I tried to run an update on the Website->Settings
> page. I changed the editor, hit save and got a Hibernate error of:
>
> =========================================================
> net.sf.hibernate.JDBCException: Could not execute JDBC batch update
> Caused by: Batch entry 0 update website set name='Mr Testy\'s Weblog',
> description='Mr Testy\'s Weblog',
> userid='ff808081074a49d901074a4ac8770006', defaultpageid=null,
> weblogdayid='dummy', enablebloggerapi='t',
> bloggercatid='ff808081074a49d901074a4ac8840009',
> defaultcatid='ff808081074a49d901074a4ac8840009',
> editorpage='editor-dhtml.jsp', ignorewords='', allowcomments='t',
> emailcomments='f', emailfromaddress='', editortheme='sotto',
> locale='en_US', timezone='US/Eastern', defaultplugins='',
> isenabled='t' where id='ff808081074a49d901074a4ac8830008' was aborted.
> 	at org.postgresql.jdbc2.Statement.executeBatch(Statement.java:201)
> 	at  
> org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStat 
> ement.java:294)
> 	at  
> net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.ja 
> va:54)
> =========================================================
>
> The only odd thing about the data on the page is that the default page
> select box has nothing in it. Thus the null in defaultpageid. This is
> a not-null in the database, so I'm guessing this is the problem.





>
> ----
>
> I was able to modify the user settings (Website->User) without
> entering a password.
>
> The right-to-left plugin didn't switch my text to be right to left,
> but that could be because that's not what it does :)
>
> ----
>
> Otherwise things looked to be good. Just the one error that seems to
> be a problem.
>
> Hen
>


Re: Roller 1.3 release

Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 1, 2005, at 10:08 AM, Anil Gangolli wrote:
> Not sure how you got to a state where the default page id was empty.  
> In 1.x, this should always be non-null.  It typically points to the 
> Weblog.vm template.     Bad things happen in the theme selector if the 
> default page is not there. We make sure that you don't delete the 
> default page in the template editor either.

If you're using a shared (i.e. not "custom") theme, then the 
defaultpageid is not used and can be allowed to be null. So, just a 
couple of minutes ago, I fixed the bug in saving Website:Settings by 
adding ALTER TABLE commands to allow nulls in that field.

- Dave


Re: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
On 11/1/05, Anil Gangolli <an...@busybuddha.org> wrote:
> Henri Yandell wrote:
>
> >On 10/31/05, Anil Gangolli <an...@busybuddha.org> wrote:
> >
> >
> >>Henri Yandell wrote:
> >>
> >>
> >
> >
> >
> >>>Planning to take a look at them myself. Do a full Postgres install and
> >>>make sure it starts up okay etc.
> >>>
> >>>
> >>>
> >>>
> >>That, we should all do.
> >>
> >>
> >
> >Things went pretty well. Install easy as usual, it's a habit now so
> >I'm a bad tester of that nowadays :)
> >
> >I hit an error when I tried to run an update on the Website->Settings
> >page. I changed the editor, hit save and got a Hibernate error of:
> >
> >=========================================================
> >net.sf.hibernate.JDBCException: Could not execute JDBC batch update
> >Caused by: Batch entry 0 update website set name='Mr Testy\'s Weblog',
> >description='Mr Testy\'s Weblog',
> >userid='ff808081074a49d901074a4ac8770006', defaultpageid=null,
> >weblogdayid='dummy', enablebloggerapi='t',
> >bloggercatid='ff808081074a49d901074a4ac8840009',
> >defaultcatid='ff808081074a49d901074a4ac8840009',
> >editorpage='editor-dhtml.jsp', ignorewords='', allowcomments='t',
> >emailcomments='f', emailfromaddress='', editortheme='sotto',
> >locale='en_US', timezone='US/Eastern', defaultplugins='',
> >isenabled='t' where id='ff808081074a49d901074a4ac8830008' was aborted.
> >       at org.postgresql.jdbc2.Statement.executeBatch(Statement.java:201)
> >       at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:294)
> >       at net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:54)
> >=========================================================
> >
> >The only odd thing about the data on the page is that the default page
> >select box has nothing in it. Thus the null in defaultpageid. This is
> >a not-null in the database, so I'm guessing this is the problem.
> >
> >
> >
> Not sure how you got to a state where the default page id was empty.  In
> 1.x, this should always be non-null.  It typically points to the
> Weblog.vm template.     Bad things happen in the theme selector if the
> default page is not there.
> We make sure that you don't delete the default page in the template
> editor either.

I think I've been getting null default page ids with every 1.3
install; I'm pretty sure I've seen this error before.

The Theme selector seems to be working though.

> >I was able to modify the user settings (Website->User) without
> >entering a password.
> >
> >
> Are you sure you didn't have a Remember Me cookie set?

I was logged in. :)

UI made me assume that I would have to put my password in to make
changes to that data. Not a biggy as long as that's not the way it's
meant to be.

Hen

Re: Roller 1.3 release

Posted by Anil Gangolli <an...@busybuddha.org>.
Henri Yandell wrote:

>On 10/31/05, Anil Gangolli <an...@busybuddha.org> wrote:
>  
>
>>Henri Yandell wrote:
>>    
>>
>
>  
>
>>>Planning to take a look at them myself. Do a full Postgres install and
>>>make sure it starts up okay etc.
>>>
>>>
>>>      
>>>
>>That, we should all do.
>>    
>>
>
>Things went pretty well. Install easy as usual, it's a habit now so
>I'm a bad tester of that nowadays :)
>
>I hit an error when I tried to run an update on the Website->Settings
>page. I changed the editor, hit save and got a Hibernate error of:
>
>=========================================================
>net.sf.hibernate.JDBCException: Could not execute JDBC batch update
>Caused by: Batch entry 0 update website set name='Mr Testy\'s Weblog',
>description='Mr Testy\'s Weblog',
>userid='ff808081074a49d901074a4ac8770006', defaultpageid=null,
>weblogdayid='dummy', enablebloggerapi='t',
>bloggercatid='ff808081074a49d901074a4ac8840009',
>defaultcatid='ff808081074a49d901074a4ac8840009',
>editorpage='editor-dhtml.jsp', ignorewords='', allowcomments='t',
>emailcomments='f', emailfromaddress='', editortheme='sotto',
>locale='en_US', timezone='US/Eastern', defaultplugins='',
>isenabled='t' where id='ff808081074a49d901074a4ac8830008' was aborted.
>	at org.postgresql.jdbc2.Statement.executeBatch(Statement.java:201)
>	at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:294)
>	at net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:54)
>=========================================================
>
>The only odd thing about the data on the page is that the default page
>select box has nothing in it. Thus the null in defaultpageid. This is
>a not-null in the database, so I'm guessing this is the problem.
>
>  
>
Not sure how you got to a state where the default page id was empty.  In 
1.x, this should always be non-null.  It typically points to the 
Weblog.vm template.     Bad things happen in the theme selector if the 
default page is not there.
We make sure that you don't delete the default page in the template 
editor either.

>----
>
>I was able to modify the user settings (Website->User) without
>entering a password.
>  
>
Are you sure you didn't have a Remember Me cookie set?

>The right-to-left plugin didn't switch my text to be right to left,
>but that could be because that's not what it does :)
>
>----
>
>Otherwise things looked to be good. Just the one error that seems to
>be a problem.
>
>Hen
>  
>
My feeling is that the first two should be checked and fixed.  I'm doing 
my install test this morning...


Re: Roller 1.3 release

Posted by Henri Yandell <fl...@gmail.com>.
On 10/31/05, Anil Gangolli <an...@busybuddha.org> wrote:
> Henri Yandell wrote:

> >Planning to take a look at them myself. Do a full Postgres install and
> >make sure it starts up okay etc.
> >
> >
> That, we should all do.

Things went pretty well. Install easy as usual, it's a habit now so
I'm a bad tester of that nowadays :)

I hit an error when I tried to run an update on the Website->Settings
page. I changed the editor, hit save and got a Hibernate error of:

=========================================================
net.sf.hibernate.JDBCException: Could not execute JDBC batch update
Caused by: Batch entry 0 update website set name='Mr Testy\'s Weblog',
description='Mr Testy\'s Weblog',
userid='ff808081074a49d901074a4ac8770006', defaultpageid=null,
weblogdayid='dummy', enablebloggerapi='t',
bloggercatid='ff808081074a49d901074a4ac8840009',
defaultcatid='ff808081074a49d901074a4ac8840009',
editorpage='editor-dhtml.jsp', ignorewords='', allowcomments='t',
emailcomments='f', emailfromaddress='', editortheme='sotto',
locale='en_US', timezone='US/Eastern', defaultplugins='',
isenabled='t' where id='ff808081074a49d901074a4ac8830008' was aborted.
	at org.postgresql.jdbc2.Statement.executeBatch(Statement.java:201)
	at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:294)
	at net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:54)
=========================================================

The only odd thing about the data on the page is that the default page
select box has nothing in it. Thus the null in defaultpageid. This is
a not-null in the database, so I'm guessing this is the problem.

----

I was able to modify the user settings (Website->User) without
entering a password.

The right-to-left plugin didn't switch my text to be right to left,
but that could be because that's not what it does :)

----

Otherwise things looked to be good. Just the one error that seems to
be a problem.

Hen

Re: Roller 1.3 release

Posted by Anil Gangolli <an...@busybuddha.org>.
Henri Yandell wrote:

>On 10/31/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>  
>
>>On Oct 31, 2005, at 4:54 PM, Henri Yandell wrote:
>>    
>>
>>
>[ .. some stuff CUT OUT... ] 
>  
>
>>>* All problems with RC files fixed?
>>>      
>>>
>>Not sure what you mean.
>>    
>>
>
>The stuff Anil brought up; though I think those were to do with the
>wiki site instead of the actual release files. Basically a 'has
>someone looked at the tar.gz/zips, and do they appear to work' bit.
>
>  
>
Oh.  Yes, my comments were only to do with the wiki and they can be 
addressed afterwards if necessary.

[Can't resist saying that I'm a proponent of putting a doc subtree in 
the source tree and distributing it with each release, but that's a 
separate issue, and I don't think we're doing it (or considering it) 
right now.  We've discussed it before, and so far I'm the only real 
proponent.  I keep hoping for more converts.  Not pushing that right at 
this moment though. :-)]

>Planning to take a look at them myself. Do a full Postgres install and
>make sure it starts up okay etc.
>  
>
That, we should all do. 

>>>* Release tagged?
>>>      
>>>
>>No. I can do this part tonight.
>>    
>>
>
>Cool.
>
>Hen
>
>
>  
>


HELP!!! (was Re: Roller 1.3 release)

Posted by Dave Johnson <da...@rollerweblogger.org>.
On Oct 31, 2005, at 11:14 PM, Henri Yandell wrote:
> My worry is that we'll be hammered for releasing with LGPL via the
> ASF, and hammered for releasing outside the ASF. This'll be an
> official release as far as I understand; ie) we'll be putting it on
> the mirrors and announcing to some portion of the user community even
> if it's just those who read the wiki page.
>
> Cc'ing Noel as I don't think I got added to the Incubator PMC list (if
> I did then it's very, very quiet). Noel, what's your take on the
> status of this release?

What's the word? We need to resolve this ASAP.

- Dave