You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Les Hazlewood <lh...@apache.org> on 2010/06/01 19:01:24 UTC

[ANN] Apache Shiro 1.0.0-incubating Released!

Dear Apache Shiro Community,

We are proud and excited to offer Apache Shiro's first stable release
as an Apache Incubator podling!

Version 1.0.0-incubating is available immediately for download here:

http://incubator.apache.org/shiro/download.html

Associated documentation is available here:

http://incubator.apache.org/shiro/documentation.html

Release notes are included below.

Thank you so much to the Apache community and the Apache Incubator for
helping us move toward our first release.  A very special thanks goes
to our user community and early adopters for helping us refine our
first stable release.

Best Regards,

Les Hazlewood

------

Release Notes are browsable online here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310950&styleName=Html&version=12314078

And included here for convenience:

Release Notes - Shiro - Version 1.0.0-incubating

** Bug
    * [SHIRO-10] - Aliases in the ini configuration builder do not
work correctly
    * [SHIRO-82] - Shiro strips anchor (#) values from the URL if user
is unauthenticated
    * [SHIRO-87] - Fix package name of package-info.java in shiro-core
    * [SHIRO-89] - Sample Spring Application - WebStart won't launch
    * [SHIRO-95] - Specifying my own Cache in ShiroFilter not working
    * [SHIRO-101] - Comma in role in the properties file is not read
correctly by the PropertyRealm
    * [SHIRO-106] - AuthorizationFilter needs to use sendError not
setStatus to make container process the request through ERROR
dispatcher
    * [SHIRO-108] - Basic HTTP Auth: Empty password or username causes
IllegalStateException
    * [SHIRO-115] - ActiveDirectoryRealm might by vulnerable to LDAP
search code injection
    * [SHIRO-120] - AbstractLdapRealm's doGetAuthenticationInfo
catches naming exception, but then only logs a message
    * [SHIRO-124] - MethodInvocation is missing a getThis() (or
equivalent) method
    * [SHIRO-130] - ShiroFilter does not work with proxied security manager
    * [SHIRO-135] - AccessControlException exception on GAE with Grails
    * [SHIRO-138] - AbstractRememberMeManager attempts to process
null/empty byte array
    * [SHIRO-141] - Problem with WebRememberMeManager
    * [SHIRO-142] - Jetty throws an IllegalStateException after
redirect in AuthorizationFilter
    * [SHIRO-145] - Losing Session
    * [SHIRO-150] - RememberMeManager NPE
    * [SHIRO-154] - Adding ehcahe CacheManager to Spring Sample failes
    * [SHIRO-156] - SimpleAuthenticationInfo.merge does not merge
principals if its internal principal collection is not mutable
    * [SHIRO-157] - RememberMeManager should no longer be consulted
once a remembered identity is discovered
    * [SHIRO-158] - Date
AbstractSessionManager.getLastAccessTime(Serializable) returns start
time
    * [SHIRO-159] - ThreadLocal is not cleared upon the unloading of
the webapp and the SHiro Servlet
    * [SHIRO-161] - No SecurityManager accessible to the calling code
    * [SHIRO-163] - ModularRealmAuthorizer.setRealms needs to call
applyRolePermissionResolverToRealms
    * [SHIRO-164] - The request/response pair should be available at
all times to web-related components
    * [SHIRO-167] - getServletContext allways return null with conf
via spring (native mode)
    * [SHIRO-172] - Missing SVN properties

** Improvement
    * [SHIRO-59] - Refactor Realm implementations to favor delegation
over inheritance
    * [SHIRO-83] - Make sessionId cookie optional
    * [SHIRO-86] - Add Builder design pattern for arbitrary Subject construction
    * [SHIRO-88] - Create a profile for installing javadocs and source
to keep build time short
    * [SHIRO-104] - Default AuthenticationStrategy should be
AtLeastOneSuccessful instead of All
    * [SHIRO-109] - RememberMeManager should have access to Subject context map
    * [SHIRO-110] - Remove org.apache.shiro.mgt.SubjectBinder and its usages
    * [SHIRO-111] - Web SecurityManager should not fail in non-request usages
    * [SHIRO-112] - Implement Externalizable for serializable classes
    * [SHIRO-114] - Break circular dependency between SubjectFactory
and DefaultSecurityManager
    * [SHIRO-125] - Support overrding the credentialsMatcher for the
implicit IniRealm
    * [SHIRO-128] - Remove convenience configuration methods
    * [SHIRO-131] - Improved Shiro Filter configuration for Spring environments
    * [SHIRO-133] - Automatically shut down the Session validation thread
    * [SHIRO-136] - Mark Spring as scope provided to let users
specificy their own version of Spring
    * [SHIRO-137] - Go through Shiro dependencies and consider marking
most third-party dependencies as provided
    * [SHIRO-139] - Cookie support refactoring - Simplify cookie
configuration, support HttpOnly cookies and default session cookies to
be HttpOnly = true
    * [SHIRO-144] - MemorySessionDao should be propably abstract
    * [SHIRO-146] - Annotation authorizations should throw
UnauthenticationException if the subject identity is not known.
    * [SHIRO-148] - SimpleSession efficient serialization
    * [SHIRO-152] - INI configuration must support configuration of
Lists, Sets and Maps
    * [SHIRO-153] - INI: remove need for [filters] section and perform
all object configuration in [main]

** New Feature
    * [SHIRO-25] - Assumed Identity, aka 'Run As' support
    * [SHIRO-30] - Subject acquisition based on method argument
    * [SHIRO-92] - Add method to Subject interface: isRemembered()
    * [SHIRO-105] - PrincipalCollection should have a
getPrimaryPrincipal() method
    * [SHIRO-107] - Filter chain definitions should match on request
method as well as request path (REST support)
    * [SHIRO-116] - Ini configuration - users/roles sections should
trigger automatic Realm creation
    * [SHIRO-118] - Ini Realm support
    * [SHIRO-121] - Change usages of java.net.InetAddress to be Strings
    * [SHIRO-122] - Create IdentifierGenerator interface for pluggable
id generation strategies
    * [SHIRO-129] - Aspecjt integration for annotation base authorization
    * [SHIRO-140] - Add a subject-aware ExecutorService implementation
to support Subject execution on other threads
    * [SHIRO-147] - Add an AES Cipher

** Task
    * [SHIRO-34] - Cipher refactoring
    * [SHIRO-37] - Deploy snapshots automatically
    * [SHIRO-43] - Ignore Eclipse folders & files and mvn target
folders from svn
    * [SHIRO-49] - Fix SimpleAccountRealm to not rely on caching
    * [SHIRO-50] - Spring NOTICE
    * [SHIRO-52] - Verify all samples deploy/run successfully
    * [SHIRO-94] - Update web pages to change JSecurity and Ki to Shiro
    * [SHIRO-102] - Set-up AutoExport of Shiro documentation to the
appropriate location
    * [SHIRO-103] - Fix "Ki" in the Apache Incubator Status Page
    * [SHIRO-149] - Create release configuration and a profile for
deploying release docs to a separate directory
    * [SHIRO-155] - Remove all deprecated methods and classes
    * [SHIRO-162] - Create SessionContext to mirror SubjectContext
concept for starting new sessions

** Test
    * [SHIRO-90] -
org.apache.shiro.session.mgt.DefaultSessionManagerTest.testGlobalTimeout
is unreliable
    * [SHIRO-91] - Tests for getRememberedPrincipals and
getRememberedPrincipalsDecryptionError in WebRememberMeManagerTest are
disabled
    * [SHIRO-93] - Add container-based integration tests for samples/web module
    * [SHIRO-96] - Add meaningful integration tests to assert key web
functionality

** Wish
    * [SHIRO-143] - Change logging level from trace to warning in
ModularRealmAuthenticator when a Realm throws an Exception

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


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Paul Merlin <es...@n0pe.org>.
Congrats !!

\o/

Le 1 juin 2010 à 19:01, Les Hazlewood <lh...@apache.org> a  
écrit :

> Dear Apache Shiro Community,
>
> We are proud and excited to offer Apache Shiro's first stable release
> as an Apache Incubator podling!
>
> Version 1.0.0-incubating is available immediately for download here:
>
> http://incubator.apache.org/shiro/download.html
>
> Associated documentation is available here:
>
> http://incubator.apache.org/shiro/documentation.html
>
> Release notes are included below.
>
> Thank you so much to the Apache community and the Apache Incubator for
> helping us move toward our first release.  A very special thanks goes
> to our user community and early adopters for helping us refine our
> first stable release.
>
> Best Regards,
>
> Les Hazlewood
>
> ------
>
> Release Notes are browsable online here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310950&styleName=Html&version=12314078
>
> And included here for convenience:
>
> Release Notes - Shiro - Version 1.0.0-incubating
>
> ** Bug
>    * [SHIRO-10] - Aliases in the ini configuration builder do not
> work correctly
>    * [SHIRO-82] - Shiro strips anchor (#) values from the URL if user
> is unauthenticated
>    * [SHIRO-87] - Fix package name of package-info.java in shiro-core
>    * [SHIRO-89] - Sample Spring Application - WebStart won't launch
>    * [SHIRO-95] - Specifying my own Cache in ShiroFilter not working
>    * [SHIRO-101] - Comma in role in the properties file is not read
> correctly by the PropertyRealm
>    * [SHIRO-106] - AuthorizationFilter needs to use sendError not
> setStatus to make container process the request through ERROR
> dispatcher
>    * [SHIRO-108] - Basic HTTP Auth: Empty password or username causes
> IllegalStateException
>    * [SHIRO-115] - ActiveDirectoryRealm might by vulnerable to LDAP
> search code injection
>    * [SHIRO-120] - AbstractLdapRealm's doGetAuthenticationInfo
> catches naming exception, but then only logs a message
>    * [SHIRO-124] - MethodInvocation is missing a getThis() (or
> equivalent) method
>    * [SHIRO-130] - ShiroFilter does not work with proxied security  
> manager
>    * [SHIRO-135] - AccessControlException exception on GAE with Grails
>    * [SHIRO-138] - AbstractRememberMeManager attempts to process
> null/empty byte array
>    * [SHIRO-141] - Problem with WebRememberMeManager
>    * [SHIRO-142] - Jetty throws an IllegalStateException after
> redirect in AuthorizationFilter
>    * [SHIRO-145] - Losing Session
>    * [SHIRO-150] - RememberMeManager NPE
>    * [SHIRO-154] - Adding ehcahe CacheManager to Spring Sample failes
>    * [SHIRO-156] - SimpleAuthenticationInfo.merge does not merge
> principals if its internal principal collection is not mutable
>    * [SHIRO-157] - RememberMeManager should no longer be consulted
> once a remembered identity is discovered
>    * [SHIRO-158] - Date
> AbstractSessionManager.getLastAccessTime(Serializable) returns start
> time
>    * [SHIRO-159] - ThreadLocal is not cleared upon the unloading of
> the webapp and the SHiro Servlet
>    * [SHIRO-161] - No SecurityManager accessible to the calling code
>    * [SHIRO-163] - ModularRealmAuthorizer.setRealms needs to call
> applyRolePermissionResolverToRealms
>    * [SHIRO-164] - The request/response pair should be available at
> all times to web-related components
>    * [SHIRO-167] - getServletContext allways return null with conf
> via spring (native mode)
>    * [SHIRO-172] - Missing SVN properties
>
> ** Improvement
>    * [SHIRO-59] - Refactor Realm implementations to favor delegation
> over inheritance
>    * [SHIRO-83] - Make sessionId cookie optional
>    * [SHIRO-86] - Add Builder design pattern for arbitrary Subject  
> construction
>    * [SHIRO-88] - Create a profile for installing javadocs and source
> to keep build time short
>    * [SHIRO-104] - Default AuthenticationStrategy should be
> AtLeastOneSuccessful instead of All
>    * [SHIRO-109] - RememberMeManager should have access to Subject  
> context map
>    * [SHIRO-110] - Remove org.apache.shiro.mgt.SubjectBinder and its  
> usages
>    * [SHIRO-111] - Web SecurityManager should not fail in non- 
> request usages
>    * [SHIRO-112] - Implement Externalizable for serializable classes
>    * [SHIRO-114] - Break circular dependency between SubjectFactory
> and DefaultSecurityManager
>    * [SHIRO-125] - Support overrding the credentialsMatcher for the
> implicit IniRealm
>    * [SHIRO-128] - Remove convenience configuration methods
>    * [SHIRO-131] - Improved Shiro Filter configuration for Spring  
> environments
>    * [SHIRO-133] - Automatically shut down the Session validation  
> thread
>    * [SHIRO-136] - Mark Spring as scope provided to let users
> specificy their own version of Spring
>    * [SHIRO-137] - Go through Shiro dependencies and consider marking
> most third-party dependencies as provided
>    * [SHIRO-139] - Cookie support refactoring - Simplify cookie
> configuration, support HttpOnly cookies and default session cookies to
> be HttpOnly = true
>    * [SHIRO-144] - MemorySessionDao should be propably abstract
>    * [SHIRO-146] - Annotation authorizations should throw
> UnauthenticationException if the subject identity is not known.
>    * [SHIRO-148] - SimpleSession efficient serialization
>    * [SHIRO-152] - INI configuration must support configuration of
> Lists, Sets and Maps
>    * [SHIRO-153] - INI: remove need for [filters] section and perform
> all object configuration in [main]
>
> ** New Feature
>    * [SHIRO-25] - Assumed Identity, aka 'Run As' support
>    * [SHIRO-30] - Subject acquisition based on method argument
>    * [SHIRO-92] - Add method to Subject interface: isRemembered()
>    * [SHIRO-105] - PrincipalCollection should have a
> getPrimaryPrincipal() method
>    * [SHIRO-107] - Filter chain definitions should match on request
> method as well as request path (REST support)
>    * [SHIRO-116] - Ini configuration - users/roles sections should
> trigger automatic Realm creation
>    * [SHIRO-118] - Ini Realm support
>    * [SHIRO-121] - Change usages of java.net.InetAddress to be Strings
>    * [SHIRO-122] - Create IdentifierGenerator interface for pluggable
> id generation strategies
>    * [SHIRO-129] - Aspecjt integration for annotation base  
> authorization
>    * [SHIRO-140] - Add a subject-aware ExecutorService implementation
> to support Subject execution on other threads
>    * [SHIRO-147] - Add an AES Cipher
>
> ** Task
>    * [SHIRO-34] - Cipher refactoring
>    * [SHIRO-37] - Deploy snapshots automatically
>    * [SHIRO-43] - Ignore Eclipse folders & files and mvn target
> folders from svn
>    * [SHIRO-49] - Fix SimpleAccountRealm to not rely on caching
>    * [SHIRO-50] - Spring NOTICE
>    * [SHIRO-52] - Verify all samples deploy/run successfully
>    * [SHIRO-94] - Update web pages to change JSecurity and Ki to Shiro
>    * [SHIRO-102] - Set-up AutoExport of Shiro documentation to the
> appropriate location
>    * [SHIRO-103] - Fix "Ki" in the Apache Incubator Status Page
>    * [SHIRO-149] - Create release configuration and a profile for
> deploying release docs to a separate directory
>    * [SHIRO-155] - Remove all deprecated methods and classes
>    * [SHIRO-162] - Create SessionContext to mirror SubjectContext
> concept for starting new sessions
>
> ** Test
>    * [SHIRO-90] -
> org.apache.shiro.session.mgt.DefaultSessionManagerTest.testGlobalTimeout
 

> is unreliable
>    * [SHIRO-91] - Tests for getRememberedPrincipals and
> getRememberedPrincipalsDecryptionError in WebRememberMeManagerTest are
> disabled
>    * [SHIRO-93] - Add container-based integration tests for samples/ 
> web module
>    * [SHIRO-96] - Add meaningful integration tests to assert key web
> functionality
>
> ** Wish
>    * [SHIRO-143] - Change logging level from trace to warning in
> ModularRealmAuthenticator when a Realm throws an Exception

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Francis De Brabandere <fr...@gmail.com>.
+1 on that step by step wiki guide.
I'm willing to contribute/discuss  as I believe our release process could be
simpler.
Cheers
Francis

On 1 Jun 2010 22:50, "Les Hazlewood" <lh...@apache.org> wrote:

Hi Sigfried,

I guess that's my point.  We use M2.  I bet 80% (if not more) of
podlings use M2.  There shouldn't have to be much thought involved to
get an M2-based project released - a de facto guide should exist and
podlings can deviate from it where allowed and where it makes sense
for their project.  Until that 'baseline' exists, we all feel
unnecessary pain.

Thanks for your offer to help - I personally think there should be an
incubator-wide editible wiki step-by-step guide that people can
contribute to (via discussion) as necessary for M2 projects since that
encompasses most Incubator projects.  Any help in writing such a guide
would be *immensely* appreciated!

Thanks,

Les


On Tue, Jun 1, 2010 at 1:44 PM, Siegfried Goeschl
<si...@it20one.at> wrote:
> Hi folks,...

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
Hi Sigfried,

I guess that's my point.  We use M2.  I bet 80% (if not more) of
podlings use M2.  There shouldn't have to be much thought involved to
get an M2-based project released - a de facto guide should exist and
podlings can deviate from it where allowed and where it makes sense
for their project.  Until that 'baseline' exists, we all feel
unnecessary pain.

Thanks for your offer to help - I personally think there should be an
incubator-wide editible wiki step-by-step guide that people can
contribute to (via discussion) as necessary for M2 projects since that
encompasses most Incubator projects.  Any help in writing such a guide
would be *immensely* appreciated!

Thanks,

Les

On Tue, Jun 1, 2010 at 1:44 PM, Siegfried Goeschl
<si...@it20one.at> wrote:
> Hi folks,
>
> congratulation for getting the release out of the door ... :-) ... and shiro
> folks (aka JSecurity) did an excellent job.
>
> Regarding the "no-frills step-by-step, no room-for-error release"
>
> +) it is difficult to write
>
> +) different projects have different tools to release (manual, Ant, Maven)
> making the stuff even more difficult
>
> Maybe more stuff can be done to streamline your release process using M2 -
> maybe I can lend you a hand
>
> Cheers,
>
> Siegfried Goeschl
>
> On 01.06.10 22:26, Les Hazlewood wrote:
>>>
>>> The download page links to reposity.apache.org.
>>>
>>> However repository.apache.org  is not to be used for direct
>>> publication to end users, it is for publishing to the main maven repo.
>>
>> This wasn't clear on the apache infrastructure page - it states that
>> repository.apache.org is part of the distribution infrastructure.  Now
>> that we've been notified that this is not the case, we'll fix it as
>> soon as possible.  Thanks!
>>
>>> Also, the downloads page does not have a link to the KEYS file. Nor
>>> does it have any documentation on how to use the sigs and hashes.
>>
>> We'll fix that.
>>
>>>
>>> The downloads page should only link to the ASF mirrors, see for example:
>>>
>>> http://incubator.apache.org/photark/photark-downloads.html
>>>
>>> Also, there is no DISCLAIMER in any of the archive files.
>>> AIUI, Incubator releases MUST contain a disclaimer:
>>
>> The branding link only specifies that podling websites must display
>> that disclaimer.  That exact disclaimer is the very first paragraph on
>> the download page.  AIUI, there is no mandate that a DISCLAIMER file
>> must be included in the actual packaged distribution.  Otherwise we
>> assume the release would have been voted against.
>>
>> On a side note, we're doing our best to adhere to all requirements,
>> and we're happy to do so.  But it has been *incredibly* time consuming
>> and frustrating to try to interpret what should be step-by-step
>> courses of action to adhere to these requirements.
>>
>> Why isn't there a no-frills step-by-step, no room-for-error release
>> checklist that podlings can follow to guarantee that all required
>> criteria are met?  It seems like such a checklist would be of the
>> highest priority for the Incubator to ensure that personal
>> interpretation is minimized or eliminated from the release process.
>>
>> This release management page [1] is incredibly long and full of policy
>> and reasoning, which is all well and good if one wants to understand
>> *why* these policies exist, but podlings really need a step-by-step
>> *how-to* guide that references the 'why' document so we can service
>> our communities as efficiently as possible.  The 'why' guide is
>> fantastic to read at our leisure, but the 'how' document would be far
>> more useful to podlings when release time comes.
>>
>> My .02,
>>
>> Les
>>
>> [1] http://incubator.apache.org/guides/releasemanagement.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

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


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Siegfried Goeschl <si...@it20one.at>.
Hi folks,

