Use fragments for platform-specific artifacts about tern.java HOT 23 CLOSED

I suppose you speak about embed node.js plugins. Do you think is it possible to provide a patch for this issue? @pascalleclercq is it possible for you to follow this issue. Thank's!

from tern.java.

I'll see if it is possible next week and send PR for that.

For now I figured out how to include tern.java platform specific features into JBT TP and integrate it into jbosstolls-jst module.

from tern.java.

I've had a look, and it looks like the best thing would simply be to package nodejs "zips" as platform-specific fragments.
Do you know if Orion does include a Node.js? Maybe we could reuse some bundles/fragments?

from tern.java.

Do you know if Orion does include a Node.js? Maybe we could reuse some bundles/fragments?

No I don't know. I think @gamerson should see this issue too because he has contribute to this embed node.js feature (node.js are zip now)

from tern.java.

Hey Angelo,

I'm all in favor of switching the platform specific bundles into fragments,
the issue is that the code to unzip on demand may have to be tweaked since
those will be coming from fragments instead of their own bundles, but that
is ok. Or even if we want to switch up the solution to no ship with zips
but unzip things just prior to tycho jars up the bundle and then there
would never be an unzip at runtime. But in dev time we would still need
code to perform the unzip for people that check out the source into a new
repository.

I don't know off hand how to get tycho to unzip the zip just prior to
jaring the bundle, Mickael? Do you know that piece of maven wizardry? If
not, we can still make my original code work with fragments. What do you
guys think?

On Fri, Apr 25, 2014 at 4:11 PM, Angelo [email protected] wrote:

Do you know if Orion does include a Node.js? Maybe we could reuse some
bundles/fragments?

No I don't know. I think @gamerson https://github.com/gamerson should
see this issue too because he has contribute to this embed node.js feature
(node.js are zip now)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-41368719
.

Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com

from tern.java.

On 04/28/2014 05:48 AM, Gregory Amerson wrote:

I don't know off hand how to get tycho to unzip the zip just prior to
jaring the bundle, Mickael? Do you know that piece of maven wizardry? If
not, we can still make my original code work with fragments. What do you
guys think?
I indeed believe that having stuff already unzipped and those
bundles/fragments using a "dir" Eclipse-BundleShape would help, remove
the necessity to unzip stuff and make things easier to maintain.

If there are maven artifacts for node.js, then we could use the
maven-dependency-plugn:unzip mojo (ex
https://github.com/jbosstools/jbosstools-server/blob/master/as/tests/org.jboss.tools.as.test.core/pom.xml#L46
)
If there are not available as Maven artifacts, then we could use the
download-maven-plugin:wget mojo, with its unzip flag (ex
https://github.com/jbosstools/jbosstools-server/blob/master/as/tests/org.jboss.tools.as.test.core/pom.xml#L100
)

With that, and platform filters set correctly, there is no unzip
operation to do, just finding the location of a file in the bundle

classloader and resolving it to filesystem should work.

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

from tern.java.

The only catch is adopters that need to checkout tern.java source, they
will need to know that they must unzip a copy of the nodejs in their
specific fragment for it to work but I believe that could be covered by an
"contributors" section in the documentation, to tell them how to get their
local dev environment working.

I'm assuming that these nodejs servers are not in maven, so probably would
need to use the download-maven-plugin:wget mojo. But that means we need
these in a stable URL location. Angelo, did you download these from a
stable URL that we could put in the pom.xml?

On Mon, Apr 28, 2014 at 4:49 PM, Mickael Istria [email protected]:

On 04/28/2014 05:48 AM, Gregory Amerson wrote:

I don't know off hand how to get tycho to unzip the zip just prior to
jaring the bundle, Mickael? Do you know that piece of maven wizardry? If
not, we can still make my original code work with fragments. What do you
guys think?
I indeed believe that having stuff already unzipped and those
bundles/fragments using a "dir" Eclipse-BundleShape would help, remove
the necessity to unzip stuff and make things easier to maintain.

