User feedback and Roadmap comments

[Gabriele Columbro]

Hi guys,

I finally, after more than a year, found time to give a serious look at this project. I see and hear lots of traction around having a properly / regularly updated Maven lifecycle for Alfresco.

Up to know, apart from some great code contributions, at least in terms of releases and strategy I kind of drove this project.

Now that this list contains more than 90 subscribers and we have at least 10 people able to commit on this code, I think it makes sense to step back and gather some shared feedback and community style decisions around this project.

WDYT?

In order to kick that off, I did some homework:

1. committing some old provided patches. Kudos to glaurung.aubrane :)
2. starting off a Roadmap (http://code.google.com/p/maven-alfresco-archetypes/wiki/ProjectRoadmap) wiki page where I added my inputs for coming TBD releases. I basically I see a last trunk maintenance release ("Milestone-NextRelease") and later a more advanced Archetypes 4x release ("Milestone-Release4x"), with latest Alfresco features support)
3. cleaning up all issues and where applicable schedule them for either "NextRelease" or "Release4x"

Would be great if you guys could contribute to this by:

- commenting roadmap / enhancements requests on this thread
- filing issues for improvement requests to be scheduled
- if you have permission, directly writing your proposal for releases and features per release on the Roadmap wiki page
- any feedback and suggestion on what we should keep / remove from current archetypes versions (there are lots of obsolete things)

In other words this is the time to shape this project for the next year or so.

I'm eager to hear your thoughts (although I'll be on holidays for the next couple of weeks :)

Ciao and don't be shy...

Thanks!
Gab

--
Gabriele Columbro
Consultant, EMEA
Alfresco Software, Ltd. (http://www.alfresco.com)

[Carlo Sciolla]

2011/8/4 Gabriele Columbro <gabriele...@alfresco.com> 

Now that this list contains more than 90 subscribers and we have at least 10 people able to commit on this code, I think it makes sense to step back and gather some shared feedback and community style decisions around this project.

WDYT?

I'd love to see this project starting again gaining traction. Interest around mavenizing Alfresco isn't faded, and while it's always a pain to setup a maven project from scratch  when dealing with Alfresco, yet I've seen that the lack of structure and updates in this project resulted in it being a hard sell, thus most of people chose to go the hard way and ended up with fully custom solutions. The only success stories I have are about using the AMP archetype, currently.

In order to kick that off, I did some homework:

1. committing some old provided patches. Kudos to glaurung.aubrane :)

yay!

 

2. starting off a Roadmap (http://code.google.com/p/maven-alfresco-archetypes/wiki/ProjectRoadmap) wiki page where I added my inputs for coming TBD releases. I basically I see a last trunk maintenance release ("Milestone-NextRelease") and later a more advanced Archetypes 4x release ("Milestone-Release4x"), with latest Alfresco features support)

that seems plain reasonable

 

3. cleaning up all issues and where applicable schedule them for either "NextRelease" or "Release4x"

OK

Would be great if you guys could contribute to this by:

- commenting roadmap / enhancements requests on this thread
- filing issues for improvement requests to be scheduled
- if you have permission, directly writing your proposal for releases and features per release on the Roadmap wiki page
- any feedback and suggestion on what we should keep / remove from current archetypes versions (there are lots of obsolete things)

Hope to be able to participate in at least some points. I'd love to see a shiny release supporting Alfresco 3.4.x soon.

I'm eager to hear your thoughts (although I'll be on holidays for the next couple of weeks :)

Have fun! *put here random insults driven by envy*

 

Ciuss,

c.

--
Carlo Sciolla

--==(A)==--
Linux User #372086
My personal blog: http://www.skuro.tk
Follow me on twitter: http://twitter.com/skuro

Fork me on Github: http://github.com/skuro

My LinkedIn profile: http://nl.linkedin.com/in/carlosciolla
--==(A)==--

Senior Developer at Backbase - Next Generation Portal Software for Financials & Large Enterprises (http://www.backbase.com)

[Chris Hubick]

Hi.

While using Maven to build my Alfresco projects I have had a couple big fundamental issues:


1) POM's for Alfresco (incl Enterprise) Artifacts

The existing artifacts published into the Maven repository don't include a real POM file declaring all their dependencies, forcing projects depending upon those artifacts to manually include a *long* list of transitive dependencies (Spring, Quartz, etc), making maintenance of those projects across Alfresco upgrades very difficult.

Also, Enterprise customers have no facility to access Alfresco Enterprise artifacts via Maven, or to upload those from the SDK into their private local repositories.

I started off building my projects against the Alfresco Community artifacts in Maven and then deploying to our testing/production servers running Alfresco Enterprise, but I eventually wanted projects in my development environment to be associated with the same code running on our servers, so that they can be used for things like attaching a remote debugger, so stack trace line numbers match, automatic source code availability, etc.