congratulation for getting the release out of the door ... :-) ... and 
shiro folks (aka JSecurity) did an excellent job.

Regarding the "no-frills step-by-step, no room-for-error release"

+) it is difficult to write

+) different projects have different tools to release (manual, Ant, 
Maven) making the stuff even more difficult

Maybe more stuff can be done to streamline your release process using M2 
- maybe I can lend you a hand

Cheers,

Siegfried Goeschl

On 01.06.10 22:26, Les Hazlewood wrote:
>> The download page links to reposity.apache.org.
>>
>> However repository.apache.org  is not to be used for direct
>> publication to end users, it is for publishing to the main maven repo.
>
> This wasn't clear on the apache infrastructure page - it states that
> repository.apache.org is part of the distribution infrastructure.  Now
> that we've been notified that this is not the case, we'll fix it as
> soon as possible.  Thanks!
>
>> Also, the downloads page does not have a link to the KEYS file. Nor
>> does it have any documentation on how to use the sigs and hashes.
>
> We'll fix that.
>
>>
>> The downloads page should only link to the ASF mirrors, see for example:
>>
>> http://incubator.apache.org/photark/photark-downloads.html
>>
>> Also, there is no DISCLAIMER in any of the archive files.
>> AIUI, Incubator releases MUST contain a disclaimer:
>
> The branding link only specifies that podling websites must display
> that disclaimer.  That exact disclaimer is the very first paragraph on
> the download page.  AIUI, there is no mandate that a DISCLAIMER file
> must be included in the actual packaged distribution.  Otherwise we
> assume the release would have been voted against.
>
> On a side note, we're doing our best to adhere to all requirements,
> and we're happy to do so.  But it has been *incredibly* time consuming
> and frustrating to try to interpret what should be step-by-step
> courses of action to adhere to these requirements.
>
> Why isn't there a no-frills step-by-step, no room-for-error release
> checklist that podlings can follow to guarantee that all required
> criteria are met?  It seems like such a checklist would be of the
> highest priority for the Incubator to ensure that personal
> interpretation is minimized or eliminated from the release process.
>
> This release management page [1] is incredibly long and full of policy
> and reasoning, which is all well and good if one wants to understand
> *why* these policies exist, but podlings really need a step-by-step
> *how-to* guide that references the 'why' document so we can service
> our communities as efficiently as possible.  The 'why' guide is
> fantastic to read at our leisure, but the 'how' document would be far
> more useful to podlings when release time comes.
>
> My .02,
>
> Les
>
> [1] http://incubator.apache.org/guides/releasemanagement.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

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


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Jun 1, 2010 at 4:42 PM, sebb <se...@gmail.com> wrote:
> On 01/06/2010, Les Hazlewood <lh...@apache.org> wrote:
>>  Otherwise we  assume the release would have been voted against.
> The lack of a DISCLAIMER was reported as part of the vote.
> I don't know why it was not considered blocking.

