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

Reply via email to