Re: [Acegisecurity-developer] Security Annotation support (initial)
Ok Ben, We can stick with separate jars for the core and core-tiger (like I have it right now)... It does seem to be a cleaner separation, I just noticed that Colin had the Java 5 annotations in the full spring.jar distribution... however seems like SWF is separating and future Spring builds may do the same.. 2 jars it is Cheers, Mark > > >Hi, > > > >I'd really encourage the use of two jars, core and core-tiger, instead > >of packaging the tiger classes inside core jar, because the core-tiger > >probably depends on core and you don't want core to depend on tiger. > >You'll notice the problem of that approach in any tool with transitive > >dependency resolution like Maven2, Ivy or any other. > > > > > Thanks Carlos > > Given Carlos' advice, it seems to me like we should stick to separate > acegi-security-xx.jar and acegi-security-tiger-xx.jar files to properly > support transitive dependencies. Do others agree? > > Cheers > Ben > > > --- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > ___ > Home: http://acegisecurity.sourceforge.net > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Security Annotation support (initial)
On Tue, 23 Aug 2005 07:44:30 +1000, Ben Alex wrote > Given Carlos' advice, it seems to me like we should stick to > separate acegi-security-xx.jar and acegi-security-tiger-xx.jar files > to properly support transitive dependencies. Do others agree? I agree. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Security Annotation support (initial)
Ben Alex wrote: Carlos Sanchez wrote: Hi, I'd really encourage the use of two jars, core and core-tiger, instead of packaging the tiger classes inside core jar, because the core-tiger probably depends on core and you don't want core to depend on tiger. You'll notice the problem of that approach in any tool with transitive dependency resolution like Maven2, Ivy or any other. Thanks Carlos Given Carlos' advice, it seems to me like we should stick to separate acegi-security-xx.jar and acegi-security-tiger-xx.jar files to properly support transitive dependencies. Do others agree? FWIW, for spring-webflow what Keith did based on my suggestion is split off the annotations code into a separate spring-webflow-annotations.jar, different from the normal spring-webflow.jar. What mostly drove this in the Web Flow case was the need to build things differently (JDK 1.3 vs JDK 1.5) as the source/target settings. In Web Flow we're using an Ivy-based common build system, so it was trivial to do things like this (just set a different property in the separate project), whereas it would have been very hard to produce one combined jar or two separate jars, from one project. I assume Maven presents some of the same issues. In the case of Spring itself, it's easier because it's a totally custom ant script that just produces two jars from two totally separate code trees. When/if core Spring itself moves to the common-build system itself, we'll probably also have ot split things out there for the same reason. Colin -- Colin Sampaleanu Interface21 Principal Consultant Spring Training, Consulting and Support - "From the Source" http://www.springframework.com --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Security Annotation support (initial)
Carlos Sanchez wrote: Hi, I'd really encourage the use of two jars, core and core-tiger, instead of packaging the tiger classes inside core jar, because the core-tiger probably depends on core and you don't want core to depend on tiger. You'll notice the problem of that approach in any tool with transitive dependency resolution like Maven2, Ivy or any other. Thanks Carlos Given Carlos' advice, it seems to me like we should stick to separate acegi-security-xx.jar and acegi-security-tiger-xx.jar files to properly support transitive dependencies. Do others agree? Cheers Ben --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Security Annotation support (initial)
Hi,
I'd really encourage the use of two jars, core and core-tiger, instead
of packaging the tiger classes inside core jar, because the core-tiger
probably depends on core and you don't want core to depend on tiger.
You'll notice the problem of that approach in any tool with transitive
dependency resolution like Maven2, Ivy or any other.
Anyway the solution maybe something like this, check the java.version
property and run maven in the other project. This will require having
the sources for core-tiger. It'd be better adding a dependency to the
core-tiger jar and extract it in classes before making the jar, but
then you propably get circular dependencies, which it's a reson to go
back to my first suggestion.
Java5
this won't work if you're using another compiler other than the used
to run maven (overriding maven.compile.executable
http://maven.apache.org/reference/plugins/java/properties.html), but I
don't think that's a common case.
Regards
Carlos Sanchez
http://www.jroller.com/page/carlossg
On 8/21/05, Ben Alex <[EMAIL PROTECTED]> wrote:
> Mark St.Godard wrote:
>
> >I just wanted to make sure I dont check in code that breaks JDK 1.4
> >users from building the CVS HEAD examples, etc.
> >
> >Therefore to sum up:
> >
> >- can we package the core-tiger classes into the single acegi security dist?
> >- where should the new samples (for java5) be located?
> >
> >Thoughts?
> >
> >
> Yesterday I asked whether anyone was using the Commons Attributes
> support. The reason is that when you install commons-attributes-plugin,
> you in effect add a plugin to Maven that will throw exceptions if you
> are using any Java 1.5 features such as annotations and enums.
>
> http://jakarta.apache.org/commons/attributes/maven_demo.html indicates
> that 2.1 is the latest version of the Commons Attributes plugin, so you
> install using:
>
> maven plugin:download -DgroupId=commons-attributes-plugin
> -DartifactId=commons-attributes-plugin -Dversion=2.1
>
> However, if you install the plugin and then use Java 1.5-specific
> features in your build, this is what the Maven build will give you:
>
> (What happens for an enum):
> Error parsing File .\CounterEnum.java:Encountered "enum" at line 9,
> column 8.
> Was expecting one of:
> "abstract" ...
> "interface" ...
> "public" ...
> "strictfp" ...
> "final" ...
> "class" ...
>
> (What happens for a generics declaration):
> Error parsing File \RoleDaoHibernate.java:Encountered "<" at line
> 21, column 51.
> Was expecting one of:
> "implements" ...
> "{" ...
> "." ...
>
> According to http://jakarta.apache.org/commons/attributes/faq.html:
>
> *Q: What are the future plans for Commons-Attributes?**
>
> A:* As indicated above, C-A isn't expected to live beyond widespread
> adoption of Java 5.0. But until then, the main area of concern is ease
> of use
>
> The above issue is therefore only a concern for people wishing to build
> the /samples/attributes sample, as then the plugin is required. I think
> we should therefore disable the /samples/attributes as part of the /docs
> multiproject build, leaving it to users of Commons Attributes to
> manually build (and install the problematic plugin) if they so wish.
> Does anyone have a concern with that?
>
> Assuming we do the above, I think that having a new sample specifically
> for annotations would be appropriate. We can use the same classes as
> used in the attributes sample, so that people can compare the two
> approaches. Of course, the attributes sample would have in its
> project.properties the 1.5-specific source and compile properties.
>
> I have no issue with having the 1.5-specific classes in the
> acegi-security-xxx.jar. Achieving that will need some /core/maven.xml
> jar:jar pre-goal customisation. Two approaches would be to run the
> /core-tiger build if 1.5 is detected and then copy the files across to
> /core/target/classes. Alternatively, just copy the
> /core-tiger/target/classes if they exist to /core/target/classes and
> expect users to first build core-tiger (such that the
> /core-tiger/target/classes exists). The latter approach is easier, but
> I'm sure the former is achievable with Maven as well.
>
> Cheers
> Ben
>
>
> ---
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> ___
> Home: http://acegisecurity.sourceforge.net
> Acegisecurity-developer mailing list
> Acegisecurity-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
>
---
SF.Net email is Sponsored by the
Re: [Acegisecurity-developer] Security Annotation support (initial)
Mark St.Godard wrote:
I just wanted to make sure I dont check in code that breaks JDK 1.4
users from building the CVS HEAD examples, etc.
Therefore to sum up:
- can we package the core-tiger classes into the single acegi security dist?
- where should the new samples (for java5) be located?
Thoughts?
Yesterday I asked whether anyone was using the Commons Attributes
support. The reason is that when you install commons-attributes-plugin,
you in effect add a plugin to Maven that will throw exceptions if you
are using any Java 1.5 features such as annotations and enums.
http://jakarta.apache.org/commons/attributes/maven_demo.html indicates
that 2.1 is the latest version of the Commons Attributes plugin, so you
install using:
maven plugin:download -DgroupId=commons-attributes-plugin
-DartifactId=commons-attributes-plugin -Dversion=2.1
However, if you install the plugin and then use Java 1.5-specific
features in your build, this is what the Maven build will give you:
(What happens for an enum):
Error parsing File .\CounterEnum.java:Encountered "enum" at line 9,
column 8.
Was expecting one of:
"abstract" ...
"interface" ...
"public" ...
"strictfp" ...
"final" ...
"class" ...
(What happens for a generics declaration):
Error parsing File \RoleDaoHibernate.java:Encountered "<" at line
21, column 51.
Was expecting one of:
"implements" ...
"{" ...
"." ...
According to http://jakarta.apache.org/commons/attributes/faq.html:
*Q: What are the future plans for Commons-Attributes?**
A:* As indicated above, C-A isn't expected to live beyond widespread
adoption of Java 5.0. But until then, the main area of concern is ease
of use
The above issue is therefore only a concern for people wishing to build
the /samples/attributes sample, as then the plugin is required. I think
we should therefore disable the /samples/attributes as part of the /docs
multiproject build, leaving it to users of Commons Attributes to
manually build (and install the problematic plugin) if they so wish.
Does anyone have a concern with that?
Assuming we do the above, I think that having a new sample specifically
for annotations would be appropriate. We can use the same classes as
used in the attributes sample, so that people can compare the two
approaches. Of course, the attributes sample would have in its
project.properties the 1.5-specific source and compile properties.
I have no issue with having the 1.5-specific classes in the
acegi-security-xxx.jar. Achieving that will need some /core/maven.xml
jar:jar pre-goal customisation. Two approaches would be to run the
/core-tiger build if 1.5 is detected and then copy the files across to
/core/target/classes. Alternatively, just copy the
/core-tiger/target/classes if they exist to /core/target/classes and
expect users to first build core-tiger (such that the
/core-tiger/target/classes exists). The latter approach is easier, but
I'm sure the former is achievable with Maven as well.
Cheers
Ben
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Security Annotation support (initial)
Hey Ben, Just wanted to mention, I have started converting over the "attributes" sample apps over to Java 5 annotations version. (Havent checked in yet) samples/attributes (Commons) samples/annotations (Java 5) Basically, I ported over the BankService code and created tests. Also, I did port over a Contacts sample using Java instead of XML configuration. My questions (prior to checking anything in), are related to packaging. First off, we now have the core-tiger project... and this creates a jar for the java 5 classes. I think we need to package these into a single acegisecurity jar file? I noticed that the Spring @Transactional annotations are packaged in the spring.jar (i.e. there is not JDK 5 vs JDK 1.4 < ) So it looks to be ok to use JDK 1.4 (and lower) loading a jar file that contains Java 5 classes as long as they dont try to use them :) 2ndly - where should the new contacts sample using the annotations reside? Should I recreate a whole new sub-project (ala core-tiger) ? Or can it be included in the existing /samples/contacts/ ? I just wanted to make sure I dont check in code that breaks JDK 1.4 users from building the CVS HEAD examples, etc. Therefore to sum up: - can we package the core-tiger classes into the single acegi security dist? - where should the new samples (for java5) be located? Thoughts? Cheers, Mark Anyway On 8/21/05, Ben Alex <[EMAIL PROTECTED]> wrote: > Mark St.Godard wrote: > > >Ben et al, > > > >Just a note, I have checked in some initial Security annotation > >support and unit tests. > > > >Feedback is always welcome, and please let me know if anyone has > >any problems with the new subproject. > > > > > > > Great work Mark. > > Are there any users out there using Acegi Security's Commons Attributes > support? > > Cheers > Ben > > > > --- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > ___ > Home: http://acegisecurity.sourceforge.net > Acegisecurity-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Security Annotation support (initial)
Mark St.Godard wrote: Ben et al, Just a note, I have checked in some initial Security annotation support and unit tests. Feedback is always welcome, and please let me know if anyone has any problems with the new subproject. Great work Mark. Are there any users out there using Acegi Security's Commons Attributes support? Cheers Ben --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Security Annotation support (initial)
Ben et al, Just a note, I have checked in some initial Security annotation support and unit tests. (see http://opensource.atlassian.com/projects/spring/browse/SEC-4) I will be also checking in a Contacts webapp example, however using Spring @Transaction annotations and the new @Secured annotation. Important Note: Ben and I decided to create a new subproject "core-tiger" that contains Java 5 core security code. i.e. core-tiger/src/main/java core-tiger/src/test/java etc. I have also created the Maven project files, etc. Again, I am just finishing the Contacts webapp example... so more to follow. Feedback is always welcome, and please let me know if anyone has any problems with the new subproject. Cheers, Mark --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