As posted at http://forums.alfresco.com/en/viewtopic.php?f=10&t=39540 - I took a stab at writing Maven POM files (including dependencies) for Alfresco Enterprise 3.3.5, along with a script to deploy those artifacts and third party jars from the Enterprise SDK zip file into a local Maven repository:

https://github.com/hubick/alfresco_sdk_mvn_deploy

It would be better if something like that were supplied out of the box though.


2) AMP Dependencies

Let's assume I have two <packaging>amp</packaging> projects, "A" and "B", where "B" lists "A" as one of it's dependencies.

Building "A" will result in any Java code from the project being compiled into an A-version.jar bundled into the resulting AMP's lib dir.

It would appear that Java code in project "B" cannot reference Java code from project "A", as A-version.jar does not appear to be included in the classpath while building "B".

As a result, I had to split all my projects into multi-module projects, where "A" becomes a parent <packaging>pom</packaging> project with two child modules "A_jar_module" (<packaging>jar</packaging>) containing all the Java code, and "A_amp_module" (<packaging>amp</packaging>) containing the configuration files, and where "A_amp_module" declares a dependency on "A_jar_module" to include the Java code in the resulting AMP.  This allows "B" to declare a <scope>provided</scope> dependency on "A_jar_module", which will resolve correctly at build time via the normal Maven jar depdenency mechanism.


Anyhow, thanks for this project and your consideration of these issues.

--
Chris Hubick
mailto:ch...@hubick.com
http://chris.hubick.com/

[Glaurung]

Hi Gabriele,

In fact I am not using Alfresco. I was in the Maven support team of my company so I did some patch to help an other team that was using Alfresco. I would be happy to help you on the Maven part (I have seen you plan Maven3 support in the roadmap). But concerning any Alfresco feature... I will be useless.

Enjoy you holidays,

Regards,

Julien

----- Mail original -----
> De : Gabriele Columbro <gabriele...@alfresco.com>
> À : maven-a...@googlegroups.com
> Cc : glaurung...@gmail.com
> Envoyé le : Jeudi 4 Août 2011 4h11
> Objet : User feedback and Roadmap comments

[Gabriele Columbro]

Hi Chris,

thanks for the reaction. See my comments interleaved:

On Aug 4, 2011, at 8:38 PM, Chris Hubick wrote:

Hi.

While using Maven to build my Alfresco projects I have had a couple big fundamental issues:


1) POM's for Alfresco (incl Enterprise) Artifacts

The existing artifacts published into the Maven repository don't include a real POM file declaring all their dependencies, forcing projects depending upon those artifacts to manually include a *long* list of transitive dependencies (Spring, Quartz, etc), making maintenance of those projects across Alfresco upgrades very difficult.

Also, Enterprise customers have no facility to access Alfresco Enterprise artifacts via Maven, or to upload those from the SDK into their private local repositories.

Also this does not allow proper unit/integration testing in Alfresco Archetypes generated projects. I would love to help maintaining those POMs but ideally they should be provided by Alfresco to be Enterprise *supported*. 

I started off building my projects against the Alfresco Community artifacts in Maven and then deploying to our testing/production servers running Alfresco Enterprise, but I eventually wanted projects in my development environment to be associated with the same code running on our servers, so that they can be used for things like attaching a remote debugger, so stack trace line numbers match, automatic source code availability, etc.

As a proper SDK should do.

As posted at http://forums.alfresco.com/en/viewtopic.php?f=10&t=39540 - I took a stab at writing Maven POM files (including dependencies) for Alfresco Enterprise 3.3.5, along with a script to deploy those artifacts and third party jars from the Enterprise SDK zip file into a local Maven repository:

https://github.com/hubick/alfresco_sdk_mvn_deploy

It would be better if something like that were supplied out of the box though.

This is great stuff dude. I added a link to this here http://code.google.com/p/maven-alfresco-archetypes/wiki/MaintainYourRepo. We should discuss on how to use those in the new release (4x). Also Carlo might be working on a fully automated script to automatically deploy JARs / WARs per release, which will nicely work with your POMs.

2) AMP Dependencies

Let's assume I have two <packaging>amp</packaging> projects, "A" and "B", where "B" lists "A" as one of it's dependencies.

Building "A" will result in any Java code from the project being compiled into an A-version.jar bundled into the resulting AMP's lib dir.

It would appear that Java code in project "B" cannot reference Java code from project "A", as A-version.jar does not appear to be included in the classpath while building "B".

As a result, I had to split all my projects into multi-module projects, where "A" becomes a parent <packaging>pom</packaging> project with two child modules "A_jar_module" (<packaging>jar</packaging>) containing all the Java code, and "A_amp_module" (<packaging>amp</packaging>) containing the configuration files, and where "A_amp_module" declares a dependency on "A_jar_module" to include the Java code in the resulting AMP.  This allows "B" to declare a <scope>provided</scope> dependency on "A_jar_module", which will resolve correctly at build time via the normal Maven jar depdenency mechanism.

