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.
<!-- Compile core-tiger if using java 5 -->
<goal name="java5:compile">
<j:if test="${context.getVariable('java.version').startsWith('1.5') }">
<echo>Java5</echo>
<maven:maven
descriptor="${rootdir}/core-tiger/project.xml"
goals="clean,java:compile"
ignoreFailures="false"/>
</j:if>
</goal>
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 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
