search

ctron / package-drone

An OSGI first software artifact repository – Moved to the Eclipse Foundation
https://github.com/eclipse/packagedrone
Eclipse Public License 1.0
39 stars 13 forks source link

mvnosgi: use group id of channel meta data #86

Closed maggu2810 closed 9 years ago

maggu2810 commented 9 years ago

See last comments of #81

maggu2810 commented 9 years ago

For the configuration web UI of mvnosgi there is no the category "Maven POM Creator". The channel aspect aready contains the description: Create Maven POM files based on the contained OSGi information. Is this ok, to keep it "Maven POM Creator" or should we name this "Maven POM by OSGi Creator".

Just want to ensure that it is clear that the POM is created using OSGi information only and does nothing for non-OSGi artifacts.

For someone you does not know that Maven stores the pom in the jar themselves your extractor is perhaps categorized to be a POM creator, too.

maggu2810 commented 9 years ago

Comment taken from the older PR: If I change the group id using http://127.0.0.1:8080/aspect/mvnosgi//config the validate process of the aspect should be started, a task should be created or a message box should inform the user that the group id is only changed, if he refreshes the channel aspect (IMHO it is enough to inform the user if the automatic triggered regeneration is to complicated).

maggu2810 commented 9 years ago

So, will change the remaining stuff tomorrow -- if there is something to change (wait for your reply of the last three comments). After that the aspect (first version, creation of pom with GAV) is finished IMHO and ready for testing.

ctron commented 9 years ago

I hope I got this right.

So when the group ID is changed the channel is automatically processed.

Only when the logic changes by a software update it is necessary to update the aspect version and do the recreate task.

maggu2810 commented 9 years ago
ctron commented 9 years ago

So I can pull it?

maggu2810 commented 9 years ago

This change should be fine, you can pull it.

ctron commented 9 years ago

So the only thing missing is that fact that the "Maven Extractor" actually does two things which conflict in this case.

So the maven extractor should be refactored to only extract the POM file and the second function, extract the maven metadata from a POM file, should be separate.

I will prepare this in the master branch by splitting of the POM file extraction into a new aspect.