To be honest I might have been clearer about this: the only dependency path supported (or at least that I tested) in the Archetypes is WAR --> AMP, since also AMP --> AMP is something also not supported in Alfresco. Why do you need AMP --> AMP dependency? 

BTW in the cases of "compile" time dependencies (meaning a Java code bit in an AMP maybe depending on Java code being on a commons AMP) I solved your issue in a different way:

- The "depended upon" AMP build apart from producing the main .amp artifact would produce also a -classes.jar artifact (with a classifier). This can be achieved with the attachClasses parameter of the maven-amp-plugin (inherited from the maven-war-plugin http://maven.apache.org/plugins/maven-war-plugin/faq.html#attached)

- The "dependent" AMP declares this JAR dependency the proper <classifier>classes</classifier>

- This way you don't need a separate project.

WDYT?

Anyhow, thanks for this project and your consideration of these issues.

Thanks again to you for the great feedback, drop me a private email if you want access to the project sources / docs or you want to merge your POM work in here.

Ciao!

Gab

--
Chris Hubick
mailto:ch...@hubick.com
http://chris.hubick.com/

--
You received this message because you are subscribed to the Google Groups "Maven Alfresco Lifecycle Discussion Group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/maven-alfresco/-/-kL8yeJNqtMJ.
To post to this group, send email to maven-a...@googlegroups.com.
To unsubscribe from this group, send email to maven-alfresc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/maven-alfresco?hl=en.

-- 
Gabriele Columbro
Field Consultant, EMEA

Alfresco Software, Ltd. (http://www.alfresco.com)

M: +31 (0)627 565 103 
P: +39 320 161 28 46 
D: +44 (0)1628 876 654
Skype: gabrielecolumbro 
Blog: http://www.mindthegab.com
Twitter: @mindthegabz

[stijnr]

Hi Gabriele,

I'm new to this list and new to active Alfresco development with Maven, but I think I'll be spending quite some time in this group, and hopefully be able to contribute some code/configuration to the community. I'll introduce myself and what I've done so far in a new thread, but for now I'm stuck with the same problem as described below:

2) AMP Dependencies

Let's assume I have two <packaging>amp</packaging> projects, "A" and "B", where "B" lists "A" as one of it's dependencies.

Building "A" will result in any Java code from the project being compiled into an A-version.jar bundled into the resulting AMP's lib dir.

It would appear that Java code in project "B" cannot reference Java code from project "A", as A-version.jar does not appear to be included in the classpath while building "B".

As a result, I had to split all my projects into multi-module projects, where "A" becomes a parent <packaging>pom</packaging> project with two child modules "A_jar_module" (<packaging>jar</packaging>) containing all the Java code, and "A_amp_module" (<packaging>amp</packaging>) containing the configuration files, and where "A_amp_module" declares a dependency on "A_jar_module" to include the Java code in the resulting AMP.  This allows "B" to declare a <scope>provided</scope> dependency on "A_jar_module", which will resolve correctly at build time via the normal Maven jar depdenency mechanism.

To be honest I might have been clearer about this: the only dependency path supported (or at least that I tested) in the Archetypes is WAR --> AMP, since also AMP --> AMP is something also not supported in Alfresco. Why do you need AMP --> AMP dependency? 

BTW in the cases of "compile" time dependencies (meaning a Java code bit in an AMP maybe depending on Java code being on a commons AMP) I solved your issue in a different way:

- The "depended upon" AMP build apart from producing the main .amp artifact would produce also a -classes.jar artifact (with a classifier). This can be achieved with the attachClasses parameter of the maven-amp-plugin (inherited from the maven-war-plugin http://maven.apache.org/plugins/maven-war-plugin/faq.html#attached)

- The "dependent" AMP declares this JAR dependency the proper <classifier>classes</classifier>

- This way you don't need a separate project.

I think your classes classifier is a nice solution to be able to share Java code across AMPs. I definitely see the need for that, as we'll be developing some abstract base beans in a common module, which we can then extend in several other modules.

I tried the attachClasses parameter in the configuration section of the Maven AMP plugin, but it doesn't seem to do anything (I'm using version 3.0.3 of the plugin). I looked at the source code in svn and at the Javadoc, but I can't find any reference to it. 

Also, on a related note: where is the most recent source located for the AMP plugin. The most recent tag in http://maven-alfresco-archetypes.googlecode.com/svn is 3.0.0. And did I miss something before, or were the 3.0.2 and 3.0.3 versions up until a few days ago not available in the Alfresco Nexus?

Regards, Stijn