Guidelines for adding/upgrading dependencies

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Guidelines for adding/upgrading dependencies

Felix Natter
Administrator
hi,

I have compiled a few best practices for adding/upgrading libraries:
  http://freeplane.sourceforge.net/wiki/index.php/Dependencies_and_Linux_Packaging#Guidelines_for_adding.2Fupgrading_dependencies

Best Regards,
--
Felix Natter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidelines for adding/upgrading dependencies

Felix Natter
Administrator
hello,

since Dimitry told me my article was not clear enough in some aspects, I have revised it completely:

http://freeplane.sourceforge.net/wiki/index.php/Dependencies_and_Linux_Packaging#Guidelines_for_adding.2Fupgrading_dependencies_.28Gradle.2C_.3E.3D_1.4.x.29

Can we agree on this?

Best Regards,
Felix
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidelines for adding/upgrading dependencies

Dimitry Polivaev
Administrator
Hello,

I like the revised version very much.
Now I have another question: for all dependencies which are not available on maven yet we can

(1) either keep them in git
(2) or upload them to our own maven repositories as described at
https://bitbucket.org/neil_rubens/rapidminer_maven-repo/wiki/Home
(3) or make them available at some central maven repository as described at

http://maven.apache.org/guides/mini/guide-central-repository-upload.html
http://central.sonatype.org/pages/ossrh-guide.html

Let us discuss which way we like more.

The only advantage of (1) is we do not have to spend time on learning new things. On the other hand
I do not like keeping software artefacts in git because it has impact on its size and performance.
So I think later we could start to do like (2) or (3) or its combination like upload SimplyHTML to
the central repository and create for JMapView some separate repository.

Regards,
Dimitry

> since Dimitry told me my article was not clear enough in some aspects, I have revised it
> completely:
>
> http://freeplane.sourceforge.net/wiki/index.php/Dependencies_and_Linux_Packaging#Guidelines_for_adding.2Fupgrading_dependencies_.28Gradle.2C_.3E.3D_1.4.x.29
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidelines for adding/upgrading dependencies

Felix Natter
Administrator
"Dimitry Polivaev [via Freeplane Developer]"
<[hidden email]> writes:

> Hello,

hello Dimitry,

> I like the revised version very much.
> Now I have another question: for all dependencies which are not available on maven yet we can

We should talk more often about the gradle strategy (I could've saved
some work on getting source attachments to work) ;-)

> (1) either keep them in git
> (2) or upload them to our own maven repositories as described at
> https://bitbucket.org/neil_rubens/rapidminer_maven-repo/wiki/Home

I think we can use github for that?

> (3) or make them available at some central maven repository as described at
>
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> http://central.sonatype.org/pages/ossrh-guide.html
>
> Let us discuss which way we like more.
>
> The only advantage of (1) is we do not have to spend time on learning new things. On the
> other hand
> I do not like keeping software artefacts in git because it has impact on its size and
> performance.

I'm not sure whether this will reduce the repo size since we won't get
rid of older artifacts, but it's certainly good practice.

> So I think later we could start to do like (2) or (3) or its combination like upload
> SimplyHTML to
> the central repository and create for JMapView some separate repository.

I don't have a strong opinion about this. Here are some thoughts:

- I don't think we can apply (3) to jsyntaxpane-0.9.6~r156-5 (patched
  Debian version), because it's not a released version

- I'd prefer to have only (2) or (3) but not both

- It will be difficult to get the JMapViewer maintainers to do (3)
  (it took me half a year to convince them of versioned releases ;-))

- if we decide to do (2) or (3), then I think (2) is the easiest option
  if it can be done in our github group

Best Regards,
--
Felix Natter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Guidelines for adding/upgrading dependencies

Dimitry Polivaev
Administrator
>  > I like the revised version very much.
>  > Now I have another question: for all dependencies which are not available on maven yet we can
>
> We should talk more often about the gradle strategy (I could've saved
> some work on getting source attachments to work) ;-)

You are our gradle strategy ;)
I can tell what I am thinking only after I think, and it does not happen every day ;)

>  > (1) either keep them in git
>  > (2) or upload them to our own maven repositories as described at
>  > https://bitbucket.org/neil_rubens/rapidminer_maven-repo/wiki/Home
>
> I think we can use github for that?

right

http://stackoverflow.com/questions/14013644/hosting-a-maven-repository-on-github

>  > (3) or make them available at some central maven repository as described at
>  >
>  > http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>  > http://central.sonatype.org/pages/ossrh-guide.html
>  >
>  > Let us discuss which way we like more.
>  >
>  > The only advantage of (1) is we do not have to spend time on learning new things. On the
>  > other hand
>  > I do not like keeping software artefacts in git because it has impact on its size and
>  > performance.
>
> I'm not sure whether this will reduce the repo size since we won't get
> rid of older artifacts, but it's certainly good practice.


It depends on what we want.
After switching to gradle we could create a new repository which could contain all the history
excluding the jars. It would dramatically decrease first cloning time.

Anyway I suggest that we consider this option.