If there are maven artifacts for node.js, then we could use the
maven-dependency-plugn:unzip mojo (ex

https://github.com/jbosstools/jbosstools-server/blob/master/as/tests/org.jboss.tools.as.test.core/pom.xml#L46
)
If there are not available as Maven artifacts, then we could use the
download-maven-plugin:wget mojo, with its unzip flag (ex

https://github.com/jbosstools/jbosstools-server/blob/master/as/tests/org.jboss.tools.as.test.core/pom.xml#L100
)

With that, and platform filters set correctly, there is no unzip
operation to do, just finding the location of a file in the bundle

classloader and resolving it to filesystem should work.

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-41535749
.

Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com

from tern.java.

On 04/28/2014 10:53 AM, Gregory Amerson wrote:

The only catch is adopters that need to checkout tern.java source, they
will need to know that they must unzip a copy of the nodejs in their
specific fragment for it to work but I believe that could be covered
by an
"contributors" section in the documentation, to tell them how to get
their
local dev environment working.
Running "mvn generate-resources" should be good to startup a developer mode.
I'm ok with telling contributors to run this and setup their environment.

Something simpler and a first iteration for this specific issue of
moving to fragments would be to commit the unzipped files.
IMO, we should focus on that first and then decide if we want to
populate bundle at each build or whether we're ok with putting unzipped
content and Eclipse-BundleShape: dir in MANIFEST.MF and unpack="true" in
feature.xml.

I'll try to prepare a PR for this change. Are there already some

automated tests that check this node.js server intergration is working?

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

from tern.java.

If we commit the unzipped files, that is the original problem my solution
fixed. If we commit unzipped files, the msysgit client on windows will
refuse to checkout that new commit. Perhaps I misunderstood your plan?

On Mon, Apr 28, 2014 at 5:21 PM, Mickael Istria [email protected]:

On 04/28/2014 10:53 AM, Gregory Amerson wrote:

The only catch is adopters that need to checkout tern.java source, they
will need to know that they must unzip a copy of the nodejs in their
specific fragment for it to work but I believe that could be covered
by an
"contributors" section in the documentation, to tell them how to get
their
local dev environment working.
Running "mvn generate-resources" should be good to startup a developer
mode.
I'm ok with telling contributors to run this and setup their environment.

Something simpler and a first iteration for this specific issue of
moving to fragments would be to commit the unzipped files.
IMO, we should focus on that first and then decide if we want to
populate bundle at each build or whether we're ok with putting unzipped
content and Eclipse-BundleShape: dir in MANIFEST.MF and unpack="true" in
feature.xml.

I'll try to prepare a PR for this change. Are there already some
automated tests that check this node.js server intergration is working?

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-41538142
.

Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com

from tern.java.

On 04/28/2014 11:30 AM, Gregory Amerson wrote:

If we commit the unzipped files, that is the original problem my solution
fixed. If we commit unzipped files, the msysgit client on windows will
refuse to checkout that new commit. Perhaps I misunderstood your plan?
Ok, I was not aware of this problem.
Why did the msysgit client have a problem? Maybe this is fix-able in a

more direct way than using zip files?

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

from tern.java.

Maybe so. I suspect that it's a windows problem. The error complains about
file path being too long. I've shortened my local git repo to short
version but the embedded nodejs files still have a problem. The only
workaround that I have found is work on a vm.

On Monday, April 28, 2014, Mickael Istria [email protected] wrote:

On 04/28/2014 11:30 AM, Gregory Amerson wrote:

If we commit the unzipped files, that is the original problem my solution
fixed. If we commit unzipped files, the msysgit client on windows will
refuse to checkout that new commit. Perhaps I misunderstood your plan?
Ok, I was not aware of this problem.
Why did the msysgit client have a problem? Maybe this is fix-able in a

more direct way than using zip files?

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-41549173
.

Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com

from tern.java.

On 04/28/2014 02:58 PM, Gregory Amerson wrote:

Maybe so. I suspect that it's a windows problem. The error complains
about
file path being too long. I've shortened my local git repo to short
version but the embedded nodejs files still have a problem. The only
workaround that I have found is work on a vm.
Oh yeah, the windows file path length issue...
I guess if we package the files inside a jarred plugin, it will work
well. This kind of error usually only hapens for BundleShape=dir bundles.
So let's keep the zip. However, it would still be helpful to use
fragments instead of extension point + bundles.

We could think of those being only jarred fragments, containing a zip
with name "node.zip" for all fragments. Fragments would contribute to
their current consumer, that instead of using the extension to load
node, would look for the node.zip file in its current classpath
(extended by the fragment), unzip it and run it as it is currently doing.
With those fragments, we can make a multi-platform feature and simplify

consumption.

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

from tern.java.

Angelo, did you download these from a stable URL that we could put in the pom.xml?

No, I have downloaded node.js at hand.

I trust you to find the better solution for this issue. Using fragments means that we can have just one node.js version of OS. It's not a big problem,but we must know that : it will impossible to provide several node.js version of OS.

from tern.java.

We could leave everything as real bundles (instead of fragments) I don't
exactly know the benefits of converting to fragments over just using
bundles. Maybe Mickael has thoughts?

On Tue, Apr 29, 2014 at 6:25 AM, Angelo [email protected] wrote:

Angelo, did you download these from a stable URL that we could put in
the pom.xml?

No, I have downloaded node.js at hand.

I trust you to find the better solution for this issue. Using fragments
means that we can have just one node.js version of OS. It's not a big
problem,but we must know that : it will impossible to provide several
node.js version of OS.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-41621891
.

Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com

from tern.java.

On 05/20/2014 03:55 AM, Gregory Amerson wrote:

We could leave everything as real bundles (instead of fragments) I don't
exactly know the benefits of converting to fragments over just using
bundles. Maybe Mickael has thoughts?
The benefit of fragments would be that since fragment contribute
directly to the classpath, there wouldn't need to an extension for that.
The "master" bundle would just need to invoke getResource or similar to
find the right implementation. It's IMO simpler. Extension have benefits
only if there can be several simultaneous contributors for the same
thing. For platform-specific artifacts, it's generally not the case.

Also, I'm not sure feature.xml allows to set platform-filters for
plugins; but marking them optional with the right Eclipse-PlatformFilter
in their MANIFEST.MF should have a similar effect. So the filtering
mechanism could probably be set up with plugins as well as fragments.

http://twitter.com/mickaelistria

from tern.java.

@gamerson @angelozerr @pascalleclercq @dgolovin @nickboldt
The attached commit removes the need for platform-specific feature by creating a single multi-platform feature. As platform-specific bundles have fragment="true" in the feature, Tycho is able to build the feature for all OS and the platform-specific bundles to install will be decided by p2 during installation.
It works at least for linux.x86.

This is a major improvement for adopters who package this in their distribution (like JBoss Tools).

from tern.java.

Suggested commit has been turned into PR #84

from tern.java.

@mickaelistria thanks for update, this indeed will be better for adopters. Quick question, you said you set "fragment=true" in the feature but I only see fragment=true for the two win32/64 bundles, but not the linux and mac. And also that feature doesn't have linux.x86 and macosx.x86 bundles specified? Lastly the bundles themselves aren't actually fragments (no Fragment-Host: ...) is that expected?

from tern.java.

Thanks for the review.
I'll fix the feature.xml to add the missing bundles.
About having fragment=true in feature for bundles that aren't fragments,
then I've mimicked what is done in this Tycho integration-test:
http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/projects/multiPlatform.reactor/feature/feature.xml
. I'll give it another try without any fragment=true to see whether
those are actually necessary, but your comment gives me the impression
that they are not. Actually, it looks like fragment=true is ignored by
Tycho package-feature mojo (p2 is able to detect whether something is a
fragment or not).

from tern.java.

I updated the suggested patch according to @gamerson 's comments. The feature=true were indeed not necessary.

from tern.java.

It seems that #84 fix this issue. @mickaelistria can I close this issue?

from tern.java.

Sure, let's close it.

from tern.java.

Thank's @mickaelistria !

from tern.java.