3.19.1 master doesn't deploy on 6.3/6.4

[heervisscher]

Required Information

• [AEM6.3 ] AEM Version, including Service Packs, Cumulative Fix Packs, etc: ___
• [3.19.1 ] ACS AEM Commons Version: _____
• [yes ] Reproducible on Latest? yes/no

Expected Behavior

Bundle is active

Actual Behavior

Bundle is 'installed'

[heervisscher]

[heervisscher]

Also on 6.4 there is the same issue

[davidjgonzalez]

It appears the MCP SFTP code introduced this dependency. I don't see AEM providing this in AEM 6.4.2 either.

I'd much prefer if we can re-write without dependency (or use a dep already provided by AEM).

• Our optionals list is already too big (requiring yet-another-install to get features to work)
• and we don't want to go back to embedding 3rd party libraries (a bad habit we've already broken).

Might be smart to just revert this feature until we can figure out a good solution.

[joerghoh]

splitting the huge package of acs-aem-commons into smaller ones? especially if the code adds 3rd party dependencies.

[davidjgonzalez]

splitting the huge package of acs-aem-commons into smaller ones? especially if the code adds 3rd > party dependencies.

that's what we did for Twitter, but TBH history has proven that is a PITA for just about everyone.

Spitting ACS Commons, in general, has been discussed in previous issues.

[davidjgonzalez]

Making jcraft optional, and gracefully handling this lack of dependency "in product", is IMO is the best work-around. The right solution is, of course, to figure out how to not rely on 3rd party deps.

[justinedelson]

FWIW, the problem with the Twitter dependency is pretty specific and not something I'd expect to be necessary in general. The issue there is that Twitter4J is used in an AdapterFactory and AdapterFactories are eagerly instantiated.

In this case, my understanding is that this dependency is used in a MCP process; a similar situation already exists with the S3 Ingestor. Seems like it would apply here.

Actually, this gives me an idea for how to fix the twitter thing...

[heervisscher]

On 6.4.2 I have this

[justinedelson]

I'm also seeing the replication issue on 6.4.0

[badvision]

Fixed in #1572

[badvision]

For now I'm just embedding it. JSCH is an old pre-osgi library. I'm not sure why it shows up as being present in the copies of AEM I was looking at, but it's safer to assume that if we need a tiny library then we just embed it. At least for something this small that doesn't get updated, like ever, and also has no readily available OSGi bundling. For now I just want to address the packaging issue created, we can reassess making it an optional dependency later. I'm not exporting it so it doesn't make any change to our API surface.

[badvision]

Also given the frequency which I've been asked for SFTP support, it still makes better sense to embed. It's not something I want to do often, but again it's at least self-contained and also very tiny. No extra dependencies, etc.

[joerghoh]

The bundle is still not getting active :-(

[heervisscher]

same here, but was it merged into master? @badvision ?

[joerghoh]

same here, but was it merged into master? @badvision ?

Yes, the jsch stuff has been merged to master.

[badvision]

Yes, well I had tested it on a relatively new AEM instance so I didn't see the issue. Also it's really weird that JZLIB is an optional dependency in the pom but is showing as required here.

[badvision]

Terribly sorry about this guys please let me know if this is a suitable fix, otherwise I can revert the tree back.