>  > So I think later we could start to do like (2) or (3) or its combination like upload
>  > SimplyHTML to
>  > the central repository and create for JMapView some separate repository.
>
> I don't have a strong opinion about this. Here are some thoughts:
>
> - I don't think we can apply (3) to jsyntaxpane-0.9.6~r156-5 (patched
>    Debian version), because it's not a released version
>
> - I'd prefer to have only (2) or (3) but not both
>
> - It will be difficult to get the JMapViewer maintainers to do (3)
>    (it took me half a year to convince them of versioned releases ;-))
>
> - if we decide to do (2) or (3), then I think (2) is the easiest option
>    if it can be done in our github group

I would contribute SimpleHTML to (3) and
write to JMapViewer maintainers to do (3)

I have no idea about patched debian versions. They are not relevant for our build, are they?

Regards,
Dimitry


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Aw: Re: Guidelines for adding/upgrading dependencies

Felix Natter
Administrator
hello Dimitry,
 
> I would contribute SimpleHTML to (3) and
> write to JMapViewer maintainers to do (3)
 
The problem with JMapViewer is that the latest 1.05 release requires Java7.
--> do we want to require Java7 for Freeplane 1.4?
IMHO that is ok, unless some Mac versions only have Java6.
 
> I have no idea about patched debian versions. They are not relevant for our build, are they?
 
The usual workflow is that I add a patch to the Debian jsyntaxpane package
(currently at jsyntaxpane-0.9.6~r156-5) and commit the result to freeplane-git.
There is no upstream for jsyntaxpane any more.
 
Felix Natter
 
 
Gesendet: Montag, 02. Februar 2015 um 21:17 Uhr
Von: "Dimitry Polivaev [via Freeplane Developer]" <[hidden email]>
An: "Felix Natter" <[hidden email]>
Betreff: Re: Guidelines for adding/upgrading dependencies
>  > I like the revised version very much.
>  > Now I have another question: for all dependencies which are not available on maven yet we can
>
> We should talk more often about the gradle strategy (I could've saved
> some work on getting source attachments to work) ;-)

You are our gradle strategy ;)
I can tell what I am thinking only after I think, and it does not happen every day ;)

>  > (1) either keep them in git
>  > (2) or upload them to our own maven repositories as described at
>  > https://bitbucket.org/neil_rubens/rapidminer_maven-repo/wiki/Home
>
> I think we can use github for that?

right

http://stackoverflow.com/questions/14013644/hosting-a-maven-repository-on-github

>  > (3) or make them available at some central maven repository as described at
>  >
>  > http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>  > http://central.sonatype.org/pages/ossrh-guide.html
>  >
>  > Let us discuss which way we like more.
>  >
>  > The only advantage of (1) is we do not have to spend time on learning new things. On the
>  > other hand
>  > I do not like keeping software artefacts in git because it has impact on its size and
>  > performance.
>
> I'm not sure whether this will reduce the repo size since we won't get
> rid of older artifacts, but it's certainly good practice.


It depends on what we want.
After switching to gradle we could create a new repository which could contain all the history
excluding the jars. It would dramatically decrease first cloning time.

Anyway I suggest that we consider this option.

>  > So I think later we could start to do like (2) or (3) or its combination like upload
>  > SimplyHTML to
>  > the central repository and create for JMapView some separate repository.
>
> I don't have a strong opinion about this. Here are some thoughts:
>
> - I don't think we can apply (3) to jsyntaxpane-0.9.6~r156-5 (patched
>    Debian version), because it's not a released version
>
> - I'd prefer to have only (2) or (3) but not both
>
> - It will be difficult to get the JMapViewer maintainers to do (3)
>    (it took me half a year to convince them of versioned releases ;-))
>
> - if we decide to do (2) or (3), then I think (2) is the easiest option
>    if it can be done in our github group

I would contribute SimpleHTML to (3) and
write to JMapViewer maintainers to do (3)

I have no idea about patched debian versions. They are not relevant for our build, are they?

Regards,
Dimitry



 

If you reply to this email, your message will be added to the discussion below:
http://freeplane-developer.996965.n3.nabble.com/Guidelines-for-adding-upgrading-dependencies-tp615p619.html
To start a new topic under Freeplane Developer, email [hidden email]
To unsubscribe from Freeplane Developer, click here.
NAML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Aw: Re: Guidelines for adding/upgrading dependencies

Dimitry Polivaev
Administrator
On 03.02.2015 08:17, Felix Natter [via Freeplane Developer] wrote:
> hello Dimitry,
>  > I would contribute SimpleHTML to (3) and
>  > write to JMapViewer maintainers to do (3)
> The problem with JMapViewer is that the latest 1.05 release requires Java7.
> --> do we want to require Java7 for Freeplane 1.4?
> IMHO that is ok, unless some Mac versions only have Java6.

I think it is OK too.

>  > I have no idea about patched debian versions. They are not relevant for our build, are they?
> The usual workflow is that I add a patch to the Debian jsyntaxpane package
> (currently at jsyntaxpane-0.9.6~r156-5) and commit the result to freeplane-git.

 > There is no upstream for jsyntaxpane any more.

I would suggest to fork the project and to contribute it to (3) if the project itself is dead.
I would keep your changes in a separate project and not as a part of Freeplane git repo.

We do not have to do it immediately, only when somebody has time and good will.

Dimitry
Loading...