Is the condition for profile enable-alfresco-testing correct in alfresco-sdk-parent v1.0.1?

[Bill Young]

I have a situation where I have a multi-module project.  Some are small bundles of Java code which are not dependent on Alfresco libraries.  Since the parent POM declares alfresco-sdk-parent as its parent, these modules inherit the profile.  The trigger for the profile is existence of src/test/java, which, since we have JUnit tests in those modules, becomes active, including Alfresco libraries in the classpath.  The problem is that this inclusion introduces some conflicts in the test code (specifically around slf4j bindings).  I know I can exclude the offending binding library in a dependency element for alfresco-repository, but the module shouldn't really be getting the Alfresco library in its classpath, and I wouldn't want to have to list all the transitive dependencies in the exclusions.

I think it would be better to be able to selectively enable or disable the profile by existence of a property, as opposed to activation by a common (best practice) path existence.

[Gabriele Columbro]

Hey Bill,

Yeah a property based activation would be the optimal design. Only if you google enough you'll find out how broken that is in Maven.

File based is the only one that, thanks to some side effect, works on a multi module build. If you can recommend an alternative file to use for activation that would be great.

Note that also multiple activations (in or or and) for a single profile do not work either.

Sorry :(

On 22 Mar 2013 06:26, "Bill Young" <bill.y...@gmail.com> wrote:

I have a situation where I have a multi-module project.  Some are small bundles of Java code which are not dependent on Alfresco libraries.  Since the parent POM declares alfresco-sdk-parent as its parent, these modules inherit the profile.  The trigger for the profile is existence of src/test/java, which, since we have JUnit tests in those modules, becomes active, including Alfresco libraries in the classpath.  The problem is that this inclusion introduces some conflicts in the test code (specifically around slf4j bindings).  I know I can exclude the offending binding library in a dependency element for alfresco-repository, but the module shouldn't really be getting the Alfresco library in its classpath, and I wouldn't want to have to list all the transitive dependencies in the exclusions.

I think it would be better to be able to selectively enable or disable the profile by existence of a property, as opposed to activation by a common (best practice) path existence.

--
You received this message because you are subscribed to the Google Groups "Maven Alfresco Lifecycle Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maven-alfresc...@googlegroups.com.
To post to this group, send email to maven-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/maven-alfresco?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ray Gauss II]

Would module.properties work as a file for activation?

[Gabriele Columbro]

It was originally like this but I completely forgot the reason why I put it to src/test/java (maybe to save some - cheap anyway - execution or even worse for a design paranoia).

At the moment I can't recall why, so I'd lean to agree with Ray's suggestion.

What do others think? Mao?

Gab

[Bill Young]

I'm guessing the intent was to enable good automated testing for any "module" (not in the AMP sense, necessarily) which would be embeeded in an Alfresco WAR and using Alfresco APIs.  The use of module.properties would limit to AMPs (unless one were to introduce a module.properties with no other purpose than to trigger the profile).

I've seen some postings on the problems with use of properties to trigger profiles, but I've also used them with some success.

I'm not sure what the proper solution is.  I'll continue to work with this and see if I come up with any ideas.  In the meantime, I've worked around the issue by splitting my POMs, so I have some which inherit from Alfresco parent POM and others which don't.  This breaks up my site building for the project I'm on, but that's rather minor.  Otherwise, it's OK, and I just have an aggregator POM to accomplish my full builds, so this isn't blocking me.