Either you vote or you don't, everything else is considered advisory,
you know that. The release packages that most people in practice will
use contain -incubating in the file name. I don't know what could be
any more explicit. Anyhow, we'll add a file for the next release.

>>  Why isn't there a no-frills step-by-step, no room-for-error release
>>  checklist that podlings can follow to guarantee that all required
>>  criteria are met?  It seems like such a checklist would be of the
>>  highest priority for the Incubator to ensure that personal
>>  interpretation is minimized or eliminated from the release process.

Maven (the project) has super clear step-by-step instructions at
http://maven.apache.org/developers/release/apache-release.html for
releasing with Maven (kudos to Maven guys for that!) which I followed
religiously. Maybe you could write another one for Maven-based podling
releases but I'm not sure it's worth it. Most of the pain we (Shiro)
experienced was with the website - these rules are really not clear
and there's a million different competing technologies to put together
a project website. Unless incubator starts dictating the technologies
to use for a podling website (which I'd be strongly against), I don't
see how one could write up a *simple* checklist. It's worth an effort
to clarify the http://incubator.apache.org/guides/releasemanagement.html
page though. Whatever the technology, I'd much rather improve
something existing than whip up yet another semi-official Confluence
page.

Kalle

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


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by sebb <se...@gmail.com>.
On 01/06/2010, Les Hazlewood <lh...@apache.org> wrote:
> > The download page links to reposity.apache.org.
>  >
>  > However repository.apache.org  is not to be used for direct
>  > publication to end users, it is for publishing to the main maven repo.
>
>
> This wasn't clear on the apache infrastructure page - it states that
>  repository.apache.org is part of the distribution infrastructure.  Now
>  that we've been notified that this is not the case, we'll fix it as
>  soon as possible.  Thanks!

Which page? Do you mean:

http://www.apache.org/dev/release-publishing.html#distribution

If so, I understand that is in the process of being updated.

>
>  > Also, the downloads page does not have a link to the KEYS file. Nor
>  > does it have any documentation on how to use the sigs and hashes.
>
>
> We'll fix that.

Thanks!

>  >
>  > The downloads page should only link to the ASF mirrors, see for example:
>  >
>  > http://incubator.apache.org/photark/photark-downloads.html
>  >
>  > Also, there is no DISCLAIMER in any of the archive files.
>  > AIUI, Incubator releases MUST contain a disclaimer:
>
>
> The branding link only specifies that podling websites must display
>  that disclaimer.  That exact disclaimer is the very first paragraph on
>  the download page.

http://incubator.apache.org/guides/branding.html#disclaimers says:

"Podling web sites MUST include a clear disclaimer on their website
and in all documentation (including releases) stating that they are in
incubation."

The important part here is "(including releases)".

> AIUI, there is no mandate that a DISCLAIMER file must be included in the actual packaged distribution.

There is no requirement that the disclaimer be in a file called DISCLAIMER.
However it must be present, as mentioned above.

It is suggested that it is placed in a separate DISCLAIMER file as
this makes it more obvious, and makes it easier to drop
post-incubation.

>  Otherwise we  assume the release would have been voted against.

The lack of a DISCLAIMER was reported as part of the vote.
I don't know why it was not considered blocking.

>
>  On a side note, we're doing our best to adhere to all requirements,
>  and we're happy to do so.  But it has been *incredibly* time consuming
>  and frustrating to try to interpret what should be step-by-step
>  courses of action to adhere to these requirements.
>
>  Why isn't there a no-frills step-by-step, no room-for-error release
>  checklist that podlings can follow to guarantee that all required
>  criteria are met?  It seems like such a checklist would be of the
>  highest priority for the Incubator to ensure that personal
>  interpretation is minimized or eliminated from the release process.

I agree entirely.

>  This release management page [1] is incredibly long and full of policy
>  and reasoning, which is all well and good if one wants to understand
>  *why* these policies exist, but podlings really need a step-by-step
>  *how-to* guide that references the 'why' document so we can service
>  our communities as efficiently as possible.  The 'why' guide is
>  fantastic to read at our leisure, but the 'how' document would be far
>  more useful to podlings when release time comes.

Agreed it is long-winded.

Toward the end it contains the section:

http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer

which says:

"TODO: the incubator requires that users are informed that the by
including a standard disclaimer. may be include in README,
RELEASE_NOTES DISCLAIMER. It is recommended that it is not included in
NOTICES"

This is very badly worded. But given that NOTICE must be included in
releases it implies that the disclaimer must also be included in
releases.

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


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
> The download page links to reposity.apache.org.
>
> However repository.apache.org  is not to be used for direct
> publication to end users, it is for publishing to the main maven repo.

This wasn't clear on the apache infrastructure page - it states that
repository.apache.org is part of the distribution infrastructure.  Now
that we've been notified that this is not the case, we'll fix it as
soon as possible.  Thanks!

> Also, the downloads page does not have a link to the KEYS file. Nor
> does it have any documentation on how to use the sigs and hashes.

We'll fix that.

>
> The downloads page should only link to the ASF mirrors, see for example:
>
> http://incubator.apache.org/photark/photark-downloads.html
>
> Also, there is no DISCLAIMER in any of the archive files.
> AIUI, Incubator releases MUST contain a disclaimer:

The branding link only specifies that podling websites must display
that disclaimer.  That exact disclaimer is the very first paragraph on
the download page.  AIUI, there is no mandate that a DISCLAIMER file
must be included in the actual packaged distribution.  Otherwise we
assume the release would have been voted against.

On a side note, we're doing our best to adhere to all requirements,
and we're happy to do so.  But it has been *incredibly* time consuming
and frustrating to try to interpret what should be step-by-step
courses of action to adhere to these requirements.

Why isn't there a no-frills step-by-step, no room-for-error release
checklist that podlings can follow to guarantee that all required
criteria are met?  It seems like such a checklist would be of the
highest priority for the Incubator to ensure that personal
interpretation is minimized or eliminated from the release process.

This release management page [1] is incredibly long and full of policy
and reasoning, which is all well and good if one wants to understand
*why* these policies exist, but podlings really need a step-by-step
*how-to* guide that references the 'why' document so we can service
our communities as efficiently as possible.  The 'why' guide is
fantastic to read at our leisure, but the 'how' document would be far
more useful to podlings when release time comes.

My .02,

Les

[1] http://incubator.apache.org/guides/releasemanagement.html

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


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
> The download page links to reposity.apache.org.
>
> However repository.apache.org  is not to be used for direct
> publication to end users, it is for publishing to the main maven repo.

This wasn't clear on the apache infrastructure page - it states that
repository.apache.org is part of the distribution infrastructure.  Now
that we've been notified that this is not the case, we'll fix it as
soon as possible.  Thanks!

> Also, the downloads page does not have a link to the KEYS file. Nor
> does it have any documentation on how to use the sigs and hashes.

We'll fix that.

>
> The downloads page should only link to the ASF mirrors, see for example:
>
> http://incubator.apache.org/photark/photark-downloads.html
>
> Also, there is no DISCLAIMER in any of the archive files.
> AIUI, Incubator releases MUST contain a disclaimer:

The branding link only specifies that podling websites must display
that disclaimer.  That exact disclaimer is the very first paragraph on
the download page.  AIUI, there is no mandate that a DISCLAIMER file
must be included in the actual packaged distribution.  Otherwise we
assume the release would have been voted against.

On a side note, we're doing our best to adhere to all requirements,
and we're happy to do so.  But it has been *incredibly* time consuming
and frustrating to try to interpret what should be step-by-step
courses of action to adhere to these requirements.

Why isn't there a no-frills step-by-step, no room-for-error release
checklist that podlings can follow to guarantee that all required
criteria are met?  It seems like such a checklist would be of the
highest priority for the Incubator to ensure that personal
interpretation is minimized or eliminated from the release process.

This release management page [1] is incredibly long and full of policy
and reasoning, which is all well and good if one wants to understand
*why* these policies exist, but podlings really need a step-by-step
*how-to* guide that references the 'why' document so we can service
our communities as efficiently as possible.  The 'why' guide is
fantastic to read at our leisure, but the 'how' document would be far
more useful to podlings when release time comes.

My .02,

Les

[1] http://incubator.apache.org/guides/releasemanagement.html

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by sebb <se...@gmail.com>.
On 01/06/2010, Les Hazlewood <lh...@apache.org> wrote:
> Dear Apache Shiro Community,
>
>  We are proud and excited to offer Apache Shiro's first stable release
>  as an Apache Incubator podling!
>
>  Version 1.0.0-incubating is available immediately for download here:
>
>  http://incubator.apache.org/shiro/download.html

Sorry to keep going on about Shiro, but the download page does not
follow standard ASF practice.

The download page links to reposity.apache.org.

However repository.apache.org  is not to be used for direct
publication to end users, it is for publishing to the main maven repo.

Also, the downloads page does not have a link to the KEYS file. Nor
does it have any documentation on how to use the sigs and hashes.

The downloads page should only link to the ASF mirrors, see for example:

http://incubator.apache.org/photark/photark-downloads.html

Also, there is no DISCLAIMER in any of the archive files.
AIUI, Incubator releases MUST contain a disclaimer:

http://incubator.apache.org/guides/branding.html#disclaimers
and
http://incubator.apache.org/guides/mentor.html#documents-clean-up

S.
P.S. The website now makes the incubation status clear - thanks!

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


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Kalle Korhonen <ka...@gmail.com>.
On Wed, Jun 2, 2010 at 11:44 PM, Les Hazlewood <lh...@apache.org> wrote:
> Sorry, that didn't sound too clear - I was thinking that we keep the
> download page as it is, but link to each .jar/sha1/md5 to a directory
> that is the built project (i.e.
> /www/incubator.apache.org/shiro/static/releases/1.0.0-incubating =
> exploded directory of the built 1.0.0-incubating release .zip).  Then
> we can just set up a symlink to point to the latest release as each
> one comes out.  Does that make more sense?

No, I'm sorry I must be a bit slow this evening but couldn't really
decipher your thinking from that. The download page doesn't have to
have anything to do with this (although the links on that page should
be pointing to central instead of Apache's nexus instance). The
distribution area is separate from site and it doesn't have to contain
everything the Maven repo does (think of it as a repo for non-Maven
projects). Simply copying the shiro-all and possibly the source
release zip to the dist area makes the most sense to me.

Kalle


> On Wed, Jun 2, 2010 at 11:42 PM, Les Hazlewood <lh...@apache.org> wrote:
>> I would assume just a built version of the project in its raw form
>> would be ok.  Then we could link to the respective target/*
>> directories to the actual .jar files.  I don't know if the target
>> directories contain the hashes, but I would assume so...
>>
>> On Wed, Jun 2, 2010 at 11:16 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> Whoops. One thing missing from the release - we don't have anything in
>>> the Apache Shiro distribution area. My oversight, been living in Maven
>>> land for too long. I checked and created the Shiro directory already,
>>> the only real question is what should we put in there? Just the
>>> shiro-all with keys (the primary artifact from
>>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>>> According to the instructions, project documentation doesn't go in
>>> there. Mentors have any advice? Maven or not, I think we should add
>>> some of the release packages in the distribution area, especially
>>> since it's tracked by Incubator clutch.
>>>
>>> Kalle
>>>
>>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
Sorry, that didn't sound too clear - I was thinking that we keep the
download page as it is, but link to each .jar/sha1/md5 to a directory
that is the built project (i.e.
/www/incubator.apache.org/shiro/static/releases/1.0.0-incubating =
exploded directory of the built 1.0.0-incubating release .zip).  Then
we can just set up a symlink to point to the latest release as each
one comes out.  Does that make more sense?

Les

On Wed, Jun 2, 2010 at 11:42 PM, Les Hazlewood <lh...@apache.org> wrote:
> I would assume just a built version of the project in its raw form
> would be ok.  Then we could link to the respective target/*
> directories to the actual .jar files.  I don't know if the target
> directories contain the hashes, but I would assume so...
>
> On Wed, Jun 2, 2010 at 11:16 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Whoops. One thing missing from the release - we don't have anything in
>> the Apache Shiro distribution area. My oversight, been living in Maven
>> land for too long. I checked and created the Shiro directory already,
>> the only real question is what should we put in there? Just the
>> shiro-all with keys (the primary artifact from
>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>> According to the instructions, project documentation doesn't go in
>> there. Mentors have any advice? Maven or not, I think we should add
>> some of the release packages in the distribution area, especially
>> since it's tracked by Incubator clutch.
>>
>> Kalle
>>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
I would assume just a built version of the project in its raw form
would be ok.  Then we could link to the respective target/*
directories to the actual .jar files.  I don't know if the target
directories contain the hashes, but I would assume so...

On Wed, Jun 2, 2010 at 11:16 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Whoops. One thing missing from the release - we don't have anything in
> the Apache Shiro distribution area. My oversight, been living in Maven
> land for too long. I checked and created the Shiro directory already,
> the only real question is what should we put in there? Just the
> shiro-all with keys (the primary artifact from
> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
> According to the instructions, project documentation doesn't go in
> there. Mentors have any advice? Maven or not, I think we should add
> some of the release packages in the distribution area, especially
> since it's tracked by Incubator clutch.
>
> Kalle
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Kalle Korhonen <ka...@gmail.com>.
On Thu, Jun 3, 2010 at 2:46 PM, Les Hazlewood <lh...@apache.org> wrote:
> Sounds good to me.

Dist is done.

> As a side note though, one of the things that is nice about a binary,
> non-source package is that I can download everything local to disk
> without needing to be connected to the internet to view documentation
> and reference .jars as a I need them.
> How do other projects do this?  I'm sure most of them don't have a
> 'use Maven or you'll have to everything on the internet' approach,
> right?

Technically it'd be simple to wrap up the Maven site plus the binaries
into a zip with an assembly, but this is 2010, I think we can safely
assume that users of Shiro will have access to the Internet at will,
Maven or not. If you want to tackle it, by all means, but personally,
I wouldn't consider it to be a good use of my time.

Kalle


> On Thu, Jun 3, 2010 at 2:26 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>> On Jun 3, 2010, at 2:24 PM, Kalle Korhonen wrote:
>>
>>> On Thu, Jun 3, 2010 at 2:03 PM, Les Hazlewood <lh...@apache.org>
>>> wrote:
>>>>
>>>> My suggestion last night that I couldn't formulate very well was
>>>> basically this:
>>>> 1.  Unzip the 'official' source release.
>>>> 2.  Build the project in its entirety from the .zip
>>>> 3.  tarball up the built project (with target directories, etc) and
>>>> upload it to dist
>>>> 4.  Untar it on dist
>>>> 5.  Change the links on the dowload page to reference the dist target
>>>> locations.
>>>> Its not as clean as only uploading the raw .jars and .asc/.sha1/.md5
>>>> files, but it is easily automated.  If there is another mechanism that
>>>> easily allows us to automate upload of only what would be downloaded,
>>>> that'd be better.  I'm in favor of whatever is easiest.
>>>
>>> Lots of unzipping, tarring and untarring there. I was merely going to
>>> put the zip and the keys and possibly the shiro-all there and be done
>>> with it.
>>
>> I'm thinking that since this is what was voted on and checked, this is what
>> we should run with.
>>
>>
>> Regards,
>> Alan
>>
>>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Kalle Korhonen <ka...@gmail.com>.
Patches welcome!

Kalle


On Thu, Jun 3, 2010 at 5:15 PM, Erik Beeson <er...@gmail.com> wrote:
> +1 from me for full built downloads (as I write this from a transatlantic
> flight).
>
> --Erik
>
>
> On Thu, Jun 3, 2010 at 9:46 PM, Les Hazlewood <lh...@apache.org> wrote:
>
>> Sounds good to me.
>>
>> As a side note though, one of the things that is nice about a binary,
>> non-source package is that I can download everything local to disk
>> without needing to be connected to the internet to view documentation
>> and reference .jars as a I need them.
>>
>> I think it would be nice to create such a package for our next
>> release.  This is the reason for example, why Spring has a
>> spring-3.0.2-with-dependencies.zip and a spring-3.0.2-with-docs.zip.
>> When I wasn't a Maven or Ant+Ivy user, I really liked being able to
>> have this 'one stop shop' download.
>>
>> How do other projects do this?  I'm sure most of them don't have a
>> 'use Maven or you'll have to everything on the internet' approach,
>> right?
>>
>> Les
>>
>>
>> On Thu, Jun 3, 2010 at 2:26 PM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>> >
>> > On Jun 3, 2010, at 2:24 PM, Kalle Korhonen wrote:
>> >
>> >> On Thu, Jun 3, 2010 at 2:03 PM, Les Hazlewood <lh...@apache.org>
>> >> wrote:
>> >>>
>> >>> My suggestion last night that I couldn't formulate very well was
>> >>> basically this:
>> >>> 1.  Unzip the 'official' source release.
>> >>> 2.  Build the project in its entirety from the .zip
>> >>> 3.  tarball up the built project (with target directories, etc) and
>> >>> upload it to dist
>> >>> 4.  Untar it on dist
>> >>> 5.  Change the links on the dowload page to reference the dist target
>> >>> locations.
>> >>> Its not as clean as only uploading the raw .jars and .asc/.sha1/.md5
>> >>> files, but it is easily automated.  If there is another mechanism that
>> >>> easily allows us to automate upload of only what would be downloaded,
>> >>> that'd be better.  I'm in favor of whatever is easiest.
>> >>
>> >> Lots of unzipping, tarring and untarring there. I was merely going to
>> >> put the zip and the keys and possibly the shiro-all there and be done
>> >> with it.
>> >
>> > I'm thinking that since this is what was voted on and checked, this is
>> what
>> > we should run with.
>> >
>> >
>> > Regards,
>> > Alan
>> >
>> >
>>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Erik Beeson <er...@gmail.com>.
+1 from me for full built downloads (as I write this from a transatlantic
flight).

--Erik


On Thu, Jun 3, 2010 at 9:46 PM, Les Hazlewood <lh...@apache.org> wrote:

> Sounds good to me.
>
> As a side note though, one of the things that is nice about a binary,
> non-source package is that I can download everything local to disk
> without needing to be connected to the internet to view documentation
> and reference .jars as a I need them.
>
> I think it would be nice to create such a package for our next
> release.  This is the reason for example, why Spring has a
> spring-3.0.2-with-dependencies.zip and a spring-3.0.2-with-docs.zip.
> When I wasn't a Maven or Ant+Ivy user, I really liked being able to
> have this 'one stop shop' download.
>
> How do other projects do this?  I'm sure most of them don't have a
> 'use Maven or you'll have to everything on the internet' approach,
> right?
>
> Les
>
>
> On Thu, Jun 3, 2010 at 2:26 PM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >
> > On Jun 3, 2010, at 2:24 PM, Kalle Korhonen wrote:
> >
> >> On Thu, Jun 3, 2010 at 2:03 PM, Les Hazlewood <lh...@apache.org>
> >> wrote:
> >>>
> >>> My suggestion last night that I couldn't formulate very well was
> >>> basically this:
> >>> 1.  Unzip the 'official' source release.
> >>> 2.  Build the project in its entirety from the .zip
> >>> 3.  tarball up the built project (with target directories, etc) and
> >>> upload it to dist
> >>> 4.  Untar it on dist
> >>> 5.  Change the links on the dowload page to reference the dist target
> >>> locations.
> >>> Its not as clean as only uploading the raw .jars and .asc/.sha1/.md5
> >>> files, but it is easily automated.  If there is another mechanism that
> >>> easily allows us to automate upload of only what would be downloaded,
> >>> that'd be better.  I'm in favor of whatever is easiest.
> >>
> >> Lots of unzipping, tarring and untarring there. I was merely going to
> >> put the zip and the keys and possibly the shiro-all there and be done
> >> with it.
> >
> > I'm thinking that since this is what was voted on and checked, this is
> what
> > we should run with.
> >
> >
> > Regards,
> > Alan
> >
> >
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
Sounds good to me.

As a side note though, one of the things that is nice about a binary,
non-source package is that I can download everything local to disk
without needing to be connected to the internet to view documentation
and reference .jars as a I need them.

I think it would be nice to create such a package for our next
release.  This is the reason for example, why Spring has a
spring-3.0.2-with-dependencies.zip and a spring-3.0.2-with-docs.zip.
When I wasn't a Maven or Ant+Ivy user, I really liked being able to
have this 'one stop shop' download.

How do other projects do this?  I'm sure most of them don't have a
'use Maven or you'll have to everything on the internet' approach,
right?

Les


On Thu, Jun 3, 2010 at 2:26 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Jun 3, 2010, at 2:24 PM, Kalle Korhonen wrote:
>
>> On Thu, Jun 3, 2010 at 2:03 PM, Les Hazlewood <lh...@apache.org>
>> wrote:
>>>
>>> My suggestion last night that I couldn't formulate very well was
>>> basically this:
>>> 1.  Unzip the 'official' source release.
>>> 2.  Build the project in its entirety from the .zip
>>> 3.  tarball up the built project (with target directories, etc) and
>>> upload it to dist
>>> 4.  Untar it on dist
>>> 5.  Change the links on the dowload page to reference the dist target
>>> locations.
>>> Its not as clean as only uploading the raw .jars and .asc/.sha1/.md5
>>> files, but it is easily automated.  If there is another mechanism that
>>> easily allows us to automate upload of only what would be downloaded,
>>> that'd be better.  I'm in favor of whatever is easiest.
>>
>> Lots of unzipping, tarring and untarring there. I was merely going to
>> put the zip and the keys and possibly the shiro-all there and be done
>> with it.
>
> I'm thinking that since this is what was voted on and checked, this is what
> we should run with.
>
>
> Regards,
> Alan
>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jun 3, 2010, at 2:24 PM, Kalle Korhonen wrote:

> On Thu, Jun 3, 2010 at 2:03 PM, Les Hazlewood  
> <lh...@apache.org> wrote:
>> My suggestion last night that I couldn't formulate very well was  
>> basically this:
>> 1.  Unzip the 'official' source release.
>> 2.  Build the project in its entirety from the .zip
>> 3.  tarball up the built project (with target directories, etc) and
>> upload it to dist
>> 4.  Untar it on dist
>> 5.  Change the links on the dowload page to reference the dist  
>> target locations.
>> Its not as clean as only uploading the raw .jars and .asc/.sha1/.md5
>> files, but it is easily automated.  If there is another mechanism  
>> that
>> easily allows us to automate upload of only what would be downloaded,
>> that'd be better.  I'm in favor of whatever is easiest.
>
> Lots of unzipping, tarring and untarring there. I was merely going to
> put the zip and the keys and possibly the shiro-all there and be done
> with it.

I'm thinking that since this is what was voted on and checked, this is  
what we should run with.


Regards,
Alan


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Kalle Korhonen <ka...@gmail.com>.
On Thu, Jun 3, 2010 at 2:03 PM, Les Hazlewood <lh...@apache.org> wrote:
> My suggestion last night that I couldn't formulate very well was basically this:
> 1.  Unzip the 'official' source release.
> 2.  Build the project in its entirety from the .zip
> 3.  tarball up the built project (with target directories, etc) and
> upload it to dist
> 4.  Untar it on dist
> 5.  Change the links on the dowload page to reference the dist target locations.
> Its not as clean as only uploading the raw .jars and .asc/.sha1/.md5
> files, but it is easily automated.  If there is another mechanism that
> easily allows us to automate upload of only what would be downloaded,
> that'd be better.  I'm in favor of whatever is easiest.

Lots of unzipping, tarring and untarring there. I was merely going to
put the zip and the keys and possibly the shiro-all there and be done
with it.

Kalle


> On Thu, Jun 3, 2010 at 12:37 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Thu, Jun 3, 2010 at 12:25 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> I'm not sure that we would need that for the binary .jar downloads on
>>> the download page [1] (in the 'Binary Distribution' section, see the
>>> 'Artifact' table column).  By linking directly to the Maven Central
>>> url, we guarantee that the ASF infrastructure won't be 'hit', since
>>> apparently that's what people are concerned about.
>>> It might make sense to use the .cgi for the source release .zip
>>> though, which Kalle is taking care of I believe.  Kalle, do you need
>>> that?
>>
>> We could go either way on that but given that Maven users likely don't
>> use the source release and that it might be more proper to point to
>> the dist location for it, we might just as well be nice to Sonatype
>> (somebody always has to pick up the tab!).
>>
>> Kalle
>>
>>
>>> On Thu, Jun 3, 2010 at 12:10 PM, Craig L Russell
>>> <cr...@oracle.com> wrote:
>>>> Hi Les,
>>>>
>>>> On Jun 3, 2010, at 10:51 AM, Les Hazlewood wrote:
>>>>
>>>>> Thanks for the clarification.  And yes, I totally agree that the
>>>>> download page should be changed to point to central
>>>>
>>>> There's a .cgi script that points to mirrors that all projects copy. It's
>>>> not a big deal right now because of the small number of downloads we expect
>>>> for an incubating release, but it's good to get it right for practice.
>>>>
>>>> If you need help finding the mirror .cgi script let me know.
>>>>
>>>> Craig
>>>>
>>>>> instead of the ASF
>>>>> repo.  I'll make that change now.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Les
>>>>>
>>>>> On Thu, Jun 3, 2010 at 7:26 AM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>>
>>>>>> Yes, that's the entire source. I missed your note on the dist, will do.
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 3, 2010 at 1:14 AM, Craig L Russell
>>>>>> <cr...@oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Kalle,
>>>>>>>
>>>>>>> When I looked at the release, it looked like the proper official source
>>>>>>> release is the shiro-root artifacts with their checksums and signatures.
>>>>>>>
>>>>>>> Specifically, the shiro-root-1.0.0-incubating-source-release.zip and
>>>>>>> checksums and signatures from
>>>>>>>
>>>>>>> https://repository.apache.org/content/repositories/staging/org/apache/shiro/shiro-root/1.0.0-incubating/
>>>>>>>
>>>>>>> If I understand this, it's the entire source tree that constitutes a
>>>>>>> release.
>>>>>>>
>>>>>>> I think I commented earlier that these artifacts are those that would be
>>>>>>> put
>>>>>>> into the dist/incubator/shiro/1.0.0-incubating directory.
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>> On Jun 2, 2010, at 11:16 PM, Kalle Korhonen wrote:
>>>>>>>
>>>>>>>> Whoops. One thing missing from the release - we don't have anything in
>>>>>>>> the Apache Shiro distribution area. My oversight, been living in Maven
>>>>>>>> land for too long. I checked and created the Shiro directory already,
>>>>>>>> the only real question is what should we put in there? Just the
>>>>>>>> shiro-all with keys (the primary artifact from
>>>>>>>>
>>>>>>>>
>>>>>>>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>>>>>>>> According to the instructions, project documentation doesn't go in
>>>>>>>> there. Mentors have any advice? Maven or not, I think we should add
>>>>>>>> some of the release packages in the distribution area, especially
>>>>>>>> since it's tracked by Incubator clutch.
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>
>>>>>>> Craig L Russell
>>>>>>> Architect, Oracle
>>>>>>> http://db.apache.org/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> Craig L Russell
>>>> Architect, Oracle
>>>> http://db.apache.org/jdo
>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>
>>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
I just updated the download page to reference Maven Central in the
meantime to ensure infra@ won't yell at us :)  The number of end users
downloading .jars directly instead of via Maven or Ant+Ivy I would
assume is very low - shouldn't hurt anything while we figure out the
final solution.

We can definitely host it ourselves if we want, and I can change the
links again at that time.  My main hope is that can be automated in as
much as possible.  Any recommendations?

My suggestion last night that I couldn't formulate very well was basically this:

1.  Unzip the 'official' source release.
2.  Build the project in its entirety from the .zip
3.  tarball up the built project (with target directories, etc) and
upload it to dist
4.  Untar it on dist
5.  Change the links on the dowload page to reference the dist target locations.

Its not as clean as only uploading the raw .jars and .asc/.sha1/.md5
files, but it is easily automated.  If there is another mechanism that
easily allows us to automate upload of only what would be downloaded,
that'd be better.  I'm in favor of whatever is easiest.

Les

On Thu, Jun 3, 2010 at 12:37 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Thu, Jun 3, 2010 at 12:25 PM, Les Hazlewood <lh...@apache.org> wrote:
>> I'm not sure that we would need that for the binary .jar downloads on
>> the download page [1] (in the 'Binary Distribution' section, see the
>> 'Artifact' table column).  By linking directly to the Maven Central
>> url, we guarantee that the ASF infrastructure won't be 'hit', since
>> apparently that's what people are concerned about.
>> It might make sense to use the .cgi for the source release .zip
>> though, which Kalle is taking care of I believe.  Kalle, do you need
>> that?
>
> We could go either way on that but given that Maven users likely don't
> use the source release and that it might be more proper to point to
> the dist location for it, we might just as well be nice to Sonatype
> (somebody always has to pick up the tab!).
>
> Kalle
>
>
>> On Thu, Jun 3, 2010 at 12:10 PM, Craig L Russell
>> <cr...@oracle.com> wrote:
>>> Hi Les,
>>>
>>> On Jun 3, 2010, at 10:51 AM, Les Hazlewood wrote:
>>>
>>>> Thanks for the clarification.  And yes, I totally agree that the
>>>> download page should be changed to point to central
>>>
>>> There's a .cgi script that points to mirrors that all projects copy. It's
>>> not a big deal right now because of the small number of downloads we expect
>>> for an incubating release, but it's good to get it right for practice.
>>>
>>> If you need help finding the mirror .cgi script let me know.
>>>
>>> Craig
>>>
>>>> instead of the ASF
>>>> repo.  I'll make that change now.
>>>>
>>>> Thanks,
>>>>
>>>> Les
>>>>
>>>> On Thu, Jun 3, 2010 at 7:26 AM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>>
>>>>> Yes, that's the entire source. I missed your note on the dist, will do.
>>>>>
>>>>> Kalle
>>>>>
>>>>>
>>>>> On Thu, Jun 3, 2010 at 1:14 AM, Craig L Russell
>>>>> <cr...@oracle.com> wrote:
>>>>>>
>>>>>> Hi Kalle,
>>>>>>
>>>>>> When I looked at the release, it looked like the proper official source
>>>>>> release is the shiro-root artifacts with their checksums and signatures.
>>>>>>
>>>>>> Specifically, the shiro-root-1.0.0-incubating-source-release.zip and
>>>>>> checksums and signatures from
>>>>>>
>>>>>> https://repository.apache.org/content/repositories/staging/org/apache/shiro/shiro-root/1.0.0-incubating/
>>>>>>
>>>>>> If I understand this, it's the entire source tree that constitutes a
>>>>>> release.
>>>>>>
>>>>>> I think I commented earlier that these artifacts are those that would be
>>>>>> put
>>>>>> into the dist/incubator/shiro/1.0.0-incubating directory.
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>> On Jun 2, 2010, at 11:16 PM, Kalle Korhonen wrote:
>>>>>>
>>>>>>> Whoops. One thing missing from the release - we don't have anything in
>>>>>>> the Apache Shiro distribution area. My oversight, been living in Maven
>>>>>>> land for too long. I checked and created the Shiro directory already,
>>>>>>> the only real question is what should we put in there? Just the
>>>>>>> shiro-all with keys (the primary artifact from
>>>>>>>
>>>>>>>
>>>>>>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>>>>>>> According to the instructions, project documentation doesn't go in
>>>>>>> there. Mentors have any advice? Maven or not, I think we should add
>>>>>>> some of the release packages in the distribution area, especially
>>>>>>> since it's tracked by Incubator clutch.
>>>>>>>
>>>>>>> Kalle
>>>>>>
>>>>>> Craig L Russell
>>>>>> Architect, Oracle
>>>>>> http://db.apache.org/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>>
>>>>>
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Kalle Korhonen <ka...@gmail.com>.
On Thu, Jun 3, 2010 at 12:25 PM, Les Hazlewood <lh...@apache.org> wrote:
> I'm not sure that we would need that for the binary .jar downloads on
> the download page [1] (in the 'Binary Distribution' section, see the
> 'Artifact' table column).  By linking directly to the Maven Central
> url, we guarantee that the ASF infrastructure won't be 'hit', since
> apparently that's what people are concerned about.
> It might make sense to use the .cgi for the source release .zip
> though, which Kalle is taking care of I believe.  Kalle, do you need
> that?

We could go either way on that but given that Maven users likely don't
use the source release and that it might be more proper to point to
the dist location for it, we might just as well be nice to Sonatype
(somebody always has to pick up the tab!).

Kalle


> On Thu, Jun 3, 2010 at 12:10 PM, Craig L Russell
> <cr...@oracle.com> wrote:
>> Hi Les,
>>
>> On Jun 3, 2010, at 10:51 AM, Les Hazlewood wrote:
>>
>>> Thanks for the clarification.  And yes, I totally agree that the
>>> download page should be changed to point to central
>>
>> There's a .cgi script that points to mirrors that all projects copy. It's
>> not a big deal right now because of the small number of downloads we expect
>> for an incubating release, but it's good to get it right for practice.
>>
>> If you need help finding the mirror .cgi script let me know.
>>
>> Craig
>>
>>> instead of the ASF
>>> repo.  I'll make that change now.
>>>
>>> Thanks,
>>>
>>> Les
>>>
>>> On Thu, Jun 3, 2010 at 7:26 AM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>>
>>>> Yes, that's the entire source. I missed your note on the dist, will do.
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Thu, Jun 3, 2010 at 1:14 AM, Craig L Russell
>>>> <cr...@oracle.com> wrote:
>>>>>
>>>>> Hi Kalle,
>>>>>
>>>>> When I looked at the release, it looked like the proper official source
>>>>> release is the shiro-root artifacts with their checksums and signatures.
>>>>>
>>>>> Specifically, the shiro-root-1.0.0-incubating-source-release.zip and
>>>>> checksums and signatures from
>>>>>
>>>>> https://repository.apache.org/content/repositories/staging/org/apache/shiro/shiro-root/1.0.0-incubating/
>>>>>
>>>>> If I understand this, it's the entire source tree that constitutes a
>>>>> release.
>>>>>
>>>>> I think I commented earlier that these artifacts are those that would be
>>>>> put
>>>>> into the dist/incubator/shiro/1.0.0-incubating directory.
>>>>>
>>>>> Craig
>>>>>
>>>>> On Jun 2, 2010, at 11:16 PM, Kalle Korhonen wrote:
>>>>>
>>>>>> Whoops. One thing missing from the release - we don't have anything in
>>>>>> the Apache Shiro distribution area. My oversight, been living in Maven
>>>>>> land for too long. I checked and created the Shiro directory already,
>>>>>> the only real question is what should we put in there? Just the
>>>>>> shiro-all with keys (the primary artifact from
>>>>>>
>>>>>>
>>>>>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>>>>>> According to the instructions, project documentation doesn't go in
>>>>>> there. Mentors have any advice? Maven or not, I think we should add
>>>>>> some of the release packages in the distribution area, especially
>>>>>> since it's tracked by Incubator clutch.
>>>>>>
>>>>>> Kalle
>>>>>
>>>>> Craig L Russell
>>>>> Architect, Oracle
>>>>> http://db.apache.org/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>>
>>>>
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
I'm not sure that we would need that for the binary .jar downloads on
the download page [1] (in the 'Binary Distribution' section, see the
'Artifact' table column).  By linking directly to the Maven Central
url, we guarantee that the ASF infrastructure won't be 'hit', since
apparently that's what people are concerned about.

It might make sense to use the .cgi for the source release .zip
though, which Kalle is taking care of I believe.  Kalle, do you need
that?

Les

[1] http://incubator.apache.org/shiro/download.html

On Thu, Jun 3, 2010 at 12:10 PM, Craig L Russell
<cr...@oracle.com> wrote:
> Hi Les,
>
> On Jun 3, 2010, at 10:51 AM, Les Hazlewood wrote:
>
>> Thanks for the clarification.  And yes, I totally agree that the
>> download page should be changed to point to central
>
> There's a .cgi script that points to mirrors that all projects copy. It's
> not a big deal right now because of the small number of downloads we expect
> for an incubating release, but it's good to get it right for practice.
>
> If you need help finding the mirror .cgi script let me know.
>
> Craig
>
>> instead of the ASF
>> repo.  I'll make that change now.
>>
>> Thanks,
>>
>> Les
>>
>> On Thu, Jun 3, 2010 at 7:26 AM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>>
>>> Yes, that's the entire source. I missed your note on the dist, will do.
>>>
>>> Kalle
>>>
>>>
>>> On Thu, Jun 3, 2010 at 1:14 AM, Craig L Russell
>>> <cr...@oracle.com> wrote:
>>>>
>>>> Hi Kalle,
>>>>
>>>> When I looked at the release, it looked like the proper official source
>>>> release is the shiro-root artifacts with their checksums and signatures.
>>>>
>>>> Specifically, the shiro-root-1.0.0-incubating-source-release.zip and
>>>> checksums and signatures from
>>>>
>>>> https://repository.apache.org/content/repositories/staging/org/apache/shiro/shiro-root/1.0.0-incubating/
>>>>
>>>> If I understand this, it's the entire source tree that constitutes a
>>>> release.
>>>>
>>>> I think I commented earlier that these artifacts are those that would be
>>>> put
>>>> into the dist/incubator/shiro/1.0.0-incubating directory.
>>>>
>>>> Craig
>>>>
>>>> On Jun 2, 2010, at 11:16 PM, Kalle Korhonen wrote:
>>>>
>>>>> Whoops. One thing missing from the release - we don't have anything in
>>>>> the Apache Shiro distribution area. My oversight, been living in Maven
>>>>> land for too long. I checked and created the Shiro directory already,
>>>>> the only real question is what should we put in there? Just the
>>>>> shiro-all with keys (the primary artifact from
>>>>>
>>>>>
>>>>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>>>>> According to the instructions, project documentation doesn't go in
>>>>> there. Mentors have any advice? Maven or not, I think we should add
>>>>> some of the release packages in the distribution area, especially
>>>>> since it's tracked by Incubator clutch.
>>>>>
>>>>> Kalle
>>>>
>>>> Craig L Russell
>>>> Architect, Oracle
>>>> http://db.apache.org/jdo
>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Craig L Russell <cr...@oracle.com>.
Hi Les,

On Jun 3, 2010, at 10:51 AM, Les Hazlewood wrote:

> Thanks for the clarification.  And yes, I totally agree that the
> download page should be changed to point to central

There's a .cgi script that points to mirrors that all projects copy.  
It's not a big deal right now because of the small number of downloads  
we expect for an incubating release, but it's good to get it right for  
practice.

If you need help finding the mirror .cgi script let me know.

Craig

> instead of the ASF
> repo.  I'll make that change now.
>
> Thanks,
>
> Les
>
> On Thu, Jun 3, 2010 at 7:26 AM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Yes, that's the entire source. I missed your note on the dist, will  
>> do.
>>
>> Kalle
>>
>>
>> On Thu, Jun 3, 2010 at 1:14 AM, Craig L Russell
>> <cr...@oracle.com> wrote:
>>> Hi Kalle,
>>>
>>> When I looked at the release, it looked like the proper official  
>>> source
>>> release is the shiro-root artifacts with their checksums and  
>>> signatures.
>>>
>>> Specifically, the shiro-root-1.0.0-incubating-source-release.zip and
>>> checksums and signatures from
>>> https://repository.apache.org/content/repositories/staging/org/apache/shiro/shiro-root/1.0.0-incubating/
>>>
>>> If I understand this, it's the entire source tree that constitutes a
>>> release.
>>>
>>> I think I commented earlier that these artifacts are those that  
>>> would be put
>>> into the dist/incubator/shiro/1.0.0-incubating directory.
>>>
>>> Craig
>>>
>>> On Jun 2, 2010, at 11:16 PM, Kalle Korhonen wrote:
>>>
>>>> Whoops. One thing missing from the release - we don't have  
>>>> anything in
>>>> the Apache Shiro distribution area. My oversight, been living in  
>>>> Maven
>>>> land for too long. I checked and created the Shiro directory  
>>>> already,
>>>> the only real question is what should we put in there? Just the
>>>> shiro-all with keys (the primary artifact from
>>>>
>>>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>>>> According to the instructions, project documentation doesn't go in
>>>> there. Mentors have any advice? Maven or not, I think we should add
>>>> some of the release packages in the distribution area, especially
>>>> since it's tracked by Incubator clutch.
>>>>
>>>> Kalle
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
Thanks for the clarification.  And yes, I totally agree that the
download page should be changed to point to central instead of the ASF
repo.  I'll make that change now.

Thanks,

Les

On Thu, Jun 3, 2010 at 7:26 AM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Yes, that's the entire source. I missed your note on the dist, will do.
>
> Kalle
>
>
> On Thu, Jun 3, 2010 at 1:14 AM, Craig L Russell
> <cr...@oracle.com> wrote:
>> Hi Kalle,
>>
>> When I looked at the release, it looked like the proper official source
>> release is the shiro-root artifacts with their checksums and signatures.
>>
>> Specifically, the shiro-root-1.0.0-incubating-source-release.zip and
>> checksums and signatures from
>> https://repository.apache.org/content/repositories/staging/org/apache/shiro/shiro-root/1.0.0-incubating/
>>
>> If I understand this, it's the entire source tree that constitutes a
>> release.
>>
>> I think I commented earlier that these artifacts are those that would be put
>> into the dist/incubator/shiro/1.0.0-incubating directory.
>>
>> Craig
>>
>> On Jun 2, 2010, at 11:16 PM, Kalle Korhonen wrote:
>>
>>> Whoops. One thing missing from the release - we don't have anything in
>>> the Apache Shiro distribution area. My oversight, been living in Maven
>>> land for too long. I checked and created the Shiro directory already,
>>> the only real question is what should we put in there? Just the
>>> shiro-all with keys (the primary artifact from
>>>
>>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>>> According to the instructions, project documentation doesn't go in
>>> there. Mentors have any advice? Maven or not, I think we should add
>>> some of the release packages in the distribution area, especially
>>> since it's tracked by Incubator clutch.
>>>
>>> Kalle
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Kalle Korhonen <ka...@gmail.com>.
Yes, that's the entire source. I missed your note on the dist, will do.

Kalle


On Thu, Jun 3, 2010 at 1:14 AM, Craig L Russell
<cr...@oracle.com> wrote:
> Hi Kalle,
>
> When I looked at the release, it looked like the proper official source
> release is the shiro-root artifacts with their checksums and signatures.
>
> Specifically, the shiro-root-1.0.0-incubating-source-release.zip and
> checksums and signatures from
> https://repository.apache.org/content/repositories/staging/org/apache/shiro/shiro-root/1.0.0-incubating/
>
> If I understand this, it's the entire source tree that constitutes a
> release.
>
> I think I commented earlier that these artifacts are those that would be put
> into the dist/incubator/shiro/1.0.0-incubating directory.
>
> Craig
>
> On Jun 2, 2010, at 11:16 PM, Kalle Korhonen wrote:
>
>> Whoops. One thing missing from the release - we don't have anything in
>> the Apache Shiro distribution area. My oversight, been living in Maven
>> land for too long. I checked and created the Shiro directory already,
>> the only real question is what should we put in there? Just the
>> shiro-all with keys (the primary artifact from
>>
>> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
>> According to the instructions, project documentation doesn't go in
>> there. Mentors have any advice? Maven or not, I think we should add
>> some of the release packages in the distribution area, especially
>> since it's tracked by Incubator clutch.
>>
>> Kalle
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Craig L Russell <cr...@oracle.com>.
Hi Kalle,

When I looked at the release, it looked like the proper official  
source release is the shiro-root artifacts with their checksums and  
signatures.

Specifically, the shiro-root-1.0.0-incubating-source-release.zip and  
checksums and signatures from https://repository.apache.org/content/repositories/staging/org/apache/shiro/shiro-root/1.0.0-incubating/

If I understand this, it's the entire source tree that constitutes a  
release.

I think I commented earlier that these artifacts are those that would  
be put into the dist/incubator/shiro/1.0.0-incubating directory.

Craig

On Jun 2, 2010, at 11:16 PM, Kalle Korhonen wrote:

> Whoops. One thing missing from the release - we don't have anything in
> the Apache Shiro distribution area. My oversight, been living in Maven
> land for too long. I checked and created the Shiro directory already,
> the only real question is what should we put in there? Just the
> shiro-all with keys (the primary artifact from
> http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
> According to the instructions, project documentation doesn't go in
> there. Mentors have any advice? Maven or not, I think we should add
> some of the release packages in the distribution area, especially
> since it's tracked by Incubator clutch.
>
> Kalle

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Kalle Korhonen <ka...@gmail.com>.
Whoops. One thing missing from the release - we don't have anything in
the Apache Shiro distribution area. My oversight, been living in Maven
land for too long. I checked and created the Shiro directory already,
the only real question is what should we put in there? Just the
shiro-all with keys (the primary artifact from
http://repo2.maven.org/maven2/org/apache/shiro/shiro-all/1.0.0-incubating/)?
According to the instructions, project documentation doesn't go in
there. Mentors have any advice? Maven or not, I think we should add
some of the release packages in the distribution area, especially
since it's tracked by Incubator clutch.

Kalle

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
Ah, thanks - that's because they're not written yet and are
placeholders.  Non space-admins can't add those pages dynamically,
which is why you're seeing the error.  I'll fix that asap.

Thanks!

Les

On Tue, Jun 1, 2010 at 11:11 AM,  <gs...@berkeley.edu> wrote:
> Congratulations!
>
> The Reference Manual doesn't provide public access to Authenticator,
> Authorizer, SessionManager, CacheManager, Cryptography, Codec, and AOP.
> Instead they show "Not Permitted"
>
> Gary Struthers
>
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by gs...@berkeley.edu.
Congratulations!

The Reference Manual doesn't provide public access to Authenticator,
Authorizer, SessionManager, CacheManager, Cryptography, Codec, and AOP.
Instead they show "Not Permitted"

Gary Struthers


Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Les Hazlewood <lh...@apache.org>.
Thanks!

And we'll get the logo in there hopefully soon after the voting is
done next week :)

Cheers,

Les

2010/6/1 Tamás Cservenák <ta...@cservenak.net>:
> Congrats for 1.0 release!
>
> But, how did you dare to release without official logo yet?? :D
>
>
> Thanks,
> ~t~

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Tamás Cservenák <ta...@cservenak.net>.
Congrats for 1.0 release!

But, how did you dare to release without official logo yet?? :D


Thanks,
~t~

On Tue, Jun 1, 2010 at 7:01 PM, Les Hazlewood <lh...@apache.org> wrote:

> Dear Apache Shiro Community,
>
> We are proud and excited to offer Apache Shiro's first stable release
> as an Apache Incubator podling!
>
> Version 1.0.0-incubating is available immediately for download here:
>
> http://incubator.apache.org/shiro/download.html
>
> Associated documentation is available here:
>
> http://incubator.apache.org/shiro/documentation.html
>
> Release notes are included below.
>
> Thank you so much to the Apache community and the Apache Incubator for
> helping us move toward our first release.  A very special thanks goes
> to our user community and early adopters for helping us refine our
> first stable release.
>
> Best Regards,
>
> Les Hazlewood
>
> ------
>
> Release Notes are browsable online here:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310950&styleName=Html&version=12314078
>
> And included here for convenience:
>
> Release Notes - Shiro - Version 1.0.0-incubating
>
> ** Bug
>    * [SHIRO-10] - Aliases in the ini configuration builder do not
> work correctly
>    * [SHIRO-82] - Shiro strips anchor (#) values from the URL if user
> is unauthenticated
>    * [SHIRO-87] - Fix package name of package-info.java in shiro-core
>    * [SHIRO-89] - Sample Spring Application - WebStart won't launch
>    * [SHIRO-95] - Specifying my own Cache in ShiroFilter not working
>    * [SHIRO-101] - Comma in role in the properties file is not read
> correctly by the PropertyRealm
>    * [SHIRO-106] - AuthorizationFilter needs to use sendError not
> setStatus to make container process the request through ERROR
> dispatcher
>    * [SHIRO-108] - Basic HTTP Auth: Empty password or username causes
> IllegalStateException
>    * [SHIRO-115] - ActiveDirectoryRealm might by vulnerable to LDAP
> search code injection
>    * [SHIRO-120] - AbstractLdapRealm's doGetAuthenticationInfo
> catches naming exception, but then only logs a message
>    * [SHIRO-124] - MethodInvocation is missing a getThis() (or
> equivalent) method
>    * [SHIRO-130] - ShiroFilter does not work with proxied security manager
>    * [SHIRO-135] - AccessControlException exception on GAE with Grails
>    * [SHIRO-138] - AbstractRememberMeManager attempts to process
> null/empty byte array
>    * [SHIRO-141] - Problem with WebRememberMeManager
>    * [SHIRO-142] - Jetty throws an IllegalStateException after
> redirect in AuthorizationFilter
>    * [SHIRO-145] - Losing Session
>    * [SHIRO-150] - RememberMeManager NPE
>    * [SHIRO-154] - Adding ehcahe CacheManager to Spring Sample failes
>    * [SHIRO-156] - SimpleAuthenticationInfo.merge does not merge
> principals if its internal principal collection is not mutable
>    * [SHIRO-157] - RememberMeManager should no longer be consulted
> once a remembered identity is discovered
>    * [SHIRO-158] - Date
> AbstractSessionManager.getLastAccessTime(Serializable) returns start
> time
>    * [SHIRO-159] - ThreadLocal is not cleared upon the unloading of
> the webapp and the SHiro Servlet
>    * [SHIRO-161] - No SecurityManager accessible to the calling code
>    * [SHIRO-163] - ModularRealmAuthorizer.setRealms needs to call
> applyRolePermissionResolverToRealms
>    * [SHIRO-164] - The request/response pair should be available at
> all times to web-related components
>    * [SHIRO-167] - getServletContext allways return null with conf
> via spring (native mode)
>    * [SHIRO-172] - Missing SVN properties
>
> ** Improvement
>    * [SHIRO-59] - Refactor Realm implementations to favor delegation
> over inheritance
>    * [SHIRO-83] - Make sessionId cookie optional
>    * [SHIRO-86] - Add Builder design pattern for arbitrary Subject
> construction
>    * [SHIRO-88] - Create a profile for installing javadocs and source
> to keep build time short
>    * [SHIRO-104] - Default AuthenticationStrategy should be
> AtLeastOneSuccessful instead of All
>    * [SHIRO-109] - RememberMeManager should have access to Subject context
> map
>    * [SHIRO-110] - Remove org.apache.shiro.mgt.SubjectBinder and its usages
>    * [SHIRO-111] - Web SecurityManager should not fail in non-request
> usages
>    * [SHIRO-112] - Implement Externalizable for serializable classes
>    * [SHIRO-114] - Break circular dependency between SubjectFactory
> and DefaultSecurityManager
>    * [SHIRO-125] - Support overrding the credentialsMatcher for the
> implicit IniRealm
>    * [SHIRO-128] - Remove convenience configuration methods
>    * [SHIRO-131] - Improved Shiro Filter configuration for Spring
> environments
>    * [SHIRO-133] - Automatically shut down the Session validation thread
>    * [SHIRO-136] - Mark Spring as scope provided to let users
> specificy their own version of Spring
>    * [SHIRO-137] - Go through Shiro dependencies and consider marking
> most third-party dependencies as provided
>    * [SHIRO-139] - Cookie support refactoring - Simplify cookie
> configuration, support HttpOnly cookies and default session cookies to
> be HttpOnly = true
>    * [SHIRO-144] - MemorySessionDao should be propably abstract
>    * [SHIRO-146] - Annotation authorizations should throw
> UnauthenticationException if the subject identity is not known.
>    * [SHIRO-148] - SimpleSession efficient serialization
>    * [SHIRO-152] - INI configuration must support configuration of
> Lists, Sets and Maps
>    * [SHIRO-153] - INI: remove need for [filters] section and perform
> all object configuration in [main]
>
> ** New Feature
>    * [SHIRO-25] - Assumed Identity, aka 'Run As' support
>    * [SHIRO-30] - Subject acquisition based on method argument
>    * [SHIRO-92] - Add method to Subject interface: isRemembered()
>    * [SHIRO-105] - PrincipalCollection should have a
> getPrimaryPrincipal() method
>    * [SHIRO-107] - Filter chain definitions should match on request
> method as well as request path (REST support)
>    * [SHIRO-116] - Ini configuration - users/roles sections should
> trigger automatic Realm creation
>    * [SHIRO-118] - Ini Realm support
>    * [SHIRO-121] - Change usages of java.net.InetAddress to be Strings
>    * [SHIRO-122] - Create IdentifierGenerator interface for pluggable
> id generation strategies
>    * [SHIRO-129] - Aspecjt integration for annotation base authorization
>    * [SHIRO-140] - Add a subject-aware ExecutorService implementation
> to support Subject execution on other threads
>    * [SHIRO-147] - Add an AES Cipher
>
> ** Task
>    * [SHIRO-34] - Cipher refactoring
>    * [SHIRO-37] - Deploy snapshots automatically
>    * [SHIRO-43] - Ignore Eclipse folders & files and mvn target
> folders from svn
>    * [SHIRO-49] - Fix SimpleAccountRealm to not rely on caching
>    * [SHIRO-50] - Spring NOTICE
>    * [SHIRO-52] - Verify all samples deploy/run successfully
>    * [SHIRO-94] - Update web pages to change JSecurity and Ki to Shiro
>    * [SHIRO-102] - Set-up AutoExport of Shiro documentation to the
> appropriate location
>    * [SHIRO-103] - Fix "Ki" in the Apache Incubator Status Page
>    * [SHIRO-149] - Create release configuration and a profile for
> deploying release docs to a separate directory
>    * [SHIRO-155] - Remove all deprecated methods and classes
>    * [SHIRO-162] - Create SessionContext to mirror SubjectContext
> concept for starting new sessions
>
> ** Test
>    * [SHIRO-90] -
> org.apache.shiro.session.mgt.DefaultSessionManagerTest.testGlobalTimeout
> is unreliable
>    * [SHIRO-91] - Tests for getRememberedPrincipals and
> getRememberedPrincipalsDecryptionError in WebRememberMeManagerTest are
> disabled
>    * [SHIRO-93] - Add container-based integration tests for samples/web
> module
>    * [SHIRO-96] - Add meaningful integration tests to assert key web
> functionality
>
> ** Wish
>    * [SHIRO-143] - Change logging level from trace to warning in
> ModularRealmAuthenticator when a Realm throws an Exception
>

Re: [ANN] Apache Shiro 1.0.0-incubating Released!

Posted by Paul Merlin <es...@n0pe.org>.
Congrats !!

\o/

Le 1 juin 2010 à 19:01, Les Hazlewood <lh...@apache.org> a  
écrit :

> Dear Apache Shiro Community,
>
> We are proud and excited to offer Apache Shiro's first stable release
> as an Apache Incubator podling!
>
> Version 1.0.0-incubating is available immediately for download here:
>
> http://incubator.apache.org/shiro/download.html
>
> Associated documentation is available here:
>
> http://incubator.apache.org/shiro/documentation.html
>
> Release notes are included below.
>
> Thank you so much to the Apache community and the Apache Incubator for
> helping us move toward our first release.  A very special thanks goes
> to our user community and early adopters for helping us refine our
> first stable release.
>
> Best Regards,
>
> Les Hazlewood
>
> ------
>
> Release Notes are browsable online here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310950&styleName=Html&version=12314078
>
> And included here for convenience:
>
> Release Notes - Shiro - Version 1.0.0-incubating
>
> ** Bug
>    * [SHIRO-10] - Aliases in the ini configuration builder do not
> work correctly
>    * [SHIRO-82] - Shiro strips anchor (#) values from the URL if user
> is unauthenticated
>    * [SHIRO-87] - Fix package name of package-info.java in shiro-core
>    * [SHIRO-89] - Sample Spring Application - WebStart won't launch
>    * [SHIRO-95] - Specifying my own Cache in ShiroFilter not working
>    * [SHIRO-101] - Comma in role in the properties file is not read
> correctly by the PropertyRealm
>    * [SHIRO-106] - AuthorizationFilter needs to use sendError not
> setStatus to make container process the request through ERROR
> dispatcher
>    * [SHIRO-108] - Basic HTTP Auth: Empty password or username causes
> IllegalStateException
>    * [SHIRO-115] - ActiveDirectoryRealm might by vulnerable to LDAP
> search code injection
>    * [SHIRO-120] - AbstractLdapRealm's doGetAuthenticationInfo
> catches naming exception, but then only logs a message
>    * [SHIRO-124] - MethodInvocation is missing a getThis() (or
> equivalent) method
>    * [SHIRO-130] - ShiroFilter does not work with proxied security  
> manager
>    * [SHIRO-135] - AccessControlException exception on GAE with Grails
>    * [SHIRO-138] - AbstractRememberMeManager attempts to process
> null/empty byte array
>    * [SHIRO-141] - Problem with WebRememberMeManager
>    * [SHIRO-142] - Jetty throws an IllegalStateException after
> redirect in AuthorizationFilter
>    * [SHIRO-145] - Losing Session
>    * [SHIRO-150] - RememberMeManager NPE
>    * [SHIRO-154] - Adding ehcahe CacheManager to Spring Sample failes
>    * [SHIRO-156] - SimpleAuthenticationInfo.merge does not merge
> principals if its internal principal collection is not mutable
>    * [SHIRO-157] - RememberMeManager should no longer be consulted
> once a remembered identity is discovered
>    * [SHIRO-158] - Date
> AbstractSessionManager.getLastAccessTime(Serializable) returns start
> time
>    * [SHIRO-159] - ThreadLocal is not cleared upon the unloading of
> the webapp and the SHiro Servlet
>    * [SHIRO-161] - No SecurityManager accessible to the calling code
>    * [SHIRO-163] - ModularRealmAuthorizer.setRealms needs to call
> applyRolePermissionResolverToRealms
>    * [SHIRO-164] - The request/response pair should be available at
> all times to web-related components
>    * [SHIRO-167] - getServletContext allways return null with conf
> via spring (native mode)
>    * [SHIRO-172] - Missing SVN properties
>
> ** Improvement
>    * [SHIRO-59] - Refactor Realm implementations to favor delegation
> over inheritance
>    * [SHIRO-83] - Make sessionId cookie optional
>    * [SHIRO-86] - Add Builder design pattern for arbitrary Subject  
> construction
>    * [SHIRO-88] - Create a profile for installing javadocs and source
> to keep build time short
>    * [SHIRO-104] - Default AuthenticationStrategy should be
> AtLeastOneSuccessful instead of All
>    * [SHIRO-109] - RememberMeManager should have access to Subject  
> context map
>    * [SHIRO-110] - Remove org.apache.shiro.mgt.SubjectBinder and its  
> usages
>    * [SHIRO-111] - Web SecurityManager should not fail in non- 
> request usages
>    * [SHIRO-112] - Implement Externalizable for serializable classes
>    * [SHIRO-114] - Break circular dependency between SubjectFactory
> and DefaultSecurityManager
>    * [SHIRO-125] - Support overrding the credentialsMatcher for the
> implicit IniRealm
>    * [SHIRO-128] - Remove convenience configuration methods
>    * [SHIRO-131] - Improved Shiro Filter configuration for Spring  
> environments
>    * [SHIRO-133] - Automatically shut down the Session validation  
> thread
>    * [SHIRO-136] - Mark Spring as scope provided to let users
> specificy their own version of Spring
>    * [SHIRO-137] - Go through Shiro dependencies and consider marking
> most third-party dependencies as provided
>    * [SHIRO-139] - Cookie support refactoring - Simplify cookie
> configuration, support HttpOnly cookies and default session cookies to
> be HttpOnly = true
>    * [SHIRO-144] - MemorySessionDao should be propably abstract
>    * [SHIRO-146] - Annotation authorizations should throw
> UnauthenticationException if the subject identity is not known.
>    * [SHIRO-148] - SimpleSession efficient serialization
>    * [SHIRO-152] - INI configuration must support configuration of
> Lists, Sets and Maps
>    * [SHIRO-153] - INI: remove need for [filters] section and perform
> all object configuration in [main]
>
> ** New Feature
>    * [SHIRO-25] - Assumed Identity, aka 'Run As' support
>    * [SHIRO-30] - Subject acquisition based on method argument
>    * [SHIRO-92] - Add method to Subject interface: isRemembered()
>    * [SHIRO-105] - PrincipalCollection should have a
> getPrimaryPrincipal() method
>    * [SHIRO-107] - Filter chain definitions should match on request
> method as well as request path (REST support)
>    * [SHIRO-116] - Ini configuration - users/roles sections should
> trigger automatic Realm creation
>    * [SHIRO-118] - Ini Realm support
>    * [SHIRO-121] - Change usages of java.net.InetAddress to be Strings
>    * [SHIRO-122] - Create IdentifierGenerator interface for pluggable
> id generation strategies
>    * [SHIRO-129] - Aspecjt integration for annotation base  
> authorization
>    * [SHIRO-140] - Add a subject-aware ExecutorService implementation
> to support Subject execution on other threads
>    * [SHIRO-147] - Add an AES Cipher
>
> ** Task
>    * [SHIRO-34] - Cipher refactoring
>    * [SHIRO-37] - Deploy snapshots automatically
>    * [SHIRO-43] - Ignore Eclipse folders & files and mvn target
> folders from svn
>    * [SHIRO-49] - Fix SimpleAccountRealm to not rely on caching
>    * [SHIRO-50] - Spring NOTICE
>    * [SHIRO-52] - Verify all samples deploy/run successfully
>    * [SHIRO-94] - Update web pages to change JSecurity and Ki to Shiro
>    * [SHIRO-102] - Set-up AutoExport of Shiro documentation to the
> appropriate location
>    * [SHIRO-103] - Fix "Ki" in the Apache Incubator Status Page
>    * [SHIRO-149] - Create release configuration and a profile for
> deploying release docs to a separate directory
>    * [SHIRO-155] - Remove all deprecated methods and classes
>    * [SHIRO-162] - Create SessionContext to mirror SubjectContext
> concept for starting new sessions
>
> ** Test
>    * [SHIRO-90] -
> org.apache.shiro.session.mgt.DefaultSessionManagerTest.testGlobalTimeout
 

> is unreliable
>    * [SHIRO-91] - Tests for getRememberedPrincipals and
> getRememberedPrincipalsDecryptionError in WebRememberMeManagerTest are
> disabled
>    * [SHIRO-93] - Add container-based integration tests for samples/ 
> web module
>    * [SHIRO-96] - Add meaningful integration tests to assert key web
> functionality
>
> ** Wish
>    * [SHIRO-143] - Change logging level from trace to warning in
> ModularRealmAuthenticator when a Realm throws an Exception