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
