Re: Deployment
Literally *just* stumbled across Bintray: https://bintray.com/beta Best, Laird On Fri, Mar 1, 2013 at 9:33 PM, Wayne Fay wrote: > > I was not thinking of adding to Maven, rather I was soliciting insight > > from the Maven community because I value their inventiveness. > > > > I am half way toying with the idea of building something myself, but > > first I want to make sure I am not reinventing the wheel. > > Sounds like you have some good ideas. I'd check to make sure Puppet > and Chef don't have some recipes you could build on top of to help you > down this path before doing any building from scratch. We use puppet @ > work pretty extensively but mostly on the sysadmin side and less on > the middleware/apps side - we are not a devops shop. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- http://about.me/lairdnelson
Re: Deployment
> I was not thinking of adding to Maven, rather I was soliciting insight > from the Maven community because I value their inventiveness. > > I am half way toying with the idea of building something myself, but > first I want to make sure I am not reinventing the wheel. Sounds like you have some good ideas. I'd check to make sure Puppet and Chef don't have some recipes you could build on top of to help you down this path before doing any building from scratch. We use puppet @ work pretty extensively but mostly on the sysadmin side and less on the middleware/apps side - we are not a devops shop. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment
I was not thinking of adding to Maven, rather I was soliciting insight from the Maven community because I value their inventiveness. I am half way toying with the idea of building something myself, but first I want to make sure I am not reinventing the wheel. I have been toying with the idea for a while as a software developer who has had to build installers for applications and services, and I am often dissatisfied with the experience I get using other people's installers. At one time I was playing with the idea of my own installer that would be cross platform, but the initial bootstrap would be platform dependent, and install enough platform independent stuff, to do the rest in a standard way. For example, a couple years ago I built an installer for a service I was working on. It is a very simple .NET Setup.exe, single file executable. The first thing it does is make sure there is a JVM present, and installs one if there is not. The next thing is does is creates a Windows Service. The Windows Service is very simple, it uses jni4net and starts up a file called service.jar, which then completed the rest of the installation. The whole thing used fat binaries so it worked on a variety of Windows platforms, both 32-bit and 64-bit. For OSX and Linux I had intended a similar simple executable, that in turn launched the same service.jar. The part I was not too happy with was my service.jar was this ginormous uber-jar created with the Assembly plug-in. Sure, everything worked perfectly well, and was simple, but when I say ginormous I am very serious. If I had had the time, the next thing I was going to do was have my installer install Maven, and then bootstrap the rest of the pieces by just choosing the right artifact names and versions given the system environment I found. Basically, replace the uber-jar with a common system-wide repository of jars, and configure the classpath appropriately. I am just thinking out loud and trying to get ideas from people. Cheers, Eric On 2013-03-01 5:31 PM, Ron Wheeler wrote: My feeling is that this would be a major addition to Maven and would still be missing a lot of stuff. It looks more like a CMS with some rules and some processes that construct a zip or an installer. You need a lot of flexibility in defining how assets are assembled into the required artifact. Of course, one could extend Maven but it would almost be a complete rewrite. I think that we would be better served by looking at what Maven does well and specifying a downstream process that incorporates the ideas that you identified below but into a system that focuses on deployment. It probably will attract a different type of person to the project. I would expect that the Maven team is heavily weighted towards developers as committers. The design and implementation of this new facility should be driven by system administrators and infrastructure support types who spend their days making applications run in production. Ron On 01/03/2013 8:06 PM, Eric Kolotyluk wrote: Thanks for the pointers Stephen,... http://wiki.opscode.com/display/chef/Chef+Basics https://puppetlabs.com/puppet/what-is-puppet/ Ron,... Yes, I remember that deployment was outside the scope of Maven, but one of the things I like about Maven is the repository concept. I was advocating extending this concept from the development realm to the deployment realm sort of the way Microsoft's Global Assembly Cache (GAC) works, but for open-source artifacts. In particular, we could leverage existing technology and tools such as Maven, Nexus, Maven Central, etc. For example, in terms of bootstrapping, you might have a simple open-source installer the checks to see if there exists a local system or network GAR (Global Artifact Repository), and if not, creates one. Then it follows an embedded script, or remote script via URI, to start populating the GAR with the artifacts needed. Finally, when it starts deploying actual applications and services, it can simply build a classpath by referencing locations in the GAR. I was installing Akka recently, and it seemed to be doing something similar to what I was looking for. There was a small bootstrap installers, that just kept pulling more and more stuff in. I have a project that is Maven based, and every time I setup my development environment on a new system, I am simply amazed while I watch Maven download hundreds of artifacts, and then it just builds my project. I would like to have this kind of awesome experience in production deployment tools. Cheers, Eric On 2013-03-01 2:07 PM, Ron Wheeler wrote: On 01/03/2013 4:26 PM, Eric Kolotyluk wrote: A while back we had some interesting discussions on using Maven, or maven-like technology for deploying production software. I was wondering if anything new has been happening since then. Basically what I am hoping to see is a generic installer framework that bootstraps deploy
Re: Deployment
My feeling is that this would be a major addition to Maven and would still be missing a lot of stuff. It looks more like a CMS with some rules and some processes that construct a zip or an installer. You need a lot of flexibility in defining how assets are assembled into the required artifact. Of course, one could extend Maven but it would almost be a complete rewrite. I think that we would be better served by looking at what Maven does well and specifying a downstream process that incorporates the ideas that you identified below but into a system that focuses on deployment. It probably will attract a different type of person to the project. I would expect that the Maven team is heavily weighted towards developers as committers. The design and implementation of this new facility should be driven by system administrators and infrastructure support types who spend their days making applications run in production. Ron On 01/03/2013 8:06 PM, Eric Kolotyluk wrote: Thanks for the pointers Stephen,... http://wiki.opscode.com/display/chef/Chef+Basics https://puppetlabs.com/puppet/what-is-puppet/ Ron,... Yes, I remember that deployment was outside the scope of Maven, but one of the things I like about Maven is the repository concept. I was advocating extending this concept from the development realm to the deployment realm sort of the way Microsoft's Global Assembly Cache (GAC) works, but for open-source artifacts. In particular, we could leverage existing technology and tools such as Maven, Nexus, Maven Central, etc. For example, in terms of bootstrapping, you might have a simple open-source installer the checks to see if there exists a local system or network GAR (Global Artifact Repository), and if not, creates one. Then it follows an embedded script, or remote script via URI, to start populating the GAR with the artifacts needed. Finally, when it starts deploying actual applications and services, it can simply build a classpath by referencing locations in the GAR. I was installing Akka recently, and it seemed to be doing something similar to what I was looking for. There was a small bootstrap installers, that just kept pulling more and more stuff in. I have a project that is Maven based, and every time I setup my development environment on a new system, I am simply amazed while I watch Maven download hundreds of artifacts, and then it just builds my project. I would like to have this kind of awesome experience in production deployment tools. Cheers, Eric On 2013-03-01 2:07 PM, Ron Wheeler wrote: On 01/03/2013 4:26 PM, Eric Kolotyluk wrote: A while back we had some interesting discussions on using Maven, or maven-like technology for deploying production software. I was wondering if anything new has been happening since then. Basically what I am hoping to see is a generic installer framework that bootstraps deployment of a production system or service the way Maven bootstraps a development environment. Can anyone point me to anything happening on that front? Cheers, Eric My recollection of the conversation is that deployment is outside the scope of Maven and there are other tools that approach this from a more effective base functionality. Maven works best at giving you 1 artifact for a project whereas deployment needs to be able to generate a whole set of artifacts based on configurations that include - software artifacts - configuration files - branding - documentation - release notes - license agreements - installer each of which may have to be customized for each client or each deployment architecture(OS, database, etc.) or each deployment environment(production, test, QA) . Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment
Thanks for the pointers Stephen,... http://wiki.opscode.com/display/chef/Chef+Basics https://puppetlabs.com/puppet/what-is-puppet/ Ron,... Yes, I remember that deployment was outside the scope of Maven, but one of the things I like about Maven is the repository concept. I was advocating extending this concept from the development realm to the deployment realm sort of the way Microsoft's Global Assembly Cache (GAC) works, but for open-source artifacts. In particular, we could leverage existing technology and tools such as Maven, Nexus, Maven Central, etc. For example, in terms of bootstrapping, you might have a simple open-source installer the checks to see if there exists a local system or network GAR (Global Artifact Repository), and if not, creates one. Then it follows an embedded script, or remote script via URI, to start populating the GAR with the artifacts needed. Finally, when it starts deploying actual applications and services, it can simply build a classpath by referencing locations in the GAR. I was installing Akka recently, and it seemed to be doing something similar to what I was looking for. There was a small bootstrap installers, that just kept pulling more and more stuff in. I have a project that is Maven based, and every time I setup my development environment on a new system, I am simply amazed while I watch Maven download hundreds of artifacts, and then it just builds my project. I would like to have this kind of awesome experience in production deployment tools. Cheers, Eric On 2013-03-01 2:07 PM, Ron Wheeler wrote: On 01/03/2013 4:26 PM, Eric Kolotyluk wrote: A while back we had some interesting discussions on using Maven, or maven-like technology for deploying production software. I was wondering if anything new has been happening since then. Basically what I am hoping to see is a generic installer framework that bootstraps deployment of a production system or service the way Maven bootstraps a development environment. Can anyone point me to anything happening on that front? Cheers, Eric My recollection of the conversation is that deployment is outside the scope of Maven and there are other tools that approach this from a more effective base functionality. Maven works best at giving you 1 artifact for a project whereas deployment needs to be able to generate a whole set of artifacts based on configurations that include - software artifacts - configuration files - branding - documentation - release notes - license agreements - installer each of which may have to be customized for each client or each deployment architecture(OS, database, etc.) or each deployment environment(production, test, QA) . Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment
On 01/03/2013 4:26 PM, Eric Kolotyluk wrote: A while back we had some interesting discussions on using Maven, or maven-like technology for deploying production software. I was wondering if anything new has been happening since then. Basically what I am hoping to see is a generic installer framework that bootstraps deployment of a production system or service the way Maven bootstraps a development environment. Can anyone point me to anything happening on that front? Cheers, Eric My recollection of the conversation is that deployment is outside the scope of Maven and there are other tools that approach this from a more effective base functionality. Maven works best at giving you 1 artifact for a project whereas deployment needs to be able to generate a whole set of artifacts based on configurations that include - software artifacts - configuration files - branding - documentation - release notes - license agreements - installer each of which may have to be customized for each client or each deployment architecture(OS, database, etc.) or each deployment environment(production, test, QA) . Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment
Chef or puppet? On Friday, 1 March 2013, Eric Kolotyluk wrote: > A while back we had some interesting discussions on using Maven, or > maven-like technology for deploying production software. I was wondering if > anything new has been happening since then. > > Basically what I am hoping to see is a generic installer framework that > bootstraps deployment of a production system or service the way Maven > bootstraps a development environment. > > Can anyone point me to anything happening on that front? > > Cheers, Eric >
AW: Is there any generic Maven code generator?
Well I guess, I will eventually whip up such a plugin myself, cause I really
need to cleanup quite a code-generation mess.
Eventually based upon the GraniteDS libs, as does the Flexmojos plugin.
Chris
-Ursprüngliche Nachricht-
Von: bmat...@gmail.com [mailto:bmat...@gmail.com] Im Auftrag von Baptiste MATHUS
Gesendet: Freitag, 1. März 2013 08:02
An: Maven Users List
Betreff: Re: Is there any generic Maven code generator?
The following is not going to really help you, but I just wanted to point out
that a plugin was recently initiated at mojo (still in the sandbox) dedicated
to templating (called templating-maven-plugin).
It's currently only supporting Maven sources filtering, but the plan is to
support different templating engines like velocity or mustache for example.
Cheers
Le 28 févr. 2013 12:17, "Anders Hammar" a écrit :
> I haven't seen any generator plugin that does what you're looking for.
>
> Wearing a Maven hat, I don't think that having these stub classes
> generated to src/main/java belongs to the build lifecycle. It's a
> separate process that should be executed outside of a Maven build. SO
> you would then have a separate goal for that is not bound to a phase by
> default.
>
> /Anders
>
>
> On Thu, Feb 28, 2013 at 10:57 AM, christofer.d...@c-ware.de <
> christofer.d...@c-ware.de> wrote:
>
> > Ahem ... this wasn't quite the path I was indenting to go with my
> question.
> >
> > What I am looking for is a generator-plugin that uses a template
> > engine (such as Velocity) to generate code, and uses as input an
> > pojo-object
> model
> > representing the details of a Java class that it should generate
> > code
> for.
> >
> > Now I would like to have (or create, if I have to) a plugin, that
> > allows me to specify which classes I am addressing using some
> > include/exclude config.
> >
> > I could configure different include/exclude groups, each one in one
> > execution and for each I could provide a set of:
> > - resourceTemplates
> > - testResourceTemplates
> > - sourceStubTemplates
> > - sourceTemplates
> > - testSourceStubTemplates
> > - testSourceTemplates
> > - ...
> > So for each matched class, I could generage:
> > - resources into the target/generated-resources directory using the
> > resourceTemplates (could be more than one)
> > - testResources into the target/generates-test-resources directory
> > using the testResourceTemplates, ...
> > - source code into target/generated-sources ...
> > - test source code into target/generated-test-sources ...
> >
> > One speciality I liked with GraniteDS was the ability to have
> > auto-generated stub-classes generated in src/main/java ... if a
> > class allready existed, no code would be generated, but if a class
> > didn't
> exist,
> > it would be generated. This was great for creating classes that
> > extend other generated classes and to allow customization. Something
> > simple as
> > this:
> >
> > public class MyClass extends MyClassBase { }
> >
> > And MyClassBase is generated to target/generated-sources.
> >
> > With such a plugin I could be able to generate my JPA MetaModel
> > classes, my DTOs, SQL scripts, ... and wouldn't have to configure
> > thousands of different generators. People could develop
> > best-practice templates for general purpose tasks.
> >
> > Hope this clarified, what I was looking for.
> >
> > If nothing similar exists, I would like to start developing
> > something
> like
> > this, because I think it would make my life a lot easier.
> >
> > Chris
> >
> >
> > Von: Stadelmann Josef [josef.stadelm...@axa-winterthur.ch]
> > Gesendet: Donnerstag, 28. Februar 2013 09:52
> > An: Maven Users List
> > Betreff: AW: Is there any generic Maven code generator?
> >
> > A code generator needs input. Hence some "generic formal language"
> > is
> used
> > to specify the input to the genric code generator? UML?
> > Visualization of
> a
> > generic language could mean - speak UML, UML is a reality today. UML
> > modells can says much more then 1000 words? Hence I opt for better
> > integration of modelling tools with maven. Also roundtrip
> > engineering is
> a
> > must. Enterprise Architect (EA) is able to generate code from UML
> > and
> other
> > diagrams for many target compiler and it helps you to have code,
> > modell
> and
> > documentation in sync. And EA can be feed with code and generates
> > your diagramms. A task which only ends when the modells become to complex.
> Maven
> > is much about geting and nailing dependent components together. If
> > maven finds the dependecies, a tool like EA could use input to draw
> > i.e. the component diagram, maybe a maven plugin can pave the way
> > for EA. Other whise, in my mind, there are far too many tools around
> > and I get to often the feeling that each time a problem developes,
> > folk starts to seek a
> tool
> > to avoid some brain work. So if one knows in which aspects maven
> > pom
Re: Antwort: Re: Maven Shade Plugin
Joachim Durchholz wrote on 03/01/2013 07:08:52 AM: > > The complete coordinates of an artifact are GAVTC: group, > > artifact(name), version, type (default is jar), classifier (default is > > empty). > > Hm. Can I specify the type in a dependency as well? > Just curious, I certainly don't want to do that, but I might stumble > over artifacts configured that way. Yes, I do this quite often when I have projects that produce secondary artifacts for use as WAR overlays. --JEC
Re: Re: Re: Antwort: Re: Maven Shade Plugin
> Hmmm, I don't understand this. I will have an more or less empty jar in my > nexus then, which is useless and there for no reason? For what reason does > that file exists then? Most like you are missing a configuration of the shade plugin: shadedArtifactAttached boolean - Defines whether the shaded artifact should be attached as classifier to the original artifact. If false, the shaded jar will be the main artifact of the project http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#shadedArtifactAttached Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: Maven Shade Plugin
On 1 March 2013 15:03, Joachim Durchholz wrote: > Am 01.03.2013 14:59, schrieb Stephen Connolly: > > On 1 March 2013 12:08, Joachim Durchholz wrote: >> >> Am 01.03.2013 07:17, schrieb Tim Kettler: >>> >>> That's not correct. The classifier is part of the artifact coordinates >>> just like group, artifact(name) and version. >>> I knew. I just didn't want to contradict Stephen right away. >>> >> >> The real issue is that the "classified" artifact will probably have >> different transitive dependencies from the "primary", and hence the only >> way to handle that is to use a separate module... plus I get tire of all >> the 'splainin' >> > > Let others do it then. > Sometimes I just need to respond ;-) > Even better, improve the Maven docs. It's on my TODO list (see the dev list) > > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Antwort: Re: Maven Shade Plugin
Am 01.03.2013 14:59, schrieb Stephen Connolly: On 1 March 2013 12:08, Joachim Durchholz wrote: Am 01.03.2013 07:17, schrieb Tim Kettler: That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. I knew. I just didn't want to contradict Stephen right away. The real issue is that the "classified" artifact will probably have different transitive dependencies from the "primary", and hence the only way to handle that is to use a separate module... plus I get tire of all the 'splainin' Let others do it then. Even better, improve the Maven docs. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: Maven Shade Plugin
On 1 March 2013 12:08, Joachim Durchholz wrote: > Am 01.03.2013 07:17, schrieb Tim Kettler: > > That's not correct. The classifier is part of the artifact coordinates >> just like group, artifact(name) and version. >> > > I knew. I just didn't want to contradict Stephen right away. The real issue is that the "classified" artifact will probably have different transitive dependencies from the "primary", and hence the only way to handle that is to use a separate module... plus I get tire of all the 'splainin' > Plus, classifiers are usually assumed to identify auxiliary artifacts for > a main artifact, and I suspect it's going to create lots of configuration > overhead in some plugins. > Jörg promptly pointed out a problem that doesn't even involve plugins. > > > > A POM can just as well > >> depend on a secondary artifact: >> >> >> foo >> bar >> 1.0 >> api >> >> > > > >> The complete coordinates of an artifact are GAVTC: group, >> artifact(name), version, type (default is jar), classifier (default is >> empty). >> > > Hm. Can I specify the type in a dependency as well? > Just curious, I certainly don't want to do that, but I might stumble over > artifacts configured that way. > > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Antwort: Re: Re: Antwort: Re: Maven Shade Plugin
Hmmm, I don't understand this. I will have an more or less empty jar in my nexus then, which is useless and there for no reason? For what reason does that file exists then? Jan Mit freundlichen Grüßen / Best regards Jan Engler Central Research & Development SICK AG Erwin-Sick-Str. 1 79183 Waldkirch, Germany Phone +49 7681 202-3214 mailto:jan.eng...@sick.de http://www.sick.com Von:Wayne Fay An: Maven Users List Datum: 01.03.2013 14:00 Betreff:Re: Re: Antwort: Re: Maven Shade Plugin > working with a split-up build project seems to work. The only problem that > I face in the moment is that there is not only my 2 shaded jars (api and > api-sources) but also a file called "original-api.jar". The content of > this jar is only the meta-inf folder and I don't want this file to be > placed in my nexusAny hints? Yes, put it in Nexus even though you "don't want to." Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Martin Krämer - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender)
Re: Re: Antwort: Re: Maven Shade Plugin
> working with a split-up build project seems to work. The only problem that > I face in the moment is that there is not only my 2 shaded jars (api and > api-sources) but also a file called "original-api.jar". The content of > this jar is only the meta-inf folder and I don't want this file to be > placed in my nexusAny hints? Yes, put it in Nexus even though you "don't want to." Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: Maven Shade Plugin
Am 01.03.2013 07:17, schrieb Tim Kettler: That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. I knew. I just didn't want to contradict Stephen right away. Plus, classifiers are usually assumed to identify auxiliary artifacts for a main artifact, and I suspect it's going to create lots of configuration overhead in some plugins. Jörg promptly pointed out a problem that doesn't even involve plugins. > A POM can just as well depend on a secondary artifact: foo bar 1.0 api > The complete coordinates of an artifact are GAVTC: group, artifact(name), version, type (default is jar), classifier (default is empty). Hm. Can I specify the type in a dependency as well? Just curious, I certainly don't want to do that, but I might stumble over artifacts configured that way. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Antwort: Re: Antwort: Re: Maven Shade Plugin
Ok, working with a split-up build project seems to work. The only problem that I face in the moment is that there is not only my 2 shaded jars (api and api-sources) but also a file called "original-api.jar". The content of this jar is only the meta-inf folder and I don't want this file to be placed in my nexusAny hints? Best, Jan Mit freundlichen Grüßen / Best regards Jan Engler Central Research & Development SICK AG Erwin-Sick-Str. 1 79183 Waldkirch, Germany Phone +49 7681 202-3214 mailto:jan.eng...@sick.de http://www.sick.com Von:Tim Kettler An: Maven Users List Datum: 01.03.2013 09:49 Betreff:Re: Antwort: Re: Maven Shade Plugin Am 01.03.2013 08:26, schrieb Jörg Schaible: > Hi Tim, > > Tim Kettler wrote: > >> Am 28.02.2013 19:47, schrieb Joachim Durchholz: >>> Am 28.02.2013 16:24, schrieb Jan Engler: At first: in fact this is only one artifact. The full jar contains all classes of the dependecies, the api a reduced set (using filtern in the shade plugin). >>> >>> Is there a (conceivable) Maven build that uses api.jar as a dependency? >>> Then it must be the main artifact at its GAV (groupId/artifact/version) >>> coordinate. >>> >>> Is there a (conceivable) Maven build that uses full.jar as a dependency? >>> Then it must be the main artifact at its GAV coordinate. >>> >>> If both jars need to be main artifacts, they need to go to different GAV >>> coordinates. Because the dependent projects that need either api.jar or >>> full.jar have no way of specifying which of them they actually need, the >>> dependency section in their poms can only specify the GAV coordinate. >> >> That's not correct. The classifier is part of the artifact coordinates >> just like group, artifact(name) and version. A POM can just as well >> depend on a secondary artifact: >> >> >> foo >> bar >> 1.0 >> api >> >> >> The complete coordinates of an artifact are GAVTC: group, >> artifact(name), version, type (default is jar), classifier (default is >> empty). > > That's not the real problem. What actually *is* a problem, if you depend on > different artifacts that bring both jars as transitive dependencies - you > cannot exclude e.g. the -api, because for exclusions you can only specify > GA. :-/ Ouch, never ran into this one. > - Jörg -Tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Martin Krämer - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender)
Re: Antwort: Re: Maven Shade Plugin
Am 01.03.2013 08:26, schrieb Jörg Schaible: Hi Tim, Tim Kettler wrote: Am 28.02.2013 19:47, schrieb Joachim Durchholz: Am 28.02.2013 16:24, schrieb Jan Engler: At first: in fact this is only one artifact. The full jar contains all classes of the dependecies, the api a reduced set (using filtern in the shade plugin). Is there a (conceivable) Maven build that uses api.jar as a dependency? Then it must be the main artifact at its GAV (groupId/artifact/version) coordinate. Is there a (conceivable) Maven build that uses full.jar as a dependency? Then it must be the main artifact at its GAV coordinate. If both jars need to be main artifacts, they need to go to different GAV coordinates. Because the dependent projects that need either api.jar or full.jar have no way of specifying which of them they actually need, the dependency section in their poms can only specify the GAV coordinate. That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. A POM can just as well depend on a secondary artifact: foo bar 1.0 api The complete coordinates of an artifact are GAVTC: group, artifact(name), version, type (default is jar), classifier (default is empty). That's not the real problem. What actually *is* a problem, if you depend on different artifacts that bring both jars as transitive dependencies - you cannot exclude e.g. the -api, because for exclusions you can only specify GA. :-/ Ouch, never ran into this one. - Jörg -Tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Antwort: Re: Antwort: Re: Maven Shade Plugin
Hi, To prevent any problems, I have now split up the build into two builds (api-build and full-jar). I think I will introduce now a third project (with pom packaging) that will build up all modules and collect the artifacts that are needed. I hope that is a correct strategy to solve the problem. I would like to reuse the api.jar and the full.jar as artifacts that can be used as dependencies, therefore I take Jörg's comment into account, thanks! Best, Jan Mit freundlichen Grüßen / Best regards Jan Engler Central Research & Development SICK AG Erwin-Sick-Str. 1 79183 Waldkirch, Germany Phone +49 7681 202-3214 mailto:jan.eng...@sick.de http://www.sick.com Von:Jörg Schaible An: users@maven.apache.org Datum: 01.03.2013 08:27 Betreff:Re: Antwort: Re: Maven Shade Plugin Hi Tim, Tim Kettler wrote: > Am 28.02.2013 19:47, schrieb Joachim Durchholz: >> Am 28.02.2013 16:24, schrieb Jan Engler: >>> At first: in fact this is only one artifact. The full jar contains all >>> classes of the dependecies, the api a reduced set (using filtern in the >>> shade plugin). >> >> Is there a (conceivable) Maven build that uses api.jar as a dependency? >> Then it must be the main artifact at its GAV (groupId/artifact/version) >> coordinate. >> >> Is there a (conceivable) Maven build that uses full.jar as a dependency? >> Then it must be the main artifact at its GAV coordinate. >> >> If both jars need to be main artifacts, they need to go to different GAV >> coordinates. Because the dependent projects that need either api.jar or >> full.jar have no way of specifying which of them they actually need, the >> dependency section in their poms can only specify the GAV coordinate. > > That's not correct. The classifier is part of the artifact coordinates > just like group, artifact(name) and version. A POM can just as well > depend on a secondary artifact: > > > foo > bar > 1.0 > api > > > The complete coordinates of an artifact are GAVTC: group, > artifact(name), version, type (default is jar), classifier (default is > empty). That's not the real problem. What actually *is* a problem, if you depend on different artifacts that bring both jars as transitive dependencies - you cannot exclude e.g. the -api, because for exclusions you can only specify GA. :-/ - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Martin Krämer - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender)
