search

Alfresco / alfresco-sdk

The Alfresco In-Process SDK is based on Apache Maven, includes support for rapid and standard development, testing, packaging, versioning and release of your Alfresco integration and extension projects
Apache License 2.0
185 stars 113 forks source link

Source path templating? #270

Closed binduwavell closed 9 years ago

binduwavell commented 9 years ago

Is there a reason we aren't using path templating in the archetype so that source files are added under the users chosen package?

binduwavell commented 9 years ago

Just did a quick exploration via GitHub UI and the only place I found path templating was in the repo amps (standalone and AIO):

src/main/resources/archetype-resources/src/main/amp/config/alfresco/module/artifactId

Doing templating here not only makes sense but obviously is highly valuable to keep module/component specific config from conflicting.

Having said that, best practices would dictate that webscripts and java classes are also on unique paths per module/component again to reduce the risk of collisions.

Imagine two folks create amps using the archetypes and they are lazy or don't know better and place their classes next to DemoComponent.java in /org/alfresco/demoamp. No suppose someone attempts to use both of these amps.

Granted this is a pretty far fetched scenario. Having said that, I believe it is relatively trivial to make these paths be relative to the users group.

I couldn't find references for how to handle this on the maven documentation, but I remembered seeing it elsewhere. I found the following tutorial: http://geekofficedog.blogspot.com/2013/08/creating-maven-archetypes-tutorial.html

Search for: packageInPathFormat on the linked tutorial.

I believe this would allow us to store demo sources under: /repo-amp/src/main/java/packageInPathFormat/demoamp

Or possibly we could use the: packaged="true" flag in: archetype-metadata.xml

See the tutorial link above for some more details on this. The archetype plugin docs are pretty horrible, they reference the packaged="true" but the language is confusing (to me at least) and they don't seem to mention packageInPathFormat. Also our archetypes don't prompt for package. I'm guessing this is just config we can add. If we do, it's not clear to me how we would supply the package in unattended mode. So clearly I don't have this all figured out, but I think it would be an improvement over what we have now in as much as it will help folks place their files in the correct locations.
binduwavell commented 9 years ago

I did some spelunking in the following archetype: http://mvnrepository.com/artifact/org.jboss.spec.archetypes/jboss-javaee6-webapp-archetype/7.1.3.Final

It appears that packaged="true" is used to cause sources to get copied into an appropriate path rather than packageInPathFormat. So presumably ${package} and ${packageInPathFormat} would then be used in .java and possibly context.xml for example...

gravitonian commented 9 years ago

Hi Bindu, I have been working on this (DEVPLAT-43) and I think it is really useful to support this to avoid conflicts between classes and between beans. And also to encourage usage of your own domain in package path. If you grab the latest code, build and install locally, you got this feature implemented, try it out.

binduwavell commented 9 years ago

Cool, thanks. I plan to check this out this weekend.

binduwavell commented 9 years ago

This is cool, but we still end up with conflicts related to module names. See https://github.com/Alfresco/alfresco-sdk/issues/278

mindthegab commented 9 years ago

So this is resolved. Not sure why was still left open @binduwavell @gravitonian. Closing.